On 07/09/2012 01:42 PM, David C. Rankin wrote: Darrell, 714 cannot be the issue. Arch uses mandb: 14:00 providence:~/tde/pkg> which mandb /usr/bin/mandb The issue is something that has changed or been introduced since 6/24/12, my last build of tdebase. I have kicked off another full build with this mornings sources and will see what happens. I built tdebase with debug so hopefully it will give more details about any failure. -- David C. Rankin, J.D.,P.E.

On 07/09/2012 02:14 PM, Slávek Banko wrote: Slavek, Thanks! No, these are from the regular GIT sources I pull with the script: "switch_all_submodules_to_head_and_clean" What can I check in my GIT tree to make sure I have the latest source? I did my last update this morning at 0700 CDT (1200 zulu). Here is my latest FETCH_HEAD: 14:24 providence:~/tde/tde/.git> cat FETCH_HEAD ce6b0ebe5802b7eb26ce9ab599577bdb083d5e53 branch 'master' of http://scm.trinitydesktop.org/scm/git/tde That is what I should have right? -- David C. Rankin, J.D.,P.E.

On 07/09/2012 02:07 PM, David C. Rankin wrote: Looking at my update logs, the following are the likely candidates that could have caused the problem (if it is on my end): [2012-06-26 12:05] upgraded glibc (2.15-11 -> 2.15-12) [2012-06-26 16:00] upgraded linux (3.4.3-1 -> 3.4.4-2) [2012-07-03 11:15] upgraded gcc-libs (4.7.1-1 -> 4.7.1-3) [2012-07-03 11:15] upgraded gcc (4.7.1-1 -> 4.7.1-3) [2012-07-03 11:15] upgraded gcc-fortran (4.7.1-1 -> 4.7.1-3) [2012-07-03 11:15] upgraded gcc-objc (4.7.1-1 -> 4.7.1-3) [2012-07-05 19:59] upgraded linux-api-headers (3.3.8-1 -> 3.4.4-1) [2012-07-05 19:59] upgraded glibc (2.15-12 -> 2.16.0-1) [2012-07-05 19:59] upgraded gcc-libs (4.7.1-3 -> 4.7.1-4) [2012-07-05 19:59] upgraded gcc (4.7.1-3 -> 4.7.1-4) [2012-07-05 19:59] upgraded gcc-fortran (4.7.1-3 -> 4.7.1-4) [2012-07-05 19:59] upgraded gcc-objc (4.7.1-3 -> 4.7.1-4) Of all the updates, this is probably the one: [2012-07-05 19:59] upgraded glibc (2.15-12 -> 2.16.0-1) Can somebody who know how glibc figures into the error below, please take a look at the glibc changes in (2.15-12 -> 2.16.0-1). The Arch link to the diffs (nicely laid out is): https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=package… The original tde failure to build error was: [ 49%] Building CXX object kioslave/man/CMakeFiles/kio_man-module.dir/kio_man.cpp.o Linking CXX shared module kio_man.so [ 49%] Built target kio_man-module [ 49%] Generating kmanpart.moc Scanning dependencies of target libkmanpart-module [ 49%] Building CXX object kioslave/man/CMakeFiles/libkmanpart-module.dir/kmanpart.cpp.o Linking CXX shared module libkmanpart.so [ 49%] Built target libkmanpart-module [ 49%] Generating nfs_prot_xdr.c cannot find any C preprocessor (cpp) rpcgen: C preprocessor failed with exit code 1 make[2]: *** [kioslave/nfs/nfs_prot_xdr.c] Error 1 make[1]: *** [kioslave/nfs/CMakeFiles/kio_nfs-module.dir/all] Error 2 make: *** [all] Error 2 -- David C. Rankin, J.D.,P.E.

