Re: [gentoo-user] Re: Kernel 3.14.14 build failure at DEPMOD stage
On Wed, Aug 13, 2014 at 05:58:44PM -0700, walt wrote On 08/13/2014 03:51 PM, Walter Dnes wrote: Going from 3.12.13 to 3.14.14 using make old config and then the standard build (64 bit). At the DEPMOD stage near the very end I get... DEPMOD 3.14.14-gentoo /usr/src/linux-3.14.14-gentoo/scripts/depmod.sh: line 57: 27721 Segmentation fault $DEPMOD $@ $KERNELRELEASE $SYMBOL_PREFIX make: *** [_modinst_post] Error 139 I *hate* when that happens! Just a few random ideas that may help the old bulb light up :) Can you re-emerge 3.12.13 without any errors? It fails now, as does 3.12.21-r1. Fortunately, I always keep 2 kernels around. The production kernel is call Production and new builds always go as Experimental. I use lilo to select the version to boot. Only after booting and running successfully for a couple of weeks do I run my promote script which copies the Experimental kernel and map and .config backup files over top of their Production equivalants. So my Production kernel is not screwed up. The kernel build system uses perl (not sure about python), so I always wonder if perl-cleaner may help fix strange new errors. I tried both perl-cleaner --all and perl-cleaner --reallyall, but I still have the problem. Is there a way to manually run depmod? I'm guessing you're running gentoo-stable on that machine? Has gcc been updated recently? glibc? linux-headers? perl? python? kmod? Stable x86_64. glibc, perl, and python were on the list. This is a notebook that hadn't been updated for a month or so. cd to /var/log/portage and ran command ll -og | grep Aug\ 13 | sed s/^.*Aug 13 // to get a list of what ran that day... 06:10 app-admin:perl-cleaner-2.16:20140813-101043.log 06:53 app-admin:syslog-ng-3.4.8:20140813-105115.log 06:10 dev-lang:perl-5.16.3:20140813-101032.log 06:10 dev-lang:perl-5.18.2-r1:20140813-100135.log 06:43 dev-lang:python-2.7.7:20140813-103957.log 07:02 dev-lang:python-3.3.5-r1:20140813-105851.log 06:51 dev-libs:glib-2.40.0-r1:20140813-104703.log 06:22 dev-libs:libgcrypt-1.5.4:20140813-102137.log 06:46 dev-libs:libxml2-2.9.1-r4:20140813-104335.log 06:46 dev-libs:libxslt-1.1.28-r3:20140813-104613.log 06:29 dev-libs:openssl-1.0.1i:20140813-102446.log 15:07 dev-perl:Locale-gettext-1.50.0:20140813-190724.log 15:07 dev-perl:Locale-gettext-1.50.0:20140813-190729.log 15:07 dev-perl:XML-Parser-2.410.0-r2:20140813-190713.log 15:07 dev-perl:XML-Parser-2.410.0:20140813-190721.log 06:33 media-libs:freetype-2.5.3-r1:20140813-103217.log 05:52 media-libs:giflib-4.1.6-r3:20140813-095222.log 05:46 media-libs:libpng-1.6.12:20140813-094555.log 05:55 sys-apps:man-pages-3.69:20140813-095510.log 06:31 sys-apps:util-linux-2.24.1-r3:20140813-102936.log 05:52 sys-boot:lilo-24.0:20140813-095205.log 05:45 sys-devel:bin86-0.16.20-r2:20140813-094523.log 05:49 sys-devel:flex-2.5.39-r1:20140813-094901.log 05:44 sys-devel:gnuconfig-20140212:20140813-094454.log 06:19 sys-devel:libtool-2.4.2-r1:20140813-101832.log 06:35 sys-fs:e2fsprogs-1.42.10:20140813-103356.log 06:17 sys-kernel:gentoo-sources-3.14.14:20140813-101527.log 06:32 sys-libs:e2fsprogs-libs-1.42.10:20140813-103145.log 05:44 sys-libs:glibc-2.19-r1:20140813-092733.log 06:33 sys-libs:gpm-1.20.7-r2:20140813-103325.log 05:45 sys-libs:timezone-data-2014d:20140813-094502.log 05:45 virtual:libintl-0-r1:20140813-094516.log 06:53 x11-libs:gdk-pixbuf-2.30.8:20140813-105308.log -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: Kernel 3.14.14 build failure at DEPMOD stage
On Thu, 14 Aug 2014 04:24:35 -0400, Walter Dnes wrote: I still have the problem. Is there a way to manually run depmod? depmod -a 3.x.y -- Neil Bothwick If you use envelopes, why not encryption ? signature.asc Description: PGP signature
Re: [gentoo-user] Re: distfiles contains extra files?
On Wednesday 13 August 2014 21:27:47 James wrote: Volker Armin Hemmann volkerarmin at googlemail.com writes: Any other idiotic ideas? Hey, JUST GO FUCK OFF! If you cannot respondd in a cilized form, then PLEASE Just ingnore the post ASSHOLE! There's no excuse for language like that in a public forum. Welcome to my kill-file. Plonk. -- Regards Peter
Re: [gentoo-user] python-updater constantly rebuilds one same package
On 14/08/2014 13:38, Сергей wrote: http://pastebin.com/L3qxu460 Is it the way how python-updater should work? Seems a bit strange Please don't use pastebin. People here hate the bloody things. Just paste the relevant output into your mail. This list is archived so one week from now anyone can still help you. With pastebin, they can't. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: distfiles contains extra files?
On Thu, Aug 14, 2014 at 6:35 AM, Peter Humphrey pe...@prh.myzen.co.uk wrote: On Wednesday 13 August 2014 21:27:47 James wrote: Volker Armin Hemmann volkerarmin at googlemail.com writes: Any other idiotic ideas? Hey, JUST GO FUCK OFF! If you cannot respondd in a cilized form, then PLEASE Just ingnore the post ASSHOLE! There's no excuse for language like that in a public forum. Welcome to my kill-file. Uh, wow. I stopped reading this thread about a dozen posts ago before stumbling on this, and it looks like this thread has only gone downhill. Some friendly advice for all: 1. If you see something designed in a way that doesn't seem right, it isn't wise to initially conclude that the designers are idiots. 2. Approaching the designers and suggesting to them that they don't know what they're doing will have fairly predictable results. 3. If you see somebody ignoring #1-2, don't feed the troll. Either answer the question, ignore the post, or just politely point out that the original post wasn't made in a helpful manner. 4. We're not in middle school any longer. If anybody here does happen to be in middle school, the fact that you figured out how to subscribe to a mailing list puts you in the 99th percentile already, so try for the 99.9th percentile by acting like an adult anyway and the world might one day belong to you. This list exists so that those who use Gentoo can interact, ask questions, and ideally get answers. Stuff like this just makes people not want to read the list, and that tends to disproportionately include those who are actually able to offer the most help. Most devs do not read -user, and stuff like this doesn't help with that. If we want to lower the barrier to contribution, part of that is going to involve making contribution more constructive. -- Rich
Re: [gentoo-user] python-updater constantly rebuilds one same package
On 14/08/2014 14:58, Сергей wrote: Sorry. Here is what I wanted to paste: sudo python-updater * Starting Python Updater... * Main active version of Python:3.3 * Active version of Python 2: 2.7 * Active version of Python 3: 3.3 * Globally supported Python ABIs in installed repositories: * gentoo: 2.4 2.5 2.6 2.7 3.1 3.2 3.3 2.5-jython 2.7-jython 2.7-pypy-1.7 2.7-pypy-1.8 2.7-pypy-1.9 2.7-pypy-2.0 * kde:2.4 2.5 2.6 2.7 3.1 3.2 3.3 2.5-jython 2.7-jython 2.7-pypy-1.7 2.7-pypy-1.8 2.7-pypy-1.9 2.7-pypy-2.0 * Adding to list: dev-libs/libgamin:0 * emerge -Dv1 --keep-going dev-libs/libgamin:0 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] dev-libs/libgamin-0.1.10-r4 USE=-debug -python -static-libs ABI_X86=(64) (-32) (-x32) 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB Verifying ebuild manifests Emerging (1 of 1) dev-libs/libgamin-0.1.10-r4 Installing (1 of 1) dev-libs/libgamin-0.1.10-r4 Jobs: 1 of 1 complete Load avg: 1.15, 0.72, 0.46 Auto-cleaning packages... No outdated packages were found on your system. * GNU info directory index is up-to-date. sergey@sergey-pc ~ % sudo python-updater * Starting Python Updater... * Main active version of Python:3.3 * Active version of Python 2: 2.7 * Active version of Python 3: 3.3 * Globally supported Python ABIs in installed repositories: * gentoo: 2.4 2.5 2.6 2.7 3.1 3.2 3.3 2.5-jython 2.7-jython 2.7-pypy-1.7 2.7-pypy-1.8 2.7-pypy-1.9 2.7-pypy-2.0 * kde:2.4 2.5 2.6 2.7 3.1 3.2 3.3 2.5-jython 2.7-jython 2.7-pypy-1.7 2.7-pypy-1.8 2.7-pypy-1.9 2.7-pypy-2.0 * Adding to list: dev-libs/libgamin:0 * emerge -Dv1 --keep-going dev-libs/libgamin:0 As you can see, though libgamin was rebuilt, if I run python-updater once more it wants to rebuild it again. These kinds of things are hard to fix, and even harder to figure out what is going on. Behind the scenes, there's a lot of portage magic involved to determine what depends on what, and what changed ABI so now it's dependants must be rebuilt. But the tools often don't give enough info (or too much!), so we have to resort to blunt weapons. I find that this often works out: revdep-rebuild, the python-updater again. If that doesn't fix it: equery depends libgamin then unmerge libgamin andthe packages that depend on it. Then emerge them back with the -1 option (not an update world just in case there are missing deps in ebuild) Yes, it's a blunt weapon and probably overkill (sorta like rebooting windows to fix every little thing), but without more info your choices are limited -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] python-updater constantly rebuilds one same package
On 14/08/2014 16:35, Сергей wrote: kdelibs and glib depend on virtual/fam provided by gamin, so I don't think removing them all is a good idea. revdep-rebuild didn't help. Maaagic ~~ I see. OK, lets try identify why python-updater thinks libgamin needs updating: python--updater -p -v -v and search the output (it's long...) -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] 32-bit gdk fail: trying to load 64-bit libpixbufloader-xpm.so
I've got a 32-bit application that ran fine until a couple weeks ago. But, now when I try to run it I get this failure: (msb_serv:9939): GdkPixbuf-WARNING **: Error loading XPM image loader: Unable to load image-loading module: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: wrong ELF class: ELFCLASS64 (msb_serv:9939): Gdk-CRITICAL **: IA__gdk_drawable_get_size: assertion 'GDK_IS_DRAWABLE (drawable)' failed (msb_serv:9939): Gdk-CRITICAL **: IA__gdk_drawable_get_depth: assertion 'GDK_IS_DRAWABLE (drawable)' failed The GDK library appears to be trying to load the 64-bit version of libpixbufloader-xpm.so instead of the 32-bit version I suspect this has something to do with the recent move to the abi_x86_32 and abi_x86_64 use flags, but I've not been able to make any sense of what google has found me on that topic. I've set those use flags and set ABI_X86=64 32 in make.conf and then re-emerged x11-libs/gdk-pixbuf, but it doesn't help. I've verified that I do have both 32 and 64 bit versions of that library: # for d in /usr/lib*; do find $d -name 'libpixbufloader-xpm*'; done /usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so /usr/lib64/debug/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so.debug /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.la /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so Any ideas what changed in the last couple weeks to break 32-bit compatiblity mode for GDK apps? -- Grant Edwards grant.b.edwardsYow! RHAPSODY in Glue! at gmail.com
Re: [gentoo-user] python-updater constantly rebuilds one same package
On Thu, Aug 14, 2014 at 11:57 AM, Сергей protsero...@gmail.com wrote: I have looked at dev-libs/libgamin-0.1.10-r4 and dev-libs/libgamin-0.1.10-r5 ebuilds and compared them. dev-libs/libgamin-0.1.10-r5 has PYTHON_TARGETS=python2_7 (r4 had no PYTHON_TARGETS) and now python-updater doesn't rebuild libgamin. Seems like now everything is ok and it was only a portage bug. It is actually a bug with python-updater. However, we have no plans to fix it; instead, the problem will be resolved once all python-based ebuilds are migrated to python-r1.eclass and therefore utilize PYTHON_TARGETS. At that point, python-updater will become obsolete and you will no longer need to run it.
Re: [gentoo-user] python-updater constantly rebuilds one same package
On Thu 14 Aug 2014 11:57:53 AM EDT, Сергей wrote: I have looked at dev-libs/libgamin-0.1.10-r4 and dev-libs/libgamin-0.1.10-r5 ebuilds and compared them. dev-libs/libgamin-0.1.10-r5 has PYTHON_TARGETS=python2_7 (r4 had no PYTHON_TARGETS) and now python-updater doesn't rebuild libgamin. Seems like now everything is ok and it was only a portage bug. I've actually never run python-updater before; now running it twice it tries to rebuild dev-libs/stfl both times. I checked the ebuild; there's no PYTHON_TARGETS at all (and 0.22-r1 is the only ebuild in my local tree right now), but the error is * Checking dev-libs/stfl-0.22-r1:0 * Adding to list: dev-libs/stfl:0 * check: PYTHON_ABIS [ Previous Python ABIs: , new Python ABIs: 2.7 3.3 ] Not sure if this is a bug or not (and personally I don't really care, not gonna run python-updater until stuff breaks like crazy), but for any developers out there it might be important to take note? I can attach any relevant logs if necessary. Alec
[gentoo-user] Re: 32-bit gdk fail: trying to load 64-bit libpixbufloader-xpm.so
On 2014-08-14, Grant Edwards grant.b.edwa...@gmail.com wrote: I've got a 32-bit application that ran fine until a couple weeks ago. But, now when I try to run it I get this failure: (msb_serv:9939): GdkPixbuf-WARNING **: Error loading XPM image loader: Unable to load image-loading module: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: wrong ELF class: ELFCLASS64 (msb_serv:9939): Gdk-CRITICAL **: IA__gdk_drawable_get_size: assertion 'GDK_IS_DRAWABLE (drawable)' failed (msb_serv:9939): Gdk-CRITICAL **: IA__gdk_drawable_get_depth: assertion 'GDK_IS_DRAWABLE (drawable)' failed The GDK library appears to be trying to load the 64-bit version of libpixbufloader-xpm.so instead of the 32-bit version Re-emerging app-emulation/emul-linux-x86-gtklibs seems to have fixed it... -- Grant Edwards grant.b.edwardsYow! So this is what it at feels like to be potato gmail.comsalad
Re: [gentoo-user] Re: Kernel 3.14.14 build failure at DEPMOD stage
On Thu, Aug 14, 2014 at 10:31:47AM +0100, Neil Bothwick wrote On Thu, 14 Aug 2014 04:24:35 -0400, Walter Dnes wrote: I still have the problem. Is there a way to manually run depmod? depmod -a 3.x.y [thimk][root][/usr/src/linux] depmod -a 3.14.14 depmod: QM_MODULES: Function not implemented Now what? Anyhow, I tried lilo -R Experimental and rebooted. It seems to work OK. I run a monolithic kernel, so modules won't be a problem. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] python-updater constantly rebuilds one same package
On 14/08/2014 18:09, Mike Gilbert wrote: On Thu, Aug 14, 2014 at 11:57 AM, Сергей protsero...@gmail.com wrote: I have looked at dev-libs/libgamin-0.1.10-r4 and dev-libs/libgamin-0.1.10-r5 ebuilds and compared them. dev-libs/libgamin-0.1.10-r5 has PYTHON_TARGETS=python2_7 (r4 had no PYTHON_TARGETS) and now python-updater doesn't rebuild libgamin. Seems like now everything is ok and it was only a portage bug. It is actually a bug with python-updater. However, we have no plans to fix it; instead, the problem will be resolved once all python-based ebuilds are migrated to python-r1.eclass and therefore utilize PYTHON_TARGETS. At that point, python-updater will become obsolete and you will no longer need to run it. Um, yeah. That's what they said about revdep-rebuild when @preserved-rebuild hit. And then again when sub-slots hit. But revdep-rebuild to this day still catches things both of those solutions missed. In Gentoo-land I have learned to be extremely wary of any statement like old xyz tool is no longer necessary :-) It seems like the 98%-2% rule is still very much in play -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Kernel 3.14.14 build failure at DEPMOD stage
On Thu, 14 Aug 2014 12:29:13 -0400, Walter Dnes wrote: depmod -a 3.x.y [thimk][root][/usr/src/linux] depmod -a 3.14.14 depmod: QM_MODULES: Function not implemented Now what? Anyhow, I tried lilo -R Experimental and rebooted. It seems to work OK. I run a monolithic kernel, so modules won't be a problem. Well, if you have no modules and CONFIG_MODULES=n you can't expect depmod to work. However, you wouldn't expect it to segfault, so a bug report is still in order. -- Neil Bothwick WinErr 815: Insufficient Memory - Only 50,312,583 Bytes available signature.asc Description: PGP signature
Re: [gentoo-user] python-updater constantly rebuilds one same package
On Thu, Aug 14, 2014 at 2:26 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On 14/08/2014 18:09, Mike Gilbert wrote: On Thu, Aug 14, 2014 at 11:57 AM, Сергей protsero...@gmail.com wrote: I have looked at dev-libs/libgamin-0.1.10-r4 and dev-libs/libgamin-0.1.10-r5 ebuilds and compared them. dev-libs/libgamin-0.1.10-r5 has PYTHON_TARGETS=python2_7 (r4 had no PYTHON_TARGETS) and now python-updater doesn't rebuild libgamin. Seems like now everything is ok and it was only a portage bug. It is actually a bug with python-updater. However, we have no plans to fix it; instead, the problem will be resolved once all python-based ebuilds are migrated to python-r1.eclass and therefore utilize PYTHON_TARGETS. At that point, python-updater will become obsolete and you will no longer need to run it. Um, yeah. That's what they said about revdep-rebuild when @preserved-rebuild hit. And then again when sub-slots hit. But revdep-rebuild to this day still catches things both of those solutions missed. In Gentoo-land I have learned to be extremely wary of any statement like old xyz tool is no longer necessary :-) It seems like the 98%-2% rule is still very much in play I have not run revdep-rebuild in over a year. If you have seen that preserve-libs is missing things, that's a a bug. Slot-operators are going to take a LONG time to get implemented tree-wide, and I agree that it may never happen. Packages which utilize PYTHON_TARGETS do not get rebuilt by python-updater anyway -- it explicitly skips them. At this point, the majority of packages that people actually use have been converted. Many users may not even need to run python-updater if they don't have USE=python enabled globally.
Re: [gentoo-user] python-updater constantly rebuilds one same package
On 14/08/2014 23:23, Mike Gilbert wrote: On Thu, Aug 14, 2014 at 2:26 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On 14/08/2014 18:09, Mike Gilbert wrote: On Thu, Aug 14, 2014 at 11:57 AM, Сергей protsero...@gmail.com wrote: I have looked at dev-libs/libgamin-0.1.10-r4 and dev-libs/libgamin-0.1.10-r5 ebuilds and compared them. dev-libs/libgamin-0.1.10-r5 has PYTHON_TARGETS=python2_7 (r4 had no PYTHON_TARGETS) and now python-updater doesn't rebuild libgamin. Seems like now everything is ok and it was only a portage bug. It is actually a bug with python-updater. However, we have no plans to fix it; instead, the problem will be resolved once all python-based ebuilds are migrated to python-r1.eclass and therefore utilize PYTHON_TARGETS. At that point, python-updater will become obsolete and you will no longer need to run it. Um, yeah. That's what they said about revdep-rebuild when @preserved-rebuild hit. And then again when sub-slots hit. But revdep-rebuild to this day still catches things both of those solutions missed. In Gentoo-land I have learned to be extremely wary of any statement like old xyz tool is no longer necessary :-) It seems like the 98%-2% rule is still very much in play I have not run revdep-rebuild in over a year. If you have seen that preserve-libs is missing things, that's a a bug. Slot-operators are going to take a LONG time to get implemented tree-wide, and I agree that it may never happen. Packages which utilize PYTHON_TARGETS do not get rebuilt by python-updater anyway -- it explicitly skips them. At this point, the majority of packages that people actually use have been converted. Many users may not even need to run python-updater if they don't have USE=python enabled globally. That's good to know - I wasn't aware that python-updater did that. -- Alan McKinnon alan.mckin...@gmail.com
