Thomas Stein posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 13 Apr 2006 11:21:26 +0200:
> On Thursday 13 April 2006 11:05, Duncan wrote: > >> What USE flags did you (previously) use when compiling PAN (the new one >> doesn't have USE flags). nls? spell? Here, I'm -nls, +spell. > > Mine was +nls +spell. So it's possible it's the nls stuff. If you check the pan-0.92 ebuild, it says nls is required, and prints a warning during the merge if you have -nls. However, that's apparently not exactly the case, as I have -nls here, and haven't had issues. Maybe it means it's required for those that want foreign character support? I only read English, so find other chars pretty, but not worth the additional hassle. In any case, I haven't had issues running it, but then again, I've not run it much beyond verifying that /would/ run after compilation, because there are features slated for 0.93 that I consider a must. After that, we'll see if there are others missing that I consider a must or not, but anyway... >> Do you >> have the latest GTK/Gnome dependencies merged? Try an --update --deep >> --pretend at least, and check that you have the below versions. > > [EMAIL PROTECTED] ~ $ emerge --update --deep --pretend pan > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild U ] sys-devel/patch-2.5.9-r1 [2.5.9] > [ebuild U ] sys-kernel/linux-headers-2.6.11-r3 [2.6.11-r2] > [ebuild U ] sys-devel/gcc-config-1.3.13-r1 [1.3.12-r6] > [ebuild U ] app-misc/pax-utils-0.1.11-r1 [0.1.11] > [ebuild U ] sys-devel/binutils-config-1.8-r7 [1.8-r6] > [ebuild U ] sys-devel/gnuconfig-20060227 [20051223] > [ebuild U ] sys-libs/gpm-1.20.1-r5 [1.20.1-r4] > [ebuild U ] sys-libs/ncurses-5.5-r2 [5.4-r6] > [ebuild U ] sys-devel/m4-1.4.4 [1.4.3] > [ebuild U ] sys-devel/bison-2.1 [1.875d] > [ebuild U ] sys-apps/sed-4.1.4-r1 [4.1.4] > [ebuild U ] sys-devel/gettext-0.14.5 [0.14.4] USE="-nocxx%" > [ebuild U ] sys-apps/texinfo-4.8-r3 [4.8-r2] > [ebuild U ] sys-apps/groff-1.19.2-r1 [1.19.1-r2] > [ebuild U ] sys-libs/db-4.2.52_p4 [4.2.52_p2-r1] > [ebuild U ] sys-devel/libperl-5.8.8-r1 [5.8.7] > [ebuild U ] dev-lang/perl-5.8.8-r1 [5.8.7-r3] > [ebuild U ] app-shells/bash-3.1_p16 [3.0-r12] > [ebuild U ] app-admin/perl-cleaner-1.03 [1.01] > [ebuild N ] virtual/perl-Test-Simple-0.62 > [ebuild U ] dev-perl/Locale-gettext-1.05 [1.03] USE="-minimal%" > [ebuild U ] sys-apps/help2man-1.35.1 [1.33.1] > [ebuild U ] sys-devel/autoconf-wrapper-3.2 [3-r1] > [ebuild U ] sys-devel/automake-1.9.6-r2 [1.9.6-r1] > [ebuild U ] dev-libs/expat-2.0.0 [1.95.8] > [ebuild U ] media-libs/fontconfig-2.3.2-r1 [2.3.2] USE="-doc%" > [ebuild U ] sys-libs/readline-5.1_p4 [5.0-r2] > [ebuild U ] dev-lang/python-2.4.2-r1 [2.4.2] > [ebuild U ] sys-apps/findutils-4.3.0 [4.1.20-r2] > [ebuild U ] sys-devel/flex-2.5.33-r1 [2.5.4a-r6] USE="nls%" > [ebuild U ] app-arch/bzip2-1.0.3-r6 [1.0.3-r5] > [ebuild U ] net-nntp/pan-0.92 [0.14.2.91-r3] > > Should i upgrade those packages? My general recommendation would be yes. The idea behind ~arch is that it's a testing ground. As such, there /will/ be unstable things there from time to time, and if you get too far behind, things will quit working quite so smoothly. I'd recommend always running --deep with --update, to make sure everything continues to be up to date. If you don't have the time or commitment to do that, and to update say weekly, certainly biweekly (2x monthly), my personal feeling would be that you may be better off switching back to stable, even tho that will mean not keeping up on some things, because you aren't keeping up anyway. That said, the above is personal feeling from someone that likes to stay at the leading edge, and doesn't mind if it's actually bleeding edge on occasion, because this is my hobby, and the challenge of detecting the problem and fixing a semi-broken system occasionally is what keeps it interesting enough to keep coming back for more. It's unfair to expect everybody that likes experimenting with the occasional leading/bleeding edge software to think the same way. Specifically, most of those packages should be sufficiently remotely related as to not be critical for pan. The toolchain list I posted earlier /is/ going to be critical in general for a Gentoo system, and the below list is likely to be critical for PAN, but most of the above shouldn't be. A couple exceptions that could be a problem that I missed, earlier: autoconf-wrapper: This wraps autoconf, helping to select the correct version, so it's a critical part of the toolchain. Keep it updated along with autoconf and the rest of the earlier list I posted. Didn't I mention automake in the previous list, and you said you'd updated it? Yes. Anyway, update that and best keep it updated, as it's a pretty commonly used bit of the toolchain. m4: A toolchain package I forgot about. Keep it updated. gnuconfig: I'm not sure on this one but I'd update it just in case. gettext and Locale-gettext: i18n stuff with which I'm not that familiar, but I'd update it, particularly since you have nls in your USE flags. !!! VERY BIG WARNING AND CAVEAT !!! If you upgrade expat to 2.x, you *WILL* have a significant number of broken apps, until you run revdep-rebuild (unless they've done something to fix it in the last few days). There *WILL* be a rather large list of broken stuff to rebuild to get things working again. Additionally, ensure you've updated gentoolkit (which contains revdep-rebuild) before trying the expat upgrade, because a recent upgrade there works around a nasty bug that's common on Gentoo AMD64 systems. (The bug isn't in revdep-rebuild itself, but the profile or portage or baselayout or something, but revdep-rebuild works around it with the latest gentoolkit.) There have been a number of folks bitten by both the expat upgrade thing, and the fact that revdep-rebuild wasn't finding all the breakage. I was one of them, thus the warning. So... don't do the expat-2.x upgrade until you have a good block of free time to rebuild all the stuff it will break. > [EMAIL PROTECTED] ~ $ emerge -p libgnome libbonobo glib gtk+ pango atk orbit > gnome-vfs libpcre gtkspell > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild R ] gnome-base/libgnome-2.12.0.1 > [ebuild R ] gnome-base/libbonobo-2.10.1 > [ebuild R ] dev-libs/glib-2.8.6 > [ebuild R ] x11-libs/gtk+-2.8.13 > [ebuild R ] x11-libs/pango-1.10.4 > [ebuild R ] dev-libs/atk-1.10.3 > [ebuild R ] gnome-base/orbit-2.12.5 > [ebuild R ] gnome-base/gnome-vfs-2.12.2 > [ebuild R ] dev-libs/libpcre-6.6 > [ebuild R ] app-text/gtkspell-2.0.11-r1 > > So those are the same versions i guess. =8^) >> As I said, eventually, you should have very close to what I have, such >> that when I configure to use the same gcc and binutils you have and run >> the merge, I should get very similar results. We'll see. > > Thanks again Duncan. I had hoped to do the compile here overnite, but time got away from me and I didn't get it done. I work this evening and should be going to bed shortly, but I have Friday off, so will try to get it tested no later than Saturday (0.93 s/b out this w/e too, I believe), and hopefully Friday AM (US) after work. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