On 07/09/2012 02:39 PM, Darrell Anderson wrote: Well -- dunno :( Of course I 'can' roll back, but that is basically creating a new 'archroot' 'chroot' environment and specifically limiting glibc to the last 2.15-12 release on Arch. What I don't know is "How many other packages are changed and dependent on 2.16 now?" I can figure that out, but it will take some figuring. The _BIG_ question is "Why is tdebase failing with 2.16?" Think about it... Everything _else_ in the build order up to tdebase, builds _fine_ on glibc 2.16. That is: # array for Archlinux specific dependencies (remote sources) declare -a archdeps archdeps=('apetag' 'hal-info' 'hal' 'libutempter' 'xmedcon' 'libnjb' 'libkarma' 'mt-daapd') _and_ ## array of TDE modules to build (source from local GIT tree tarballs) declare -a tbo tbo=("dependencies/$useqt" 'dependencies/tqtinterface' 'dependencies/arts' 'dependencies/dbus-tqt' 'dependencies/dbus-1-tqt' 'dependencies/tqca-tls' 'dependencies/libart-lgpl' 'dependencies/avahi-tqt' 'dependencies/libcaldav' 'dependencies/libcarddav' 'dependencies/sip4-tqt' 'dependencies/python-tqt' 'dependencies/tqscintilla' # not currently building 'dependencies/tqscintilla-plugin' # not currently building 'tdelibs' 'tdebase' <snip> TQt3 and tdelibs are some huge packages to build. If there was a generic problem in glibc 2.16, I would expect to see build failures in one of those, or in the other 19 packages that build. From googling similar failures, the problem seems to be the hardcoded location of rpcgen in tdebase. Here is a similar issue found in the arch hamlib packages. I'll try a similar solution: https://bbs.archlinux.org/viewtopic.php?pid=1126084 -- David C. Rankin, J.D.,P.E.

On 07/09/2012 03:16 PM, David C. Rankin wrote: Just finished another run and still tdebase ftbfs: [ 49%] Building CXX object kioslave/man/CMakeFiles/kio_man-module.dir/kio_man.cpp.o Linking CXX shared module kio_man.so [ 49%] Built target kio_man-module [ 49%] Generating kmanpart.moc Scanning dependencies of target libkmanpart-module [ 49%] Building CXX object kioslave/man/CMakeFiles/libkmanpart-module.dir/kmanpart.cpp.o Linking CXX shared module libkmanpart.so [ 49%] Built target libkmanpart-module [ 49%] Generating nfs_prot_xdr.c cannot find any C preprocessor (cpp) rpcgen: C preprocessor failed with exit code 1 make[2]: *** [kioslave/nfs/nfs_prot_xdr.c] Error 1 make[1]: *** [kioslave/nfs/CMakeFiles/kio_nfs-module.dir/all] Error 2 make: *** [all] Error 2 Any idea where I should look first? CMakefiles? TDE code/regular Makefiles? Also -- doesn't rpcgen get called before this point in the build? Either with tdebase or in tdelibs? If so, that should at least point us to how the rpcgen call should be handled. This smells like a messed up CMakeFiles issue that wasn't caught until glibc 2.16. Like with: kioslave/man/CMakeFiles/libkmanpart-module.dir I'll pick around later tonight. Any ideas - please send them on :) -- David C. Rankin, J.D.,P.E.

On 07/09/2012 07:16 PM, Darrell Anderson wrote: Sounds like you do some 'pretty darn good guessing'... In the same spot: 22:13 archangel:/dat_e/abs/util-linux> whereis -b cpp cpp: /usr/bin/cpp That looks like the information we need for a bug report. Since the fix looks simple from this standpoint, I'll open the bug and mark it a "Blocker" for R14. Hopefully, this will be the last little 'surprise' of the gcc/glib update season. But, since we are working on making R14 the best stable TDE release to date, I want it to build and run on the current libs -- that way we get a bit of longevity from the initial release and not a flood of bug reports filed right off the bat as each distro moves to glibc 2.16. ((You really need to install and run at least one partition of Arch. Talk about the excitement of trying to iterate down to a final finished project the size of TDE when the foundation is constantly changing -- wow! It never gets old...)) Seriously, I think there has rarely been any 3 month stretch before in recent history where so many of the underlying libraries have had significant upstream changes as TDE has tried to dial in a next release -- not to mention one with the polish and improvement that TDE has undergone to get to the point of this R14 release. Little more time on the front end -- better reviews, less bugs on the backend :) -- David C. Rankin, J.D.,P.E.

As /usr/bin is a standard FHS location, I'd like to know where rpcgen is hard-coded to look for the cpp executable. I hope this is not Yet Another WTF example of egghead development. I don't have that kind of energy. :-) Rolling releases tend to sound like a great idea, but these kinds of problems discourage me from going down that road. I suspect people working with other projects have experienced the same issues. A significant difference is they have more people participating, group knowledge levels are higher and deeper, and therefore they can resolve these bumps faster. Possibly, because those other projects have many more people staying in contact with these upstream groups, I suspect these types of changes get forewarned in one manner or another to those other groups but not to us. These upstream changes greatly reflect the scratch-your-own-itch mentality. The upstream developers might forewarn everybody of upcoming changes, they might not, but they are going to do whatever they want. Not to mention that the developers who participate in these dependent upstream projects like gcc and glibc are mostly paid programmers working for the big shots in the industry, such as RedHat. They aren't going to wait for people in small projects to voice an opinion. I think the overall problem is free/libre software changes at a relentless and unforgiving pace. Free source code is just too much to resist for most software geeks, so they tweak, and they tweak, and they tweak.... :-) Darrell

