Re: [gentoo-user] Checking the reason for (-useflags) in brackets
On 21/06/2014 11:19, meino.cra...@gmx.de wrote: Hi, for some applications I want to activate some USE flags, which are disabled by default. Some of those USE flags are set in () brackets. From searching the internet I learned, that this may be due to unresolveable dependencies or settings in the make.profile or Is there a way to exactly pin point the reason why a certain USE flags gets (diabled) and whether it is possible to resolve the problem? How can I figure out that? From the emerge man page: () circumfix forced, masked, or removed So the answer is usually one of - flag not in ebuild anymore. Look in the ebuild - masked in profile. For these I usually search the profile directory recursively for the flag and figure it out that way What is it that you are trying to find out? A disabled flag is disabled and can't work, what further detail do you need? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Checking the reason for (-useflags) in brackets
Alan McKinnon alan.mckin...@gmail.com [14-06-21 12:36]: On 21/06/2014 11:19, meino.cra...@gmx.de wrote: Hi, for some applications I want to activate some USE flags, which are disabled by default. Some of those USE flags are set in () brackets. From searching the internet I learned, that this may be due to unresolveable dependencies or settings in the make.profile or Is there a way to exactly pin point the reason why a certain USE flags gets (diabled) and whether it is possible to resolve the problem? How can I figure out that? From the emerge man page: () circumfix forced, masked, or removed So the answer is usually one of - flag not in ebuild anymore. Look in the ebuild - masked in profile. For these I usually search the profile directory recursively for the flag and figure it out that way What is it that you are trying to find out? A disabled flag is disabled and can't work, what further detail do you need? -- Alan McKinnon alan.mckin...@gmail.com Thanks for your help. In the internet I have already found the answer in the meanwhile. Best regards, mcc
Re: [gentoo-user] checking whether the C compiler works... no Oooops !!
This is usually CFLAGS and other bits of env stuff. There's probably a more meaningful error earlier in the build log. Can you post the full log for a failing file? Apparently, though unproven, at 09:45 on Friday 06 May 2011, Dale did opine thusly: Hi, I'm trying to update my old rig, the x86 one. It is about 2 months or so behind. I wanted to get it ready for the latest KDE for my brother to play on. I keep running into this type of error: checking whether make sets $(MAKE)... yes checking whether to disable maintainer-specific portions of Makefiles... yes checking for i686-pc-linux-gnu-gcc... gcc checking whether the C compiler works... no configure: error: in `/var/tmp/portage/x11-libs/gdk-pixbuf-2.22.1/work/gdk-pixbuf-2.22.1': configure: error: C compiler cannot create executables See `config.log' for more details. !!! Please attach the following file when seeking support: !!! /var/tmp/portage/x11-libs/gdk-pixbuf-2.22.1/work/gdk-pixbuf-2.22.1/config.l og * ERROR: x11-libs/gdk-pixbuf-2.22.1 failed (configure phase): * econf failed This happens with LOTS of packages. I did a google search and found some really old threads and tried a few things but nothing seems to work. This is emerge info: root@smoker ~ # emerge --info Portage 2.2.0_alpha31 (default/linux/x86/10.0/desktop/kde, gcc-4.4.4, glibc-2.11.2-r3, 2.6.36-gentoo-r5 i686) = System uname: Linux-2.6.36-gentoo-r5-i686-AMD_Athlon-tm-_XP_2500+-with-gentoo-1.12.14 Timestamp of tree: Fri, 06 May 2011 00:15:01 + app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.6.6-r1, 2.7.1-r1, 3.1.3-r1 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 1.12.14-r1 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc:4.4.4-r2 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool:2.2.10 sys-devel/make: 3.81-r2 sys-kernel/linux-headers: 2.6.36.1 (virtual/os-headers) sys-libs/glibc: 2.11.2-r3 Repositories: gentoo Installed sets: @system, @xorg-drivers ACCEPT_KEYWORDS=x86 ACCEPT_LICENSE=* CBUILD=i686-pc-linux-gnu CFLAGS=-march=native -O2 -pipe -fomit-frame-pointer CHOST=i686-pc-linux-gnu CONFIG_PROTECT=/etc /usr/share/config /var/lib/hsqldb CONFIG_PROTECT_MASK=/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo CXXFLAGS=-march=native -O2 -pipe -fomit-frame-pointer DISTDIR=/usr/portage/distfiles EMERGE_DEFAULT_OPTS=--with-bdeps y --backtrack=30 FEATURES=assume-digests binpkg-logs buildpkg distlocks fixlafiles fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch FFLAGS= GENTOO_MIRRORS=http://distfiles.gentoo.org; LANG=en_US LC_ALL=en_US.utf8 LDFLAGS=-Wl,-O1 -Wl,--as-needed LINGUAS=en_US en MAKEOPTS=-j2 PKGDIR=/usr/portage/packages PORTAGE_CONFIGROOT=/ PORTAGE_RSYNC_EXTRA_OPTS=--timeout=600 PORTAGE_RSYNC_OPTS=--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages PORTAGE_TMPDIR=/var/tmp PORTDIR=/usr/portage PORTDIR_OVERLAY= Unset: CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS root@smoker ~ # I left out the USE line. It needs cleaning. lol This is a list of the packages that have failed so far: =sys-kernel/linux-headers-2.6.36.1 =sys-libs/glibc-2.11.3 =sys-devel/binutils-2.20.1-r1 =sys-libs/zlib-1.2.5-r2 =dev-libs/expat-2.0.1-r3 =app-arch/xz-utils-5.0.1 =app-arch/bzip2-1.0.6 =media-libs/libogg-1.2.0 =app-misc/pax-utils-0.2.2 =app-arch/cpio-2.11 =dev-libs/gmp-4.3.2 =app-text/libpaper-1.1.23 =media-libs/openjpeg-1.3-r3 =sys-apps/tcp-wrappers-7.6-r8 =app-portage/portage-utils-0.3.1 =dev-libs/nspr-4.8.7 =sys-libs/timezone-data-2011d =media-libs/jbigkit-2.0-r1 =sys-fs/sysfsutils-2.1.0 =sys-libs/libutempter-1.1.5 =dev-libs/libx86-1.1-r1 =sys-apps/sdparm-1.03 =media-libs/libdvbpsi-0.1.6 =dev-libs/libevent-2.0.10 =dev-libs/libdaemon-0.14-r1 =dev-libs/libusb-1.0.8 =media-libs/jpeg-8b =dev-libs/libffi-3.0.9-r2 =sys-devel/patch-2.5.9 =sys-apps/which-2.20 =dev-util/gperf-3.0.4 =dev-lang/swig-1.3.40-r1 =sys-devel/m4-1.4.15 =media-libs/libpng-1.4.5 =app-arch/unzip-6.0-r1 =sys-apps/pciutils-3.1.7 =dev-libs/mpfr-3.0.0_p3 =sys-apps/sandbox-2.4 It only has one gcc installed and it is selected: root@smoker / # gcc-config -l [1] i686-pc-linux-gnu-4.4.4 * root@smoker / # Can anyone see what I am missing? I got to be missing something. It won't even do a emerge -e system right now. Thanks. Dale :-) :-) --
Re: [gentoo-user] checking whether the C compiler works... no Oooops !!
Alan McKinnon wrote: This is usually CFLAGS and other bits of env stuff. There's probably a more meaningful error earlier in the build log. Can you post the full log for a failing file? Here is one: Emerging (1 of 5) x11-libs/gdk-pixbuf-2.22.1 * gdk-pixbuf-2.22.1.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * Package:x11-libs/gdk-pixbuf-2.22.1 * Repository: gentoo * Maintainer: gn...@gentoo.org * USE:X consolekit elibc_glibc jpeg jpeg2k kernel_linux policykit tiff userland_GNU x86 * FEATURES: preserve-libs Unpacking source... Unpacking gdk-pixbuf-2.22.1.tar.bz2 to /var/tmp/portage/x11-libs/gdk-pixbuf-2.22.1/work Source unpacked in /var/tmp/portage/x11-libs/gdk-pixbuf-2.22.1/work Preparing source in /var/tmp/portage/x11-libs/gdk-pixbuf-2.22.1/work/gdk-pixbuf-2.22.1 ... * Applying gdk-pixbuf-2.21.4-fix-automagic-x11.patch ... [ ok ] * Applying gdk-pixbuf-2.22.1-fix-libpng15.patch ... [ ok ] * Running elibtoolize in: gdk-pixbuf-2.22.1/ * Applying portage-2.2.patch ... * Applying sed-1.5.6.patch ... * Applying as-needed-2.2.6.patch ... * Running eautoreconf in '/var/tmp/portage/x11-libs/gdk-pixbuf-2.22.1/work/gdk-pixbuf-2.22.1' ... * Running aclocal -I m4 ... [ ok ] * Running libtoolize --copy --force --install --automake ... [ ok ] * Running aclocal -I m4 ... [ ok ] * Running autoconf ... [ ok ] * Running autoheader ... [ ok ] * Running automake --add-missing --copy --foreign ... [ ok ] Source prepared. Configuring source in /var/tmp/portage/x11-libs/gdk-pixbuf-2.22.1/work/gdk-pixbuf-2.22.1 ... * econf: updating gdk-pixbuf-2.22.1/config.guess with /usr/share/gnuconfig/config.guess * econf: updating gdk-pixbuf-2.22.1/config.sub with /usr/share/gnuconfig/config.sub ./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-gtk-doc --with-libjpeg --with-libjasper --with-libtiff --disable-introspection --with-x11 --with-libpng checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to disable maintainer-specific portions of Makefiles... yes checking for i686-pc-linux-gnu-gcc... gcc checking whether the C compiler works... no configure: error: in `/var/tmp/portage/x11-libs/gdk-pixbuf-2.22.1/work/gdk-pixbuf-2.22.1': configure: error: C compiler cannot create executables See `config.log' for more details. !!! Please attach the following file when seeking support: !!! /var/tmp/portage/x11-libs/gdk-pixbuf-2.22.1/work/gdk-pixbuf-2.22.1/config.log * ERROR: x11-libs/gdk-pixbuf-2.22.1 failed (configure phase): * econf failed * * Call stack: * ebuild.sh, line 56: Called src_configure * environment, line 2981: Called econf '--disable-gtk-doc' '--with-libjpeg' '--with-libjasper' '--with-libtiff' '--disable-introspection' '--with-x11' '--with-libpng' * ebuild.sh, line 557: Called die * The specific snippet of code: * die econf failed And here is another: Emerging (1 of 1) sys-apps/sandbox-2.4 * sandbox-2.4.tar.xz RMD160 SHA1 SHA256 size ;-) ...[ ok ] * Package:sys-apps/sandbox-2.4 * Repository: gentoo * Maintainer: sand...@gentoo.org * USE:consolekit elibc_glibc kernel_linux policykit userland_GNU x86 * FEATURES: preserve-libs sandbox Unpacking source... Unpacking sandbox-2.4.tar.xz to /var/tmp/portage/sys-apps/sandbox-2.4/work unpack sandbox-2.4.tar.xz: file format not recognized. Ignoring. Source unpacked in /var/tmp/portage/sys-apps/sandbox-2.4/work Compiling source in /var/tmp/portage/sys-apps/sandbox-2.4/work/sandbox-2.4 ... *
Re: [gentoo-user] Checking an HD for problems
On Wed, Sep 22, 2010 at 9:46 AM, Grant emailgr...@gmail.com wrote: I just switched to a new WD Caviar Black hard drive (really fast and quiet!) and I noticed some errors when I was cp -ax'ing everything from my old drive to the new drive which were accompanied by loud clicks. Is there a way to do a comprehensive test/check of the old drive to see if it has any problems? - Grant I know it's not a popular solution here in Linux-land, and it's pretty slow for large drives, but I still use SpinRite for that sort of thing. As a quick test, if the old drive has S.M.A.R.T. is to read the data held in the drive to tell you if the on-board controller is seeing problems. Hope this helps, Mark
Re: [gentoo-user] Checking an HD for problems
On 22 Sep 2010, at 17:46, Grant wrote: ... I noticed some errors when I was cp -ax'ing everything from my old drive to the new drive which were accompanied by loud clicks. Is there a way to do a comprehensive test/check of the old drive to see if it has any problems? You don't need to do a test. The disk that is making the noises is f**ked. Assuming that it's the old drive that is knackered, and if you're not certain that all important data has been copied correctly, then use GNU ddrescue (there is more than one dd_rescue, and GNU's is the best one) to do a bitwise clone of the data. Follow the examples in the manual to do multiple passes - the first pass will get most of the data from good sectors, subsequent passes will make repeated attempts at the bad sectors. Stroller.
Re: [gentoo-user] Checking sanity of system...
meino.cra...@gmx.de wrote: Hi, this is no security issue in sense of attacks...it is related to the consistency of the system. Simple question (and may be complicate to answer... ;) ) How can I check, that my Gentoo system is uptodate, consistent and sane? Best regards, mcc I think this is what you want. man glsa-check I don't use it so you will have to read or wait until someone who uses it comes along. No real clue how it works. I hope that helps and is what you are looking for. Dale :-) :-)
Re: [gentoo-user] Checking sanity of system...
Dale rdalek1...@gmail.com [10-04-04 08:20]: meino.cra...@gmx.de wrote: Hi, this is no security issue in sense of attacks...it is related to the consistency of the system. Simple question (and may be complicate to answer... ;) ) How can I check, that my Gentoo system is uptodate, consistent and sane? Best regards, mcc I think this is what you want. man glsa-check I don't use it so you will have to read or wait until someone who uses it comes along. No real clue how it works. I hope that helps and is what you are looking for. Dale :-) :-) Hi Dale, As far as I can understand the man-page, glsa-check is a tool to check security settings in the system: _G_entoo _L_inux _S_ecurity _A_visory. I didnt know of this tool before so it is a goog hint anyway, but for the moment I want only check, whether the system is not cleanly setup/installed/updated in the sense of it is working well ;) Best regards, mcc -- Please don't send me any Word- or Powerpoint-Attachments unless it's absolutely neccessary. - Send simply Text. See http://www.gnu.org/philosophy/no-word-attachments.html In a world without fences and walls nobody needs gates and windows.
Re: [gentoo-user] Checking sanity of system...
Am 04.04.2010 07:18, schrieb meino.cra...@gmx.de: Hi, this is no security issue in sense of attacks...it is related to the consistency of the system. Simple question (and may be complicate to answer... ;) ) How can I check, that my Gentoo system is uptodate, consistent and sane? Best regards, mcc Hi, Every Update: emerge --sync emerge -uDN world -- Read the Packagemessages for Instructions. etc-update# Merge new Configfiles revdep-rebuild# Identify broken libraries From time to time: emerge --deplcean (-p) revdep-rebuild# Delete old packages and sort out the resulting broken packages eclean distfiles# Delete the old source-packages in your distfile repo. Regards, Norman
Re: [gentoo-user] Checking sanity of system...
Von: nor...@smash-net.org Datum: 04.04.2010 11:37 An: gentoo-user@lists.gentoo.org Betreff: Re: [gentoo-user] Checking sanity of system... Am 04.04.2010 07:18, schrieb meino.cra...@gmx.de: Hi, this is no security issue in sense of attacks...it is related to the consistency of the system. Simple question (and may be complicate to answer... ;) ) How can I check, that my Gentoo system is uptodate, consistent and sane? Best regards, mcc Hi, Every Update: emerge --sync emerge -uDN world -- Read the Packagemessages for Instructions. etc-update# Merge new Configfiles revdep-rebuild# Identify broken libraries From time to time: emerge --deplcean (-p) revdep-rebuild# Delete old packages and sort out the resulting broken packages eclean distfiles# Delete the old source-packages in your distfile repo. Regards, Norman and aditionally from time to time: eix -u (packages which have at least one slotted version installed which is not the best version within that slot) and eix-test-obsolete -d (display missing packages or packages with obsolete entries in /etc/portage/package.* ) Check for viruses, lookout for SMART data, and filesystem inconsistencies, check temperatures, check log files, listen to fans... there are many levels where a system could fail. Urs
Re: [gentoo-user] checking for working mkstemp..... taking forever
Frank Steinmetzger wrote: I've encountered the same and didn't know how to solve it. I found out that mkstemp was some standard C function so I remerged glibc, but that didn't do the trick. Eventuella I restarted my installation. It as i686 with 32 bit though. Did you change CHOST maybe? python folks can't write configure.in files (- AC_TRY_RUN() causes headaches) ... that's also why it's not crosscompile'able ;-o file a bug to python folks, it's not gentoo's fault. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: i...@metux.de skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-user] checking for working mkstemp..... taking forever
On Wednesday 02 September 2009 01:16:10 Frank Steinmetzger wrote: Am Mittwoch, 2. September 2009 schrieb Nick Khamis: Hello Everyone. I am trying to update-python and I am stuck at checking for working mkstemp. for ever, what should I do.. This is a fresh install AMD64. Thanks in Advanced, Ninus. I've encountered the same and didn't know how to solve it. I found out that mkstemp was some standard C function so I remerged glibc, mktemp is now in coreutils It used to be in debianutils Not glibc. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] checking for working mkstemp..... taking forever
On Wed, 2 Sep 2009 13:12:22 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On Wednesday 02 September 2009 01:16:10 Frank Steinmetzger wrote: Am Mittwoch, 2. September 2009 schrieb Nick Khamis: Hello Everyone. I am trying to update-python and I am stuck at checking for working mkstemp. for ever, what should I do.. This is a fresh install AMD64. Thanks in Advanced, Ninus. I've encountered the same and didn't know how to solve it. I found out that mkstemp was some standard C function so I remerged glibc, mktemp is now in coreutils It used to be in debianutils Not glibc. I believe you're confusing mktemp with mkstemp, the latter being C function indeed - man 3 mkstemp. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature
Re: [gentoo-user] checking for working mkstemp..... taking forever
On Wednesday 02 September 2009 16:13:12 Mike Kazantsev wrote: On Wed, 2 Sep 2009 13:12:22 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On Wednesday 02 September 2009 01:16:10 Frank Steinmetzger wrote: Am Mittwoch, 2. September 2009 schrieb Nick Khamis: Hello Everyone. I am trying to update-python and I am stuck at checking for working mkstemp. for ever, what should I do.. This is a fresh install AMD64. Thanks in Advanced, Ninus. I've encountered the same and didn't know how to solve it. I found out that mkstemp was some standard C function so I remerged glibc, mktemp is now in coreutils It used to be in debianutils Not glibc. I believe you're confusing mktemp with mkstemp, the latter being C function indeed - man 3 mkstemp. You are correct and I am :-) I even double checked to make sure I was on the right track and could have sworn I saw mktemp somewhere in the OPs mail... It must be this bloody flu. Makes one's eyes work poorly... -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] checking for working mkstemp..... taking forever
Am Mittwoch, 2. September 2009 schrieb Nick Khamis: Hello Everyone. I am trying to update-python and I am stuck at checking for working mkstemp. for ever, what should I do.. This is a fresh install AMD64. Thanks in Advanced, Ninus. I've encountered the same and didn't know how to solve it. I found out that mkstemp was some standard C function so I remerged glibc, but that didn't do the trick. Eventuella I restarted my installation. It as i686 with 32 bit though. Did you change CHOST maybe? -- Gruß | Greetings | Qapla' No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] checking for working mkstemp..... taking forever
I did not change CHOST just CFLAGS and CXXFLAGS as per the manual. h Regards, Ninus
Re: [gentoo-user] checking for.....
* Alan McKinnon [EMAIL PROTECTED] wrote: You are expecting autoconf to actually do something sane when it runs??? *rofl* The point is: the way autoconf does its 'checks' is completely insane - beginning with the expectation that an dumb script is more clever than an operator ;-o I've did a lot research in this area some time ago and came the conclusion, that autoconf cannot be fixed - it's broken by design. So I developed unitool: http://unitool.metux.de/ It uses an system/target-wide config database which can be either auto-generated or tweaked manually. I'm currently in the process of redesigning the database scheme to be more convenient and flexible and also allow several autoconf macros (eg. AC_CHECK_HEADER, ...) to directly query that config database. So autoconf can be easily rewritten to at least do a large bunch of checks via that db instead of compiling test programs. If anyone's interested in it, please let me know. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] checking for.....
[EMAIL PROTECTED] wrote: In the middle of doing a major upgrade from very old pkgs to current 2008 and compiling lots and lots of stuff. Seeing that line `checking for WHATEVER' go by 486,211 times so far makes me wonder if there wouldn't be someway to cache all those answers somewhere so whatever test is done for each line could be dispensed with for most of them. Probably would need more than 2-3 compiles to have all but rare ones answered. Some items really check a lot of things. I think it would be a major time saver when discussing huge numbers of compiles. Hello, ccache does caching, I use it and I'm very satisfied. W. Canis signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] checking for.....
ccache caches the compile step. I believe the OP was specifically looking for something that would cache the answers to the checking for lines (the configuration step). On Fri, May 2, 2008 at 4:49 AM, Wolf Canis [EMAIL PROTECTED] wrote: [snip] Hello, ccache does caching, I use it and I'm very satisfied. W. Canis -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] checking for.....
Brandon Mintern wrote: ccache caches the compile step. I believe the OP was specifically looking for something that would cache the answers to the checking for lines (the configuration step). Yes, you are right, but I thought that ccache cached parts of the configuration too. That's what I noticed in outputs during the build process. Perhaps my conclusion is wrong. W. Canis signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] checking for.....
On Fri, 02 May 2008 11:25:41 +0200 Wolf Canis wrote: Brandon Mintern wrote: ccache caches the compile step. I believe the OP was specifically looking for something that would cache the answers to the checking for lines (the configuration step). Yes, you are right, but I thought that ccache cached parts of the configuration too. That's what I noticed in outputs during the build process. Perhaps my conclusion is wrong. W. Canis As part of identifying the capabilities and files of your operating system (distro) ./configure creates a lot of small programs and compiles them. I can see how caching compilation info would help with this. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] checking for.....
Brandon Mintern ha scritto: I had thought the same thing myself some time ago, and I discovered that there had been work on a FEATURE called confcache. I believe it was abandoned, though, due to major difficulties. This is merely a guess, but I think some of the problems arise in that some of the things that are checked for actually change as a package is installed or updated (e.g. checking gcc version). This means that each package being installed would have to somehow flag confcache and indicate that it has changed, and confcache would have to keep a list of all these cached values and their dependencies. What was the problem with that? Ebuilds of stuff like gcc could be tailored to flag confcache. Otherwise, emerge could do the relevant checks before emerging the first package, and be trained to do them again after a known troublesome package has been emerged. I understand this requires coordination and maintaining, of course, and that's the non-trivial part, I guess. However, are there many packages affecting common configure checks? If they are, say, less than 10 affecting 80% of configure flags, it seems worth the hassle. If troubles arise, one can quickly try with confcache disabled, and debug. Heck, I'd help with it myself, if only I had some confidence with portage code and C compilation (However, I know Python, FWIW) m. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] checking for.....
On Thu, May 1, 2008 at 3:11 PM, [EMAIL PROTECTED] wrote: In the middle of doing a major upgrade from very old pkgs to current 2008 and compiling lots and lots of stuff. Seeing that line `checking for WHATEVER' go by 486,211 times so far makes me wonder if there wouldn't be someway to cache all those answers somewhere so whatever test is done for each line could be dispensed with for most of them. Probably would need more than 2-3 compiles to have all but rare ones answered. Some items really check a lot of things. I think it would be a major time saver when discussing huge numbers of compiles. -- gentoo-user@lists.gentoo.org mailing list I had thought the same thing myself some time ago, and I discovered that there had been work on a FEATURE called confcache. I believe it was abandoned, though, due to major difficulties. This is merely a guess, but I think some of the problems arise in that some of the things that are checked for actually change as a package is installed or updated (e.g. checking gcc version). This means that each package being installed would have to somehow flag confcache and indicate that it has changed, and confcache would have to keep a list of all these cached values and their dependencies. I think there might be potential, however, for something that cached some of the more common system checks such as number of command line arguments. Then again, if many of these configuration items are discovered through a simple system call or by running a quick command, I'm not sure how much faster something like confcache would actually be. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] checking for.....
On Thursday 01 May 2008, [EMAIL PROTECTED] wrote: In the middle of doing a major upgrade from very old pkgs to current 2008 and compiling lots and lots of stuff. Seeing that line `checking for WHATEVER' go by 486,211 times so far makes me wonder if there wouldn't be someway to cache all those answers somewhere so whatever test is done for each line could be dispensed with for most of them. Probably would need more than 2-3 compiles to have all but rare ones answered. Some items really check a lot of things. I think it would be a major time saver when discussing huge numbers of compiles. You are expecting autoconf to actually do something sane when it runs??? Har har. You must be new here. :-) That problem has been discussed about 486,212 times and solved about 0 times. -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] checking for.....
On Thursday 01 May 2008, Alan McKinnon wrote: On Thursday 01 May 2008, [EMAIL PROTECTED] wrote: In the middle of doing a major upgrade from very old pkgs to current 2008 and compiling lots and lots of stuff. Seeing that line `checking for WHATEVER' go by 486,211 times so far makes me wonder if there wouldn't be someway to cache all those answers somewhere so whatever test is done for each line could be dispensed with for most of them. Probably would need more than 2-3 compiles to have all but rare ones answered. Some items really check a lot of things. I think it would be a major time saver when discussing huge numbers of compiles. You are expecting autoconf to actually do something sane when it runs??? Har har. You must be new here. :-) That problem has been discussed about 486,212 times and solved about 0 times. Fortunately, more packages go over to cmake. Just a matter of time. Uwe -- Ignorance killed the cat, sir, curiosity was framed! -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
On 8/11/07, Mark Knecht [EMAIL PROTECTED] wrote: Hi, emerge gnome fails. Does anyone recognize what portage is complaining about here? I'm not really sure, but I solved it by reemerging dev-perl/XML-Parser. -- Canek Peláez Valdés Facultad de Ciencias, UNAM -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
On Saturday 11 August 2007 20:53:59 Canek Peláez wrote: On 8/11/07, Mark Knecht [EMAIL PROTECTED] wrote: Hi, emerge gnome fails. Does anyone recognize what portage is complaining about here? I'm not really sure, but I solved it by reemerging dev-perl/XML-Parser. -- Canek Peláez Valdés Facultad de Ciencias, UNAM Confirmed -- Guillermo Antonio Amaral Bastidas # Free Open Source Software Advocate # KDE Developer: gamaral $ irc: [EMAIL PROTECTED] @ blog: http://blog.guillermoamaral.com/ @ site: http://www.guillermoamaral.com/ % gpg: http://downloads.guillermoamaral.com/public.asc signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] checking local packages against portage
On Tue, 06 Jun 2006 18:17:46 -0600, Joseph wrote: How to check packages that are installed on my system but are no longer available in portage (so I can remove them)? emerge -uavDN world should show them up. I get this on one machine These are the packages that would be merged, in order: Calculating world dependencies . . !!! Packages for the following atoms are either all !!! masked or don't exist: app-misc/jbidwatcher -- Neil Bothwick I have seen things you lusers would not believe. I've seen Sun monitors on fire off the side of the multimedia lab. I've seen NTU lights glitter in the dark near the Mail Gate. All these things will be lost in time, like the root partition last week. Time to die. signature.asc Description: PGP signature
Re: [gentoo-user] checking local packages against portage
Joseph wrote: Recently I found out that I had an old package avifile installed on my system but it was no longer in portage. How to check packages that are installed on my system but are no longer available in portage (so I can remove them)? /usr/sbin/emaint --check -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] checking local packages against portage
Ryan Tandy wrote: Joseph wrote: Recently I found out that I had an old package avifile installed on my system but it was no longer in portage. How to check packages that are installed on my system but are no longer available in portage (so I can remove them)? /usr/sbin/emaint --check Well, I thought that was neat until I got this: [EMAIL PROTECTED] / # emaint --check usage: emaint [options] all | world Currently emaint can only check and fix problems with one's world file. Future versions will integrate other portage check-and-fix tools and provide a single interface to system health checks. emaint: error: Incorrect number of arguments [EMAIL PROTECTED] / # In case it matters: [EMAIL PROTECTED] / # emerge -pv portage These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-apps/portage-2.0.54-r2 -build +doc (-selinux) 0 kB Total size of downloads: 0 kB [EMAIL PROTECTED] / # What's up with that? Dale :-) :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] checking local packages against portage
On Tue, 2006-06-06 at 20:57 -0500, Teresa and Dale wrote: [EMAIL PROTECTED] / # emerge -pv portage These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-apps/portage-2.0.54-r2 -build +doc (-selinux) 0 kB Total size of downloads: 0 kB [EMAIL PROTECTED] / # What's up with that? I keep my portage up to date every time there is an update. For some reason an application avifile was left on my system but no longer in portage. When I tried to run revdep-rebuild it gave me an error message, so I was forced to remove it manually. -- #Joseph -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] checking local packages against portage
Teresa and Dale wrote: [EMAIL PROTECTED] / # emaint --check usage: emaint [options] all | world Currently emaint can only check and fix problems with one's world file. Future versions will integrate other portage check-and-fix tools and provide a single interface to system health checks. emaint: error: Incorrect number of arguments [EMAIL PROTECTED] / # /me smacks head # emaint --check world I'll try to remember, next time, to check that I'm giving the correct command *before* hitting send. At this point, emaint can only check that packages *in your world file* are still in the portage tree. Future versions will be more comprehensive. emaint --help and man emaint for details. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] checking local packages against portage
Ryan Tandy wrote: Teresa and Dale wrote: [EMAIL PROTECTED] / # emaint --check usage: emaint [options] all | world Currently emaint can only check and fix problems with one's world file. Future versions will integrate other portage check-and-fix tools and provide a single interface to system health checks. emaint: error: Incorrect number of arguments [EMAIL PROTECTED] / # /me smacks head # emaint --check world I'll try to remember, next time, to check that I'm giving the correct command *before* hitting send. At this point, emaint can only check that packages *in your world file* are still in the portage tree. Future versions will be more comprehensive. emaint --help and man emaint for details. I was wondering if I was behind a version or ahead one. It happens. No worries. Dale :-) :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] checking local packages against portage
Am Mittwoch, 7. Juni 2006 02:17 schrieb ext Joseph: Recently I found out that I had an old package avifile installed on my system but it was no longer in portage. How to check packages that are installed on my system but are no longer available in portage (so I can remove them)? It seems emerge -a --depclean is not broken anymore (I use portage-2.1_rc4-r2). Don't forget to run revdep-rebuild afterwards. HTH... Dirk -- Dirk Heinrichs | Tel: +49 (0)162 234 3408 Configuration Manager | Fax: +49 (0)211 47068 111 Capgemini Deutschland | Mail: [EMAIL PROTECTED] Hambornerstraße 55 | Web: http://www.capgemini.com D-40472 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: www.keyserver.net pgpln3lzAok9F.pgp Description: PGP signature
