Re: [blfs-support] Audacity, and its help.
On Fri, Apr 18, 2014 at 01:27:14AM +0100, Ken Moffat wrote: > > The docs, as noted, unzip as a help/ directory and it looks for > that in /usr/share. Hit the full-stop too soon there. It looks in /usr/share/audacity/. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Audacity, and its help.
On Thu, Apr 17, 2014 at 02:48:36PM -0500, Douglas R. Reno wrote: > Are there any specific dependencies for Audacity that aren't generic > (Generic being GTK or QT)? I use it all the time on my Windows PC but now > that I know it exists for Linux I am interested on trying it on my LFS box. > > Douglas Reno Oh yes, at least two ;-) Please bare in mind that I've already got a _fat_ set of audio tools for handling old things (including mp3, ogg) and for dealing with flac files. I'm trying to use audacity to edit some rips from vinyl so that I can stream them - got a Tascam DR-05 [ none of the reviews mentioned the external input is at microphone level, and my preamp puts out about 1V on the tape outputs - fortunately I've got a spare second output for a power amp which is usable at normal levels ]. So, I don't intend to use audacity for recording, and along the way I'm pulling in things that might not be necessary or indeed useful to me (everything will be wav or flac), such as libid3tag. According to the audacity website, it needs wxwidgets (wxGTK) and libsndfile, and recommends libsoxr. In practice, what it actually needs is the 2.8 version of wxpython : wxPython-src-2.8.12.1. Gentoo say: # we use the wxPython tarballs because they include the full wxGTK # sources and # docs, and are released more frequently than wxGTK. From wxpython at sourceforge. My build is based on gentoo, with one addition : ./configure --prefix=/usr \ --with-opengl \ --enable-unicode --enable-graphics_ctx \ --with-regex=builtin \ --with-libpng=sys \ --with-libxpm=sys --with-libjpeg=sys \ --with-libtiff=sys \ --with-sdl \ --enable-shared \ --with-zlib=sys --with-expat=sys Comments on some of these: --with-opengl : is for Mesa. --enable-graphics_ctx : found that used at Arch, it is a 2D drawing library, might be useful. --with-sdl : apparently SDL provides the audio on unix systems using wxgtk, so probably needed for audacity to be able to play things, and is in BLFS. Follow by make && make install && ldconfig (the install output says that is needed on linux). libsndfile is in BLFS. libsoxr : soxr-0.1.1-source from soxr at sourceforge - requires cmake. I take the opportunity to link to libavcodec from current ffmpeg (which pulls in a shed-load of other AV libs used by my ffmpeg builds). So, I'm running cmake -DCMAKE_INSTALL_PREFIX=/usr \ -DDOC_INSTALL_DIR=/usr/share/doc/soxr-0.1.1 \ -DWITH_AVFFT=yes \ -Wno-dev .. followed by make && make test && make install I _suppose_ that I could have gone with the version shipped in audacity, since nothing else is liekly to use it. Audacity is old (I don't mean that the current release is especially old, more that the 2.0 series started a long time ago - not only does it require a very old version of wxgtk, it can only build against versions of ffmpeg < 1.0. At one time, I tried putting a maintained old ffmpeg in /opt for transcode - but that was always a PITA, and now we patch transcode to let its critical tool work. So for this, I don't try to link audacity against ffmpeg - if I ever have need of ffmpeg, I'll use that separately. The sources are audacity-minsrc-2.0.5 and audacity-manual-2.0.5.zip. I'm using the following from the versions shipped with audacity - libnyquist, libvamp, portsmf, sbsms. Please note that soundtouch is NOT shipped with audacity, despite what the docs say, and that if you enable libsamplerate the preferred libsoxr will be disabled. I've configured with ./configure --prefix=/usr --docdir=/usr/share/doc/audacity-2.0.5 \ --with-libsndfile=system \ --with-expat=system \ --with-libsoxr=system \ --with-libvorbis \ --with-libmad \ --with-libflac \ --with-libid3tag \ --with-sbsms \ --with-soundtouch \ --with-ffmpeg=no \ --with-alsa The docdir is not particularly important (just LICENSE.txt and README.txt), but since the manual is version-specific I also install it there and symlink it from /usr/share/audacity/help. I don't use the thing known as pulse, no idea if it can be used (and no interest in it). I do know that jack can be used, but that is more than I need. For what I'm doing libflac may be useful, the other AV libs maybe not. I see that I've still got --with-soundtouch : that gives me - configure: Libsoundtouch libraries are NOT available as system libraries checking for ./lib-src/soundtouch/include/SoundTouch.h... no configure: libsoundtouch libraries are NOT available in the local tree but it didn't break the build. Guess I'll drop that switch. The package is in BLFS, but I don't have any obvious reason to use it. Actually, configure didn't recognize at least one of my options - I didn't spot that earlier, and I've no idea which it dislikes. Ah, that is only reported in the lib-widget-extra directory, and that has picked up --with-wx-config [ unterminated - in another directory it got =/usr/bin/wx-config ] : looks like a configure bug. Follow with make && make install. 'make check' exists
Re: [blfs-support] Audacity, and its help.
On Wed, Apr 16, 2014 at 11:45:19PM +0100, Ken Moffat wrote: > Anybody here using audacity ? If so, do you have any idea what the > secret is for making the local help show up, please ? > > I've downloaded audacity-manual-2.0.5.zip and installed it (help/ > directory) in /usr/share/audacity, but firing up the program still > fails to open it. I suspect that I maybe need to do something to > set a default browser, or perhaps set a symlink for mozilla [ I only > recently stopped doing that, nothing I then used needed it ] but at > the moment I'm clueless. The strace output from starting audacity > and trying to open the help/manual is large and I don't know what > I'm looking for :-( > > ĸen Got a hint at almost 36000 lines into the strace output - it tried to stat xdg-open, then went swanning off through mime types, defaults.list, mimeapps.list [ don't think I've got any of those last two ], and then for some reason it seemed to read all my .desktop files. Adding xdg-utils has fixed it for me (the quick help and the manual now open in firefox). Not sure if that is because of something I've done in the past to set up firefox as my default browser (~/ is shared between each LFS/BLFS system I build on this box) : I tried interrogating xdg-settings, but just got: ken@ac4tv ~ $xdg-settings get default-web-browser xdg-settings: unknown desktop environment which is true (I don't have a DE) but not useful. For me, the problem is now solved. For anyone else who gets this problem, YMMV. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Audacity, and its help.
Anybody here using audacity ? If so, do you have any idea what the secret is for making the local help show up, please ? I've downloaded audacity-manual-2.0.5.zip and installed it (help/ directory) in /usr/share/audacity, but firing up the program still fails to open it. I suspect that I maybe need to do something to set a default browser, or perhaps set a symlink for mozilla [ I only recently stopped doing that, nothing I then used needed it ] but at the moment I'm clueless. The strace output from starting audacity and trying to open the help/manual is large and I don't know what I'm looking for :-( ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] rpcbind-0.2.1 build fails
On Tue, Apr 15, 2014 at 07:35:59AM +1000, Ian Macdonald wrote: > Ken, > > That seems to be the problem. My LFS build is 7.4 and the glibc-2.18 configure > options did not include --enable-obsolete-rpc (but did copy the headers to > /usr/include). > I'm guessing that means libtirpc installs because the headers were there but > they are not compiled into glibc. > My memory says that --enable-obsolete-rpc is just a quick and easy way of copying the headers :-( > My question now is: Is it safe to re-build glibc-2.18 with the > --enable-obsolete-rpc > option or do I have to build L(FS)(FS)? I don't think rebuilding glibc will help, and I'm not sure if the option exists in glibc-2.18. My first thought was to point you to the 7.4 BLFS book, which used 0.2.3 : http://www.linuxfromscratch.org/blfs/view/7.4/basicnet/libtirpc.html But I've now looked at my own git commits for the buildscripts I use. I see that I only updated to libtirpc-0.2.4 in February, as part of a catch-up to what was already in BLFS. Looking at the diff, I see that BLFS has moved libtirpc.so to /lib and created a versioned symlink from /usr/lib. I guess that you have a problem with the symlink ;-) [ I've lost count of the number of times _I_ create broken symlinks in my own builds. ] ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] rpcbind-0.2.1 build fails
On Mon, Apr 14, 2014 at 06:22:54AM +1000, Ian Macdonald wrote: > Hi, > > I am trying to build rpcbind-0.2.1 from the current book but make fails > with undefined references to > key_encryptsessions_pk > key_gendes > cbc_crypt > ecb_crypt > getnetname > getpublickey > > all from libtirpc. > > libtirpc-0.2.4 is installed as per the book with --disable-gssapi. > > It looks like a missing dependency ( encryption related?) and I don't > need encryption. > > Any hints much appreciated. > Google thinks that ecb_crypt comes from glibc, although it is of course possible that things have changed recently. Looking to see what it finds for getpublickey libtirpc took me to http://webcache.googleusercontent.com/search?q=cache:94LUO-Dtx-8J:comments.gmane.org/gmane.linux.lfs.support/35000+&cd=4&hl=en&ct=clnk&gl=uk (For some reason, clicking on the direct link from google's results gave me a formatted page for the list, but with no content. So I took a look at the cached version). The old rpc headers problem. If this is not LFS-7.1, perhaps you failed to install the glibc rpc headers. See LFS chapter 6 glibc for whichever version you are using (-enable-obsolete-rpc for LFS-7.5). We used to go into detail somewhere in BLFS to ensure that the rpc headers had been installed (specifically re LFS-7.1), but at the moment I can not spot where that is. My reading of your problem is that libtirpc compiled and installed ok, but rpcbind is failing to link. I _thought_ libtirpc usually failed to install if the headers were missing. Maybe I'm misreading the problem - is this LFS-svn from the last couple of weeks (it was ok on about 31st March, but conceivably something in the changes to include systemd might have broken things although that seems unlikely) ? I'm also in awe of "I don't need encryption". Wish I could share that sentiment ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] libreoffice-4.2.2, java, jdbc and postgresql questions
On Sat, Apr 12, 2014 at 03:20:37PM +0100, lux-integ wrote: > > I noticed the above blfs recipe has these switches > > --disable-postgresql-sdbc \ > --without-java > From memory, postgresql and java are among the default options. Most BLFS users probably don't build either of them, or want them. As to your other questions, I have no idea. For postgresql in /usr/local I would expect it to be found [ and if you had different versions in /usr and /usr/local I would expect the version in /usr/local to be used ], but LO is a very long compile, even with -j4, and my guesses might not match what it really does. So if you don't get definitive answers you should expect to try to build it several times, and to log the builds so that you can find the first error message if it does fail. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Heartbleed
On Tue, Apr 08, 2014 at 08:55:01PM +0100, Ken Moffat wrote: > On Wed, Apr 09, 2014 at 03:41:16AM +0100, lux-integ wrote: > > > > openssl is a package one generally installs early in the > > distribution-build > > process. To upgrade to say openssl-1.0.1g > > --(a) does one need to yank out the old say openssl-1.0.1 and install the > > new > > 1,0,1g and if so would there not be breakages? OR > > --(b) can one install openssl-1.0.1g over the old version of say > > openssl-1.0.1 ? > > > > advice from anyone on list will be much appreciated > > > > With the instructions used in recent versions of BLFS (in > particular, shared libraries), just drop it over the top. If you > are _serving_ anything which links to openssl then you will need to > bounce those services (i.e. stop them and restart them). For a > desktop, I guess that closing the browser(s) and reopening those > should be sufficient. > > ĸen Whoops, that is badly WRONG. At lwn.net [ thread https://lwn.net/Articles/593683/ - might be subscriber only ] someone suggests running this after the upgrade : grep -l 'libssl.*deleted' /proc/*/maps | tr -cd 0-9\\n | xargs -r ps u (as root) On my current desktop machine that shows the following : root 2206 0.0 0.0 37016 1260 ?Ss Apr06 0:00 /usr/sbin/cupsd -C /etc/cups/cupsd. root 2416 0.0 0.0 27736 512 ?Ss Apr06 0:00 /usr/lib/postfix/master -w postfix 2418 0.0 0.0 27968 668 ?SApr06 0:00 qmgr -l -t unix -u ken 2828 0.0 5.8 1384924 232188 ? Sl Apr06 1:37 /usr/lib/libreoffice/program/soffic So in my desktop case I need to bounce cups and postfix, and also to close my current LO documents. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Heartbleed
On Wed, Apr 09, 2014 at 03:41:16AM +0100, lux-integ wrote: > > openssl is a package one generally installs early in the distribution-build > process. To upgrade to say openssl-1.0.1g > --(a) does one need to yank out the old say openssl-1.0.1 and install the > new > 1,0,1g and if so would there not be breakages? OR > --(b) can one install openssl-1.0.1g over the old version of say > openssl-1.0.1 ? > > advice from anyone on list will be much appreciated > With the instructions used in recent versions of BLFS (in particular, shared libraries), just drop it over the top. If you are _serving_ anything which links to openssl then you will need to bounce those services (i.e. stop them and restart them). For a desktop, I guess that closing the browser(s) and reopening those should be sufficient. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] xine-ui-0.99.7 build failure
On Mon, Apr 07, 2014 at 11:24:15PM +0200, Pierre Labastie wrote: > Le 07/04/2014 22:24, Robin a écrit : > > On 7 April 2014 19:46, Robin wrote: > >> ^ > >> network.c: In function ‘main’: > >> network.c:1258:39: error: ‘CPPFunction’ undeclared (first use in this > >> function) > >>rl_attempted_completion_function = (CPPFunction *)completion_function; > >>^ > >> [...] > >> Seems to match https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741847 > Some packages are still using functions which have been deprecated in readline > since 2004... As of readline 6.3, these function are not available anymore, so > the said packages fail... > I guess we may expect to find a few other places where this hits... > I create a ticket for xine-ui, but do not fix it tonight, it is too late... > Pierre It's on my ToDo list as part of xine-ui-0.99.8. The upstream patch is already in -patches. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Graphite2-1.2.4 make check no target check
On Mon, Apr 07, 2014 at 12:02:21PM +0100, Robin wrote: > make test works > > Thanks > ISTR someone (probably Fernando, or else Pierre) fixed this in the last couple of weeks in the -svn book. Mea culpa. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Wrong prompt and “file not found” with xterm – BLFS 7.5
On Thu, Apr 03, 2014 at 09:21:34AM -0500, rhubarbpie...@gmail.com wrote: > > This is a stretch, but I should mention I compiled BLFS/X with an older > kernel than I used in compiling LFS. I found I booted to a blank screen > after compiling LFS with the 3.13.13 kernel so I reverted to my LFS/BLFS > 3.10.10 kernel. I did post the problem to LFS support "Blank screen > when booting with 3.13.3 kernel. - LFS 7.5" but didn't get a resolution > and wasn't told I couldn't use an older kernel. It was a surprise to me > I could revert to an older kernel. I specifically asked the question in > my post. I will re-compile LFS with the 3.10.10 kernel if suggested. > I thought you did get a reply to that point, but it looks as if I'm confusing it with a different thread and perhaps that was on lfs-support. Short answer : as long as the kernel version is at least what you used for --enable-kernel= when compiling glibc everything should continue to work. I say "should" because you have already discovered that things sometimes break with newer releases, and equally newer releases contain fixes for older versions. In awkward areas (I'm guessing you have an intel video controller), fixes for some machines can break other machines. By the same token, an up-to-date kernel release might have already fixed the problem. But getting a working term in X is obviously more important. > I should also mention I've continued past my basic X installation and > have no problems other than xterm. I can run X, connect to the > internet, and run all programs I ran with BLFS 7.4 without incident. > My evil twin suggests that you build a better terminal (urxvt), but that would be working around the problem even if it did work for you. And to be honest I'm not at all convinced it will help, and it would definitely need to be configured [ in .XResources or wherever, and ensure that gets pulled in with "xrdb -merge /path/to/resources] so there would be more things which could go wrong. Apart from what Bruce has suggested, compare _all_ the bash files in your 7.5 and 7.4 builds. Is /home shared by the two builds ? If it isn't, also compare the bash files for your regular user account. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Wrong prompt and “file not found” with xterm – BLFS 7.5
On Wed, Apr 02, 2014 at 11:37:40AM -0500, rhubarbpie...@gmail.com wrote: > > I should mention I can't even bring up an xterm window if I start X as a > non-root user. The window flashes briefly and disappears. Also, while > using a root user xterm, I can't "source SomeScript.sh" but can > "./SomeScript.sh." > I'm starting to think that you have more than one problem. They might be related, but you probably need to tackle one at a time. I think it might be easier to start with the xterm-for-regular-user problem. I guess you are trying to do this from your .xinitrc file, so I would _log_ the output of startx (both stdout and stderr), and end X as soon as you can after the term window has disappeared. Then look at the stdout/stderr messages and also the log from X itself, and perhaps the system log too [ segfaults often show up in that ]. You might also try the same thing on the non-broken system, to compare the messages - X generally reports a lot of things, some of which can look scary [ particularly when shutting X down ] but what you want to examine are the new/different messages from the broken system. > I'm really at a loss as to how I messed this up. > That's the "joy" of this pasttime - we each get to make our own unique mistakes, and then try to reassemble something from the broken pieces. With luck, we learn from whatever we do wrong and also remember enough to either not make the same mistake again, or at least to recognise it when we do. Generally, understanding what we have done wrong only comes when we have understood the resulting problem. And sometimes the explanation for what really triggered it may only become apparent _much_ later, at least in my own experience. For the moment, concentrate on understanding the problem(s), and then on resolving it/them. Unfortunately, you have to do most of the legwork yourself. Sometimes, 'strace' is sort-of-useful in finding where a program is getting an unexpected result [ albeit with voluminous output ], but I think you first need to pin down where a problem is happening. At the moment, all I can do is try to encourage you and wish you good luck. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Wrong prompt and “file not found” with xterm – BLFS 7.5
On Tue, Apr 01, 2014 at 06:15:05PM -0500, rhubarbpie...@gmail.com wrote: > > My BLFS 7.5 xterm displays a “sh-4.2#” prompt. My xterm prompt in BLFS > 7.4 is “/ >” and “PS1=”\w > “ is in my BLFS 7.5 /etc/bashrc file. In > addition to the wrong prompt, I can't “source” scripts, and receive > “file not found.” LFS 7.5 seems to be working fine, with the correct > prompt and without “file not found” or sourcing problems. > > I've apparently done something wrong with X. I've re-read the > documentation but am flat-out not seeing my error. What should I check? Since you are running as root (the '#' in the prompt), check root's .bashrc (if it exists) and .bash_login. In particular, check anything setting the path. Also, if bash is invoked as 'sh' the behaviour is apparently different. See the "source filename" explanation in 'man bash'. Alternatively, perhaps ~/ (i.e. /root) is not writable by root. Or even not readable. I was going to suggest you checked that '/' and '/tmp' were not full [ that would be 100% full for root, including any reserved space ], but I guess that if X starts then it has managed to write in /tmp. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Building Poppler
On Sun, Mar 30, 2014 at 01:06:34PM -0300, Fernando de Oliveira wrote: > > Meanwhile, I just found that "CMake build system" was introduced in > 2008, so, I am wondering why devs in the book kept considering only > autotools build. I've seen a comment about problems with glib-side > developers of poppler regarding cmake, but these are old, from 2010. > At that time, cmake was not only weird to use (just as it is now), it also had obscure dependencies such as xmlrpc which was needed if you wanted t make cmake use the system libs - at that time it needed all of the system libs, or else it would use its own versions for all of them. Also, at that time the only thing in BLFS which required cmake was kde4. Personally, I've only recently started to use cmake in my normal builds (for graphite2). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] NPAPI-SDK-0.27.2
On Fri, Mar 28, 2014 at 01:20:04PM +1300, m...@pc-networking-services.com wrote: > Hello, > > With the npapi sdk there is only three .h files and an index.html page > included in the unpacked archive. > > > The instructions state to run configure and make install. > > I have created the directory that was mentioned as the installation > directory and copied the three header files to there. Is that all that > needs to be done for that sdk? > > I guess the configure and install instructions are not correct for this. > And I guess you have a bad download of that tarball. My logs show that four headers, together with the .pc file, were installed. Does your download's md5sum match what is in the book ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Not able to start the Xorg.
On Fri, Mar 28, 2014 at 01:08:56AM +1300, m...@pc-networking-services.com wrote: > > Hello, > > There is one more driver to try: > > Xorg Fbdev Driver-0.4.4 > > This one is meant to be if all else fails it should start the server > unless you have not installed ALL of the software excluding the other > drivers in the Xorg section. If you have left out any of the components > in that section, as David stated it will not work. > > If you could also attach a copy of the .config file from your kernel. > > Also an output of dmesg. For that do dmesg > test so that we can see the > full output of what is actually going on. > > Regards, > > Christopher. > I've got a slightly different request: Did X manage to create a log in /var/log ? If it did, what does it say ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Iced Tea again!!!!!
On Sun, Mar 23, 2014 at 11:30:01PM +1300, m...@pc-networking-services.com wrote: > > Em 23-03-2014 06:15, m...@pc-networking-services.com escreveu: > >>> On Sun, Mar 23, 2014 at 01:01:18PM +1300, m...@pc-networking-services.com > >>> wrote: > >> When people are TESTING the versions of the book before making them a > >> release I am having a very hard time believing that what they are doing > >> to > >> compile the package and what they have written that they have done are > >> the > >> exact same things. If they were, then someone such as me who is > >> following > >> through the written instructions and copying and pasting them exactly > >> would be able to make it work from a bare hard drive. This is clearly > >> not > >> the case. We (the editors) are human - like everybody else, we sometimes make mistakes. I think that only Bruce and Pierre use jhalfs to convert the book's xml into scripts - for me it doesn't work beause my /sources directory is an nfs mount and I do not want to start building in it. In any case, with all the optional deps it is not practical to cover every possibility. > > I get the point you make Fernando. I am sorry but I have written > technical documentation myself for server setups and I guess I have a > different approach with regards to it. I am frustrated because I HAVE > followed the instructions to the letter. > > I do not script ANYTHING if I can avoid it. I like to see what is going > on and fix any issues that come up. If you are building something more than once, scripting ensures that you do the same thing each time. It is also part of the 'nix tradition - a reach set of commandline tools to help with day-to-day tasks. > > My approach to testing technical writing is to do the installation and > document every step that I have done at the time and after the > installation is completed, then I expand my notes and put it into proper > sentences and steps, then I go through the server setup as per my own > written instructions and make sure that they are correct. > > Sorry for sounding harsh, I am not meaning to be. > That is, I think, how most of us test additional packages. > I also notice that the issues I am having are to do with the fact that the > > SYSTEMD version of the BLFS book was taken offline. I have downloaded the > svn copy and am trying to get it converted to html so I can see the > differences. > I'm surprised that this now appears to be a systemd issue - I had assumed that all the pain there would be in replacing bootscripts. But, the links in other posts seem to bear that out. So, you should probably look at other distros using systemd - probably fedora and arch will be your best bets - to see if there is anything relevant there. Links in : http://www.linuxfromscratch.org/blfs/view/svn/introduction/beyond.html ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Iced Tea again!!!!!
On Sun, Mar 23, 2014 at 01:01:18PM +1300, m...@pc-networking-services.com wrote: > Hello, > > Well this is ridiculous. I have reached the point after a few days of > installing the systemd 7.5 version of LFS, and going through the > configuration of quite a number of other packages following BLFS 7.5 > stable to the point of having a working graphical interface, so decide now > is a good time to install java again. > > I set everything up as per the instructions, which I did when I first set > it up following the previous version of LFS. > > This time round though I can NOT even get the blasted thing to compile. I > have even reverted back to the iced tea 2.4.1 and get EXACTLY the same > message. > > Please note that in between changing the versions I have deleted the files > for the CURRENT 7.5 stable version. The only thing that I did not do was > to delete /usr/share/java before extracting the earlier binary and > supporting files. > > BOOT_JAR_CMD = /opt/icedtea-2.4.1/bootstrap/jdk1.6.0/bin/jar > BOOT_JARSIGNER_CMD = /opt/icedtea-2.4.1/bootstrap/jdk1.6.0/bin/jarsigner > JAVAC_CMD = > JAVAH_CMD = > JAVADOC_CMD = > > Build Platform Settings: > USER = root > PLATFORM = linux > ARCH = i586 > LIBARCH = i386 > ARCH_FAMILY = i586 > ARCH_DATA_MODEL = 32 > ARCHPROP = i386 > ALSA_VERSION = 1.0.27.2 > OS_VERSION = 3.13.3 [requires at least 2.6] > OS_VARIANT_NAME = Linux From Scratch > OS_VARIANT_VERSION = 7.5-systemd > MB_OF_MEMORY = 1504 > > GNU Make Settings: > MAKE = /usr/bin/make > MAKECMDGOALS = sanity > MAKEFLAGS = w > SHELL = /bin/sh > > Target Build Versions: > JDK_VERSION = 1.7.0_40External File/Binary Locations: > USRJDKINSTANCES_PATH = /opt/java > BUILD_JDK_IMPORT_PATH = /NOT-SET/re/jdk/1.7.0_40/promoted/latest/binaries > ALT_BUILD_JDK_IMPORT_PATH = > JDK_IMPORT_PATH = /opt/icedtea-2.4.1/bootstrap/jdk1.6.0 > ALT_JDK_IMPORT_PATH = /opt/icedtea-2.4.1/bootstrap/jdk1.6.0 > LANGTOOLS_DIST = > ALT_LANGTOOLS_DIST = /opt/icedtea-2.4.1/openjdk.build-boot/langtools/dist > CORBA_DIST = > ALT_CORBA_DIST = /opt/icedtea-2.4.1/openjdk.build-boot/corba/dist > JAXP_DIST = > ALT_JAXP_DIST = /opt/icedtea-2.4.1/openjdk.build-boot/jaxp/dist > JAXWS_DIST = > ALT_JAXWS_DIST = /opt/icedtea-2.4.1/openjdk.build-boot/jaxws/dist > HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR > ALT_HOTSPOT_DOCS_IMPORT_PATH = > HOTSPOT_IMPORT_PATH = /opt/icedtea-2.4.1/openjdk.build-boot/hotspot/import > ALT_HOTSPOT_IMPORT_PATH = > /opt/icedtea-2.4.1/openjdk.build-boot/hotspot/import > HOTSPOT_CLIENT_PATH = > /opt/icedtea-2.4.1/openjdk.build-boot/hotspot/import/jre/lib/i386/client > ALT_HOTSPOT_CLIENT_PATH = > HOTSPOT_SERVER_PATH = > /opt/icedtea-2.4.1/openjdk.build-boot/hotspot/import/jre/lib/i386/server > ALT_HOTSPOT_SERVER_PATH = > CACERTS_FILE = ./../src/share/lib/security/cacerts > ALT_CACERTS_FILE = > CUPS_HEADERS_PATH = /usr/include > ALT_CUPS_HEADERS_PATH = > > OpenJDK-specific settings: > FREETYPE_HEADERS_PATH = /usr/include > ALT_FREETYPE_HEADERS_PATH = > FREETYPE_LIB_PATH = /usr/lib > ALT_FREETYPE_LIB_PATH = > > Previous JDK Settings: > PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE > ALT_PREVIOUS_RELEASE_PATH = > PREVIOUS_JDK_VERSION = 1.6.0 > ALT_PREVIOUS_JDK_VERSION = > PREVIOUS_JDK_FILE = > ALT_PREVIOUS_JDK_FILE = > PREVIOUS_JRE_FILE = > ALT_PREVIOUS_JRE_FILE = > PREVIOUS_RELEASE_IMAGE = /opt/icedtea-2.4.1/bootstrap/jdk1.6.0 > ALT_PREVIOUS_RELEASE_IMAGE = > > MILESTONE = fcs > RELEASE = 1.7.0_40-blfs > FULL_VERSION = 1.7.0_40-blfs-b31 > BUILD_NUMBER = b31 > > WARNING: This build does not include running javadoc. > > WARNING: The version of unzip being used is older than >the required version of '5.12'. >The version of unzip found was ''. > > WARNING: The version of zip being used is older than >the required version of '2.2'. >The version of zip found was ''. > > ERROR: The version of make being used is older than >the required version of '3.81'. >The version of make found was ''. > > ERROR: Your BOOTDIR environment variable does not point >to a valid JDK for bootstrapping this build. >A JDK 7 Update 40 build must be bootstrapped using >JDK 1.6.0 fcs (or later). >Apparently, your bootstrap JDK is version >Please update your ALT_BOOTDIR setting and start your build again. > > Exiting because of the above error(s). > > make/sanity-rules.gmk:71: recipe for target 'post-sanity' failed > make[1]: *** [post-sanity] Error 1 > make[1]: Leaving directory '/opt/icedtea-2.4.1/openjdk-boot' > Makefile:2465: recipe for target 'stamps/icedtea-boot.stamp' failed > make: *** [stamps/icedtea-boot.stamp] Error 2 > > I went to the icedtea wiki page at: > > http://icedtea.classpath.org/wiki/CommonIssues > > and it has the exact message about the ALT_BOOTDIR and it suggested > reco
Re: [blfs-support] Solution for twm complaining about lacking fonts
On Fri, Mar 21, 2014 at 09:24:26PM -0500, Bruce Dubbs wrote: > m...@pc-networking-services.com wrote: > > Hello, > > > > When we install xorg following the BLFS_7.5 stable book, when you first > > start x using the startx command, it will complain bitterly about the ISO > > fonts are lacking and it will NOT correctly bring up twm with the three > > windows and clock. (If you installed the clock.) > > > > To solve this issue you need to actually install the international fonts: > > > > ftp://ftp.openbsd.com/ports/distfiles/intlfonts-1.2.tar.gz > > > > After I installed these fonts I actually rebooted my computer and when I > > issued the startx command, after a couple minutes twm started correctly > > and the clock also came up correctly. > > > > Maybe it would be a good idea to add this to the user notes or to the xorg > > instructions page. > > > > This is easily verified by doing a completely fresh install and testing. > > Do you have the LANG or LC_* environment variables set? I've never > loaded intlfonts and have never had a problem. > > Also, you must have a really slow system. For me, twm comes up in about > 2 seconds. > >-- Bruce > I agree that the intlfonts are not normally needed - I don't usually build twm, but I used it when testing BLFS-7.4 in en_GB.UTF-8. What particularly puzzles me about the suggestion that it is needed, is that BLFS has _all_ the "legacy" core fonts, i.e. the current versions of every font which used to be included in the last monolithic xorg. Many people will not need all the core fonts! One of the adobe 75 or 100 dpi fonts, and perhaps misc-misc, should cover all the bases in an English or N.W. European locale. For modern terms (unfortunately, not xterm), TrueType/OTF fonts are the way to go. A look at the intlfonts suggests they are needed for emacs (i.e. for coverage of everything which emacs can support - for UTF-8 users that seems unlikely, all the main UTF-8 glyphs were added to the core fonts back in XFree86 days and only recent things like the new Turkish Lire symbol should cause problems. But on the second point (slowness) - I've seen xorg taking a significant time to start the first time on *two* builds since, I think, last October. I think one was when I was testing things for make-4.0, the other time was one of my four 7.5 builds and I believe they happened once on each of my two main machines. In each case, the subsequent runs of 'startx', whatever the wm, were at normal speed. I didn't measure how long either slow start took (wasn't expecting it to be slow), but I would be surprised if it was more than a minute each time - that _is_ on a reasonably fast machine (phenom, 3.4GHz, and Sandy Bridge, I think 3.2 GHz), so if it is the same problem, a slow machine could well take two minutes. Whatever, for me this has only ever happ0ened the first time I run startx. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] garbled text
On Wed, Mar 19, 2014 at 09:53:49PM -0400, Andrew Warshall wrote: > On Thu, 20 Mar 2014 00:35:01 + > > Hi- > >The versions are mostly current. (I built basically the svn, and it >was within the last month.) Cairo is 1.12.16. One thing that isn't >so current is xorg; I basically built a straight 7.7 (as opposed to >the newer versions in the book). So that's xorg-server 1.12.2. A quick google suggested that was released in June 2012 ? If so, you are missing all of the vulnerability fixes which came to light around July 2013 - as well as all the various bug fixes throughout xorg. We've recently been reasonably good at keeping the xorg versions current. Yes, there is always a possibility of breakage with the latest and greatest, but for common video drivers it is reasonably-well tested. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] garbled text
On Wed, Mar 19, 2014 at 04:34:40PM -0400, Andrew Warshall wrote: > Hi- > >Been using LFS/BLFS as my main system for almost 8 years now, >recently did my 6th build; so thanks! This one has the "feature" >that text on-screen sometimes (infrequently) becomes garbled to the >point of illegibility. I can make it come back (usually) by forcing >the program to redraw it, or clicking on it, or the like. This can >happen to lines in text entry boxes, menu items, spreadsheet cells >--- I would guess anything, really. I've seen it in Emacs, Gnumeric >and Firefox. Note that Emacs and Gnumeric use GTK3 while Firefox >still uses GTK2, so it's unlikely to be a GTK bug per se (though it >could be a bug in a GTK dependency). Searching the web has >revealed nothing apparently useful. Where do you suggest I look? > >Thanks in advance, > >Andrew Warshall You don't say which versions you are using. There _was_ a past bug with cairo or the xorg-server (apparently, a particular version of cairo triggered it in the newer xserver), but that was all-but two years ago : the thread appears to start at http://osdir.com/ml/blfs-support/2012-04/msg2.html (I say "appears" because Tobias was referring to something Andy had written). I don't use emacs, and now only use gnumeric for testing the book (and it worked for me in BLFS-7.5, although I didn't use it a lot). I haven't seen that sort of problem in current firefox versions for a very long time. So, is this a very old version of the book ? Or perhaps you are using very recent BLFS-svn ? (I haven't updated packages on my systems, except gnutls/sqlite/nss/nspr/firefox, since BLFS-7.5). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Cyrus SASL compilation error
On Fri, Mar 07, 2014 at 05:59:03PM -0600, Bruce Dubbs wrote: > Ken Moffat wrote: > > > I see that in a later mail you pointed to a patch. I _like_ patches > > (easy to see if they still apply - if in any doubt use 'git apply') > > but BLFS prefers to use simple things like sed, so I assume that > > specifying CFLAGS= will meet with more approval. > > We like sed because you can *see* what it changes without opening a > separate file. > >-- Bruce > In that you mean "you can see which file it changes", I cannot dispute it. Many of the seds over the years have also been very educational, e.g. using a specification before the sed to ensure that only one possible match is changed, and that is part of the book's purpose. But some of those same seds are not obvious about exactly how the text is being changed. A patch with context always shows the exact change when you look at it, but for seds you may have to copy the file, apply the sed, and then diff the file against the vanilla copy before you can see the exact detail. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Cyrus SASL compilation error
On Fri, Mar 07, 2014 at 10:47:01PM +0100, Armin K. wrote: > On 03/07/2014 10:04 PM, Ken Moffat wrote: > > > > And looking back, we had CFLAGS=-fPIC at the end of configure in > > BLFS-7.4, but without an explanation. > > > > It fell out in r12739 when Fernando applied a fix from Armin. The > > fPIC seems to have come in at r11674, amongst some tagging for 7.4. > > I'll put it back, and add an explanation. > > I still can't reproduce it. I have -fPIC in my cflags even if I don't > specify them. > It occurred to me that the patch might have been intended to solve this, so I double-checked in a manual build - no CFLAGS, no log - and saw the error. > > > make[2]: Entering directory '/home/armin/src/cyrus-sasl-2.1.26/sasldb' > /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > -I.. -I../include -I../include -DOBSOLETE_CRAM_ATTR=1 -Wall -W -g -O2 > -MT allockey.lo -MD -MP -MF .deps/allockey.Tpo -c -o allockey.lo allockey.c > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include > -I../include -DOBSOLETE_CRAM_ATTR=1 -Wall -W -g -O2 -MT allockey.lo -MD > -MP -MF .deps/allockey.Tpo -c allockey.c -fPIC -DPIC -o .libs/allockey.o > mv -f .deps/allockey.Tpo .deps/allockey.Plo I too noticed that -fPIC that -DPIC, but apparently it wasn't used for the static lib which caused the problem. > /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > -I.. -I../include -I../include -DOBSOLETE_CRAM_ATTR=1 -Wall -W -g -O2 > -MT db_berkeley.lo -MD -MP -MF .deps/db_berkeley.Tpo -c -o > db_berkeley.lo db_berkeley.c > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include > -I../include -DOBSOLETE_CRAM_ATTR=1 -Wall -W -g -O2 -MT db_berkeley.lo > -MD -MP -MF .deps/db_berkeley.Tpo -c db_berkeley.c -fPIC -DPIC -o > .libs/db_berkeley.o > mv -f .deps/db_berkeley.Tpo .deps/db_berkeley.Plo > /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -W -g -O2 -o > libsasldb.la allockey.lo db_berkeley.lo -ldb -lresolv > libtool: link: ar cru .libs/libsasldb.a .libs/allockey.o > .libs/db_berkeley.o > libtool: link: ranlib .libs/libsasldb.a > libtool: link: ( cd ".libs" && rm -f "libsasldb.la" && ln -s > "../libsasldb.la" "libsasldb.la" ) > I see that in a later mail you pointed to a patch. I _like_ patches (easy to see if they still apply - if in any doubt use 'git apply') but BLFS prefers to use simple things like sed, so I assume that specifying CFLAGS= will meet with more approval. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Cyrus SASL compilation error
On Fri, Mar 07, 2014 at 05:37:22PM +, Ken Moffat wrote: > On Fri, Mar 07, 2014 at 04:17:29PM +0100, Sergei Antonov wrote: > > Hello! > > I follow this instruction to build Cyrus SASL-2.1.26: > > http://www.linuxfromscratch.org/blfs/view/svn/postlfs/cyrus-sasl.html > > > > "make -j1" results in a link error about PIC: > > > > libtool: link: gcc -shared -fPIC -DPIC .libs/sasldb.o > > .libs/sasldb_init.o .libs/plugin_common.o -Wl,--whole-archive > > ../sasldb/.libs/libsasldb.a -Wl,--no-whole-archive -ldb -lresolv -O2 > > -Wl,-soname -Wl,libsasldb.so.3 -o .libs/libsasld > > b.so.3.0.0 > > /usr/bin/ld: ../sasldb/.libs/libsasldb.a(allockey.o): relocation > > R_X86_64_32 against `.rodata.str1.1' can not be used when making a > > shared object; recompile with -fPIC > > ../sasldb/.libs/libsasldb.a(allockey.o): could not read symbols: Bad value > > collect2: error: ld returned 1 exit status > > > > What may cause this? > > > The cause is as it says. On 32-bit x86 you can build shared > objects using static libs compiled without -fPIC, on 64-nit x86 you > cannot. I guess that whoever originally updated the book was using > i686. Once upon a time, many packages had similar problems, but most > have now been fixed upstream. > > I did notice that I build it by passing CFLAGS=-fPIC at the end of > my configure command, but I forgot to check if that was necessary > (it isn't a package I _use_). > > My bad, seems something like that _is_ needed on x86_64. And looking back, we had CFLAGS=-fPIC at the end of configure in BLFS-7.4, but without an explanation. It fell out in r12739 when Fernando applied a fix from Armin. The fPIC seems to have come in at r11674, amongst some tagging for 7.4. I'll put it back, and add an explanation. > > > > And a slight correction: && is missing after "pushd saslauthd" and > > "popd" build commands. > > Yes, for consistency. > > Unless anyone else is interested I'll take a look, maybe some time > this weekend. > > ĸen > -- > das eine Mal als Tragödie, dieses Mal als Farce > -- > http://linuxfromscratch.org/mailman/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Cyrus SASL compilation error
On Fri, Mar 07, 2014 at 04:17:29PM +0100, Sergei Antonov wrote: > Hello! > I follow this instruction to build Cyrus SASL-2.1.26: > http://www.linuxfromscratch.org/blfs/view/svn/postlfs/cyrus-sasl.html > > "make -j1" results in a link error about PIC: > > libtool: link: gcc -shared -fPIC -DPIC .libs/sasldb.o > .libs/sasldb_init.o .libs/plugin_common.o -Wl,--whole-archive > ../sasldb/.libs/libsasldb.a -Wl,--no-whole-archive -ldb -lresolv -O2 > -Wl,-soname -Wl,libsasldb.so.3 -o .libs/libsasld > b.so.3.0.0 > /usr/bin/ld: ../sasldb/.libs/libsasldb.a(allockey.o): relocation > R_X86_64_32 against `.rodata.str1.1' can not be used when making a > shared object; recompile with -fPIC > ../sasldb/.libs/libsasldb.a(allockey.o): could not read symbols: Bad value > collect2: error: ld returned 1 exit status > > What may cause this? > The cause is as it says. On 32-bit x86 you can build shared objects using static libs compiled without -fPIC, on 64-nit x86 you cannot. I guess that whoever originally updated the book was using i686. Once upon a time, many packages had similar problems, but most have now been fixed upstream. I did notice that I build it by passing CFLAGS=-fPIC at the end of my configure command, but I forgot to check if that was necessary (it isn't a package I _use_). My bad, seems something like that _is_ needed on x86_64. > > And a slight correction: && is missing after "pushd saslauthd" and > "popd" build commands. Yes, for consistency. Unless anyone else is interested I'll take a look, maybe some time this weekend. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Missing icons in gnome apps
On Thu, Feb 27, 2014 at 05:33:26PM -0300, Fernando de Oliveira wrote: > Em 27-02-2014 17:09, Ken Moffat escreveu: > > In testing various gnome apps for 7.5 (e.g. epiphany and evince), > > I've noticed that the icons on the application window don't appear, > > I just get little red 'X's on a white square. [...] > > Easiest way I find is install LXAppearance > > http://www.linuxfromscratch.org/blfs/view/svn/lxde/lxappearance.html > > Required > > GTK+-2.24.22 > > Recommended > > dbus-glib-0.102 > > Optional > > libxslt-1.1.28 with docbook-xml-4.5 and docbook-xsl-1.78.1 (to build man > pages) > Thanks - and no extra deps on top of what I already had installed. Turns out that the only available _icon_ themes it finds on my system are 'GNOME' and 'HighContrast'. Setting either of those in this app makes the icons on epiphany and evince appear. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Missing icons in gnome apps
In testing various gnome apps for 7.5 (e.g. epiphany and evince), I've noticed that the icons on the application window don't appear, I just get little red 'X's on a white square. This used to work, and in ~/.config/gtk-3.0/settings.ini I've got the following in '[settings]' : gtk-theme-name = Adwaita gtk-fallback-icon-theme = gnome # next option is applicable only if selected theme supports it gtk-application-prefer-dark-theme = false # set font name and dimension gtk-font-name = Sans 10 Any ideas how to get this working ? I recall that I had a similar issue in xfce, which was solved when I changed the theme in the xfce settings app, but I can't find anything in those parts of gnome which are still in BLFS that actually lets me select a theme. In /usr/share/themes I have Adwaita and HighContrast, as well as some gtk-2.0 stuff. TIA ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] LibreOffice: NO audio on some pps files
On Thu, Feb 27, 2014 at 03:18:36AM +, Ken Moffat wrote: Also, please note that I was lying when I said I build LO against gstreamer-0.10 : I now see that I disable 0.10. But for my usages (no slides to play, writer and calc don't lend themselves to audio) the difference is moot. People who think that powerpoint was a brilliant idea are probably better-placed than I am to provide assistance. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] LibreOffice: NO audio on some pps files
On Wed, Feb 26, 2014 at 09:56:54PM -0500, alex lupu wrote: > Hi Ken: > > Ken: ... where do you get this watermelons.pps file ? > > I got it in the mail sometime ago. Pretty nice. About 7 MB. > Some Germans(?) painting watermelons Christmas-egg style. > If you want a copy, let me know where to put/send it. > > Cheers, > -- Alex > If there is a publically-accessible source, so that people on the list can play along at home, it is interesting. Something of unknown provenance from an unknown source is not, generally, a good idea. There might also be copyright issues, and as an advocate for GPL'd software I'm a firm believer in copyright! In fact, I have zero .pps files here. Is there _any_ publically accessible source for playing with these gewgaws ? Also, you seem to have decided to top-post, I'm sure you know we dislike people who do that. The multipart-alternative html mail works, but is _disappointing_ from an LFS/BLFS user - do you not agree that html in mail is for windows users ? ;-) (yeah, I'm pretty pissed-off at the moment, mostly down to 3.13.5 (probably), not poor Alex who has triggered this) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] LibreOffice: NO audio on some pps files
On Wed, Feb 26, 2014 at 06:58:20PM -0500, alex lupu wrote: > Hello everybody, > > libreoffice-4.2.0.4 Built per BLFS Development Book v2014-02-21 with > --disable-gstreamer-0.10 --enable-gstreamer > > gstreamer-1.2.3 (with base-, good- and bad-1.2.3) > gst-plugins-ugly-1.2.3 (main suspect, according to my intuition) > > This is driving me crazy: > > 1. 'watermelons.pps' (in 'loimpress'): NO sound (but, fwiw, the slides move > OK) Stop there - I've got 4.2.0.4 [ built against the old 0.10 gstreamer/base, because on my normal desktop firefox and arora need that [ and I build all the plugins only when I get to arora, which is after libreoffice in my builds ] and only parole, which comes much later, uses 1.2. ] but where do you get this watermelons.pps file ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Recommended Display Manager for BLFS
On Sun, Feb 16, 2014 at 12:55:09AM +, Douglas R. Reno wrote: > Hello, > > This is probably not the right list to report this, I realize that. > According to http://osdir.com/ml/plasma-devel/2014-01/msg00208.html and > http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=8577abf894a661bc0700adc72513dacf0b7dca7f, > KDM is being retired. This is the only Display Manager that I know of that > BLFS Supports that I can use multiple desktop environments with. Is there > any way that SDDM or LightDM could be added to the book, or possibly > another replacement? I use KDM on my BLFS box and when I update to KDE5, I > expect that it will no longer work and that future builds of BLFS will not > contain it. What display manager does the list recommend I use? I do not > like logging in from the command line, and it is very hard to teach family > members who use my computer occasionally how to do so. > > Thank you, > > Douglas Reno I dare say that whoever is editing kdm will come up with something when the time comes. Personally, I hate DMs : I did use gdm for a while, until a change in it prevented me from seeing _where_ my altered bootscripts were failing to shut down, and I tried what I think was lightdm, but didn't like it (e.g. unreadably small font). Do you or your users regularly change desktop environments ? If not, what about a variant of what our late colleague Andy used to use, second post in the thread at: http://comments.gmane.org/gmane.linux.lfs.beyond.support/41986 More specifically, do you have some strange app that only works (for your use case) in its own DE ? My belief is that everything will work in other DEs, and that the menu system ought to make non-native apps possible to find. For most users of BLFS, the problem is building all the dependencies, but you must have already done that to have multiple DEs which you can switch between. But I suspect that I don't understand your problem - I have no problem with using startx - occasionally, on a test box, I hack my .xinitrc to allow me to specify _which_ wm to use, more often I just comment out my normal wm and uncomment the one I want to briefly test. Similarly, the shiny! shiny! fat! slow! nature of kde makes it something I prefer to avoid unless I'm testing that part of thebook ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] iptables-1.4.21 install broken
On Wed, Feb 12, 2014 at 09:53:16PM +0100, Armin K. wrote:
>
> Seems like failure in this part:
>
> for file in ip4tc ip6tc ipq iptc xtables
> do
> mv -v /usr/lib/lib${file}.so.* /lib &&
> ln -sfv ../../lib/$(readlink /usr/lib/lib${file}.so)
> /usr/lib/lib${file}.so
> done
>
> Either your scripts still have the old switches or something else went
> wrong. Note that BLFS configure options don't have --exec-prefix switch
> anymore.
>
Thanks for that.
I seem to have removed the --exec-prefix, although I did have it
for 1.4.20. But I did still have the old version of making the
symlinks, perhaps that was the problem. I've installed 1.4.21 now.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-support] iptables-1.4.21 install broken
I'm seeing the following when I try to install of 1.4.21 : libtool: install: (cd /building/iptables-1.4.21/libiptc; /bin/sh /building/iptables-1.4.21/libtool --tag CC --mode=relink gcc -Wall -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wshadow -Wstrict-prototypes -Winline -pipe -O2 -version-info 0:0:0 -Wl,--no-as-needed -o libiptc.la -rpath /usr/lib libip4tc.la libip6tc.la ) libtool: relink: gcc -shared -fPIC -DPIC -L/usr/lib -lip4tc -lip6tc -O2 -Wl,--no-as-needed -Wl,-soname -Wl,libiptc.so.0 -o .libs/libiptc.so.0.0.0 /usr/lib/libip4tc.so: file not recognized: Is a directory collect2: error: ld returned 1 exit status libtool: install: error: relink `libiptc.la' with the above command before installing it Makefile:330: recipe for target 'install-libLTLIBRARIES' failed make[2]: *** [install-libLTLIBRARIES] Error 1 What seems to be happening, for reasons I do not understand, is that libiptc.so gets installed as a symlink: root in chroot ~# ls -l /usr/lib/libip4tc.so lrwxrwxrwx 1 root root 10 Feb 12 20:41 /usr/lib/libip4tc.so -> ../../lib/ I think I'll revert to 1.4.20 for this build :-( ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Texmaker : Pdf Viewer (embedded) display diagonal?line across page
On Mon, Feb 10, 2014 at 11:17:41AM +, Dan Shved wrote: > Magnus Larsson tele2.se> writes: > [ in case anyone is wondering, Magnus asked this on 24th January. I'll keep a chunk of his post for context ] > > > > Dear blfs-support linuxfromscratch.org > > > > Texmaker : Pdf Viewer (embedded) display diagonal line across page > > > > I built Texmaker 4.1.1. http://www.xm1math.net/texmaker/ an use it in top > > of > > Texlive. > > > > Texmaker works fine, so far, but I get a diagonal when using Texmaker > 4.1.1 on > > my Linux From Scratch system when the internal pdf viewer is used and I > > zoom > > in. Snapshot1.png is attached. (The pdf as such is ok when viwed using an > > external tool). > > http://filebin.net/7ntorhye1q/snapshot1.png > > > > I filed an issue with Texmaker, but they can not reproduce it. Moreover, if > > I > > take the same 4.1.1 tarball and compiles and installs from source on a > > Debian > > 7 system, I do not get this problem. Only when built on BLFS. > > > > The BLFS used is reasonably coherent. I have X and QT and KDE4 working. > > > > What steps will reproduce the problem? > > 1. Open a latex source file. At this point (the PDF works in other viewers, and recreating the problem needs 3.7GB of TeX to be installed as a prerequisite) I guess that most people who read this list cannot help. So, I'll just reply to some of Dan's points. > > > > For Poppler I have > > libpoppler.so.43 -> libpoppler.so.43.0.0 > > libpoppler-cpp.so.0 -> libpoppler-cpp.so.0.2.0 > > libpoppler-glib.so.8 -> libpoppler-glib.so.8.6.0 > > libpoppler-qt4.so.4 -> libpoppler-qt4.so.4.3.0 > > > > I'm having exactly the same problem on Gentoo, texmaker version is 4.0.1. > The installed poppler version is: > > [IP-] [ ] app-text/poppler-0.24.5:0/44 > > Not sure which number means what here. My guess would be that 0.24,5 is some > gentoo-specific ebuild version whereas 44 is how poppler's developers call > it. Who knows. The actual poppler lib files are like this: > Actually, it's the other way round - 0.24.5 is the release (look at the tarball name!), and based on what Magnus showed us, 44 is the library version for libpoppler itself. > dan@dan /usr/lib $ ls | grep poppler > libpoppler-cpp.so > libpoppler-cpp.so.0 > libpoppler-cpp.so.0.2.0 > libpoppler-glib.so > libpoppler-glib.so.8 > libpoppler-glib.so.8.6.0 > libpoppler-qt4.so > libpoppler-qt4.so.4 > libpoppler-qt4.so.4.3.0 > libpoppler.so > libpoppler.so.44 > libpoppler.so.44.0.0 > > I geoss the next logical step would be to find another poppler-based PDF > viewer and see if it renders with or without the diagonal line... > Marcus said it worked in other viewers. If you want to try, a viewer using poppler (via libpoppler-glib) is epdfview. It can't handle every PDF I come across, but it is comparatively simple to build. Last time I looked, gentoo had retired it. But we still have build instructions for it in BLFS. http://www.linuxfromscratch.org/blfs/view/svn/pst/epdfview.html ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Cups and the usblp kernel driver
On Mon, Jan 27, 2014 at 08:51:23PM -0300, Fernando de Oliveira wrote: > Em 27-01-2014 19:58, Ken Moffat escreveu: > > > > > 1. Escputil probably only works on non-multifunction Epson stylus > > printers. > > ĸen, > > Thanks for this investigation. > > I am not so sure about this point: > > $ escputil -M | grep CX7400 > escp2-cx7400Epson Stylus CX7400 > > This is a multifunctional, and is in the list of supported ones. My > printer is not supported: CX7300. > OK, I hadn't spotted from your replies on -dev that CX7400 was multifunctional. So, escputil works on _some_ epson stylus printers. I had mentioned multifunction because the link I listed on -dev implied to me that it was multifunction printers which could not be adequately controlled by /dev/usb/lpX, at least for Epson. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Cups and the usblp kernel driver
I'm intending to change the cups page in the book, to remove the Note which says: | There is a conflict between the Cups libusb backend and the usblp | kernel driver. If you want to use Cups with libusb, do not enable | USB Printer support in your kernel. But since most people don't read blfs-dev, I'm asking here first - in case there are any different opinions. Sorry for the length of thii I (occasionally) use an Epson Stylus Photo R360. Until October I had _always_ used the kernel usblp driver - as a module - instead of libusb. I can vaguely remember that Greg KH reported an "unable to print" problem on lkml several years ago, and that the usblp driver appeared to have come into conflict with libusb (presumably, libusb had changed). I guess that is what eventually triggered the Note. In October, I was building _everything_ to test make-4.0. On my second such build (all the things I couldn't conveniently fit into the main build), I tried adding libusb (strictly, it is now called libusbx and produces libusb-1.0.pc, libusb.pc comes from libusb-compat) and dropping the kernel usblp printer. I was pleased that printing still worked, because this will allow me to reinstate colord - libusb is. or at least was, a recommended dependency - and will let me install usbutils (lsusb might be useful for debugging kernel problems). But earlier this month I wanted to check my ink levels whilst I happened to be using that system. To do that I use escputil from gutenprint, but it needs /dev/usb/lpX (i.e. you can only run it on the machine the printer is connected to) and that device is provided for the kernel usb printer driver. If CONFIG_USB_PRINTER is turned off, /dev/usb/lpX will not be created by whichever flavour of udev is being used. So, a build "by the book" does not let me check my ink levels. :-( So, first I tried what had been recommended in the past in other distros - build usblp as a module, and perhaps try to modprobe it to check the ink levels, and then rmmod it before printing. I built it as a module with 3.13.0: it gets installed as soon as I connect the printer, ink levels are reported, and I am able to print _without_ removing the module. Testing with usblp built-in has taken a little longer (only this one system has libusbx, no newer released kernels to test), but tonight I've built it into 3.12.9 and confirmed that both escputil and printing still work. I assume that changes in libusb, perhaps as part of the move to libusbx, solved the original problem. But printing on BLFS has always given problems for some people - often because different printers are just _different_ - so before I drop the note from the book I'll give everyone a chance to express any concerns. Additional notes: 1. Escputil probably only works on non-multifunction Epson stylus printers. 2. I don't have any printers of other brands on which to test this. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Can not compile XULrunner
On Wed, Jan 08, 2014 at 10:17:10PM +0100, Niels Terp wrote: > > I will try to look further into this, but if you - or anybody else - happen > to know if there is a general problem with CFLAGS when compiling with RPM, I > would appreciate any input you may be able to give me ! > > Best regards > > Niels > Looking at http://pkgs.fedoraproject.org/cgit/sqlite.git/plain/sqlite.spec perhaps you didn't _export_ the amended CFLAGS ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] CMake Compilation Errors
On Mon, Jan 06, 2014 at 04:09:25PM -0600, Douglas R. Reno wrote:
> Hello,
>
> LFS Version: 7.3
> BLFS Version: 7.4 Stable
> Brief Hardware Description: 256mb RAM, Intel Pentium III 800Mhz (Dell
> Latitude C800)
>
> I am having issues compiling Cmake. No special environmental variables or
> anything. Running a by-the-book install. I get the following error:
>
>
> [ 93% ] Building CXX object
> Source/CMakeFiles/ccmake.dir/CursesDialog/ccmake.cxx.o
> make[2]: *** No rule to make target '/usr/lib/libz.so', needed by
> 'bin/ccmake'.
> Stop.
Seems fairly obvious - it apparently wants to link to libz.so but
cannot find it in /usr/lib. Probably it found the headers in /usr
and was satisfied with those, or maybe it tested that libz existed
by using -lz and linked to the static libz.a.
Probably you did something wrong when installing zlib in LFS : we
move the .so.1 and .so.1.2.x [ 1.2.7 in LFS-7.3 ] to /lib, and make
/usr/lib/libz.so as a symlink to 1.2.x. I guess you moved the
libraries but perhaps created a broken symlink, e.g. to ../../lib/
i.e. to the non-existent ../../lib/libz.so instead of to the fully
versioned solib.
'file /usr/lib/lib/libz.so' and 'ls -l {,/usr}/lib/libz.*' might
show you the details.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] Destdir installation question
On Sat, Jan 04, 2014 at 10:12:57AM -0600, Bruce Dubbs wrote: > Ken Moffat wrote: > > I don't know what I_R is, but my approach is similar to Ken's, I only > use DESTDIR when checking things for the book. I got fed up with typing INSTALL_ROOT in full, and wrongly assumed I_R would be understood ;-) > I almost always script > packages and do note issues. In some cases I find I need to create some > directories, e.g. $DESTDIR/lib, when the instructions call for moving > files around. Generally, the reason that packages need to be installed > in DESTDIR as root is because the Makefile wants to chown files during > install. > >-- Bruce > Yes, chown and chgrp are the commands which come to mind. At least one package, probably exim, complains if you try to install as non-root. Oh, and if anyone ever wants to do similar with glibc, ISTR the variable it uses is INSTALLROOT without an underscore. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Destdir installation question
On Sat, Jan 04, 2014 at 12:46:56PM +0100, Thomas Trepl wrote: > > Note that some BLFS instructions in the book needs some tweaks in order to > work proper when installing via DESTDIR. Some packages do not take care about > DESTDIR but uses INSTALL_ROOT or even do not care about DESTDIR at all. I > needed only for 5 of over 400 packages a patch (rcs, unzip, zip, xinetd and > cdparanoia). For some other packages its a valid approach to specify the > destdir in the prefix-argument. That occurse mostly on packages without a > configure script where the install command looks like "make prefix=/usr > install". > For INSTALL_ROOT, or no available DESTDIR-style install, I've noted that in the wiki for some packages. In particular, anything using QT will probably need I_R instead of DESTDIR. NB - I only use the DESTDIR approach when looking at a new package, or when editing the book. There are also several packages which appear to respect DESTDIR but which do things requiring root privileges - only noticeable because if DESTDIR install fails, there are probably others where a DESTDIR install doesn't do everything but nevertheless ends successfully. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Python vs Python Modules in MesaLib and libxml2 - BLFS 2013-03-18
On Thu, Dec 26, 2013 at 10:51:42AM +, eddie james wrote: > The instructions are a tad ambiguous to a soft mind such as my own. After > google for 3 hours, I looked into the exploded libxml2 directory and saw > files related to python. I then did ./configure --help and noticed the > --with-python option.. The odd thing is I don't believe I passed that option > to ./configure when I built this for blfs. Mesa compiled with out a hiccup > and X worked. I'm currently installing X11 in a chrooted environment using > slackware 14.0 as a host, and installing to a gentoo installation. to make a > long story even longer... I think the instructions to build Mesa should be > written with "dim" people in mind > Why ? What is/was your problem ? I've _never_ passed that option, but libxml2 appears to build all the included python 'stuff' without it : provided recent python2 is present. Everybody who reads configure scripts, particularly their included help, needs to be aware that they often lie or at least mislead! Actually, googling for 3 hours will make anyone's mind soft. Too many outdated postings and false positives. Exploding libxml2 seems a bit drastic, but your system, your rules, your explosives. ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] JSON-C fails to build
On Fri, Dec 20, 2013 at 12:09:30PM -0600, Dan McGhee wrote: > Thanks, Bruce. I'm so locked in on getting sound that I didn't think > about that until after I responded to Armin. First, I built and did a > DESTDIR install as me, then a DESTIR and a final install as root. Then > used chown to get the package user involved. There didn't seem to be any > permissions problems. > > This is actually a mosquito bite right now. I *think* it's a path and > permissions problem with `/usr/bin/ld.` Things worked fine when I built > as me. When I'm through with sound and printing, I'll come back and > troubleshoot this some more. > I've been away from my machines, so coming late to this thread. I had a similar problem when building this to test some gnome packages with make-4.0. In my case, falling back to make -j1 instead of -j4 fixed it for me. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Trying to Decide Which Qt
On Fri, Dec 13, 2013 at 01:10:54PM -0600, Dan McGhee wrote: > > What, if any, functional loss will I experience by not installing Cups > right now? If I wait to build Cups will I have to rebuild Qt-5.2.0 > For qt-5 I cannot comment, and for qt-4 I've always built cups before qt. The reason for that is simple : most of my printing has historically been from gtk applications. If cups has been installed before gtk+-2 then the gtk2 apps can see the cups print queues when those have been created. I assume the same is true for gtk3, and probably for qt. Note that I never have _working_ printing until quite late in my build : my sequence is xorg then glib/gtk_2,3}, preferred wm, firefox, printing stack including gutenprint [ after that, I can print ] plus the gimp and other photo stuff, office apps [ I keep various notes in spreadsheets :) ], remaining AV [ pulls in qt for vlc ], other apps. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Setting Up "unix charset" in Samba Configuration File
On Wed, Dec 11, 2013 at 05:40:46PM -0500, Alan Feuerbacher wrote: > > How can I tell if I have "ISO-8859-1 data in the files offered by > Samba"? As I understand it, Samba is a general file server, so in > general it should handle all manner of files; hence I should use UTF-8, no? > I assume you are intending to use Samba to share some of your own (text) data with other boxes on your own network. For modern data, I assume UTF-8 will be correct. If you have created data using the limited set of symbols and accented letters in iso-8859-1 then the reverse would apply. If the data is all ASCII then either, but UTF-8 will then allow you to use any character in the future. N.B. You mentioned an American locale, so I've ignored the available variations for other character sets. Also, I don't use Samba (when I have to use windows, I use nfs to get data to/from my main systems). I'm just attempting to clarify the difference between the two character sets. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Setting Up "unix charset" in Samba Configuration File
On Wed, Dec 11, 2013 at 12:46:09AM -0500, Alan Feuerbacher wrote: > > LC_ALL=en_US locale charmap -> ISO-8859-1 > LC_ALL=en_US.iso88591 locale charmap-> ISO-8859-1 > LC_ALL=en_US.utf8 locale charmap-> UTF-8 > > So far as I understand, US English installations work with either of the > above charmap settings. > > Can someone explain the difference? So long as you use _only_ ASCII characters or the few symbols and accented letters offered in it, ISO-8859-1 works fine. Once people start using UTF-8 (like in my .sig), things break down. If you look at iso-8859-1 on wikipedia it will show you the limited range of glyphs / codepoints it supports. What that page *doesn't* mention is the encoding. For that, look at the UTF-8 page if you are interested in the messy details. The point is that ANY latin-1 (ISO-8859-1) character with a value greater than 0x7F is represented by a single byte. However, when I send you the same character in UTF-8 it will occupy more than one byte. For example, the copyright sign is 0x00A9 - in UTF-8 that becomes 0xC2 0xA9 [ © ] if I've read the UTF-8 wiki page correctly. > And what I should set in the Samba > smb.conf file for "unix charset"? > If you have ISO-8859-1 data in the files offered by Samba, then I guess you need to use 8859-1. Otherwise, use UTF-8. Windows has supported UTF-8 for a long time. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] problem using BS or DEL key
On Fri, Dec 06, 2013 at 02:26:24PM +0100, Alexey Orishko wrote: > On Thu, Dec 5, 2013 at 11:01 PM, Ken Moffat wrote: > > > > I still think my suggestion of checking every key will identify if > > any of the keys are being garbled in the kernel, and therefore if > > this is a kernel _input_ problem. > > > > But here is an alternative train of thought : > > > > When you trigger the garbage, is it really there, or only in the > > screen output ? Start a command with '#' so that it is treated as a > > comment, type, do whatever you need to so that the spurious garbage > > appears, then press enter. And make a written note of exactly what > > you typed, and a guide to what appeared and where it was on the > > line, so that you can repeat the test. > > 1. Typed: > # k kk > 2. Then deleted 2 speces between kkk-s with BS > 3. white blocks appeared on the same line till the end of the screen > > > Then key enter again : does the garbage scroll up, so that the > > current line is empty apart from the prompt ? > It does scroll up > > > Then key the up-arrow once to see the last line of history - is the > > garbage there in the history ? > No, it's not there (not in bash history) > > > If the garbage is only on the screen then I guess it _is_ a kernel > > problem, but in the _video_ driver (i915 I suppose, but maybe you > > compiled in vga). > I will rebuild kernel Yes, based on what you said about gma500 then I guess that should fix it. > > > Your LatArCyrHeb font has two, possibly three, characters which > > match a "white square". If you manage to prove that it is a kernel > > video problem, can you please "loadkeys LatGrkCyr-8x16" and repeat > > the test. I'm guessing you will get a capital T with a comma below > > it (either U+021A or, in that font, U+0162), or a capital U with an > > acute accent (U+00DA), or else a capital U with a breve (U+016C). > > Knowing what appears might be useful if this is a bug in a video > > driver. I'll attach the text listing of that font - I'm guessing it > > is one of character positions 210, 212, or 216. > > Do you mean setfont instead of loadkeys? Screen font changed, but > white block is still the same while using LatGrkCyr-8x16. > If I select viscii10-8x16 I can see blinking white letter U with diacritics on > a grey background. It is a last letter in showconsolefont. > If Iset lat1-16 I see "y" (U+00FF) > Yes, I did mean setfont - sorry. If you change to the gma500 driver, I hope it will fix this. > > If it is a video-driver problem, please attach the relevant part of > > your kernel config > > I will recompile with: > Graphics support ---> > <*> Intel GMA5/600 KMS Framebuffer > [*] Intel GMA3600/3650 support (Experimental) > > > And, which kernel is this ? > I'm going to build a latest stable from kernel.org 3.10.22 > > /alexey Good luck - I guess that compiling a kernel on an atom will be slow. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] problem using BS or DEL key
On Thu, Dec 05, 2013 at 10:01:00PM +, Ken Moffat wrote: > > Your LatArCyrHeb font has two, possibly three, characters which > match a "white square". If you manage to prove that it is a kernel > video problem, can you please "loadkeys LatGrkCyr-8x16" and repeat > the test. I'm guessing you will get a capital T with a comma below > it (either U+021A or, in that font, U+0162), or a capital U with an > acute accent (U+00DA), or else a capital U with a breve (U+016C). > Knowing what appears might be useful if this is a bug in a video > driver. I'll attach the text listing of that font - I'm guessing it > is one of character positions 210, 212, or 216. > Forgot to attach it the first time, and when I did it bounced (too big, whoops!). So here's the third attempt, using xz to compress it from 177K to < 7K. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce LatGrkCyr-8x16.psfu.txt.xz Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] problem using BS or DEL key
On Thu, Dec 05, 2013 at 05:43:28PM +0100, Alexey Orishko wrote:
> On Thu, Dec 5, 2013 at 4:40 PM, Ken Moffat wrote:
> >>
> > This gets weirder and weirder. Most of us don't have a stock of
> > different motherboards to play with, and I've no experience in this
> > area. I think you said that showkey and dumpkeys reported the
> > keyboard was giving the expected values for the BS and DEL keys
> > even though they were giving white squares when you deleted, so in
> > theory the kernel drivers are ok.
> >
> > Perhaps make a list of the values for _every_ key you use (with
> > showkey) with this drive on a "good" motherboard, and then put it
> > back on the bad motherboard and repeat the exercise just in case one
> > or more _other_ keys are somehow corrupted.
>
> Well, I only need to type english letter "k" and space to get into problems..
> While changing fonts I've noticed that white square boxes have inverted "y"
> with two dots over it.. Anyway, they appear on empty position of the
> command line (where no text was typed in).
>
From memory, you said that k was involved when you specified that
you were NOT using unicode in the setup, so I'm inclined to ignore
that. I thought your problem was that *deleting* characters on the
commandline caused spurious garbage to appear after it ? If that is
wrong, ignore the rest of this reply and instead please restate the
problem.
I still think my suggestion of checking every key will identify if
any of the keys are being garbled in the kernel, and therefore if
this is a kernel _input_ problem.
But here is an alternative train of thought :
When you trigger the garbage, is it really there, or only in the
screen output ? Start a command with '#' so that it is treated as a
comment, type, do whatever you need to so that the spurious garbage
appears, then press enter. And make a written note of exactly what
you typed, and a guide to what appeared and where it was on the
line, so that you can repeat the test.
Then key enter again : does the garbage scroll up, so that the
current line is empty apart from the prompt ?
Then key the up-arrow once to see the last line of history - is the
garbage there in the history ?
If the garbage is only on the screen then I guess it _is_ a kernel
problem, but in the _video_ driver (i915 I suppose, but maybe you
compiled in vga).
Conversely, if the garbage appears in the history then ignore the
rest of this mail.
Your LatArCyrHeb font has two, possibly three, characters which
match a "white square". If you manage to prove that it is a kernel
video problem, can you please "loadkeys LatGrkCyr-8x16" and repeat
the test. I'm guessing you will get a capital T with a comma below
it (either U+021A or, in that font, U+0162), or a capital U with an
acute accent (U+00DA), or else a capital U with a breve (U+016C).
Knowing what appears might be useful if this is a bug in a video
driver. I'll attach the text listing of that font - I'm guessing it
is one of character positions 210, 212, or 216.
I base that paragraph on what 'showconsolefont' shows me. If you
get a different character, or more than one, please attempt to
identify them against that listing. You mentioned a different
character appeared when you tried other fonts, but there is no rule
about where any particular character is stored _within_ a console
font.
If it is a video-driver problem, please attach the relevant part of
your kernel config ("Graphics support", "I2C encoder or helper
chips" (in mine that is actually Direct Rendering Manager, possibly
because the I2C stuff is disabled and DRM doesn't have a heading),
"Frame buffer hardware drivers" and "Console display driver support"
- cut at "CONFIG_SOUND" which is the start of the sound drivers - they
don't have a neat heading comment.
And, which kernel is this ? At this point (for a video problem)
you should have a reliable and simple testcase to show if the system
has a problem. Either I will suggest that you change the .config (it
is unfortunately very easy to create a config which doesn't work
properly) or else to try building older and newer released kernels.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] problem using BS or DEL key
On Thu, Dec 05, 2013 at 03:06:01PM +0100, Alexey Orishko wrote: > On Wed, Dec 4, 2013 at 7:27 PM, Ken Moffat wrote: > > > > In my previous reply I included an invalid-unicode symbol, code > > U+FFFD displaying as reverse-video question mark : � : if you read > > the mail on the LFS-7.4 machine (or copy this paragraph to a file, > > scp that file to the LFS machine, and then read it), does the > > resulting glyph appear correctly, and if not, does it match the > > white squares you had [ you need to revert the LANG and UNICODE > > settings ] ? > > I can see reverse-video question mark on LFS box, but reverse area is square > in firefox/gmail and oval in lfs (I assume due to different font) > Good, you are displaying UTF-8. That unfortunately doesn't help explain why you were getting white squares after deleting. Yes, different fonts display things differently (e.g. serif and sans-serif). > > However when I tried to boot from exactly the same HDD on another > motherboard from different vendor - everything works fine! It doesn't > work on recent Atom D2550 motherboard and works on old D510 and > on HP desktop with Core2. New Atom board has Intel ICH10R chipset > and NUVOTON NTC6776D SuperIO, while old one has Intel ICH9R > chipset and Winbond 83627DHG-P SuperIO. > > Does it mean the problem might be with some kernel drivers? > > /alexey This gets weirder and weirder. Most of us don't have a stock of different motherboards to play with, and I've no experience in this area. I think you said that showkey and dumpkeys reported the keyboard was giving the expected values for the BS and DEL keys even though they were giving white squares when you deleted, so in theory the kernel drivers are ok. Perhaps make a list of the values for _every_ key you use (with showkey) with this drive on a "good" motherboard, and then put it back on the bad motherboard and repeat the exercise just in case one or more _other_ keys are somehow corrupted. To be absolutely clear - you haven't installed xorg on the LFS-7.4 system, this is all about a problem in the console terminals (the ttys), right ? -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] problem using BS or DEL key
On Wed, Dec 04, 2013 at 08:38:12PM +0100, Alexey Orishko wrote: > On Wed, Dec 4, 2013 at 7:27 PM, Ken Moffat wrote: > > > > I now wonder if you are using a non-unicode console font ? > > I've built LFS using ALFS scripts and didn't change anything regarding > fonts... should I? > I'll check the rest tomorrow. > > /alexey No idea - I use my own scripts (/sources is an nfs mount for all my machines and I do not want to work in it), but in general configuring the linux console is user-specific. Any console font which is ".psfu" (instead of ".psf") _ought_ to understand enough unicode to understand _where_ the characters begin and end. No font can display everything (there are too few _available_ codepoints) and some representations are subjectively ugly or easy to confuse). Also, one font _size_ doesn't suit everyone - of my own[¹] fonts, I still use the 8x16 on one machine but otherwise I use 12x22, even on the netbook because its pixels are tiny :-) [¹] LatGrkCyr - the two sizes look very different from each other. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Suggestions on Desktop Environment
On Wed, Dec 04, 2013 at 11:26:25AM +, akhiezer wrote:
>
> TLDR: *if* using a Desktop Environment ('DE'), then I'd _suggest_ XFCE for <=
> medium-power machines, KDE for >~ medium-power machines, and GNOME for ...
> er,
> I guess if you know/want GNOME.
>
I found kde slow on my 8GB AMD phenom (4 processors).
XFCE is very usable for me. My fingers are hard-wired to icewm
actions [ ctrl-alt-space to type in the program name, ctrl-alt-n to
move to desktop n, ctrl-alt-Fn to move to ttyn ] and I prefer a
plain background (except at this time of year where I run xsnow ]
without icons wasting space, but I could live with xfce and will
probably use it when I get around to installing LFS/BLFS on my
netbook.
>
> A side-light on the matter:
>
> It can be worth bearing in mind the view, "I run applications, not Desktop
> Environments".
>
I very much agree with that.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] problem using BS or DEL key
On Wed, Dec 04, 2013 at 01:11:00PM +0100, Alexey Orishko wrote: > On Tue, Dec 3, 2013 at 10:53 PM, Ken Moffat wrote: > > On Tue, Dec 03, 2013 at 08:29:42PM +0000, Ken Moffat wrote: > >> > >> What are the locales (LC_ALL or similar) in BOTH systems ? > Neither has LC_ALL set > > Ubuntu and LFS-7.4 had this set: > LANG=en_US.UTF-8 > > My old LFS-6.3 has > LANG=en_US.ISO-8859-1 > Oh. I had misunderstood that you were a norwegian. Anyway, you are using UTF-8 in both ubuntu and LFS-7.4. > >> Using 'showkey' [ in a tty ], find the values for the Backspace and > >> Del keys - on a regular 102-key keyboard mine are 14 and 111 - then > >> use 'dumpkeys | less' to find what is output for those keys - mine > >> are 'Delete' and 'Remove' : for no-latin1 the latter is corrected in > >> the patch. I _think_ ubuntu has versions of both those commands > >> (from console-tools), so you could compare them. > On all systems showkey output is: > BS - keycode 14 and DEL -keycode 111 > dumpkeys has 'Delete' and 'Remove' > So the keymap is ok. > > Also, check what you have in /etc/inputrc [ LFS section 7.14 ], > content is exactly as in the book > Good. > After deeper investigation I got really confused > BS/DEL problem exists in en_US layout and appearing while I'm deleting > SPACE symbol with BS within a string like "k ". > > I've changed LANG to LANG=en_US.ISO-8859-1 and UNICODE=0 and > problem is still there, however on old LFS-6.3 everything works fine with > LANG=en_US.ISO-8859-1 and even with "loadkeys no-latin1". > > Problem looks like described in BLFS Chapter 2. Important Information, > Locale Related Issues: "The Program Breaks Multibyte Characters or > Doesn't Count Character Cells Correctly" > Using 8859-1 instead of unicode will cause the reverse of that problem - any non-ASCII unicode text will probably be converted to garbage, e.g. some common Norwegian letters - ae æ o-slashø a-ring å > Since issue is present even with US keyboard layout, I wonder if ALFS > build did something funny during build (or didn't do something right). > > I've tried to rebuild kbd with a patch, but didn't help. > The patch fixed up the BS and DEL keycodes in the keymap, but your problem is different. > If I log via ssh everyhting looks ok. Is it because I use other pc > facilities in this case? > > /alexey You are using at least some of the settings from the machine where you are typing, e.g. the font (whether in a tty or a desktop term) comes from that machine. I think you need to fix the problem on the LFS machine - and then you might have to adjust the terminal or environment on the other box where you use ssh. First, you have to make sure that your 7.4 system is correctly set up for UTF-8. Your ubuntu system appears to be ok for UTF-8 (as expected), your antiquated LFS-6.3 is a historical curiosity from the days before UTF-8 was the norm. In my previous reply I included an invalid-unicode symbol, code U+FFFD displaying as reverse-video question mark : � : if you read the mail on the LFS-7.4 machine (or copy this paragraph to a file, scp that file to the LFS machine, and then read it), does the resulting glyph appear correctly, and if not, does it match the white squares you had [ you need to revert the LANG and UNICODE settings ] ? There are (at least) three things to be done when moving from non-unicode to unicode: (i.) set the environment to use the unicode versions such as en_US.UTF-8. (ii.) use a unicode console font. (iii.) adjust environment or other settings for individual applications, e.g. in the distant past I used to use LESSCHARSET but that is now redundant. I now wonder if you are using a non-unicode console font ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] problem using BS or DEL key
On Tue, Dec 03, 2013 at 08:29:42PM +, Ken Moffat wrote: > > Other things to consider: > > What are the locales (LC_ALL or similar) in BOTH systems ? > > Using 'showkey' [ in a tty ], find the values for the Backspace and > Del keys - on a regular 102-key keyboard mine are 14 and 111 - then > use 'dumpkeys | less' to find what is output for those keys - mine > are 'Delete' and 'Remove' : for no-latin1 the latter is corrected in > the patch. I _think_ ubuntu has versions of both those commands > (from console-tools), so you could compare them. > > The backspace and delete keys are sufficiently common that the > LEGACY_CHARSET variable (LFS section 7.10) probably doesn't come > into play - but it might be needed to fix up other symbols if you > are using UTF-8 and the keymap is iso-8859-something. > Also, check what you have in /etc/inputrc [ LFS section 7.14 ], particularly the "for linux console" part [ one sequence is for delete-char ], and specifically for mc the section "Configuring MC" on the MC page in BLFS. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] problem using BS or DEL key
On Tue, Dec 03, 2013 at 12:41:26PM -0600, William Harrington wrote: > > On Dec 3, 2013, at 10:14 AM, Alexey Orishko wrote: > > > At least LANG=en_US.UTF-8 and non-us keyboard are working file with > > Ubuntu... > > I wonder what's wrong with my LFS setup... > > utf-8 (Unicode ), iso-8859-1, iso-8859-15 (with euro symbol) > > For norwegian you need to load the "no" keymap > > There is also "no-latin1" keymap. You may want "no-latin1" rather than > the "no" keymap. > > For the console font you may want: lat0-16 > > Sincerely, > > William Harrington > I'm still having difficulty envisioning what is happening on Alexey's system, but I guess it might be down to an invalid unicode character (assuming he is using UTF-8), and that his chosen font doesn't display those sanely [ U+FFFD should be generated for this in a unicode locale, preferably as a reverse-video question mark "�" ]. Other things to consider: What are the locales (LC_ALL or similar) in BOTH systems ? Using 'showkey' [ in a tty ], find the values for the Backspace and Del keys - on a regular 102-key keyboard mine are 14 and 111 - then use 'dumpkeys | less' to find what is output for those keys - mine are 'Delete' and 'Remove' : for no-latin1 the latter is corrected in the patch. I _think_ ubuntu has versions of both those commands (from console-tools), so you could compare them. The backspace and delete keys are sufficiently common that the LEGACY_CHARSET variable (LFS section 7.10) probably doesn't come into play - but it might be needed to fix up other symbols if you are using UTF-8 and the keymap is iso-8859-something. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Su and Sudo--Getting Both to Work
On Mon, Dec 02, 2013 at 12:46:56PM -0600, Bruce Dubbs wrote: > > > When I try, I get "Crypt error." > > I go that yesterday when I locked an account, but it went away when I > unlocked it. I think it just means bad password, but there is an issue > there that it gives the wrong message. I suspect it's the only error message nowadays ;-) I had it the other week when I filled up '/tmp'. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Lots of problems with Firefox
On Sun, Dec 01, 2013 at 02:45:28PM -0500, Richard wrote: > > I have recently installed LFS 7.4, and I have > also installed various packages from the BLFS > book that are identified as compatible with > LFS 7.4. Umm, *everything* in BLFS should work on LFS-7.4 ! > One of the packages I installed was > Firefox-23.0.1. I believe I have also installed > all the required and recommended dependencies > for it. > I can never recommend an old version of firefox (at least on i686 and x86_64) when there are known issues fixed in each newer release. But that's not (all) the problem here. > When I first start up Firefox I get the following > message: > > > (process:1035): GLib-CRITICAL **: g_slice_set_config: assertion > > `sys_page_size == 0' failed > As already noted, that is normal and harmless. > When I go on a news site at: > www.cbc.ca/thenational/watch/, I get a bunch > of error messages like: > > > (plugin-container:1120): Gtk-CRITICAL **: IA__gtk_widget_get_visual: > > assertion `GTK_IS_WIDGET (widget)' failed > > > (plugin-container:1120): Gdk-CRITICAL **: IA__gdk_colormap_new: assertion > > `GDK_IS_VISUAL (visual)' failed > > > (plugin-container:1120): Gdk-CRITICAL **: IA__gdk_colormap_alloc_colors: > > assertion `GDK_IS_COLORMAP (colormap)' failed > > > (plugin-container:1120): Gtk-CRITICAL **: IA__gtk_widget_modify_bg: > > assertion `GTK_IS_WIDGET (widget)' failed > > These errors occur before I try to watch anything. > When I click on a video to watch it, Firefox hangs > up and I just have to kill the process. The final > logs I am able to see on the screen are lines like: > > > ###!!! [Parent][RPCChannel] Error: Channel error: cannot send/recv > FWIW, the site itself renders for me with ff-25 and no plugins. Google's matches for GDK_IS_COLORMAP find old problems with the flash player plugin. Adobe discontinued that - perhaps gnash would work for you, but I wouldn't bet any money on it. My own selection of random links on that site variously give me: This content is not supported by your handset so that might well be flash or links to mp4 files - I tried one of those, firefox offered to open it in parole, which is my default player, and it worked fine. another from the link "View all The National video at cbc.ca/player »" reported: To view this content, you need the latest version of Adobe Flash Player (but 'Adobe Flash Player' was greyed out until I copied it with the mouse :) Overall, cbc.ca seems to be mostly flash and for many of us that doesn't work™. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Proprietary Radeon Driver
On Wed, Nov 27, 2013 at 11:17:53AM -0600, Dan McGhee wrote: > I'm working my way throught the Xorg installation and getting close to > installing the drivers. Xorg hasn't quite caught up yet with my chip > which is Radeon HD 8610G, and I'm going to use the proprietary driver > from ATI. I'm asking for advice on when to install it. It's a > pre-compiled binary and installs with a script. Should I install it > when I install drivers for Xorg, or should I wait until I'm finished > with Xorg and install it before I start Xorg for the first time? > Ubuntu thinks this is a "Richland" ? https://help.ubuntu.com/community/RadeonDriver Phoronix (yeah, I know, treat their advice with more than a pinch of salt!) thinks the Richland is supported in version 7.2.0 of xf86-video-ati. http://www.phoronix.com/scan.php?page=news_item&px=MTQzMDU If that is true, the xorg radeon wiki at http://www.x.org/wiki/RadeonFeature/ might help (as well as the gentoo wiki for firmware, of course). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] /dev/fb0 not being created on boot
On Thu, Nov 21, 2013 at 10:33:25AM -0600, Bruce Dubbs wrote: > Richard Melville wrote: > > I've just configured a new 3.12 kernel and now /dev/fb0 is not being > > created, despite all the necessary configurations being built into the > > kernel. This means that I can't get a decent resolution in the console; I > > was using vga=792. > > > > My old kernel was a 3.7-rc8 and worked without problems. The config file > > (in relation to the framebuffer at least) appears to be identical for both > > kernels. > > > > This is driving me crazy. Any help or suggestions much appreciated. > > The vga= setting has been deprecated for some time. Use video=1024x768 > or similar resolution. > > I'm not sure why you don't have /dev/fb0, my 3.11.4 kernel has it: > 3.7 was a year ago : 5 kernel releases. A lot has changed in that time. Which video driver are you using ? Are you using KMS (if it is supported for your driver) ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Boot Failure with wlan0 firmware
On Mon, Nov 18, 2013 at 07:27:06PM -0600, Dan McGhee wrote: > > I'm glad I thought of that. I'm tired of configuring kernels. Have > done eight since Friday. yuk. > Yeah, sorting out new machines is fun. > You and Bruce are going to have to buy new hardware to check out all of > this EFI stuff. :) -ENOSPACE : I bought a new low-end AMD A4 in the spring (for Win 7), all four positions on my KVM switch are occupied (that box, AMD Phonon, low-end Sandy Bridge, ppc64). > So that I don't have to advertise my "rustiness" with a subject line on > the list, I've got a really noob question. I can't dredge up the answer > from the "grey cells." What are the "key presses" to switch between > terminals in a non-graphic environment? I think ALT-CTRL-F[1-6] takes > you to different run levels, but what about terminals? Uhoh. I think I > just remembered something. Am I thinking of ALT-CTRL-F[1-4]? > Alt-F[1-6] for terminals. I've not _seen_ runlevel switching like that, and on icewm I use Alt-Ctrl-Fn to get back to a tty (Alt-F7 to return to xorg), Alt-F[1-4] in icewm switches desktops. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Boot Failure with wlan0 firmware
On Mon, Nov 18, 2013 at 06:25:23PM -0600, Dan McGhee wrote: > Worked like a charm! Thanks, Ken. > > rt3290.bin to /lib/firmware with the CONFIG statements as you > indicated. I just booted into my brand-new, shiny LFS system. And from > efi no less. :) :) > Great! > There are still a couple of "script" things I need to chase: 1) I start > getting the pretty, green OK's then the screen goes dark for a count of > at least 1-2-3 then I get mixed kernel ans "script" messages but in a > much, much smaller font. And I think there's something with dhcpcd. At > least now I don't have to "raise eyebrows" trying to run some of the > start up scripts in chroot. :) > I'm guessing the tiny font has something to do with framebuffer consoles. I don't know what size of console font you use, nor what size your screen is, but perhaps enabling something in the CONFIG_FONT_SUPPORT area of the kernel (with one or more of the fonts), OR adding something like "video=1024x768" (or 800x600, or whatever) to the boot args mught help. On one of my boxes I pass that video=1024x768, between 'root=' and 'ro', so that I can read an 8x16 font on a 1600x1200 screen (the other desktops use 12x22, as does my netbook if I want to read things comfortably) For dhcpcd I have no suggestions - I use dhclient. Similarly, no suggestions if it is actually a problem in bringing up the wifi in userspace. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Boot Failure with wlan0 firmware
On Mon, Nov 18, 2013 at 11:56:14AM -0600, Dan McGhee wrote: > > I got the following messages on boot: > > Starting wpa_supplicant on the wlan0 interface > > ieee80211 phy0: rt2x00 lib_request_ firmware: Info-loading firmware file > 'rt329.bin' (could have been 3290) > ieee80211 phy0: rt2x00lib_request_firmware: Error-Failed to request Firmware > This is key. Most recent firmware is NOT supplied with the kernel (license issues). Usually, things don't work without the firmware. http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/ If you look down there, you will see rt3290.bin, and if you click on 'plain' in a graphical brower you can put it in /lib/firmware [ so that future kernel versions will also be able to find it ]. If it is anythong like recent radeon graphics chips, you might have to repeat the process for subsequent firmware blobs. I might have misunderstood a few of the datails, but this is what I currently do on my newest radeon machine [ the one that needs loads of blobs ] n the kernel .config- CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_EXTRA_FIRMWARE="radeon/BTC_rlc.bin radeon/ARUBA_me.bin radeon/ARUBA_pfp.bin radeon/ARUBA_rlc.bin radeon/TAHITI_uvd.bin rtl_nic/rtl8168e-3.fw" CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" CONFIG_FW_LOADER_USER_HELPER=y From memory, the help on the firmware settings is a bit confusing and with this setup it pulls the firmware in near the end of the kernel compile - at which point any missing firmware becomes apparent. My firmware is in directories (radeon/, rtl_nic/) because that is conventional for those particular blobs. For you, I guess you can put rt3290.bin into /lib/firmware and use CONFIG_EXTRA_FIRMWARE="rt3290.bin". Technically, you could put it/them anywhere that is readable at kernel compile time, but /lib/firmware is the common choice. After you set it in menuconfig and save the config, take a look at it to confirm that the entries look correct. In particular, /lib/firmware unless you want to use lib/firmware in the kernel tree and to have to reload that every time you untar the kernel source. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Problems Compiling Gimp, Gegl and Babl
On Sat, Nov 16, 2013 at 01:05:39PM -0500, Alan Feuerbacher wrote:
> On 11/16/2013 11:37 AM, Bruce Dubbs wrote:
> > Alan Feuerbacher wrote:
> >> ...
> >> babl-0.1.10 installed without a hitch, but put all of its libraries
> >> and such in "babl-0.1" rather than in "babl".
> >
> > That is correct. Gimp should be getting info from babl.pc:
> >
> > Cflags: -I${includedir}/babl-0.1
> > Libs: -L${libdir} -lbabl-0.1 -lm
>
> That's what is happening alright. Likely the problems with compiling
> gegl affected the above, but I don't see the connection.
>
Snipped from your original mail :
|*===*===*===*===*===*
|babl-0.1.10 installed without a hitch, but put all of its libraries
|and such in "babl-0.1" rather than in "babl". Gimp complained about
|that so I had to make a link:
|
|ln -sv /usr/include/babl-0.1/babl /usr/include/babl
|*===*===*===*===*===*
I don't have a /usr/include/babl directory or symlink. I've now
compiled and run a DESTDIR install of gimp-2.8.8 to be sure that
there isn't a problem in the current version. I had already built
gegl-0.2.0 and babl-0.1.10. I cannot replicate your problem.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] Problems Compiling Gimp, Gegl and Babl
On Sat, Nov 16, 2013 at 10:36:56AM -0300, Fernando de Oliveira wrote:
> Em 16-11-2013 08:51, Alan Feuerbacher escreveu:
>
> > *===*===*===*===*===*
> > babl-0.1.10 installed without a hitch, but put all of its libraries
> > and such in "babl-0.1" rather than in "babl". Gimp complained about
> > that so I had to make a link:
> >
> > ln -sv /usr/include/babl-0.1/babl /usr/include/babl
> > *===*===*===*===*===*
>
> I have just installed it without problem. Perhaps, if you can install
> gegl without modifications, and remove the links you added that are not
> in the book would solve it. I would try fixing gegl's build and install,
> first.
>
Yeah, as Bruce has said : pkgconfig should sort everything out.
Take a look at /usr/include/pkgconfig/babl.pc. Mine says, in full -
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: babl
Description: Dynamic, any to any, pixel format conversion library
Version: 0.1.10
Cflags: -I${includedir}/babl-0.1
Libs: -L${libdir} -lbabl-0.1 -lm
: note the Cflags.
>
> Anyway, ĸen knows much more about gelgl, babl and gimp.
>
I'm still running 2.8.6 - I didn't see any "must have" features (or
vulnerability fixes) in 2.8.8 so upgrading isn't an urgent task for
me.
And I normally give it few of the optional deps, and then only
because they are already installed [ I build the gimp along with
printing and image-manipulation tools, after firefox is installed ].
I think it was Fernando who had a problem with gegl getting broken
by vala with previous versions! If I _have_to_ build vala for
anything, I do it a long while after I've built the gimp. So far,
I haven't noticeably lacked anything by not installing lua or ruby in
my normal desktop builds.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-support] make-4.0 testing : completed
I've now completed my test builds of everything in BLFS using make-4.0. For the second build there is nothing related to make to report. So, the new version of make went more smoothly than I had anticipated. Full results (list of the most recent versions of everything that I built, plus the sequences in which I built them (now includes the things NOT in BLFS that I built) are at: http://www.linuxfromscratch.org/~ken/make-4.0-testing/ ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] CUPS and Mavericks
On Sun, Nov 10, 2013 at 06:50:51PM -0800, Walter P. Little wrote: > > > > I didn't realise that osx on ppc was still upgradeable! > > > It's not. 10.6 and up has been Intel only. I think the OP is talking about > two computers - an old (system 7 era) PPC that is running Linux instead of > Mac OS (a great idea - I've got a similar vintage PowerMac that I can't > bear to part with but is pretty much useless to me as a Mac)... and a more > recent Intel iMac. > Yeah, I wasn't paying sufficient attention - sorry about that. Too busy documenting what I _have_ built with current 'make' and discovering the packages where I thought I was on a sufficiently-current version when I started, but still managed to use an old version in both builds, and the couple of things I had managed to completely ignore :-( Anyway, I did devote some attention to what I suggested. No idea if it is right, but that part of the reply was my best shot. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] CUPS and Mavericks
On Sun, Nov 10, 2013 at 11:13:30PM +0100, Pol Vangheluwe wrote: > I use an Apple PowerPC 7500 as print server on my local network (IPP). It > runs LFS-6.8 (I know - a bit old…) with CUPS-1.4.5. > I could print without any problem from my iMac under OSX 10.8 (Mountain Lion) > but this is not the case anymore since I upgraded the iMac to OSX 10.9 > (Mavericks). > There are no error messages, not on the client nor on the server. The server > reports the job as “finished”, but the number of pages is always “unknown”. > The printer itself (an Epson Stylus Color 740 with USB connection) does not > move at all. > I have another iMac, running OSX 10.4 (Tiger) that still can print without > any problem, so I think that my LFS system is still OK. > Mavericks has CUPS-1.7.0 on-board. Is it possible that there is an > incompatibility between a CUPS-1.4.5 server and a CUPS-1.7.0 client? > And if so, is it possible to upgrade the CUPS system on my LFS-6.8 system? > > pvg > I didn't realise that osx on ppc was still upgradeable! I've been saving my ppc64 osx install in case I ever find the missing part of my slide scanner. Anyway - https://discussions.apple.com/message/23597377#23597377 and various similar threads. I've no idea what is different, and anyway apple care nothing about things outside their walled garden, but perhaps upgrading to the current cups might help. Obviously, back up ALL of /etc/cups, the cups user programs [ cancel, cups*, lp*, pp* ], the cups /usr/sbin programs [ accept, cups*, lp*, reject ], /usr/lib/cups, /usr/lib/libcups*, /usr/share/cups, /usr/share/cups together with the programs from ghostscript if installed [ dumphint, dvi2pdf, eps2eps, font2c, gs*, lprsetup.sh, pdf*, pdf*, pf*, pp*, printafm, ps*, unix-lpr.sh, wftopfa ], /usr/share/ghostscript-v.wx and if you use gutenprint, everything from that. I've only ever used cups for printing from the same machine (I plug the printer in to whichever desktop box I'm using). And I haven't needed to upgrade my printing stack recently, but my upgrade script deletes - /etc/cups, /usr/lib/cups, /usr/lib/libcups*, /usr/lib/gutenprint*, /usr/share/cups, /usr/share/gutenprint, /var/spool/cups. I only use gutenprint, other printers might be a bit different, but you're using an Epson Stylus so I guess you too are using gutenprint. A little of gs (at least, with the old cups versions) and gutenprint get installed into the cups directories. I did once try not ripping everything out for a partial upgrade, but I ended up with a broken mix of versions. I then rebuild the print stack - cups, [ for LFS-7.0+ I would update the cups bootscript for any potential improvements in newer versions, but you need to stick with the old bootscript - best to back that up too, just in case ], ghostscript (actually, current cups with gutenprint no longer needs gs but definitely reinstall if you use it), qpdf, cups-filters, gutenprint. I see that I also reinstall ImageMagick, probably that links to the shared gs lib if both are installed. I did build whatever versions were current for LFS-7.4 on ppc userspace [ G5 but using linux32 ] without any issues, but using an *old* toolchain might be different. I had a problem on x86_64 LFS-7.0 (gcc-4.6.1) when I built firefox-25, but at least the error message suggested the workaround - in that case, add -fpermissive to the CFLAGS. Usually, it is newer toolchains that give the grief. But first - one of the other threads (about a similar problem using a NAS box running a binary old version of cups) had some success reports for an upgrade - looks like something was changed, but it was apparently still some sort of 1.4 version, so maybe just a config switch was involved, or a patch. But one reporter said he had to add the printer again in osx. And that is where things get murky - http://wiki.phys.ethz.ch/readme/printing_with_lpr_macos_x says that apple have changed how printers are added, and that you will need to use the LPD protocol [ see the note at the bottom of that page - up to 10.7 you could use cups ]. OTOH, a different site talks about using cups with 10.7/8/9. I _think_ I would try installing current cups and its post-install deps [ it's a bit different since 1.6 ]. But that's only because no useful information about how they broke things seems to be out there. Good luck, I hope you manage to fix it (and don't break the other osx machine's printing in the process). ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Xorg-7.7 Does not Detect Input Devices on 64-bit Build
On Wed, Nov 06, 2013 at 10:36:07AM +, John Frankish wrote: > > > How would I go about using strace to check where the xorg-server is > > looking for 10-evdev.conf? > > > > > > Using "strace -o log_file Xorg -nolisten tcp &", Xorg beings to start up, but > then stops with the error: > > ... > xf86OpenConsole cannot open virtual console2 (permission denied) > > Examining the log file up to that point shows that "10-evdev.conf" is found > and parsed and libudev is found. > > Is there a way to use strace on Xorg without resorting to running it as root? > > Thanks > John I'm not aware of any. But if it found 10-evdev.conf, and that matches your working 32-bit version, then I've no idea why evdev isn't working for you. Not sure if either of the following links have any relevance - http://forums.gentoo.org/viewtopic-t-963468-start-0-postdays-0-postorder-asc-highlight-.html?sid=188698f49e2764a07d079e038b9acb2e or http://lists.x.org/archives/xorg/2011-June/053035.html Failing that, maybe there is something in the arch wiki - https://wiki.archlinux.org/index.php/Xorg Sorry I've no more ideas. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Wifi Operations--Again
On Mon, Nov 04, 2013 at 01:59:11AM +, Ken Moffat wrote: > Distros mostly use > NetworkManager - my only use of wifi on a pc is my netbook, which > uses NM [ and what a pain it is - it decided the passphrase for my > router had changed, now I have to type it in every time it wakes up]. > For anyone with a similar problem, using nm-connection-editor (I found it mentioned last night when I was preparing my scripts) has fixed it for me. Of course, 'buntu makes it really hard to get to any useful programs - I might have to take a few months out to put LFS on the netbook. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Xorg-7.7 Does not Detect Input Devices on 64-bit Build
On Mon, Nov 04, 2013 at 08:03:09AM +, John Frankish wrote: > > > > > > 10-evdev.conf is at /usr/local/share/X11/xorg.conf.d and verified to be > > > the > > > same as the 32-bit install, which works. > > > > I'm not sure I follow that : did you verify the file's contents or > > it's location match ? > > Both its location and its contents match exactly. > OK > > > I have the feeling that this is something to do with lib64 being > > > hardcoded > > > into evdev/mtdev somewhere in the 64-bit build, but ldd shows everything > > > to > > > be present and correct. > > > > Maybe strace would show you which places it was looking for conf > > files. I'm note sure about that (you would probably need to follow > > the child processes), and the output would certainly be large. > > > > I forget - were both keyboard and mouse non-functional until you > > added the old keyboard driver ? > > Both the keyboard and mouse were non-functional before I added the > /etc/X11/xorg.conf code to disable autoadddevice and installed the old > keyboard and mouse drivers. > > Also, from a comparison of the 32-bit Xorg.0.log, it looks like some video > functionality is not being added due to the lack of evdev driver. > > How would I go about using strace to check where the xorg-server is looking > for 10-evdev.conf? > As a high-level overview : install strace [ link from the Other Programming Tools page at the end of the main Programming chapter, just before java ] - there is a patch in patches. Then man strace for the semantics. Then strace startx. Please note that I said 'maybe' - I'm not sure if it will be useful. When/if you get an output file, open it in view or less and look for xorg.conf.d : the individual filenames aren't important, anything ending in .conf will be read, so it isn't specifically _looking_ for 10-evdev.conf, but it should read it if it finds it. If you do get an output file, I suppose that looking for evdev.conf in it should be the first step, just in case it does find it but takes a dislike to it. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Wifi Operations--Again
On Sun, Nov 03, 2013 at 06:13:25PM -0600, Dan McGhee wrote: > On 11/03/2013 05:42 PM, Ken Moffat wrote: > > Actually, if at all possible I'd use a wired network while > > building (faster downloads) and when first booting. > In my house it is possible. But I don't have a 20 ft cable. :) > For that length, don't get a cat-6 : they are much less flexible than cat-5e and will lay where they want, waiting to trip you. 8-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Wifi Operations--Again
On Sun, Nov 03, 2013 at 09:47:07PM -0300, Fernando de Oliveira wrote: > Em 03-11-2013 21:13, Dan McGhee escreveu: > > On 11/03/2013 05:42 PM, Ken Moffat wrote: > >> On Sun, Nov 03, 2013 at 05:16:23PM -0600, Dan McGhee wrote: > >>> First question, does anyone know if it's even possible to do this in > >>> chroot? > > There is one thing I am trying to understand. Forgive-me if I am missing > something. > > Is it so different with wifi? > > In my case there is no wifi. But in chroot I can use the network as is > set by the host, no need to try setting up the network in chroot: > Indeed. I don't know if Dan has already installed wget in chroot, which is partly why I suggested downloading on the host. The other part of 'partly' is that my own /sources is an nfs mount [ download once, build on one or more of my machines ]. What Dan seems to want to do differently is to *configure* the wifi in chroot. With wired ethernet, we have bootscripts which work. With wifi, people will have to work out how to set this up. Distros mostly use NetworkManager - my only use of wifi on a pc is my netbook, which uses NM [ and what a pain it is - it decided the passphrase for my router had changed, now I have to type it in every time it wakes up]. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Wifi Operations--Again
On Sun, Nov 03, 2013 at 05:16:23PM -0600, Dan McGhee wrote: > > First question, does anyone know if it's even possible to do this in > chroot? I have never had much luck building BLFS packages in a non X > situation. Therefore, it's easier for me to build in chroot until Xorg > is installed. Yes, I can use the host system to get packages and such, > but it would be more convenient if I could do this in chroot. So > knowing if this is even possible in chroot is important. What I know > right now is that I can do anything but get past my router in chroot. > (I also know that if I try to do this with wlan0 connected to my network > in the host system, I must reboot my laptop to clear whatever I've done > because I can't use the connection.) > No idea if it is possible, but configuring the network in chroot sounds *hard*. What's the problem with working out what you want to build, downloading on the host, and then running your scripts in chroot ? When you come to boot it, all manner of things can go wrong. Perhaps what you have done so far isn't sufficient, or maybe it's just the host's setup interfering with the chroot attempt. If it was my machine, I'd try to boot at an early stage, and try to fix any problems (perhaps by going back to chroot) until it did actually boot with connectivity. After that was working, I'd probably go back to chroot to build both X and a desktop browser of choice. Actually, if at all possible I'd use a wired network while building (faster downloads) and when first booting. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Xorg-7.7 Does not Detect Input Devices on 64-bit Build
On Sun, Nov 03, 2013 at 04:52:35PM -0300, Fernando de Oliveira wrote: > > ĸen, > > Sometimes I have some libtool complaints. Fox example, dozens of the kind: > > libtool: relink: warning: > `/usr/lib/gcc/i686-pc-linux-gnu/4.8.1/../../../libcairo.la' seems to be > moved > > I gave up removing the .la, after some problems that had to solve > individually. > > But my points (or questions) are: (1) never understood the reason and > (2) after your comment about /lib64, I remembered that I had these in 1686. > I build i686 very rarely, and obviously I don't read the logs. The symlink seemed a plausible reason why I was seeing these messages on x86_64, but now I'll have to mark it as "I don't know why these messages occur, they're annoying but not worth caring about." 8-() Thanks for the comment. Actually, I only really notice these messages when I'm building something by hand. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] at-spi2-core-2.10.1 build fails
On Sun, Nov 03, 2013 at 02:39:31PM -0300, Fernando de Oliveira wrote:
> Em 03-11-2013 13:58, Bruce Dubbs escreveu:
> > John Frankish wrote:
> >> Ref: Beyond Linux(r) From Scratch - Version 2013-11-01,
> >> at-spi2-core-2.10.1:
> >>
> >> The build fails with
> >>
> >> CC libatspi_la-atspi-value.lo
> >> CCLD libatspi.la
> >> GISCAN Atspi-2.0.gir
> >
> >> OSError: [Errno 2] No such file or directory
> >
> >> Is there a way to force make to provide more details as to what might be
> >> missing?
> >
> > Try using 'make V=1' for more verbose output.
> >
> >-- Bruce
> >
>
> I may be wrong, I am writing this from old memories when I had similar
> problems again and again.
>
> This must be related to gobject-introspection. Is it installed?
> Depending on the order when it was installed, other package(s) needs to
> be reinstalled (unfortunately, I failed to remember which one(s)). if
> somebody remembers, please help us. i think it might be just gtk+ that
> needs to be rebuilt. Or atk, too?
>
When I was testing totem for the 7.4 book, I did it on top of my
normal desktop which includes gtk2 and gtk3 but not introspection.
My rebuild order was : introspection, pango, atk, at-spi2-{core,atk},
gdk-pixbuf, gtk3.
> I never tried this solution, but there a switch that can be used in
> configure: --enable-introspection=no or perhaps just
> --disable-introspection. But it depends on how it is going to be used
> and perhaps if other applications have been built with gir support.
>
I normally use those for gucharmap, librsvg, pygobject2, and also
when building or rebuilding eudev. Probably both variants work.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] Xorg-7.7 Does not Detect Input Devices on 64-bit Build
On Sun, Nov 03, 2013 at 07:17:22AM +, John Frankish wrote:
> >
> >
> > It's a bit hard to diagnose when you use /usr/local/lib (it
> > *always* gets harder to build things correctly, e.g. PKG_CONFIG_PATH
> > needs to be set), and *my* modules are all in
> > /usr/lib/X11/modules/{,drivers/,input/} because I pass
> > --with-module-dir=/usr/lib/X11/modules. But your evdev_drv seems
> > to be in the right place for your system.
>
> Thanks for the feedback (in fact pkg-config will automatically look in
> /usr/local).
> The keyboard and mouse drivers are loaded from the same location as the evdev
> driver when I disable evdev
I disagree. I put a few packages into /usr/local the week
before last - dependencies for other packages I wanted to
test-build - and configure scripts failed to find the libraries
unless I exported PKG_CONFIG_DIR=/usr/local/lib/pkgconfig. The only
places pkgconfig is guaranteed to look are /usr/share/pkgconfig and
/usr/lib/pkgconfig.
>
> > BUT the first mentions of evdev in my log are
> >
> > [ 23798.003] (II) config/udev: Adding input device Power
> > Button(/dev/input/event1)
> > [ 23798.004] (**) Power Button: Applying InputClass "evdev keyboard
> > catchall"
> > [ 23798.004] (**) Power Button: Applying InputClass "keyboard-all"
> >
> > and that appears to be what causes evdev to get loaded. I guess
> > that's because the first entry in my /usr/share/X11/xorg.conf.d is
> > 10-evdev.conf : that has the settings to match /dev/input/event* to
> > the evdev driver. 10-evdev.conf comes from the xorg-server install.
> >
> > So, I guess there are three possibilities :
> >
> > 1. 10-evdev.conf didn't get installed - I guess that might happen if
> > the build for xorg-server thought it was on a non-linux system, but
> > it seems pretty unlikely.
>
> 10-evdev.conf is at /usr/local/share/X11/xorg.conf.d and verified to be the
> same as the 32-bit install, which works.
I'm not sure I follow that : did you verify the file's contents or
it's location match ?
>
> >2. 10-evdev.conf is somehow not in the right place (I guess it needs
> > to be in /usr/local for you, but you might find that putting it in
> > /etc/X11 works).
>
> I tried copying 10-evdev.conf to various locations, including
> /etc/X11/xorg.conf.d, without success
>
> > 3. The file is there, but your kernel is not providing
> > /dev/input/event* - probably, CONFIG_INPUT_EVDEV is not set.
> >
> CONFIG_INPUT_EVDEV is set in the kernel config and /proc/bus/input/devices
> shows the keyboard, mouse, etc, have been assigned event numbers.
>
> I have the feeling that this is something to do with lib64 being hardcoded
> into evdev/mtdev somewhere in the 64-bit build, but ldd shows everything to
> be present and correct.
>
As long as /lib64 is a symlink to /lib, everything just works. It
isn't strictly 'pure' (libtool complains that files seem to be
moved, which I'm sure is because of the symlink) but it works
well-enough and allows for the occasional stupid package which
insists on installing to lib64 for x86_64 [ I noticed a couple when
I was doing DESTDIR installs for the test compiles ].
> Thanks for the suggestions so far.
>
> John
Maybe strace would show you which places it was looking for conf
files. I'm note sure about that (you would probably need to follow
the child processes), and the output would certainly be large.
I forget - were both keyboard and mouse non-functional until you
added the old keyboard driver ?
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] Xorg-7.7 Does not Detect Input Devices on 64-bit Build
On Sat, Nov 02, 2013 at 12:35:10PM +, John Frankish wrote:
> > > >
> > > Do you have somthing like:
> > > [25.470] (II) LoadModule: "evdev"
> > > in the log?
> > > If not, It might be that you forgot to compile the evdev driver. (see
> > > Xorg drivers page).
> > >
> >
> > No, I don't have anything like LoadModule: "evdev", but the evdev driver is
> > there at:
> >
> > /usr/local/lib/xorg/modules/input/evdev_drv.so
> >
> > Note that the intel driver is loaded from:
> >
> > /usr/local/lib/xorg/modules/drivers/intel_drv.so
> >
> > Is there a way to force Xorg to use the old-style mouse/keyboard drivers
> > rather than evdev?
It's a bit hard to diagnose when you use /usr/local/lib (it
*always* gets harder to build things correctly, e.g. PKG_CONFIG_PATH
needs to be set), and *my* modules are all in
/usr/lib/X11/modules/{,drivers/,input/} because I pass
--with-module-dir=/usr/lib/X11/modules. But your evdev_drv seems
to be in the right place for your system.
BUT the first mentions of evdev in my log are
[ 23798.003] (II) config/udev: Adding input device Power Button
(/dev/input/event1)
[ 23798.004] (**) Power Button: Applying InputClass "evdev keyboard
catchall"
[ 23798.004] (**) Power Button: Applying InputClass "keyboard-all"
and that appears to be what causes evdev to get loaded. I guess
that's because the first entry in my /usr/share/X11/xorg.conf.d is
10-evdev.conf : that has the settings to match /dev/input/event* to
the evdev driver. 10-evdev.conf comes from the xorg-server install.
So, I guess there are three possibilities :
1. 10-evdev.conf didn't get installed - I guess that might happen if
the build for xorg-server thought it was on a non-linux system, but
it seems pretty unlikely.
2. 10-evdev.conf is somehow not in the right place (I guess it needs
to be in /usr/local for you, but you might find that putting it in
/etc/X11 works).
3. The file is there, but your kernel is not providing
/dev/input/event* - probably, CONFIG_INPUT_EVDEV is not set.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-support] firefox-25.0 on LFS-7.0
I've spent the day rebuilding firefox on all of my desktops that I
regard as "supported". Most of the x86_64 systems were no problem,
but my oldest is LFS-7.0 and on that it failed while building
js/src/vm/Debugger.cpp -
/scratch/working/mozilla-release/js/src/vm/Debugger.cpp:2674:1: error: invalid
conversion from 'JSBool (*)(JSContext*, unsigned int, JS::Value*) {aka int
(*)(JSContext*, unsigned int, JS::Value*)}' to
'JSPropertyOp {aka int (*)(JSContext*, JS::Handle, JS::Handle, JS::MutableHandle)}' [-fpermissive]
Followed by a host of similar messages. In this case,
[-fpermissive] is a hint : I added it to my CXXFLAGS (and also my
CFLAGS) and it has now completed. I hope that anyone else still
using such an old (2 years!) LFS for a desktop system will find that
useful :-)
Usually, it's *newer* versions of g++ which give the problems! In
this case, LFS-7.1 and LFS-7.3 were fine (I don't have an ongoing
7.2 system).
Still got one system to (re) do - LFS-7.4 (mostly) on my mac G5
with 32-bit ppc userspace : it failed during the link (after 8h40m),
the disk was full : only 4.5GB available on that filesystem before I
untarred firefox :-(
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] Dead links
On Sun, Oct 27, 2013 at 05:27:26PM -0400, Baho Utot wrote: > > nss-3.15.1-standalone-2.patch is not on anduin.linuxfromscratch.org, > well I can not find it > Does http://www.linuxfromscratch.org/patches/downloads/nss/ work for you ? ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] mpg123 and libtool .la files
On Sun, Oct 27, 2013 at 05:37:22PM +, Ken Moffat wrote: > On Sun, Oct 27, 2013 at 11:17:17AM -0500, Bruce Dubbs wrote: > > Ken Moffat wrote: > > > I just got round to doing some more use-testing of my current build > > > (for packages newer than what I built before) and hit a problem with > > > mpg123 : > > > > > > ken@ac4tv ~ $mpg123 > > > /sources/sounds/randall-preamp-channels/Plexi-TexasDirt.mp3 > > > [module.c:144] error: Failed to open module alsa: file not found > > > [module.c:144] error: Failed to open module oss: file not found > > > [module.c:144] error: Failed to open module sdl: file not found > > > [audio.c:180] error: Unable to find a working output module in this > > > list: alsa,oss,sdl > > > [audio.c:532] error: Failed to open audio output module > > > [mpg123.c:902] error: Failed to initialize output, goodbye. > > > > > > In the book, we get rid of .la files, except from ImageMagick, with > > > > > > find /lib /usr/lib -not -path "*Image*" -a -name \*.la -delete > > > > Hmm. We may want to add '-a -not -path "*mpg123*"' > > > > Do you wnat to do that? > > > >-- Bruce > > > I'd prefer confirmation that it isn't just something weird in my > build - we all know I get "issues" that nobody else reports :) > Someone has pointed me to the Command Explanations on the mpg123 page for the optional '--with-module-suffix=.so'. No further action. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] mpg123 and libtool .la files
On Sun, Oct 27, 2013 at 11:17:17AM -0500, Bruce Dubbs wrote: > Ken Moffat wrote: > > I just got round to doing some more use-testing of my current build > > (for packages newer than what I built before) and hit a problem with > > mpg123 : > > > > ken@ac4tv ~ $mpg123 > > /sources/sounds/randall-preamp-channels/Plexi-TexasDirt.mp3 > > [module.c:144] error: Failed to open module alsa: file not found > > [module.c:144] error: Failed to open module oss: file not found > > [module.c:144] error: Failed to open module sdl: file not found > > [audio.c:180] error: Unable to find a working output module in this > > list: alsa,oss,sdl > > [audio.c:532] error: Failed to open audio output module > > [mpg123.c:902] error: Failed to initialize output, goodbye. > > > > In the book, we get rid of .la files, except from ImageMagick, with > > > > find /lib /usr/lib -not -path "*Image*" -a -name \*.la -delete > > Hmm. We may want to add '-a -not -path "*mpg123*"' > > Do you wnat to do that? > >-- Bruce > I'd prefer confirmation that it isn't just something weird in my build - we all know I get "issues" that nobody else reports :) Thanks for the suggestion, I'll give it some testing on dummy data but probably not today. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] mpg123 and libtool .la files
I just got round to doing some more use-testing of my current build (for packages newer than what I built before) and hit a problem with mpg123 : ken@ac4tv ~ $mpg123 /sources/sounds/randall-preamp-channels/Plexi-TexasDirt.mp3 [module.c:144] error: Failed to open module alsa: file not found [module.c:144] error: Failed to open module oss: file not found [module.c:144] error: Failed to open module sdl: file not found [audio.c:180] error: Unable to find a working output module in this list: alsa,oss,sdl [audio.c:532] error: Failed to open audio output module [mpg123.c:902] error: Failed to initialize output, goodbye. In the book, we get rid of .la files, except from ImageMagick, with find /lib /usr/lib -not -path "*Image*" -a -name \*.la -delete but my builds are less "all or nothing" - I rename them to '.hidden' like I do for static libs, so that I can make them accessible if ever required. This is what I had: ken@ac4tv ~ $grep '/usr/lib/' /home/logs/LFS-svn-20131006-1/desktop5/mpg123-1.15.4.log.installed /usr/lib/libmpg123.la.hidden /usr/lib/libmpg123.so /usr/lib/libmpg123.so.0 /usr/lib/libmpg123.so.0.37.5 /usr/lib/mpg123 /usr/lib/mpg123/output_alsa.la.hidden /usr/lib/mpg123/output_alsa.so /usr/lib/mpg123/output_dummy.la.hidden /usr/lib/mpg123/output_dummy.so /usr/lib/mpg123/output_oss.la.hidden /usr/lib/mpg123/output_oss.so /usr/lib/mpg123/output_sdl.la.hidden /usr/lib/mpg123/output_sdl.so /usr/lib/pkgconfig/libmpg123.pc In my case, I only want to use alsa and I've now got it working by reinstating (only) the output_alsa.la file. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Building with make-4.0
As I have mentioned, I'm testing make-4.0 against the packages in the BLFS books : 3.82 gave problems with a few (gstreamer, one of its plugin packages, and I think one other package) and 4.0 has a few backward-incompatible changes/fixes. This is only a test to check that the packages build and install. My initial results are at http://www.linuxfromscratch.org/~ken/make-4.0-testing/ - a file of everything I've built so far, and a summary which will eventually collate the notes for this and the next build. Initial summary : only qemu had a problem - there is a workaround in BLFS, and one of its maintainers has a patch to fix it. In this build, a few packages were out of date. I also avoid a *lot* of traditional xorg packages and most of the gnome packages which are still in BLFS. The next build will aim to cover those, as well as the other missing packages. What I don't intend to test is new packages added to BLFS since 9th October. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Squid Configure
On Mon, Oct 21, 2013 at 11:09:44AM +0200, thorsten wrote: > Am 10/12/13 03:03, schrieb Ken Moffat: > > > /me resolves never to touch squid with the proverbial barge-pole. > > > > ĸen > > > Hello Ken, > > just a curious question: what do you dislike about squid? And which > alternative do you use? > > Thanks, > > Thorsten > That comment was after the original problem was reported to be solved by installing an uncommon netfilter library which is not intended for general use. We never found out what configure options were being used, but I have to assume that one of them, and/or a deleted library, caused the problem. If you read the whole thread you'll see that I managed to compile the current release (3.4.0.2) without difficulty, using its default options. But I have no requirement for it, nor for any of its alternatives. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Compiling PyPy?
On Mon, Oct 21, 2013 at 12:28:10AM +0100, Ken Moffat wrote: > > Will leave it running for a while, I'm still up (sorting out what > fits where in my make-4.0 testing) so it can have an hour or two. > It stalled: [translation:ERROR] assert not self.finished_helpers [translation:ERROR] AssertionError [translation] start debugger... > /scratch/ken/pypy-2.1-src/rpython/memory/gctransform/transform.py(261)annotate_helper() -> assert not self.finished_helpers (Pdb+) It continued after I keyed Ctrl-C, but I don't have any confidence in letting it continue so I killed it. That was just over an hour. So no, it doesn't build for me. And since that command isn't using make, I think the same will be true on 7.4. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Compiling PyPy?
On Sun, Oct 20, 2013 at 05:18:49PM -0500, rhubarbpie...@gmail.com wrote: > Has anyone compiled PyPy on BLFS 7.4? I compiled Python and libffi > using --with-pydebug and --enable-debug respectively and attempted to > compile from pypy/goal with: > > python ../../rpython/bin/rpython --opt=mem targetpypystandalone.py > python ../../rpython/bin/rpython --opt=jit targetpypystandalone.py > > Both attempts seemed to be compiling, with characters walking across the > screen. I received no errors, but neither finished. The documentation > mentions compiling is quite long, with 45 minutes on a fast machine. My > machine isn't fast, but I gave both attempts many multiples of 45 > minutes (six and nine hours respectively). Both attempts were > unattended but were happily churning away when I returned. > Unfortunately, I was far from happy as neither had finished and the jit > attempt was mercilessly pounding the hard drive. > Is the required 4G of memory perhaps the problem ? Original paragraph, now out of date but left as a comment - I don't have debug versions of python and libffi, and the build is poorly documented. Arch (usually fairly reliable, except for testsuites) show that it needs a binary pypy installed - normal for many languages which bootstrap - and the files pypy offers for x86_64 are for ubuntu-12.04 - no idea what symlinks would be needed, nor if my own glibc has an old enough '--enable-kernel='. FWIW, the 32-bit binary is targetted at ubuntu-10.04. Then I realised you had provided a recipe. OK, I'm running the first line for python2 at the moment (AMD phenom, seems to run flat-out [3400MHz] on the cores it is using for this) and it was obviously written by someone who thinks that using multiple colours to create random patterns is a clever thing to do ;-) Perhaps the various "+%#* ." symbols in the pattern mean different things - I do note that the pattern appears to be adapted to the terminal width [ I'm on 100x40 for this ], but my overall impression is that it's a toy. I'm also unimpressed by red text for the error messages - very hard to read on my black background. Will leave it running for a while, I'm still up (sorting out what fits where in my make-4.0 testing) so it can have an hour or two. Most recent white message was [rtyper] specializing: 8700 / 172911 blocks (5%) If it doesn't complete by the time I'm done, I'll leave the box up and reply with timings if it completes. This machine has 8GB and I'm barely doing anything else, so I _should_ have enough memory without swapping ;-) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] How to clean up /usr/lib/
On Thu, Oct 17, 2013 at 10:12:47AM -0500, Bruce Dubbs wrote: > alex lupu wrote: > > Hi Bruce, > > > >>> ... > >>>921939 2012-03-27 12:51 libjpeg.so.8.4.0 > >>>425541 2013-09-30 12:05 libjpeg.so.8.0.2 > >>>16 2013-09-30 12:05 libjpeg.so.8 -> libjpeg.so.8.4.0 > >>>16 2013-09-30 12:05 libjpeg.so -> libjpeg.so.8.0.2 > > > >> ... > >> Note that only libjpeg.so -> libjpeg.so.8.0.2 is used for new builds and > >> libjpeg.so.8 points to libjpeg.so.8.4.0. I think there is a potential > >> problem there. > > > > Was this problem caused by me (by mistake, obviously) or is this the way > > libjpeg installs these days? > > I don't know. I only have > > /usr/lib/libjpeg.so -> libjpeg.so.8.0.2 > /usr/lib/libjpeg.so.8 -> libjpeg.so.8.0.2 > /usr/lib/libjpeg.so.8.0.2 > > right now. Those are from libjpeg-turbo-1.3.0. > >-- Bruce > Been here, and eventually found the problem. This is only an issue for people who install libjpeg-turbo on a system where libjpeg is already installed. 1. Turbo installs v8 jpeg as 8.0.2, but most people who had real jpegsrc.v8 used "newer" versions such as the 8.4.0 in this case. 2. ldconfig will remake the symlinks whenever it is run, and will point to the newest version (8.4.0 in this case). For me, this was an issue whenever I upgraded things on old (as in "built before I used jpeg-turbo") systems - firefox would break (ran, but not all jpegs, particularly thumbnails, were displayed. Now I've only got one or two such systems, and only firefox is likely to get updated on them. My firefox upgrade script now checks where libjpeg.so.8 points, and forcibly remakes the symlink to point to the lower number where necessary. People who built jpeg-turbo as v7 or v6 might also see a similar issue. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] kde - hopefully, my final comment
On Wed, Oct 16, 2013 at 01:54:47AM +0100, Ken Moffat wrote:
This is interfering with my sleep - went to bed, couldn't sleep,
thinking about this. The answer was, eventually obvious (and the
hint was where I said re kdelibs that I'd hardcoded everything to
/usr. For this one I'd done an unthinking copy-n-paste.
> file(RELATIVE_PATH relInstallDir
> ${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}/cmake/libkcddb
> ${CMAKE_INSTALL_PREFIX})
So, this is another 'mea culpa' - I still don't think the kde build
system is robust, but sorry for the noise and wasting people's time.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] kde - hopefully, my final comment
On Tue, Oct 15, 2013 at 02:53:05PM -0500, Bruce Dubbs wrote:
> Ken Moffat wrote:
> > I had overlooked that one of the kde packages in the book fails to
> > configure for me. It's libkcddb. I wasn't intending to install it
> > ('/' is all-but-full), only do a DESTDIR on another filesystem, but
> > I'd better record it :
> >
> > ken@ac4tv /scratch/ken/libkcddb-4.11.1/build $cmake
> > -DCMAKE_INSTALL_PREFIX=$KDE_PREFIX \
> >>-DCMAKE_BUILD_TYPE=Release \
> >>..
>
> > -- Found the KDE4 kconfig_compiler preprocessor:
> > /usr/bin/kconfig_compiler
> > -- Found automoc4: /usr/bin/automoc4
> > -- Found MusicBrainz5: /usr/include
> > CMake Error at CMakeLists.txt:37 (file):
> >file RELATIVE_PATH called with incorrect number of arguments
>
> My log from KDE-4.11.0:
>
> -- Found automoc4: /opt/qt/bin/automoc4
> -- Found MusicBrainz5: /usr/include
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /tmp/libkcddb/libkcddb-4.11.0/build
>
> I can't explain the difference.
>
>-- Bruce
Interesting. I get the exact same error in 4.11.0 and 4.11.2.
Line 37 is the line after the comment:
# Figure out the relative path from the installed Config.cmake file
# to the install prefix (which may be at
# runtime different from the chosen CMAKE_INSTALL_PREFIX if under
# Windows the package was installed anywhere)
# This relative path will be configured into LibkcddbConfig.cmake
file(RELATIVE_PATH relInstallDir
${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}/cmake/libkcddb
${CMAKE_INSTALL_PREFIX})
I'm only mentioning this because it means I can't test k3b.
Still don't think it is related to make-4.0. See rt's comments in
the soprano ticket [ #4167 ] as circumstantial evidence that kde
configuration may be problematic.
I'm sure there will be other things I can't test - or perhaps my
interest in build-testing the less-used parts of BLFS (e.g.
sendmail) will cause me to give up first.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] kdelibs-4.11.1 build error
On Tue, Oct 15, 2013 at 10:35:14PM +0200, Igor Živković wrote: > On 2013-10-15 21:38, Ken Moffat wrote: > > On Tue, Oct 15, 2013 at 02:31:02PM -0500, Bruce Dubbs wrote: > >> Ken Moffat wrote: > >>> > >>> okular (can display everything _except_ PDFs in this build) > >> > >> I have no problem viewing PDFs. > > > > Obviously a local problem, but for the moment I'm happy to stick to > > evince-3.8 (will try 3.10 when I build gnome), and epdfview for PDFs > > where it works. > > If you're looking for something light on dependencies and still > maintained I'd suggest you to check out > http://pwmt.org/projects/zathura/ or http://naihe2010.github.io/apvlv/ > I'll take a look after I've finished trying the rest of the book. Before that I'll be looking at what else I can build now, then I'll do a mostly chroot build - primarily for gnome, but also for twm and some legacy fonts. That will be slimmed-down (once I've worked out the deps and build order) - e.g. I won't bother building firefox, I'll be in chroot so I can use firefox on the host if/when I have problems. Don't hold your breathe. I'll post my interim results in my lfs webspace when I think I've completed the current round of packages. So far, nothing appears to be impacted by make-4.0. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] kdelibs-4.11.1 build error
On Tue, Oct 15, 2013 at 02:31:02PM -0500, Bruce Dubbs wrote: > Ken Moffat wrote: > > > After looking at the kde apps I have installed : konsole (always > > starts with a small font), > > I haven't found that to be true. Even if I had, I can edit the profile > to use any font, size, and color scheme I want and it will stay that way > until I change it. The changes are saved at > ~/.kde4/share/apps/konsole/Shell.profile. For me, I like: > > [Appearance] > ColorScheme=GreenOnBlack > Font=DejaVu Sans Mono,10,-1,5,50,0,0,0,0,0 > I can't in all honesty say that I'll try that, but thanks for documenting it. I increased the font size with ctrl+ and made the screen bigger by pulling it, used, closed. Ran it again, the enlarged screen was in the same place, but the font was its original small size. > > okular (can display everything _except_ PDFs in this build) > > I have no problem viewing PDFs. > >-- Bruce Obviously a local problem, but for the moment I'm happy to stick to evince-3.8 (will try 3.10 when I build gnome), and epdfview for PDFs where it works. Anyway, back to testing other packages with make-4.0 : after the issues with 3.82 (e.g gstreamer, ISTR) I'm still expecting that something other than glibc will fail to build out of the box :) ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] kde - hopefully, my final comment
I had overlooked that one of the kde packages in the book fails to
configure for me. It's libkcddb. I wasn't intending to install it
('/' is all-but-full), only do a DESTDIR on another filesystem, but
I'd better record it :
ken@ac4tv /scratch/ken/libkcddb-4.11.1/build $cmake
-DCMAKE_INSTALL_PREFIX=$KDE_PREFIX \
> -DCMAKE_BUILD_TYPE=Release \
> ..
-- The C compiler identification is GNU 4.8.1
-- The CXX compiler identification is GNU 4.8.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found
-- Found Qt-Version 4.8.5 (using /usr/bin/qmake)
-- Looking for XOpenDisplay in
/usr/lib64/libX11.so;/usr/lib64/libXext.so;/usr/lib64/libXft.so;/usr/lib64/libXau.so;/usr/lib64/libXdmcp.so;/usr/lib64/libXpm.so
-- Looking for XOpenDisplay in
/usr/lib64/libX11.so;/usr/lib64/libXext.so;/usr/lib64/libXft.so;/usr/lib64/libXau.so;/usr/lib64/libXdmcp.so;/usr/lib64/libXpm.so
- found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib64/libX11.so
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found OpenSSL: /usr/lib64/libssl.so;/usr/lib64/libcrypto.so
(found version "1.0.1e")
-- Looking for _POSIX_TIMERS
-- Looking for _POSIX_TIMERS - found
-- Found Automoc4: /usr/bin/automoc4
-- Found Perl: /usr/bin/perl (found version "5.18.1")
-- Found Phonon: /usr/include (Required is at least version
"4.3.80")
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
-- Performing Test HAVE_FPIE_SUPPORT
-- Performing Test HAVE_FPIE_SUPPORT - Success
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL - Success
-- Performing Test __KDE_HAVE_GCC_VISIBILITY
-- Performing Test __KDE_HAVE_GCC_VISIBILITY - Success
-- Found KDE 4.11 include dir: /usr/include
-- Found KDE 4.11 library dir: /usr/lib
-- Found the KDE4 kconfig_compiler preprocessor:
/usr/bin/kconfig_compiler
-- Found automoc4: /usr/bin/automoc4
-- Found MusicBrainz5: /usr/include
CMake Error at CMakeLists.txt:37 (file):
file RELATIVE_PATH called with incorrect number of arguments
-- Configuring incomplete, errors occurred!
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] kdelibs-4.11.1 build error
On Tue, Oct 15, 2013 at 12:48:27AM +0100, Ken Moffat wrote: > On Mon, Oct 14, 2013 at 09:31:17PM +0100, Ken Moffat wrote: > > I'd also forgotten that kde/cmake tells you very little that is > useful about how it is trying to link things. And I forget things > from 4½ years ago. Thread at > http://comments.gmane.org/gmane.linux.lfs.beyond.devel/18284 > eventually mentions libQtUiTools. > If anybody else suppresses static libs, and wants to build kde, libQtUiTools.a is also used by kdepim-runtime and kdepim. After looking at the kde apps I have installed : konsole (always starts with a small font), juk (useless for me, but no worse than rhythmbox), kmix (works, but is now enormous on the screen), dragon (works fine), konqueror (works), okular (can display everything _except_ PDFs in this build) I conclude that revisiting kde will be a waste of my time. Meanwhile, my dislike of cmake has slightly reduced (only libarchive is now a dependency I would not otherwise install to get it to build with system libs, so I might look more kindly at non-kde packages which use cmake. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] kdelibs-4.11.1 build error
On Mon, Oct 14, 2013 at 09:31:17PM +0100, Ken Moffat wrote: > > I'm putting everything in /usr, so I now have -prefix /usr through > to -translationdir /usr/share/qt4/translations as in the book's > Method 1. I don't have -plugin-sql-sqlite, all the other options > appear to be the same. So, if a problem only applies to my builds, it must be something different in *how* I build it. I remembered that _something_ in kde4 used to need a static lib, but I guess the fact kdelibs built the first time made me discount that. I'd also forgotten that kde/cmake tells you very little that is useful about how it is trying to link things. And I forget things from 4½ years ago. Thread at http://comments.gmane.org/gmane.linux.lfs.beyond.devel/18284 eventually mentions libQtUiTools. Summary : I hide static libs until they are proved to be required, by renaming them to libwhatever.a.hidden. In regular programs (firefox, tk, xulrunner and also current yaboot) I occasionally see error messages referencing libwhatever and after a bit of looking around I usually see what needs to be done. This time it really did match my .sig - according to Wikipedia, Monday is/was the 23rd Vendémiaire in the French revolutionary calendar (I looked it up after being reminded of my earlier version of the sig from Marx's 18e Brumaire), and that day is associated with the Navet (Turnip) which is how I now feel ;-) http://en.wikipedia.org/wiki/French_revolutionary_calendar ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] kdelibs-4.11.1 build error
On Mon, Oct 14, 2013 at 02:33:36PM -0500, Bruce Dubbs wrote: > > The configuration I use for Qt is: > > ./configure -confirm-license \ > -opensource \ > -release \ > -prefix /opt/qt-$VERSION \ > -sysconfdir /etc/xdg \ > -dbus-linked \ > -openssl-linked \ > -system-sqlite \ > -plugin-sql-sqlite \ > -no-phonon \ > -no-phonon-backend \ > -no-nis \ > -no-openvg \ > -nomake demos\ > -nomake examples \ > -optimized-qmake && > > With that, I didn't have a problem with KDE (4.11). > I'm putting everything in /usr, so I now have -prefix /usr through to -translationdir /usr/share/qt4/translations as in the book's Method 1. I don't have -plugin-sql-sqlite, all the other options appear to be the same. I'm hardcoding -DCMAKE_INSTALL_PREFIX=/usr for all the cmake apps. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] kdelibs-4.11.1 build error
On Sun, Oct 13, 2013 at 11:09:51PM +0100, Ken Moffat wrote: > On Sun, Oct 13, 2013 at 02:24:29AM +0100, Ken Moffat wrote: > > I was ploughing slowly through the desktop packages, looking for > > problems with make-4.0. But I've come to a halt in kdelibs : > > > Sorted: due to an inadequate qt build - I'd only needed qt for vlc, > so I was passing -no-accessibility. KDE needs the accessibility > functions in qt. > But back to a dead end in kdelibs. After I rebuilt qt with accessibility enabled, I got past kdelibs and as far as kde-baseapps which failed looking for k3listview.h - that comes from kdelibs and presumably needs qt3 support in qt (I'd disabled that, neither arora nor vlc need it and smaller is better) So, I rebuilt my whole kde stack from qt onwards (qt, JS, libgpg-error, libassuan, gpgme, cyrus-sasl, polkit, acl, ConsoleKit, xcb-util-*, libarchive, cmake, libical, automoc, phonon, gstreamer backend, boost, libiodbc, virtuoso, soprano, akonadi, attica,qimageblitz, shared desktop ontologies, polkit-qt, oxygen-icons, qca, libdbusmenu-qt, strigi, libdaemon, avahi, aspell + dict, enchant, grantlee all rebuilt) but now I again can't get kdelibs to build : Linking CXX shared library ../../lib/libkjsembed.so CMakeFiles/kjsembed.dir/qwidget_binding.o: In function `KJSEmbed::uiLoader()': qwidget_binding.cpp:(.text+0x24): undefined reference to `QUiLoader::QUiLoader(QObject*)' CMakeFiles/kjsembed.dir/quiloader_binding.o: In function `KJSEmbed::UiLoaderBinding::bindMethod(KJS::ExecState*, PointerBase&)': and several more undefined references to QUiLoader functions, then collect2: error: ld returned 1 exit status kjsembed/kjsembed/CMakeFiles/kjsembed.dir/build.make:995: recipe for target 'lib/libkjsembed.so.4.11.1' failed make[2]: *** [lib/libkjsembed.so.4.11.1] Error 1 Doesn't seem to be related to make-4.0, and my qt build matches the book. Any ideas, pretty please ? I realise I've still got the non-qt3-compatible versions of polkit-kde-agent, nepomuk*, qjson, kdepimlibs, kactivities, kde-runtime installed, but I find it hard to believe those will break the build. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] kdelibs-4.11.1 build error
On Sun, Oct 13, 2013 at 02:24:29AM +0100, Ken Moffat wrote: > I was ploughing slowly through the desktop packages, looking for > problems with make-4.0. But I've come to a halt in kdelibs : > > [ 14%] Building CXX object > kdeui/CMakeFiles/kdeui.dir/widgets/kcapacitybar.o > /scratch/working/kdelibs-4.11.1/kdeui/widgets/kcapacitybar.cpp: In > member function ‘void KCapacityBar::setText(const QString&)’: > /scratch/working/kdelibs-4.11.1/kdeui/widgets/kcapacitybar.cpp:96:27: > error: ‘setAccessibleName’ was not declared in this scope > setAccessibleName(text); >^ Sorted: due to an inadequate qt build - I'd only needed qt for vlc, so I was passing -no-accessibility. KDE needs the accessibility functions in qt. I guess the kde devs are spoiled - they assume everybody enables all the options of everything, so they don't test to see whether headers/libraries are not only present, but contain the functions they want to use. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] kdelibs-4.11.1 build error
I was ploughing slowly through the desktop packages, looking for problems with make-4.0. But I've come to a halt in kdelibs : [ 14%] Building CXX object kdeui/CMakeFiles/kdeui.dir/widgets/kcapacitybar.o /scratch/working/kdelibs-4.11.1/kdeui/widgets/kcapacitybar.cpp: In member function ‘void KCapacityBar::setText(const QString&)’: /scratch/working/kdelibs-4.11.1/kdeui/widgets/kcapacitybar.cpp:96:27: error: ‘setAccessibleName’ was not declared in this scope setAccessibleName(text); ^ kdeui/CMakeFiles/kdeui.dir/build.make:4040: recipe for target 'kdeui/CMakeFiles/kdeui.dir/widgets/kcapacitybar.o' failed make[2]: *** [kdeui/CMakeFiles/kdeui.dir/widgets/kcapacitybar.o] Error 1 CMakeFiles/Makefile2:7780: recipe for target 'kdeui/CMakeFiles/kdeui.dir/all' failed make[1]: *** [kdeui/CMakeFiles/kdeui.dir/all] Error 2 Makefile:146: recipe for target 'all' failed make: *** [all] Error 2 To me, that looks like a toolchain problem (usually, newer glibc), but this is LFS-svn-20131006. I note that I don't have the recommended upower, nor either version of udisks (I'm intending to keep this build in use for a few days - not willing to add libusb etc which might break my printing). I also built qt without -no-phonon-backend and -optimized-qmake but I will be very surprised if those switches are the problem. Giving up for tonight. Current status : everything _I_ care about in the BLFS book as at 20131009 [ but using gnome-3.8 versions as in BLFS-7.4 - that includes glib...gtk3 ] builds with make-4.0, as does xfce. Thanks for any clue. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Squid Configure
On Sat, Oct 12, 2013 at 10:38:19AM -0400, Casey Daniels wrote:
>
> On 10/12/2013 10:18 AM, Ken Moffat wrote:
> > On Sat, Oct 12, 2013 at 02:03:43AM +0100, Ken Moffat wrote:
> >> Glad you were right - I've just posted that this seemed unlikely to
> >> be the error, but if it builds then you are sorted.
> >>
> >> /me resolves never to touch squid with the proverbial barge-pole.
> >>
> > Slept on it, decided that since I am actually looking for build
> > problems (but related to make-4.0) and I haven't prepared my scripts
> > to build kde, I might as well give it a try.
> >
> > 3.3.9 configured ok (with the default settings), but first there was
> > a segfault in g++, then when I resumed it eventually produced an
> > internal error in gas.
> >
> > Took my own advice, tried 3.4.0.2 - no issues, did a successful
> > DESTDIR install.
> >
> > ĸen
> Just curious, did you try to load it? I also had an issue loaded it, it
> was looking for libecap.so.2 which was also out of place.
>
> Casey
It isn't installed, and I have no use for it. But this is what ldd
reports (built with just ./configure --prefix=/usr) - no idea if
libcap and libattr are required, they happen to be present on this
system :
ken@ac4tv ~ $ldd /scratch/ken/SQUID3402/usr/bin/*
/scratch/ken/SQUID3402/usr/bin/purge:
linux-vdso.so.1 (0x7fff01dff000)
libnsl.so.1 => /lib/libnsl.so.1 (0x7f0647d06000)
libresolv.so.2 => /lib/libresolv.so.2 (0x7f0647aeb000)
libcap.so.2 => /lib/libcap.so.2 (0x7f06478e7000)
librt.so.1 => /lib/librt.so.1 (0x7f06476df000)
libdl.so.2 => /lib/libdl.so.2 (0x7f06474db000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f06471d8000)
libm.so.6 => /lib/libm.so.6 (0x7f0646ed1000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f0646cbb000)
libc.so.6 => /lib/libc.so.6 (0x7f06468f1000)
libattr.so.1 => /lib/libattr.so.1 (0x7f06466ed000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7f06464ce000)
/lib64/ld-linux-x86-64.so.2 (0x7f0647f2)
/scratch/ken/SQUID3402/usr/bin/squidclient:
linux-vdso.so.1 (0x7fff30a71000)
libnsl.so.1 => /lib/libnsl.so.1 (0x7fd188a7b000)
libresolv.so.2 => /lib/libresolv.so.2 (0x7fd18886)
libcap.so.2 => /lib/libcap.so.2 (0x7fd18865c000)
librt.so.1 => /lib/librt.so.1 (0x7fd188454000)
libdl.so.2 => /lib/libdl.so.2 (0x7fd18825)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7fd187f4d000)
libm.so.6 => /lib/libm.so.6 (0x7fd187c46000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7fd187a3)
libc.so.6 => /lib/libc.so.6 (0x7fd187666000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7fd187447000)
libattr.so.1 => /lib/libattr.so.1 (0x7fd187243000)
/lib64/ld-linux-x86-64.so.2 (0x7fd188c95000)
Looking for what else is present, I note that --sysconfdir=/etc
would be a good idea if building in /usr, and --libexecdir for those
who dislike /usr/libexec. Ah, squid itself is in /usr/sbin :
ken@ac4tv ~ $ldd /scratch/ken/SQUID3402/usr/sbin/squid
linux-vdso.so.1 (0x7fffd000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7f5ac7b05000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x7f5ac78cc000)
libnsl.so.1 => /lib/libnsl.so.1 (0x7f5ac76b2000)
libresolv.so.2 => /lib/libresolv.so.2 (0x7f5ac7497000)
libcap.so.2 => /lib/libcap.so.2 (0x7f5ac7293000)
librt.so.1 => /lib/librt.so.1 (0x7f5ac708b000)
libdl.so.2 => /lib/libdl.so.2 (0x7f5ac6e87000)
libltdl.so.7 => /usr/lib/libltdl.so.7 (0x7f5ac6c7e000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f5ac697b000)
libm.so.6 => /lib/libm.so.6 (0x7f5ac6674000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f5ac645e000)
libc.so.6 => /lib/libc.so.6 (0x7f5ac6094000)
/lib64/ld-linux-x86-64.so.2 (0x7f5ac7d24000)
libattr.so.1 => /lib/libattr.so.1 (0x7f5ac5e9)
and for the *many* libexec progs (several are scripts, and the libs
produce different addresses):
ken@ac4tv ~ $ldd /scratch/ken/SQUID3402/usr/libexec/* | grep -v ':' | cut -d
'(' -f 1 | sort -u
/lib64/ld-linux-x86-64.so.2
libattr.so.1 => /lib/libattr.so.1
libcap.so.2 => /lib/libcap.so.2
libcrypt.so.1 => /lib/libcrypt.so.1
libc.so.6 => /lib/libc.so.6
libdb-6.0.so => /usr/lib/libdb-6.0.so
libdl.so.2 => /lib/libdl.so.2
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libm.so.6 => /lib/libm.s
Re: [blfs-support] Squid Configure
On Sat, Oct 12, 2013 at 02:03:43AM +0100, Ken Moffat wrote: > > Glad you were right - I've just posted that this seemed unlikely to > be the error, but if it builds then you are sorted. > > /me resolves never to touch squid with the proverbial barge-pole. > Slept on it, decided that since I am actually looking for build problems (but related to make-4.0) and I haven't prepared my scripts to build kde, I might as well give it a try. 3.3.9 configured ok (with the default settings), but first there was a segfault in g++, then when I resumed it eventually produced an internal error in gas. Took my own advice, tried 3.4.0.2 - no issues, did a successful DESTDIR install. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