On 07/10/2012 11:57 AM, Darrell Anderson wrote: Yes, the change for arch is from /lib to /usr/lib, though I haven't found the specifics for cpp. My guess at this point is that a sym link isn't being made. I'm checking all ends -- if it isn't a whacky path in tdebase, I'll report back and close the report. I haven't had the couple of hours needed to pick through this line-by-line yet. I'll hopefully get some time tonight. Nothing like having 3 kids between 7 and 13 to make that evaporate though :) -- David C. Rankin, J.D.,P.E.

On 07/09/2012 07:16 PM, Darrell Anderson wrote: GIT for dummies Q: Do you use some web based tool to query the tree on the remote server, or do you just do a good 'ole grep of your local copy? (I presume grep of the local, but I didn't know if there was some tool that provided results with links to the past commits for the found sections of code, etc...) -- David C. Rankin, J.D.,P.E.

On 9 Jul 2012, David C. Rankin outgrape: OK. This is glibc's rpcgen that's failing. It specifically searches for /lib/cpp, then for /usr/ccs/lib/cpp (I kid you not) then fails if it can't find either of them. It would be interesting to see an strace of your rpcgen, to see what it's searching for... I note that in glibc 2.14 and 2.15, the RPC calls were made unusable by newly-linked programs, and rpcgen was removed. Because no replacement was ready, this broke compilation of every RPC user out there, so most distros patched it back in. I suspect arch's patching back in failed. In glibc 2.16, RPC is back upstream again (until such time as libtirpc is *really* ready to replace it), if glibc is configured with --enable-obsolete-rpc, which absolutely every non-embedded distro will be doing. Which explains why it works with glibc 2.16. -- NULL && (void)

On 07/13/2012 12:11 PM, David C. Rankin wrote: It was either Arch or glibc 2.16 upstream, and it was the missing link in the search locations Nix provided. To solve the issue, I simply created a symlink /lib/cpp->/usr/bin/cpp and tdebase built fine. <rant> Just for the next two months, I wish upstream would QUIT DORKING WITH THE DAMN PACKAGES!!! </rant> I posted this info to the Arch list as well. http://bugs.pearsoncomputing.net/bugzilla/show_bug.cgi?id=1082 [RESOLVED] [NOTOURPROBLEM] -- David C. Rankin, J.D.,P.E.

On 07/14/2012 10:12 AM, Nix wrote: Allan McRae, one of the primary Arch developers is talking with the upstream folks about the issue. That tells me Arch will get a patch that resolves it within a day or two. -- David C. Rankin, J.D.,P.E.