Re: [gentoo-user] tuning ./configure parameters via emerge
Nicolas Sebrecht schrieb: Justin Findlay <[EMAIL PROTECTED]> a écrit: You probably just need to set it in your /etc/make.conf. make.conf is just a bunch of bash variables anyway. Hmmm. If I do that, it will be applied to all ebuilds. You can set it in /etc/portage/env//. There you set every variable portage knows and overwrite the default value. I always use this to use package specific CFLAGS, FFLAGS, fortran compiler and else. If it doesn't work directly try to set an export in front. For some strange reason, this has to be done in many cases for switching the F77 variable. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] VLC segfaults at the end of audio cds
Peter Wood <[EMAIL PROTECTED]> a écrit: > I tried with a few CDs and always get the same result. > Does anybody know how to fix this? I think you should do a bug report. -- Nicolas Sebrecht -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Cleaning up installation / two glibc versions
Nicolai Beuermann <[EMAIL PROTECTED]> a écrit: > Again > the result was an unbootable system. What is the error exactly ? -- Nicolas Sebrecht -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] tuning ./configure parameters via emerge
Nicolas Sebrecht <[EMAIL PROTECTED]> a écrit: > Hmmm. If I do that, it will be applied to all ebuilds. Or not applied at all. As far as I know make.conf isn't "dumped sourced" by the shell (nor by emerge). -- Nicolas Sebrecht -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] tuning ./configure parameters via emerge
Justin Findlay <[EMAIL PROTECTED]> a écrit: > You probably just need to set it in your /etc/make.conf. make.conf is > just a bunch of bash variables anyway. Hmmm. If I do that, it will be applied to all ebuilds. -- Nicolas Sebrecht -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] tuning ./configure parameters via emerge
On AD 2008 June 10 Tuesday 02:12:10 AM +0200, Nicolas Sebrecht wrote: > I didn't know that. If I can use it as a replacement for the "make > ebuild" solution, I don't think I can make it permanent (I mean like > package.use for choices about useflags). > > The idea is to have $EXTRA_ECONF value relevant to next updates. > > Is it possible to do that ? You probably just need to set it in your /etc/make.conf. make.conf is just a bunch of bash variables anyway. Justin -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] tuning ./configure parameters via emerge
Alan McKinnon <[EMAIL PROTECTED]> a écrit: > man 5 ebuild > > Search for EXTRA_ECONF Thanks Alan for your answer. I didn't know that. If I can use it as a replacement for the "make ebuild" solution, I don't think I can make it permanent (I mean like package.use for choices about useflags). The idea is to have $EXTRA_ECONF value relevant to next updates. Is it possible to do that ? -- Nicolas Sebrecht -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Cleaning up installation / two glibc versions
On 09.06.2008 19:10:53, Alan McKinnon wrote: > On Monday 09 June 2008, Nicolai Beuermann wrote: > > After I'd reemerged listed packages the equery command from above > > still lists the dependencies. > > > > what goes wrong? > The definitive way to find out exactly what is going on is to run emerge > with the -t option and see from that what is pulling a package in. I've run "emerge -tevp" (or similar) on the packages "equery depends =sys-libs/glibc-2.3.4" reports. All of sys related ebuilds among others show a dependency to glibc-2.6.1. I thought that was a good sign and unmerged old glibc-2.3.4. Again the result was an unbootable system. So for now, i am where i started. Any ideas? thanks -- mailto: [EMAIL PROTECTED] http://www.nico-beuermann.de gnupg fingerprint: 56DA 4E32 3A4A 52AC B769 DFC2 BF3E 9805 09BB 4259 -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Problems mounting Nikon D40 Camera, vfat FS issue?
quoth the Hal Martin: > > If you'd like, I can post my kernel config and you can look for > differences between them. Not neccesary. I tried on another Gentoo system and it worked fine. Comparing .config files shows I didn't have "Codepage 437 (United States, Canada) " selected in the problem machine. > > Thanks for consideration, > > -d > > -Hal Thanks, -d -- darren kirby :: Part of the problem since 1976 :: http://badcomputer.org "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Problems mounting Nikon D40 Camera, vfat FS issue?
darren kirby wrote: Hello all, Trying for the first time to download images from a new Nikon D40 camera. libgphoto2 lists the camera as supported in PTP mode. I have tried using PTP mode with digikam (hooking up the camera directly), and also simply trying to mount the memory card using a card reader. Both methods fail. The card is recognized: usb 1-5: new high speed USB device using ehci_hcd and address 2 usb 1-5: configuration #1 chosen from 1 choice scsi6 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0001 PQ: 0 ANSI: 0 sd 6:0:0:0: [sdc] Attached SCSI removable disk sd 6:0:0:0: Attached scsi generic sg3 type 0 usb-storage: device scan complete sd 6:0:0:0: [sdc] 3970048 512-byte hardware sectors (2033 MB) sd 6:0:0:0: [sdc] Write Protect is off sd 6:0:0:0: [sdc] Mode Sense: 02 00 00 00 sd 6:0:0:0: [sdc] Assuming drive cache: write through sd 6:0:0:0: [sdc] 3970048 512-byte hardware sectors (2033 MB) sd 6:0:0:0: [sdc] Write Protect is off sd 6:0:0:0: [sdc] Mode Sense: 02 00 00 00 sd 6:0:0:0: [sdc] Assuming drive cache: write through sdc: sdc1 usb 1-4: new high speed USB device using ehci_hcd and address 8 usb 1-4: configuration #1 chosen from 1 choice scsi7 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 8 usb-storage: waiting for device to settle before scanning scsi 7:0:0:0: Direct-Access NIKOND40 1.10 PQ: 0 ANSI: 2 sd 7:0:0:0: [sdc] 3970048 512-byte hardware sectors (2033 MB) sd 7:0:0:0: [sdc] Write Protect is off sd 7:0:0:0: [sdc] Mode Sense: 0f 00 00 00 sd 7:0:0:0: [sdc] Assuming drive cache: write through sd 7:0:0:0: [sdc] 3970048 512-byte hardware sectors (2033 MB) sd 7:0:0:0: [sdc] Write Protect is off sd 7:0:0:0: [sdc] Mode Sense: 0f 00 00 00 sd 7:0:0:0: [sdc] Assuming drive cache: write through sdc: sdc1 sd 7:0:0:0: [sdc] Attached SCSI removable disk sd 7:0:0:0: Attached scsi generic sg2 type 0 usb-storage: device scan complete Attempts in PTP mode fail with digikam reporting "Failed to connect to the camera. Please make sure it is connected properly and turned on". The camera itself reports that it is connected to the computer properly. When directly mounting I get: # mount -t vfat /dev/sdc1 /mnt/camera mount: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so Works on my D40. I haven't tried with digikam though, as I prefer to use direct file access. I assume that if mounting the card works, PTP should as well. I have these lines in my dmesg whenever I try to mount it, or use PTP mode: Unable to load NLS charset cp437 FAT: codepage cp437 not found In my kernel config I have this: (437) Default codepage for FAT So, is there something else I need to get this codepage? The camera appears to be detected just fine, and the issue seems to be directly related to mounting the vfat filesystem and this missing codepage... Just to note: It is a stable amd64 Gentoo system, and I do have vfat module loaded when I attempt to mount. I am on the same arch and have the module fat and vfat loaded. Kernel version 2.6.23-gentoo-r6. Any other ideas? Use an SD card reader, pull your data off, then format the card again? If you'd like, I can post my kernel config and you can look for differences between them. Thanks for consideration, -d -Hal -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] tuning ./configure parameters via emerge
On Monday 09 June 2008, Nicolas Sebrecht wrote: > Hi, > > I would like to compile a soft by passing some available options > to ./configure. > > I'm currently pretty sure I have to build my own ebuild. I don't > enjoy because of further maintenance. > > Is there any way to do it with the classical emerge program ? man 5 ebuild Search for EXTRA_ECONF -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] vixie cron
On Sat, Jun 7, 2008 at 1:12 AM, Teng Wang <[EMAIL PROTECTED]> wrote: > Hi there, > > I am using vixie cron to maintain my scheduled > jobs. Everything is just fine other than one. I find that > when I use, for example, 0 * * * * /usr/bin/eix-sync to > update the portage everyday, the cron works without any > problem. But I was told by manpage I could still use @daily > instead. So I tried but failed. The system does nothing at > all. It is not a big issue, but I just want to make > sure it has nothing to do with my setting. Furthermore, I > still want to start some program like fetchmail after > reboot. Then I put @reboot in crontab. I also tried, and > failed. Does anybody have any idea about this? > > Best, > -- > Teng Wang > -- > gentoo-user@lists.gentoo.org mailing list > > There should be a single text file in /etc/cron.daily/ with the command you want to run daily. Like this: $ cat /etc/cron.daily/esync /usr/bin/esync You also may need to make the file executable, so chmod +x /etc/cron.daily/esync. Mine syncs daily with this command. -- - Mark Shields
[gentoo-user] tuning ./configure parameters via emerge
Hi, I would like to compile a soft by passing some available options to ./configure. I'm currently pretty sure I have to build my own ebuild. I don't enjoy because of further maintenance. Is there any way to do it with the classical emerge program ? -- Nicolas Sebrecht -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] Problems mounting Nikon D40 Camera, vfat FS issue?
Hello all, Trying for the first time to download images from a new Nikon D40 camera. libgphoto2 lists the camera as supported in PTP mode. I have tried using PTP mode with digikam (hooking up the camera directly), and also simply trying to mount the memory card using a card reader. Both methods fail. The card is recognized: usb 1-5: new high speed USB device using ehci_hcd and address 2 usb 1-5: configuration #1 chosen from 1 choice scsi6 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0001 PQ: 0 ANSI: 0 sd 6:0:0:0: [sdc] Attached SCSI removable disk sd 6:0:0:0: Attached scsi generic sg3 type 0 usb-storage: device scan complete sd 6:0:0:0: [sdc] 3970048 512-byte hardware sectors (2033 MB) sd 6:0:0:0: [sdc] Write Protect is off sd 6:0:0:0: [sdc] Mode Sense: 02 00 00 00 sd 6:0:0:0: [sdc] Assuming drive cache: write through sd 6:0:0:0: [sdc] 3970048 512-byte hardware sectors (2033 MB) sd 6:0:0:0: [sdc] Write Protect is off sd 6:0:0:0: [sdc] Mode Sense: 02 00 00 00 sd 6:0:0:0: [sdc] Assuming drive cache: write through sdc: sdc1 Attempts in PTP mode fail with digikam reporting "Failed to connect to the camera. Please make sure it is connected properly and turned on". The camera itself reports that it is connected to the computer properly. When directly mounting I get: # mount -t vfat /dev/sdc1 /mnt/camera mount: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so I have these lines in my dmesg whenever I try to mount it, or use PTP mode: Unable to load NLS charset cp437 FAT: codepage cp437 not found In my kernel config I have this: (437) Default codepage for FAT So, is there something else I need to get this codepage? The camera appears to be detected just fine, and the issue seems to be directly related to mounting the vfat filesystem and this missing codepage... Just to note: It is a stable amd64 Gentoo system, and I do have vfat module loaded when I attempt to mount. Any other ideas? Thanks for consideration, -d -- darren kirby :: Part of the problem since 1976 :: http://badcomputer.org "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Weird SMP problem
>> and the solution seems to be upgrade to 0.9.4. Hmmm. I think my >> only option is to disable SMP support until this is fixed. > > 'Tis indeed a sad state of affairs. > > I'm also out of my depth here (never used madwifi), but what happens is > you downgrade to a version lower than 0.9.3.3? > > Unless 0.9.4 is the first version to support amd64, in which case I'd > agree that you are out of luck. That's a good idea and it might work but I've got a critical system picking up the wireless signal a fair distance away. I'd rather not jeopardize it and just let core #2 sleep for now. I guess I should try again with another release of the kernel or madwifi. Thanks again. - Grant -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Weird SMP problem
On Monday 09 June 2008, Grant wrote: > and the solution seems to be upgrade to 0.9.4. Hmmm. I think my > only option is to disable SMP support until this is fixed. 'Tis indeed a sad state of affairs. I'm also out of my depth here (never used madwifi), but what happens is you downgrade to a version lower than 0.9.3.3? Unless 0.9.4 is the first version to support amd64, in which case I'd agree that you are out of luck. -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Cleaning up installation / two glibc versions
On Monday 09 June 2008, Nicolai Beuermann wrote: > After I'd reemerged listed packages the equery command from above > still lists the dependencies. > > what goes wrong? equery depends is not accurate. It does not list packages that are definitely dependencies, it lists dependencies that might possibly be applicable to your system, based on what is in the ebuild. The definitive way to find out exactly what is going on is to run emerge with the -t option and see from that what is pulling a package in. -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] Can't play audio CD's
Hello all, All of the sudden I found out that I can no longer play audio cd's from my computer, nor can I rip them and listen to the music from my HD. I have checked that the CD drive works (I can mount data cd's), and I checked /etc/mtab in case audio cd's are being mounted automatically by hald or something, and they are not. dmesg provides no clues, and alsamixer's settings seem reasonable enough. Grip recognize there's a cd, and appears to play it, but I don't hear nothing. When I try to rip the cd, it gives a "no cd" error. Gnome's CD player gives a "no cd" message as well. Grip (and I think some other program) finds CDDB info for CD's. Any clue what's going on?
Re: [gentoo-user] ssmtp/sendmail file collision
Chema Alonso wrote: dhk escribió: I want to install sendmail, but when ssmtp is installed a file collision with mailer.conf is detected. ssmtp was also installed previously with -mailwrapper in the USE and has since been unmerged. The problem started when taking -mailwrapper out of the ssmtp USE variable. The emerge trace for ssmtp is below. How can I ignore the collision and get everything installed? Thanks, Dave # emerge ssmtp Calculating dependencies... done! >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) mail-mta/ssmtp-2.61-r2 to / * ssmtp_2.61.orig.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking ssmtp_2.61.orig.tar.gz ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking ssmtp_2.61.orig.tar.gz to /var/tmp/portage/mail-mta/ssmtp-2.61-r2/work * Applying ssmtp-2.61-bug127592.patch ... [ ok ] >>> Source unpacked. >>> Compiling source in /var/tmp/portage/mail-mta/ssmtp-2.61-r2/work/ssmtp-2.61 ... ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --sysconfdir=/etc/ssmtp --enable-ssl --enable-inet6 --disable-md5auth --libdir=/usr/lib64 --build=x86_64-pc-linux-gnu creating cache ./config.cache checking for gcc... x86_64-pc-linux-gnu-gcc checking whether the C compiler (x86_64-pc-linux-gnu-gcc -march=k8 -O2 -pipe ) works... yes checking whether the C compiler (x86_64-pc-linux-gnu-gcc -march=k8 -O2 -pipe ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes checking for a BSD compatible install... /usr/bin/install -c checking whether ln -s works... yes checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E checking for ANSI C header files... yes checking for limits.h... yes checking for strings.h... yes checking for syslog.h... yes checking for unistd.h... yes checking for obsolete openlog... no checking for working const... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for gethostname in -lnsl... yes checking for socket in -lsocket... no checking return type of signal handlers... void checking for vprintf... yes checking for gethostname... yes checking for socket... yes checking for strdup... yes checking for strstr... yes updating cache ./config.cache creating ./config.status creating Makefile rm -f ssmtp *.o md5auth/*.o core x86_64-pc-linux-gnu-gcc -Wall -DSTDC_HEADERS=1 -DHAVE_LIMITS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBNSL=1 -DRETSIGTYPE=void -DHAVE_VPRINTF=1 -DHAVE_GETHOSTNAME=1 -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DREWRITE_DOMAIN=1 -DHAVE_SSL=1 -DINET6=1 -DSSMTPCONFDIR=\"/etc/ssmtp\" -DCONFIGURATION_FILE=\"/etc/ssmtp/ssmtp.conf\" -DREVALIASES_FILE=\"/etc/ssmtp/revaliases\" -march=k8 -O2 -pipe -c -o ssmtp.o ssmtp.c ssmtp.c: In function 'ssmtp': ssmtp.c:1376: warning: pointer targets in passing argument 1 of 'to64frombits' differ in signedness ssmtp.c:1376: warning: pointer targets in passing argument 2 of 'to64frombits' differ in signedness ssmtp.c:1385: warning: pointer targets in passing argument 1 of 'to64frombits' differ in signedness ssmtp.c:1385: warning: pointer targets in passing argument 2 of 'to64frombits' differ in signedness ssmtp.c: In function 'smtp_open': ssmtp.c:990: warning: 's' may be used uninitialized in this function ssmtp.c: In function 'header_parse': ssmtp.c:735: warning: 'q' may be used uninitialized in this function x86_64-pc-linux-gnu-gcc -Wall -DSTDC_HEADERS=1 -DHAVE_LIMITS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBNSL=1 -DRETSIGTYPE=void -DHAVE_VPRINTF=1 -DHAVE_GETHOSTNAME=1 -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DREWRITE_DOMAIN=1 -DHAVE_SSL=1 -DINET6=1 -DSSMTPCONFDIR=\"/etc/ssmtp\" -DCONFIGURATION_FILE=\"/etc/ssmtp/ssmtp.conf\" -DREVALIASES_FILE=\"/etc/ssmtp/revaliases\" -march=k8 -O2 -pipe -c -o arpadate.o arpadate.c x86_64-pc-linux-gnu-gcc -Wall -DSTDC_HEADERS=1 -DHAVE_LIMITS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBNSL=1 -DRETSIGTYPE=void -DHAVE_VPRINTF=1 -DHAVE_GETHOSTNAME=1 -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DREWRITE_DOMAIN=1 -DHAVE_SSL=1 -DINET6=1 -DSSMTPCONFDIR=\"/etc/ssmtp\" -DCONFIGURATION_FILE=\"/etc/ssmtp/ssmtp.conf\" -DREVALIASES_FILE=\"/etc/ssmtp/revaliases\" -march=k8 -O2 -pipe -c -o base64.o base64.c x86_64-pc-linux-gnu-gcc -o ssmtp ssmtp.o arpadate.o base64.o -lnsl -lssl >>> Source compiled. >>> Test phase [not enabled]: mail-mta/ssmtp-2.61-r2 >>> Install ssmtp-2.61-r2 into /var/tmp/portage/mail-mta/ssmtp-2.61-r2/image/ category mail-mta >>> Completed installing ssmtp-2.61-r2 into /var/tmp/portage/mail-mta/ssmtp-2.61-r2/image/ ecompressdir: bzip2 -9 /usr/sh
Re: [gentoo-user] Cleaning up installation / two glibc versions
On 09.06.2008 14:10:00, Dirk Heinrichs wrote: > Am Sonntag, 8. Juni 2008 schrieb Nicolai Beuermann: > > Basic question: Why do I need two versions of glibc? > > You don't. > > > equery depends =sys-libs/glibc-2.6.1 lists about 30 entries > > equery depends =sys-libs/glibc-2.3.4.20040808-r1 lists 27 entries of > > which some are the same some are different. > > > > glibc-2.3.4.20040808-r1 seems to be a leftover from initial install back > > in 2004. > > Re-emerge those packages which have the older glibc as dependency. After > that, you can unmerge 2.3.4. > > HTH... > > Dirk After I'd reemerged listed packages the equery command from above still lists the dependencies. what goes wrong? thanks -- mailto: [EMAIL PROTECTED] http://www.nico-beuermann.de gnupg fingerprint: 56DA 4E32 3A4A 52AC B769 DFC2 BF3E 9805 09BB 4259 -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Weird SMP problem
>> I swapped out my Sempron for an Athlon X2 4000+, but when I have >> "Symmetric multi-processing support" enabled in the >> 2.6.24-hardened-r2 kernel, the system freezes as soon as the madwifi >> wireless interface starts in master mode. Weird. Any ideas? > > > > http://madwifi.org/ticket/1903 > > has the solution. Apparently it's a kernel bug, hitting a lot of people > and a workaround is to downgrade to madwifi-0.9.3.3 Thanks Alan. Compiling madwifi-ng-0.9.3.3 I get: ARCH mismatch: supplied "x86", determined "x86_64". It's covered here: https://bugs.gentoo.org/show_bug.cgi?id=205116 and the solution seems to be upgrade to 0.9.4. Hmmm. I think my only option is to disable SMP support until this is fixed. - Grant -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] wpa_supplicant confusion
On Friday 06 June 2008 14:36:14 Mick wrote: > > Yep. I did manage to get it working with wpa_supplicant (or so I > thought . . . ) > > # lsmod | grep rt2 > rt2500usb 21728 0 > rt2x00usb 8576 1 rt2500usb > rt2x00lib 14944 2 rt2500usb,rt2x00usb > > Am I on a hiding to nothing? I thought that if it made it into the kernel > it would be alright to use. When I was downloading the rt2x00 from cvs it > was a bit of a hit and miss affair. > The rt2x00 driver works for some chipsets, but the rt2500usb doesn't seem to work at all. If you check the kernel config you may still see it marked as experimental. Better to use a CVS build (not in portage IIRC) of rt2570 and a current kernel than to try with rt2500usb at this time. That is what I am doing, with wpa using the iwpriv commands. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] gcc-4.3.x and Core 2 Duo, safe way
On Mon, 09 Jun 2008 06:43:41 +0100 Graham Murray <[EMAIL PROTECTED]> wrote: > Andrew Gaydenko <[EMAIL PROTECTED]> writes: > > > gcc-4.3.1 is umasked now. I'm on ~amd64 with Core 2 Duo CPU. Is it > > sufficient just to set > > > > CFLAGS="-O2 -march=core2 -mtune=core2 -pipe" > > > > instead of > > > > CFLAGS="-O2 -march=native -mtune=native -pipe" > > > > which I have in make.conf now? Are there any other things to do? > > Should the two not be equivalent? On a core2 processor, should > -march=native not generate code for the core2? If we are going to get picky about this, it should be noted the -march implies -mtune, at least according to the gcc man pages, and I will trust them to know. I can't remember which will actually be implemented if both are specified, but march is a essentially a stronger version of mtune which breaks compatibility with other CPUs within the same ARCH type. (i.e. march=pentium4 may not run on a pentium3, but should run faster than mtune on a pentium4) RobbieAB -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] ssmtp/sendmail file collision
dhk escribió: I want to install sendmail, but when ssmtp is installed a file collision with mailer.conf is detected. ssmtp was also installed previously with -mailwrapper in the USE and has since been unmerged. The problem started when taking -mailwrapper out of the ssmtp USE variable. The emerge trace for ssmtp is below. How can I ignore the collision and get everything installed? Thanks, Dave # emerge ssmtp Calculating dependencies... done! >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) mail-mta/ssmtp-2.61-r2 to / * ssmtp_2.61.orig.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking ssmtp_2.61.orig.tar.gz ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking ssmtp_2.61.orig.tar.gz to /var/tmp/portage/mail-mta/ssmtp-2.61-r2/work * Applying ssmtp-2.61-bug127592.patch ... [ ok ] >>> Source unpacked. >>> Compiling source in /var/tmp/portage/mail-mta/ssmtp-2.61-r2/work/ssmtp-2.61 ... ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --sysconfdir=/etc/ssmtp --enable-ssl --enable-inet6 --disable-md5auth --libdir=/usr/lib64 --build=x86_64-pc-linux-gnu creating cache ./config.cache checking for gcc... x86_64-pc-linux-gnu-gcc checking whether the C compiler (x86_64-pc-linux-gnu-gcc -march=k8 -O2 -pipe ) works... yes checking whether the C compiler (x86_64-pc-linux-gnu-gcc -march=k8 -O2 -pipe ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes checking for a BSD compatible install... /usr/bin/install -c checking whether ln -s works... yes checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E checking for ANSI C header files... yes checking for limits.h... yes checking for strings.h... yes checking for syslog.h... yes checking for unistd.h... yes checking for obsolete openlog... no checking for working const... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for gethostname in -lnsl... yes checking for socket in -lsocket... no checking return type of signal handlers... void checking for vprintf... yes checking for gethostname... yes checking for socket... yes checking for strdup... yes checking for strstr... yes updating cache ./config.cache creating ./config.status creating Makefile rm -f ssmtp *.o md5auth/*.o core x86_64-pc-linux-gnu-gcc -Wall -DSTDC_HEADERS=1 -DHAVE_LIMITS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBNSL=1 -DRETSIGTYPE=void -DHAVE_VPRINTF=1 -DHAVE_GETHOSTNAME=1 -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DREWRITE_DOMAIN=1 -DHAVE_SSL=1 -DINET6=1 -DSSMTPCONFDIR=\"/etc/ssmtp\" -DCONFIGURATION_FILE=\"/etc/ssmtp/ssmtp.conf\" -DREVALIASES_FILE=\"/etc/ssmtp/revaliases\" -march=k8 -O2 -pipe -c -o ssmtp.o ssmtp.c ssmtp.c: In function 'ssmtp': ssmtp.c:1376: warning: pointer targets in passing argument 1 of 'to64frombits' differ in signedness ssmtp.c:1376: warning: pointer targets in passing argument 2 of 'to64frombits' differ in signedness ssmtp.c:1385: warning: pointer targets in passing argument 1 of 'to64frombits' differ in signedness ssmtp.c:1385: warning: pointer targets in passing argument 2 of 'to64frombits' differ in signedness ssmtp.c: In function 'smtp_open': ssmtp.c:990: warning: 's' may be used uninitialized in this function ssmtp.c: In function 'header_parse': ssmtp.c:735: warning: 'q' may be used uninitialized in this function x86_64-pc-linux-gnu-gcc -Wall -DSTDC_HEADERS=1 -DHAVE_LIMITS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBNSL=1 -DRETSIGTYPE=void -DHAVE_VPRINTF=1 -DHAVE_GETHOSTNAME=1 -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DREWRITE_DOMAIN=1 -DHAVE_SSL=1 -DINET6=1 -DSSMTPCONFDIR=\"/etc/ssmtp\" -DCONFIGURATION_FILE=\"/etc/ssmtp/ssmtp.conf\" -DREVALIASES_FILE=\"/etc/ssmtp/revaliases\" -march=k8 -O2 -pipe -c -o arpadate.o arpadate.c x86_64-pc-linux-gnu-gcc -Wall -DSTDC_HEADERS=1 -DHAVE_LIMITS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBNSL=1 -DRETSIGTYPE=void -DHAVE_VPRINTF=1 -DHAVE_GETHOSTNAME=1 -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DREWRITE_DOMAIN=1 -DHAVE_SSL=1 -DINET6=1 -DSSMTPCONFDIR=\"/etc/ssmtp\" -DCONFIGURATION_FILE=\"/etc/ssmtp/ssmtp.conf\" -DREVALIASES_FILE=\"/etc/ssmtp/revaliases\" -march=k8 -O2 -pipe -c -o base64.o base64.c x86_64-pc-linux-gnu-gcc -o ssmtp ssmtp.o arpadate.o base64.o -lnsl -lssl >>> Source compiled. >>> Test phase [not enabled]: mail-mta/ssmtp-2.61-r2 >>> Install ssmtp-2.61-r2 into /var/tmp/portage/mail-mta/ssmtp-2.61-r2/image/ category mail-mta >>> Completed installing ssmtp-2.61-r2 into /var/tmp/portage/mail-mta/ssmtp-2.61-r2/image/ ecompressdir: bzip2 -9 /usr/share/man strip: x86_64-p
[gentoo-user] ssmtp/sendmail file collision
I want to install sendmail, but when ssmtp is installed a file collision with mailer.conf is detected. ssmtp was also installed previously with -mailwrapper in the USE and has since been unmerged. The problem started when taking -mailwrapper out of the ssmtp USE variable. The emerge trace for ssmtp is below. How can I ignore the collision and get everything installed? Thanks, Dave # emerge ssmtp Calculating dependencies... done! >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) mail-mta/ssmtp-2.61-r2 to / * ssmtp_2.61.orig.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking ssmtp_2.61.orig.tar.gz ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking ssmtp_2.61.orig.tar.gz to /var/tmp/portage/mail-mta/ssmtp-2.61-r2/work * Applying ssmtp-2.61-bug127592.patch ... [ ok ] >>> Source unpacked. >>> Compiling source in /var/tmp/portage/mail-mta/ssmtp-2.61-r2/work/ssmtp-2.61 ... ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --sysconfdir=/etc/ssmtp --enable-ssl --enable-inet6 --disable-md5auth --libdir=/usr/lib64 --build=x86_64-pc-linux-gnu creating cache ./config.cache checking for gcc... x86_64-pc-linux-gnu-gcc checking whether the C compiler (x86_64-pc-linux-gnu-gcc -march=k8 -O2 -pipe ) works... yes checking whether the C compiler (x86_64-pc-linux-gnu-gcc -march=k8 -O2 -pipe ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes checking for a BSD compatible install... /usr/bin/install -c checking whether ln -s works... yes checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E checking for ANSI C header files... yes checking for limits.h... yes checking for strings.h... yes checking for syslog.h... yes checking for unistd.h... yes checking for obsolete openlog... no checking for working const... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for gethostname in -lnsl... yes checking for socket in -lsocket... no checking return type of signal handlers... void checking for vprintf... yes checking for gethostname... yes checking for socket... yes checking for strdup... yes checking for strstr... yes updating cache ./config.cache creating ./config.status creating Makefile rm -f ssmtp *.o md5auth/*.o core x86_64-pc-linux-gnu-gcc -Wall -DSTDC_HEADERS=1 -DHAVE_LIMITS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBNSL=1 -DRETSIGTYPE=void -DHAVE_VPRINTF=1 -DHAVE_GETHOSTNAME=1 -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DREWRITE_DOMAIN=1 -DHAVE_SSL=1 -DINET6=1 -DSSMTPCONFDIR=\"/etc/ssmtp\" -DCONFIGURATION_FILE=\"/etc/ssmtp/ssmtp.conf\" -DREVALIASES_FILE=\"/etc/ssmtp/revaliases\" -march=k8 -O2 -pipe -c -o ssmtp.o ssmtp.c ssmtp.c: In function 'ssmtp': ssmtp.c:1376: warning: pointer targets in passing argument 1 of 'to64frombits' differ in signedness ssmtp.c:1376: warning: pointer targets in passing argument 2 of 'to64frombits' differ in signedness ssmtp.c:1385: warning: pointer targets in passing argument 1 of 'to64frombits' differ in signedness ssmtp.c:1385: warning: pointer targets in passing argument 2 of 'to64frombits' differ in signedness ssmtp.c: In function 'smtp_open': ssmtp.c:990: warning: 's' may be used uninitialized in this function ssmtp.c: In function 'header_parse': ssmtp.c:735: warning: 'q' may be used uninitialized in this function x86_64-pc-linux-gnu-gcc -Wall -DSTDC_HEADERS=1 -DHAVE_LIMITS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBNSL=1 -DRETSIGTYPE=void -DHAVE_VPRINTF=1 -DHAVE_GETHOSTNAME=1 -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DREWRITE_DOMAIN=1 -DHAVE_SSL=1 -DINET6=1 -DSSMTPCONFDIR=\"/etc/ssmtp\" -DCONFIGURATION_FILE=\"/etc/ssmtp/ssmtp.conf\" -DREVALIASES_FILE=\"/etc/ssmtp/revaliases\" -march=k8 -O2 -pipe -c -o arpadate.o arpadate.c x86_64-pc-linux-gnu-gcc -Wall -DSTDC_HEADERS=1 -DHAVE_LIMITS_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBNSL=1 -DRETSIGTYPE=void -DHAVE_VPRINTF=1 -DHAVE_GETHOSTNAME=1 -DHAVE_SOCKET=1 -DHAVE_STRDUP=1 -DHAVE_STRSTR=1 -DREWRITE_DOMAIN=1 -DHAVE_SSL=1 -DINET6=1 -DSSMTPCONFDIR=\"/etc/ssmtp\" -DCONFIGURATION_FILE=\"/etc/ssmtp/ssmtp.conf\" -DREVALIASES_FILE=\"/etc/ssmtp/revaliases\" -march=k8 -O2 -pipe -c -o base64.o base64.c x86_64-pc-linux-gnu-gcc -o ssmtp ssmtp.o arpadate.o base64.o -lnsl -lssl >>> Source compiled. >>> Test phase [not enabled]: mail-mta/ssmtp-2.61-r2 >>> Install ssmtp-2.61-r2 into /var/tmp/portage/mail-mta/ssmtp-2.61-r2/image/ category mail-mta >>> Completed installing ssmtp-2.61-r2 into /var/tmp/portage/mail-mta/ssmtp-2.61-r2/image/ ecompressdir: bzip2 -9 /usr/share/man strip: x86_64-pc-linux-gnu-strip
SOLVED: Re: [gentoo-user] Sudden problems with NIS logins
Hi, Wolfgang Liebich schrieb: Hi, I'm running a linux system at work, which is member in a NIS domain. My username is local, the others are on the NIS server (home dirs are distributed around the cluster). Now I suddenly detected that users whose login data are on the NIS server cannot login anymore! I suspect somehow that the upgrade to pam 0.99 and the disappearance of the "nis" USE flag. It's rather bad form to answer one's own posts, BUT the REAL cause of the problem was something very different: - On the Solaris boxen which comprise the rest of our NIS cluster, the login shell of the users is /usr/bin/bash - On my linux box it's /bin/bash - I've added a symlink from /usr/bin/bash to /bin/bash NOT DONE: add /usr/bin/bash to /etc/shells Moral of the story: - Always check the FULL pam stack for possible problems - "authentification failed" does NOT mean just "authentification failed" :-/ Ciao, Wolfgang -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] Sudden problems with NIS logins
Hi, I'm running a linux system at work, which is member in a NIS domain. My username is local, the others are on the NIS server (home dirs are distributed around the cluster). Now I suddenly detected that users whose login data are on the NIS server cannot login anymore! I suspect somehow that the upgrade to pam 0.99 and the disappearance of the "nis" USE flag. My nsswitch.conf looks like: passwd: compat nis shadow: compat nis group: compat nis hosts: files dns networks:files dns services:db files protocols: db files rpc: db files ethers: db files netmasks:files netgroup:files bootparams: files automount: files aliases: files (only pwd and group info are distributed by nis) my /etc/pam.d/system-auth looks so: auth required pam_env.so auth sufficient pam_unix.so try_first_pass likeauth nullok audit nis debug auth required pam_deny.so accountrequired pam_unix.so password sufficient pam_unix.so try_first_pass nullok md5 shadow audit nis debug password required pam_deny.so sessionrequired pam_limits.so sessionrequired pam_unix.so audit nis debug (I also tried without the audit, nis and debug parameters to pam_unix.so - they were added now for trouble shooting - didn't see a difference, though). What am I missing here?? - wolfgang -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Subversion emerge fails
On Sun, 8 Jun 2008 12:52:03 +0200
"Dirk Uys" <[EMAIL PROTECTED]> wrote:
> Hi everyone.
>
> When I emerge subversion, i get the following error:
>
>
> checking for availability of Berkeley DB... no
> configure: error: Berkeley DB 4.0.14 wasn't found.
>
> !!! Please attach the following file when seeking support:
> !!!
> /var/tmp/portage/dev-util/subversion-1.5.0_rc5/work/subversion-1.5.0-rc5/config.log
> *
> * ERROR: dev-util/subversion-1.5.0_rc5 failed.
> ...
>
>
> Here is the output of eix sys-libs/db:
>
>
> [D] sys-libs/db
> Available versions:
> (1) *1.85-r1 1.85-r3
> (3) 3.2.9-r11
> (4.2) 4.2.52_p4-r2
> (4.3) 4.3.29-r2
> (4.4) (~)4.4.20_p4
> (4.5) 4.5.20_p2
> (4.6) (~)4.6.19 (~)4.6.21
> {bootstrap doc elibc_FreeBSD java nocxx tcl test}
> Installed versions: 4.3.29-r2(4.3)(02:52:26 04/20/07)(-bootstrap
> -doc -elibc_FreeBSD -java -nocxx -tcl -test)
> 4.5.20_p2(4.5)(22:43:07 04/14/08)(-bootstrap
> -doc -elibc_FreeBSD -java -nocxx -tcl -test)
> 4.6.21_p1(4.6)(20:12:09 06/07/08)(-bootstrap
> -doc -elibc_FreeBSD -java -nocxx -tcl -test)
> Homepage:
> http://www.oracle.com/technology/software/products/berkeley-db/index.html
> Description: Oracle Berkeley DB
>
>
> I'm running ~x86, so I don't expect things to always work. Is this a
> bug, or is there something else wrong?
>
> Regards
> Dirk
Why don't you just disable the berkdb USE-flag? The usage of
subversion's database backend is discouraged anyway (for most use
cases).
signature.asc
Description: PGP signature
Re: [gentoo-user] gcc-4.3.x and Core 2 Duo, safe way
Graham Murray schrieb: Andrew Gaydenko <[EMAIL PROTECTED]> writes: gcc-4.3.1 is umasked now. I'm on ~amd64 with Core 2 Duo CPU. Is it sufficient just to set CFLAGS="-O2 -march=core2 -mtune=core2 -pipe" instead of CFLAGS="-O2 -march=native -mtune=native -pipe" which I have in make.conf now? Are there any other things to do? Should the two not be equivalent? On a core2 processor, should -march=native not generate code for the core2? I can't remember where (but it could only be in the wiki or the official gcc docs), I read that using -march="YOURARCH" should be preferred over -march=native. signature.asc Description: OpenPGP digital signature
