Re: [blfs-support] Is it worth jumping in for me? / Can LFS be even more simple?

[Michael Shell via blfs-support]

On Wed, 6 Jan 2021 22:24:21 -0600
Paul via blfs-support  wrote:

> Question 2: Is it possible to run a system using only the kernel, grub 
> (or other bootloader), maybe a compiler/libc if I need it, and a single 
> executible loaded by the kernel that I would write in C?


Just for the record, yes. What you are asking concerns the use of
a custom init process, which is the initial "mother" process that
all the other/later processes are spawned from.

Your custom "init" program (if called something other than the system
default /sbin/init ) can be specified via the init= kernel option:

https://unix.stackexchange.com/questions/428347/how-to-pass-arguments-to-a-linux-kernel-init-bootparam
https://www.cyberciti.biz/tips/10-boot-time-parameters-you-should-know-about-the-linux-kernel.html

and that process, and only that process, will be started after the
kernel is loaded.

Note that the kernel init= option has been used in the past to bypass
login security:

https://unix.stackexchange.com/questions/172651/disallow-change-of-init-kernel-parameter

Most bootloaders have a security feature that allows init= to be disabled.

However, in that regard, always bear in mind that it is a
difficult/impossible task to totally secure a machine that a
potential attacker has physical access to.


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Default Printer Not Showing In Firefox Or Thunderbird

[Michael Shell via blfs-support]

On Tue, 08 Sep 2020 11:31:58 +0200
Stephen Berman via blfs-support  wrote:

> added the line `gtk-print-backends = cups,file,lpr' to
> ~/.config/gtk-3.0/settings.ini and now firefox shows the printer.

Thanks for posting the solution.

Maybe this setting should be added to the GTK+3 configuration
example in the BLFS book:

http://www.linuxfromscratch.org/blfs/view/svn/x/gtk3.html

possibly with a note that mentions the need for this setting
for Firefox.


  Mike Shell


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Introduction and request for information on Bind uid to 0: Operation not permitted

[Michael Shell via blfs-support]

On Thu, 17 Oct 2019 05:45:10 +
EscuelitaViva via blfs-support  wrote:

> New to the list and will be helping out as best I can to support my
> favorite project, LFS. I'm a grey beard, a throw back from the Commodore,
> Atari, Timex Sinclair, Trash 80 days. Anyone program Fortran here?
> Never mind ;P

Welcome! :) FWIW, I still own a working TRS-80 Model I system - complete
with expansion interface (48K RAM, two disk drives, etc.). It was given to me
by my high school after they upgraded to Macs. My own personal system back
in those days was a TRS-80 Color Computer.

> But at the rate things are changing, not just in our field, but in the
> world in general ... going to need a miracle to pull off supporting
> the exponential growth of these systems in the future.

This is something people don't appreciate yet - that complexity carries
a cost of its own. In the recent (October) issue of IEEE Spectrum, there
is an article about how traffic apps are *causing* traffic jams because
they fail to take into consideration how their use/advice will alter
existing traffic patterns. Also, they don't consider factors such as
the (un)suitability of certain roads, when schools let out, etc.

The coming end of Moore's Law will slow the change - systems will advance
linearly rather than exponentially. I believe that there will then be a
greater emphasis on quality and reliability than is the case today.

One of the many things I like about LFS is that, to me, in some respects,
complexity is actually *reduced*, at least in the long term. There
certainly is a steep learning curve, but the Unix system evolves slowly
and deliberately - when changes happen, there usually is some good
engineering reason for doing so. Contrast this with how unwanted
changes are often quickly forced down the throats of users of
Microsoft products, etc.


   Cheers,

   Mike Shell
 
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] BLFS-8.1 with new kernel patches

[Michael Shell via blfs-support]

On Tue, 30 Jul 2019 10:20:24 +0100
Richard Melville via blfs-support  
wrote:

> There's also Startpage and Qwant


Thanks for those! But, Startpage does rely on Google's engine,
and Qwant on Bing's:

https://en.wikipedia.org/wiki/Startpage.com
https://en.wikipedia.org/wiki/Qwant


I also forgot to mention the Russian search engine:

https://yandex.com/
https://en.wikipedia.org/wiki/Yandex_Search

Yandex is impressive.


  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] BLFS-8.1 with new kernel patches

[Michael Shell via blfs-support]

On Thu, 25 Jul 2019 20:55:18 +0100
Ken Moffat via blfs-support  wrote:

> Sorry, I've no idea for what to search for (current google mostly
> returns results for multiple terms with one of the crossed through
> in the 'must include' underneath the summary.


FWIW, Google is really, really going downhill for all
non-brain-dead users, to the point of being scary:

https://www.reddit.com/r/google/comments/azcdp7/google_sucks_now/

DuckDuckGo is improving as an alternative:

https://duckduckgo.com/

And GNU/FSF's distributed peer-to-peer search engine, Yacy, 

http://search.yacy.net/
http://yacy.searchlab.eu/
https://www.theregister.co.uk/2011/11/29/yacy_google_open_source_engine/

is supposedly quite good for computer and open source software
queries, but not so much for more mainstream stuff.

In any case, if Google keeps going on its current course,
it will no longer be a usable search tool. It already is
a shadow of what it was in the late 90's and early 2000's.


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] twm menu not working(SOLVED)

[Michael Shell via blfs-support]

On Sat, 9 Feb 2019 21:29:42 +0100
Cliff McDiarmid via blfs-support  
wrote:

> Yes that's it Douglas. I had avoided the legacy fonts, not thinking they
> would effect TWM.


Perhaps this little gotcha should be mentioned on the TWM BLFS page:

http://www.linuxfromscratch.org/blfs/view/svn/x/twm.html


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

  rhubarbpieguy,

For a 0.67 poppler release after the cmake command has been run (I don't
think it matters if the make step was later run and whether or not the
build was actually successful, but you have to do the

cmake  -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr 
-DTESTDATADIR=$PWD/testfiles -DENABLE_XPDF_HEADERS=ON ..

step) take a look at the resulting build/CMakeCache.txt file.

Do you see any //usr directories mentioned in there? Can you post your
CMakeCache.txt for us to look at, or email it to me, if you wish.

Another thing to try (as above, do this after cmake was run, but you
don't have to do the make step), after changing to the build dir
(cd build), do a:

find . -type f -print|sort|xargs grep //usr

to search for all instances of //usr in files within the build directory.


  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

On Mon, 15 Oct 2018 21:31:36 -0500
rhubarbpieguy via blfs-support  wrote:

> -I//usr/include

Again that is there. Where is this strange path coming from?

> find /etc -type f -print|sort|xargs grep /usr/include reports:
> /etc/udev/hwdb.d/60-keyboard.hwdb:# is the bus-id (see 
> /usr/include/linux/input.h BUS_*), ,  and
> /etc/udev/hwdb.d/70-pointingstick.hwdb:# is the bus-id (see 
> /usr/include/linux/input.h BUS_*), ,  and

This looks OK to me. All of your files in /etc are free of /usr/include .

Here's a working theory - in your BLFS build scripts, could there be a
mistake whereby --prefix=/usr is incorrectly set to --prefix=//usr
possibly with regard to the GTK3 package. Something like /$PREFIX in
a script (where $PREFIX=/usr) could do it.

You can scan all your /usr pkgconfig files for any mention of //usr via:

find /usr/lib/pkgconfig -type f -name "*.pc" -print|sort|xargs grep //usr

Can you see/find anything like that?


  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

On Mon, 15 Oct 2018 14:40:12 -0500
rhubarbpieguy via blfs-support  wrote:

> Poppler 0.67 compiles without error using 
> poppler_fix_cmake_gtk3_include_dir.patch.

:)

Good! OK, there is a problem in the poppler build system. However, there
is *also* something unusual with your system - well, at least, your
system does differ somehow from Bruce's (and presumably from Ken's). It
is not a gcc system problem, but rather something else, some environment
variable that is being set, etc.

FWIW, poppler uses the cmake build system, not autotools/automake.
cmake takes the place of ./configure, setting options and
detecting/locating packages, etc. After cmake sets things up, make can
then be run to start the build.

Now, when the poppler developers made the 0.63 change, in 
test/CMakeLists.txt they changed

if (GTK_FOUND)
   add_definitions(${GTK3_CFLAGS})

to this:

if (GTK_FOUND)
 include_directories(
 SYSTEM
 ${GTK3_INCLUDE_DIRS})

where SYSTEM specifies an -isystem option (rather than the default -I)
to gcc. The problem is that GTK3_INCLUDE_DIRS is never initialized to
anything by the poppler cmake GTK detection/setup module! They forgot
to define it before they used it.

cmake/modules/FindGTK.cmake has:

pkg_check_modules(GTK3 "gtk+-3.0>=3.8" "gdk-pixbuf-2.0")

  find_package_handle_standard_args(GTK DEFAULT_MSG GTK3_LIBRARIES GTK3_CFLAGS)

where find_package_handle_standard_args initializes/defines the listed
variables for the given package (the package name is the first in the list).
Note that GTK3_INCLUDE_DIRS is not listed, but the old 0.62 GTK3_CFLAGS
still is!

My poppler_fix_cmake_gtk3_include_dir.patch changes that to:

find_package_handle_standard_args(GTK DEFAULT_MSG GTK3_LIBRARIES 
GTK3_INCLUDE_DIRS GTK3_CFLAGS)

after which it builds just fine on rhubarbpieguy's system.

Now, note that even under the old 0.62 build system, which does work
on rhubarbpieguy's system, (using the two
patches with 0.67 - poppler_revert_gtk3_include_dirs.patch and 
poppler_gtk-test_force_build_fail.patch the latter of which is just to
halt the build at the right place) there is still an anomaly in the
calling of gcc on rhubarbpieguy's system:

> -I//usr/include 

Even though that anomaly alone does not cause a build failure, it is
not right. With the 0.63 and later build system and without fixing
the undefined GTK3_INCLUDE_DIRS, this anomaly becomes:

-isystem //usr/include

which does error out with gcc 8.x - it takes *two* wrongs here for a
build failure to result.

Note that Bruce's system does not have any mention of any include
for /usr/include, let alone //usr/include.

I think the reason that the build does not fail on Bruce's system
even though poppler fails to define GTK3_INCLUDE_DIRS is that the
build system declares the GTK3 includes more than once - and the
first one alone still allows it to build even though the second
declaration, from FindGTK.cmake, is incomplete.

In summary, I think there are two problems: a mistake in poppler's
GTK cmake code and something wrong/different with rhubarbpieguy's
system. It is not a gcc problem, but rather it has to do with how
gcc is being called.

I will look more into how poppler cmake sets up its gcc calls and
try to see how a -I//usr/include could come about.

In the meantime, Bruce and rhubarbpieguy, what version of cmake are
each of you running?

cmake --version


rhubarbpieguy, can you try a 0.67 build with the two patches:

patch -p1 -i ../poppler_fix_cmake_gtk3_include_dir.patch
patch -p1 -i ../poppler_gtk-test_force_build_fail.patch

mkdir build
cdbuild
cmake  -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr 
-DTESTDATADIR=$PWD/testfiles -DENABLE_XPDF_HEADERS=ON ..
 
make VERBOSE=1

and show me the c++ line that fails? This way, I can see how gcc is
being called on your system after the poppler GTK cmake code bug is
fixed.

Also, please verify for me again that none of the include variables
are being set:

echo $CPLUS_INCLUDE_PATH
echo $C_INCLUDE_PATH
echo $CPATH
echo $GTK3_INCLUDE_DIRS
echo $GTK3_INCLUDE_DIR

rhubarbpieguy, do your recall doing/setting anything else with regard to
/usr/include in your /etc/profile, bashrc, anything in /etc/profile.d
including xorg.sh, or your .bashrc, .bash_profile, etc. ?

You can scan your entire /etc for all mentions of /usr/include by
running

find /etc -type f -print|sort|xargs grep /usr/include

as root. What does it show?


  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

On Mon, 15 Oct 2018 00:31:15 -0500
Bruce Dubbs via blfs-support  wrote:

> Yes.


  Bruce,

OK, could run the following build test on poppler 0.67 applying the
attached poppler_gtk-test_force_build_fail.patch (and no other patches):


patch -p1 -i ../poppler_gtk-test_force_build_fail.patch

mkdir build
cdbuild
cmake  -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr 
-DTESTDATADIR=$PWD/testfiles -DENABLE_XPDF_HEADERS=ON ..
 
make VERBOSE=1


The build should fail at gtk-test.cc. Show us the c++ command line 
for gtk-test.cc. Then we can compare how your c++ is being invoked to
build gtk-test.cc to that of rhubarbpieguy.

If the build does *not* fail, can you explain why there is no build
attempt for test/gtk-test.cc on your system (e.g., GTK3 not detected,
etc.)?


  Cheers,

  Mike


poppler_gtk-test_force_build_fail.patch
Description: Binary data
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

On Sun, 14 Oct 2018 21:23:06 -0500
rhubarbpieguy via blfs-support  wrote:

> OK, it's not that big a deal to redo LFS 8.3.  I've nuked all my log 
> files but don't remember a problem with the output of "Adjusting the 
> Toolchain."  Regardless, I'll go again and save that output.  I'll 
> repost either way to this topic with the outcome.


Wait on that. At this point, I do not think it is a problem with your
system. You have already indicated that your system has all the include
files Bruce asked about. 

I believe I see a mistake in the poppler source code. Try my latest poppler
patch tests first and then we'll go from that.


Bruce, Ken: have you tried compiling poppler 0.63 or later on a system with:

  1. GTK3 v3.8 or later
 
  2. gcc 8.2

Did you build poppler *before* GTK3 is installed, or are you using a gcc prior
to 8.2?


  Cheers,

  Mike






-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

On Sun, 14 Oct 2018 14:28:01 -0500
rhubarbpieguy via blfs-support  wrote:

> [ 89%] Building CXX object test/CMakeFiles/gtk-test.dir/gtk-test.cc.o
> ..
> /usr/include/glib-2.0 -isystem /usr/lib/glib-2.0/include -isystem 
> //usr/include  -Wall -Wextra -Wpedantic -Wno-unused-parameter 
> ..


Good! Note the strange/suspicious include construct: 

-isystem //usr/include


Now, for the next test, try the following two attached patches on poppler
0.67 (should work on any version 0.63 or later) without using any other
patches (starting with a fresh poppler 0.67 unpack):

patch -p1 -i ../poppler_revert_gtk3_include_dirs.patch
patch -p1 -i ../poppler_gtk-test_force_build_fail.patch

mkdir build
cdbuild
cmake  -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr 
-DTESTDATADIR=$PWD/testfiles -DENABLE_XPDF_HEADERS=ON ..
 
make VERBOSE=1


The build will fail, but in a different way (as is intended so you can
easily locate the same c++ command line). Show us the c++ command line
that failed (but it would have worked had it not been for 
poppler_gtk-test_force_build_fail.patch) so we can compare it to the
previous failure.


Then, test the new attached poppler_fix_cmake_gtk3_include_dir.patch on
poppler 0.67 (should work on any version 0.63 or later) *without* using
any other patches (starting with a fresh poppler 0.67 unpack):

patch -p1 -i ../poppler_fix_cmake_gtk3_include_dir.patch

mkdir build
cdbuild
cmake  -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr 
-DTESTDATADIR=$PWD/testfiles -DENABLE_XPDF_HEADERS=ON ..
 
make VERBOSE=1


And let us know if it compiles OK and, if not, show us the c++ command
line that failed.


   Mike




poppler_fix_cmake_gtk3_include_dir.patch
Description: Binary data


poppler_gtk-test_force_build_fail.patch
Description: Binary data


poppler_revert_gtk3_include_dirs.patch
Description: Binary data
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

On Fri, 12 Oct 2018 14:33:35 +0200
Pierre Labastie via blfs-support  
wrote:

> Because the piece of code (lines 18 to 23 intest/CMakeLists.txt) which 
> generates the error seems to not have been changed in 0.69? But, maybe it
> is upstream job to try to debug this...


Yeah, the problematic code is the same from 0.63 to 0.69. However, IMHO,
we don't yet have enough info to file a report upstream. Once I see how
g++ is being called differently between 0.62 and 0.63 then I can get a
better idea of what exactly is going wrong - mostly likely a duplication
in the include paths.

I then plan to report this issue upstream. The main unresolved problem is
that I still don't see what is different about rhubarbpieguy's system - why
does he run into this problem while no one else seems to? The mostly likely
candidiate here was the setting of $CPLUS_INCLUDE_PATH, but it seems that
is not the case.


  Mike




-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

On Thu, 11 Oct 2018 17:58:44 -0500
rhubarbpieguy via blfs-support  wrote:

> I see two batches of Error 2 errors.  I hope this is what you want:

We want to see not just the error message, but the actual g++ command
line that caused the error.

When you build via:

make VERBOSE=1

you should be able to see all the gcc/g++ commands as they are being
executed, long lines like:

/usr/bin/c++  -DUSE_OPENJPEG2 -Dpoppler_EXPORTS -I

Do you see all that? The one that tries to compile gtk-test.cc
just before the error message is the one we are interested in.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

On Wed, 10 Oct 2018 16:47:49 -0500
rhubarbpieguy via blfs-support  wrote:

> I applied the patch to poppler-0.63.0 and poppler-0.67.0.  
> Both compiled successfully.

The changeset between 0.63 and 0.64 is tens of thousands of lines long.
Tis much like finding a needle in haystack on the first try. Yay!

However, we still don't know exactly what is going wrong and why others
haven't encountered this problem.

However, given that the offending change was made/suggested by a clang
script, I think it is likely that it is a bug (in poppler 0.63-on).

First of all, GTK3 must be installed for gtk-test.cc to be built.
So, the problem won't occur on systems without GTK3.

Now, on your gcc 8.2.0 system (the newer one where the build fails),
do a fresh unpack of poppler 0.63. Do not apply any patches to it.

Verify that your gcc/g++ path variables are indeed not set to
anything:

echo $CPLUS_INCLUDE_PATH
echo $C_INCLUDE_PATH

They are both unset/blank, right?

Now, attempt to build poppler 0.63, but invoke the verbose
option with make to see the actual gcc/g++ command that fails:

mkdir build
cdbuild
cmake  -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr 
-DTESTDATADIR=$PWD/testfiles -DENABLE_XPDF_HEADERS=ON ..
 
make VERBOSE=1


Could you paste the gcc/g++ commands just before and after the
build failure occurred so we can see what command line options
gcc/g++ was invoked with when attempting to build gtk-test.cc?


   Cheers,

   Mike


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

On Tue, 9 Oct 2018 18:32:08 -0500
rhubarbpieguy via blfs-support  wrote:

> I've never set $CPLUS_INCLUDE_PATH and/or $C_INCLUDE_PATH as I compile
> X in /usr. My original (and current) problem is Poppler-0.67.0 won't
> compile and those variables are not set. I only set them as I thought
> you wanted that as a test.

Well, I asked you if you had set the variables, and so what did you
mean by this reply?:

> Yes, I changed /etc/profile.d/xorg.sh according to Introduction to 
> Xorg-7.

Anyway, in all that follows, I'm assuming the $CPLUS_INCLUDE_PATH and/or
$C_INCLUDE_PATH variables are *not* set.

> Poppler-0.62.0 compiles successfully on my BLFS 8.3 build but any 
> version above that fails.

OK, good, so we now know the problem starts with 0.63.0

I looked through the changes from 0.62.0 to 0.63.0. The most likely
suspect is an automated script (clang-tidy) change made to the file
test/CMakeLists.txt. It is the only change I can see that affects
the include files. This change was made to please clang, not gcc:

https://github.com/freedesktop/poppler/commits/master/test/CMakeLists.txt
https://github.com/freedesktop/poppler/commit/e428033c2d7efbbbf89bb2f84c8998521ac7ef8e#diff-15547c54d3d4898a882b4ab7b3cee381

The attached patch reverts what I think is your trouble maker. Apply
it to 0.63.0 and later (it should work with 0.69.0 as well) using:

patch -p1 -i ../poppler_revert_gtk3_include_dirs.patch

And let us know if you can build 0.63.0 and later after applying
the patch.


  Cheers,

  Mike


poppler_revert_gtk3_include_dirs.patch
Description: Binary data
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

On Sun, 7 Oct 2018 07:28:34 -0500
rhubarbpieguy via blfs-support  wrote:

> Yes, I changed /etc/profile.d/xorg.sh according to Introduction to 
> Xorg-7.  So without that change I see the following:

OK, the include search paths look OK to me for both your g++/gcc 8.2.0 and
7.3.0 systems - that is for the example you gave *without*
$CPLUS_INCLUDE_PATH and/or $C_INCLUDE_PATH being set.

Can you compile Poppler-0.67.0 on your gcc 8.2.0 system *if*
$CPLUS_INCLUDE_PATH and/or $C_INCLUDE_PATH are *not* set (don't have
any pathappend lines in /etc/profile.d/xorg.sh, unset/clear
C_INCLUDE_PATH CPLUS_INCLUDE_PATH, and restart x) and thus your gcc's search
paths are as you stated (quoted at the end of this post)?

If yes, then I sure don't think you should be setting $CPLUS_INCLUDE_PATH
et al. Note that in the Xorg-7 instructions:

http://www.linuxfromscratch.org/blfs/view/svn/x/xorg7.html

it is stated:

"Note: If you've decided to use the standard /usr prefix, you can omit
 the remainder of this page and continue at util-macros-1.19.2. 
 If you've decided to not use the standard prefix, be sure to add
 $XORG_PREFIX/bin to your PATH environment variable, and
 $XORG_PREFIX/lib/pkgconfig and $XORG_PREFIX/share/pkgconfig to
 your PKG_CONFIG_PATH variable. It is also helpful to specify
 additional search paths for gcc and an include directory for the
 aclocal program. Issue the following commands as the root user:
"

that is ONLY if the standard prefix /usr is *not* being used.

But, you had:

> echo $CPLUS_INCLUDE_PATH - /usr/include
> echo $C_INCLUDE_PATH - /usr/include

You should not be setting $CPLUS_INCLUDE_PATH, $C_INCLUDE_PATH
is the include paths gcc/g++ is using already "includes the includes
of Xorg", which is the case for /usr/include.


If you still can't compile poppler-0.67.0 with your gcc 8.2.0 system
being sure $CPLUS_INCLUDE_PATH and $C_INCLUDE_PATH are not set, then
you will have to begin with poppler-0.62 and advance the version number
until the build fails. My guess is the trouble starts with version 0.65.


   Cheers,

   Mike


For reference, the gcc search paths that look OK to me are as you gave
here:

> -
> `gcc -print-prog-name=cc1plus` -v
> 
> ignoring nonexistent directory 
> "/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
> #include "..." search starts here:
> #include <...> search starts here:
>   /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0
>   
> /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/x86_64-pc-linux-gnu
>   
> /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/backward
>   /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
>   /usr/local/include
>   /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
>   /usr/include
> 
> -
> `gcc -print-prog-name=cc1` -v
> 
> ignoring nonexistent directory 
> "/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
> #include "..." search starts here:
> #include <...> search starts here:
>   /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
>   /usr/local/include
>   /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
>   /usr/include
> -


So, IMHO, that is what you want to have and what matches most everyone
else's systems.

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

On Sat, 6 Oct 2018 08:52:26 -0500
rhubarbpieguy via blfs-support  wrote:

> It appears setting the new variables didn't fix the problem.  I hope 
> I've followed your and Ken's guidance correctly. Again, I should mention 
> Poppler was the only problem package and the older version works well, 
> but it would be nice to know what I've done wrong.  So ...
> 
> echo $CPLUS_INCLUDE_PATH - /usr/include
> echo $C_INCLUDE_PATH - /usr/include
> echo $CPATH - nothing returned


Wait, we have to do one thing at a time. Did you set the above
$CPLUS_INCLUDE_PATH and $C_INCLUDE_PATH? If so, don't do that yet -
we need to see the gcc paths without these variables being set.
If you didn't set them, do you have any idea where and why they
are being set?

> `gcc -print-prog-name-cc1plus` -v

I think you meant

`gcc -print-prog-name=cc1plus` -v

OK, so, do a:

unset CPLUS_INCLUDE_PATH
unset C_INCLUDE_PATH
unset CPATH
`gcc -print-prog-name=cc1plus` -v
`gcc -print-prog-name=cc1` -v

and show us the result.

Now, what Alex did to overcome his problem was this:

export CPLUS_INCLUDE_PATH=/usr/include/c++/8.2.0:/usr/include

So, it wasn't just /usr/include

If you use Alex's longer CPLUS_INCLUDE_PATH definition, can you build
poppler 0.69?

Without any CPLUS_INCLUDE_PATH etc. variables set, can you build poppler
0.62 on the gcc 8.2.0 system?

If so, but poppler 0.69 fails, can you narrow it down to which release
first shows the problem?

https://poppler.freedesktop.org/releases.html

You don't have to try to build these different releases right now, at least
not until after the questions above are answered. But, I notice that for
the 0.65 release changes there is the item:

  "Fix compilation with libc++"

which might actually mean "break the libc++ build on rhubarbpieguy's system"
LOL!


> find /usr -name "stdlib.h"
> 
> /usr/include/bits/stdlib.h
> /usr/include/c++/8.2.0/stdlib.h
> /usr/include/c++/8.2.0/tr1/stdlib.h
> /usr/include/stdlib.h

All this looks OK to me.



  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

On Thu, 4 Oct 2018 18:33:07 -0500
rhubarbpieguy via blfs-support  wrote:

> What have I missed?  Is there another area where I'm to set 
> CPLUS_INCLUDE_PATH?

See my recent reply to Alex who has a similar problem in the BLFS thread
"Compilation failures - missing header files".

On your system, run these commands:

unset CPLUS_INCLUDE_PATH
`gcc -print-prog-name=cc1plus` -v

to show the g++ include paths irrespective of what CPLUS_INCLUDE_PATH
was set to. Be sure to use the correct type of quotes in the above
command. Both of the quotes are ` which is on the same key as the tilde ~
on most keyboards. And it seems one has to press ctl-C to get back to
the command prompt after "End of search list." is displayed.

Show us what your gcc spits out from the above and then we all can
compare notes.


  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Compilation failures - missing header files

[Michael Shell via blfs-support]

On Wed, 3 Oct 2018 23:50:15 -0600
Alex B  wrote:

> "export CPLUS_INCLUDE_PATH=/usr/include/c++/8.2.0:/usr/include" did the
> trick.
> ..
> I still don't see why there is a need to set that variable, when it is 
> not being set by jhalfs and can't find any reference to it under /etc 
> either. The packages should have compiled successfully without the need 
> for it.


  Alex,

I agree with you and Paul here:

On Thu, 04 Oct 2018 16:01:16 -0700
Paul Rogers via blfs-support  wrote:

> It really does suggest there are further problems in your system. 


I found something else that we can compare notes to.
Do a:

unset CPLUS_INCLUDE_PATH
`gcc -print-prog-name=cc1plus` -v

to show the g++ include paths irrespective of what CPLUS_INCLUDE_PATH
was set to. Be sure to use the correct type of quotes in the above
command. Both of the quotes are ` which is on the same key as the tilde ~
on most keyboards. And it seems one has to press ctl-C to get back to
the command prompt after "End of search list." is displayed.

I found this tip at:
https://askubuntu.com/questions/573417/where-are-header-files-for-gcc-located

So, this information from your gcc setup can then be compared to that
of others with recent BLFS systems and then we can see if something
is indeed different.


  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Compilation failures - missing header files

[Michael Shell via blfs-support]

I also found this:

https://www.linuxquestions.org/questions/slackware-14/on-current-qt-include-directory-appears-2x-4175636463/

(referenced by https://trac.wildfiregames.com/ticket/5157)

Check what the environment variable CPLUS_INCLUDE_PATH is being
set to and where it is being set:

echo $CPLUS_INCLUDE_PATH
grep -s CPLUS_INCLUDE_PATH /etc/*

Problems can occur here if a path is duplicated within $CPLUS_INCLUDE_PATH


 Cheers,

 Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

It seems another BLFS user has encountered this issue (but with
applications other than poppler):

http://lists.linuxfromscratch.org/pipermail/blfs-support/2018-October/080407.html

I also found this:

https://www.linuxquestions.org/questions/slackware-14/on-current-qt-include-directory-appears-2x-4175636463/

Check what the environment variable CPLUS_INCLUDE_PATH is being
set to and where it is being set:

echo $CPLUS_INCLUDE_PATH
grep -s CPLUS_INCLUDE_PATH /etc/*

Problems can occur here if a path is duplicated within $CPLUS_INCLUDE_PATH


 Cheers,

 Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Compilation failures - missing header files

[Michael Shell via blfs-support]

On Wed, 3 Oct 2018 12:18:19 -0600
Alex via blfs-support  wrote:

> /usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such 
> file or directory
> .
> .
> Has anyone encountered this or something similar?


Yes, rhubarbpieguy has:

http://lists.linuxfromscratch.org/pipermail/blfs-support/2018-October/080398.html

If rebuilding gcc per Oleh's suggestion works, do let us know.
I'll also post to rhubarbpieguy's thread to link to this one.


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Poppler-0.67.0 gtk-test.dir/all Error 2 - BLFS 8.3

[Michael Shell via blfs-support]

On Mon, 1 Oct 2018 19:18:40 -0500
rhubarbpieguy via blfs-support  wrote:

> > /usr/include/c++/8.2.0/cstdlib:75:15: fatal error: stdlib.h: No such 
> > file or directory
> >  #include_next 
> >    ^~


Perhaps the first link below is the most helpful:

https://github.com/Martchus/tageditor/issues/22
https://github.com/OxfordSKA/OSKAR/issues/10
https://stackoverflow.com/questions/45245923/mingw-include-c-cstdlib-stdlib-h-no-such-file-or-directory
https://bugreports.qt.io/browse/QTBUG-53367

It seems gcc was changed in way that the use of -isystem now alters
the include directory search order which breaks some packages.

One suggested solution seems to be to simply remove the use of the gcc -isystem
option (perphaps in a cmake/XX.cmake file). Another suggestion is
to change the order of the c++ search path:

export 
CPLUS_INCLUDE_PATH=/usr/local/include/c++/8.2.0:/usr/local/include:/usr/include:$CPLUS_INCLUDE_PATH

Yet another solution suggests changing the
#include_next
to
#include

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936

However, I don't see any reference to -isystem in the poppler-0.69.0
source tree:

find . -type f -print|sort|xargs grep isystem

Nor did I find a reference to CPLUS_INCLUDE_PATH.

I did find a reference to CMAKE_SYSTEM_INCLUDE_PATH in
cmake/modules/PopplerMacros.cmake

You have to do a:

make VERBOSE=1

to get the actual gcc command that fails, then we can see how gcc
was called. You can then try modifying things (either in the source
tree or in that command line) until you get past the problem.

If you get it to work, I would report the problem to the poppler folks.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] lightdm: Failed to get list of logind seats

[Michael Shell via blfs-support]

On Mon, 1 Oct 2018 21:24:52 +0200 (CEST)
Ben Bellemans via blfs-support  wrote:

> Both "/etc/rc.d/init.d/lightdm start" and "init 5" don't start the greeter
> and procuce this warning: "WARNING: Failed to get list of logind seats:
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
> org.freedesktop.login1 was not provided by any .service files"


  Google found these:

https://forums.gentoo.org/viewtopic-t-1055748-start-0.html
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215669
https://classicforum.manjaro.org/index.php?topic=28459.0
https://bbs.archlinux.org/viewtopic.php?id=186550

However, you need to post the debug info from the logs that comes
after the above warning, which by itself, may or may not be part
of the "failure mode" you see (e.g., the warning may not be a
key part of the final error.)

See the gentoo link for how to check/fix your
/etc/lightdm/lightdm.conf file.

According to

https://wiki.archlinux.org/index.php/LightDM

 "You will probably want to install a greeter. A greeter is a GUI that
  prompts the user for credentials, lets the user select a session, and
  so on. It is possible to use LightDM without a greeter, but only if
  an automatic login is configured, otherwise you will need to install
  xorg-server and one of the greeter packages below.
 "


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] I hate rustc!

[Michael Shell via blfs-support]

On Sun, 23 Sep 2018 01:15:23 +0100
Ken Moffat via blfs-support  wrote:

> The other worrying thing about building rust is the way that it
> builds multiple versions of some of the crates (presumably as
> dependencies for different other crates), with all the versions set
> in stone.  I fear that it is going to keep growing.


  Ken,

Is there any chance on the horizon that we will be able to find
a way, or the rustc developers will in the future provide a way,
for us to be able to build this thing without a net connection,
or if we just don't want the build process to "phone home" and
start downloading things. I hate stuff like that.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] I hate rustc!

[Michael Shell via blfs-support]

On Sat, 22 Sep 2018 22:53:39 +0100
Ken Moffat via blfs-support  wrote:

>  export LIBSSH2_SYS_USE_PKG_CONFIG=1
> 
> just before the DESTDIR install.


Thanks Ken! I'm sure this is going to help more than a few folks out
there. If rustc is going to be used for production, the rust developers
better get their act together, IMHO.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Revert Berkeley DB to v5

[Michael Shell]

I don't have a strong opinion on it one way or another, but my vote is to
retain the latest version. Oracle is using a GPL license (AGPL) so
redistribution (i.e. a lack of distribution sites) should not be an issue.
The LWN article expressing concern about the AGPL was written in 2013.

Given the way things work with the FSF, many other projects will eventually
be affected by the AGPL issue anyway. (If the FSF wants all source
code/modifications to be publicly available for all GPL/free software that
has been modified and that provides, or is linked to that which provides,
public web services, then it will evolve the GPL as needed to achieve that
goal world wide.) 

Furthermore, recent versions of packages tend to have fewer problems with
recent compilers.

If there were to arise a significant fork or alternative with regard to the
Berkeley DB, or we could not download it from any site without registering
with Oracle, or if we knew that db-18.1.25 or later broke a significant
number things, then I could see some solid grounds for reverting to an
older version or even to an alternate db.

In short, I think that keeping with the most recent version of packages is
the way to go to *reduce* maintenence and patch issues (by avoiding the
"code rot" problem) over the long term.


  Just my $0.02,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] BLFS systemd 239?

[Michael Shell]

On Tue, 31 Jul 2018 15:36:45 -0500
Bruce Dubbs  wrote:

> In systemd's src/basic/missing.h is:
> 
> #ifndef SCM_SECURITY
> #define SCM_SECURITY 0x03
> #endif
> 
> Shouldn't that take care of it?  missing.h is included in 
> src/journal/journald-server.c.


  Bruce,

Yep, good catch. Searching more, I can confirm (with Ken) that neither the
sanitized kernel headers, nor glibc (at least version 2.27) provide
SCM_SECURITY. So, it has to come internal to the systemd source tree.

In the systemd source tree for v239:

grep -r SCM_SECURITY *

yields:

src/journal/journald-server.c:   cmsg->cmsg_type == SCM_SECURITY) {
src/basic/missing.h:#ifndef SCM_SECURITY
src/basic/missing.h:#define SCM_SECURITY 0x03

in missing.h, SCM_SECURITY is defined around line 547.

And indeed journald-server.c loads missing.h around line
45:

#include "missing.h"


spiky, what does 
grep -r SCM_SECURITY *
show on your systemd source tree? Does your src/journal/journald-server.c
include missing.h ?

You could manually set

#define SCM_SECURITY 0x03

in journald-server.c to get around this problem (and likely hit right
upon another), but you should look into why missing.h is not doing the
def for you. Your systemd source tree might have gotten corrupted
somehow.


  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] BLFS systemd 239?

[Michael Shell]

On Mon, 30 Jul 2018 20:05:54 +0100
spiky  wrote:

> ../src/journal/journald-server.c:1134:45: error: 'SCM_SECURITY' 
> undeclared (first use in this function); did you mean 'PF_SECURITY'?
>    cmsg->cmsg_type == SCM_SECURITY) {
>   ^~~~


SCM_SECURITY is defined in the Linux kernel headers in
/include/linux/socket.h

https://elixir.bootlin.com/linux/latest/source/include/linux/socket.h#L152


/* "Socket"-level control message types: */

#define SCM_RIGHTS  0x01/* rw: access rights (array of int) */
#define SCM_CREDENTIALS 0x02/* rw: struct ucred */
#define SCM_SECURITY0x03/* rw: security label   */


However, given that we are supposed to use "sanitized" kernel headers,
it is glibc's job to export these values. I believe this is done in
/usr/include/bits/socket.h

What version of glibc are you using? Perhaps older versions don't define
SCM_SECURITY?

Can someone with a recent glibc system verify that SCM_SECURITY is indeed
defined in /usr/include/bits/socket.h ?

FWIW, all the header include files that have references to SCM_SECURITY
can be found using:

cd /usr/include
find . -type f -name "*.h" -print|sort|xargs grep SCM_SECURITY


You can either add the SCM_ defs to your /usr/include/bits/socket.h or add
them to your systemd's journald-server.c


  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Reducing my contributions

[Michael Shell]

On Mon, 25 Jun 2018 02:53:59 +0100
Ken Moffat  wrote:

> I find it hard to believe that I can ever happily run anything
> except LFS (sysv), but I need to step further back.


  Ken,

Well, thanks so much for all your help. I've said it before, but I
believe that LFS/BLFS really is an important public service to the
world, and if it were possible, I think it would be fair for all
the people who contributed to the LFS/BLFS project would get some
type of (substantial) payment.

As far as Firefox goes, I sure hope someone either comes out with
a better/simplier/saner browser or that the existing alternative
browser project reach a point where they can replace it (well,
that does depend on the needs of each specific user).

Sometimes I've encountered bugs/changes in firefox in which I
suspect the developers are playing little jokes on us. Sure
seems that way sometimes.


  Cheers and take care,

  Mike

  
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Speculative Store Bypass

[Michael Shell]

FWIW, when searching for more info on the SSB vulnerability, I found this:

https://www.tomshardware.com/news/researchers-discover-speculative-store-bypass-attack,37092.html


Tis some really bad news:

 "But the hope remained that the manufacturers could solve the problem with
  a few security updates. As it turns out, we can bury that hope. A total
  of eight new security flaws in Intel CPUs have already been reported to
  the manufacturer by several teams of researchers. For now, details on the
  flaws are being kept secret. All eight are essentially caused by the same
  design problem - you could say that they are Spectre Next Generation.
  ..
  One of the Spectre-NG flaws simplifies attacks across system boundaries
  to such an extent that we estimate the threat potential to be significantly
  higher than with Spectre. Specifically, an attacker could launch exploit
  code in a virtual machine (VM) and attack the host system from there - the
  server of a cloud hoster, for example. 
  ..
  Overall, the Spectre-NG gaps show that Spectre and Meltdown were not a
  one-off slip-up. It is not just a simple gap that could be plugged with a
  few patches. Rather, it seems that for each fixed issue, two others crop
  up. "



  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] BLFS 8.2-systemd, modules/firmware for Broadcom BCM4322 wireless network card

[Michael Shell]

On Tue, 20 Mar 2018 20:46:31 + (GMT)
Hans Malissa  wrote:


> and then the build stops. I tried to read up on that error message, and it
> seems like it's related to the kernel version - the driver was prepared
> for an earlier version of linux 
> (https://github.com/NixOS/nixpkgs/issues/27607 ). But I can't seem to
> find any specific information about how to fix this.


  Hans,

At the URL you gave, it is stated that they fixed the problem:
"Probably requires some backports from master like daf6744 and c71233f"
followed later by
"Fixed by backporting those two commits and testing build."

Those fixes are in patches here:

https://github.com/NixOS/nixpkgs/tree/c71233f12cb976b259e88ee4300687df26e5377d/pkgs/os-specific/linux/broadcom-sta

Click on a patch, then select raw and copy and paste the text.
They apply all the patches in this order:

i686-build-failure.patch
license.patch
linux-4.7.patch
linux-4.8.patch
linux-4.11.patch
linux-4.12.patch
null-pointer-fix.patch
gcc.patch

You may, or may not, want the license patch - with it you will likely see
something like "wl: module license 'MIXED/Proprietary' taints kernel"
in the kernel logs.

Do let us know if the patches do the trick.


  Cheers,

  Mike Shell


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] https://docs.python.org/3.6/archives/python-3.6.2-docs-html.tar.bz2

[Michael Shell]

On Mon, 12 Feb 2018 16:13:03 -0500
Baho Utot  wrote:

> well I guess I am about to find out I am going with python 3 only so 
> I will see how far I get with that.


Do let us know how it goes. Python 3 comes with a script, 2to3, that can
convert Python 2 code to that of version 3:

https://docs.python.org/2/library/2to3.html

If it is just a case of fixing static python code, then this should
be all that is needed. However, it can't address those cases where
a python script is *dynamically* generated by/within another
application.


  Cheers,

  Mike Shell


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] libxshmfence 1.2 Xorg Libaries

[Michael Shell]

On Wed, 7 Feb 2018 15:38:04 +
spiky  wrote:

> I have not added a CFLAGS this is from the install script
>./configure $XORG_CONFIG CFLAGS='$CFLAGS -D_GNU_SOURCE'


That's wrong. The '' will prevent all shell variable expansion.
Thus, $CFLAGS will be preserved as-is, a string, rather than
treated as a variable name.

For example:

CFLAGS=one
CFLAGS='$CFLAGS two'
echo $CFLAGS

yields:

$CFLAGS two

I think the '' should be "" :
 
CFLAGS=one
CFLAGS="$CFLAGS two"
echo $CFLAGS

yields:

one two



  Cheers,

  Mike Shell


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Portability problems ?

[Michael Shell]

On Thu, 1 Feb 2018 23:03:00 +0100
Edgar Alwers  wrote:

> 1.) xfce4-terminal did not work anymore ( input/output error ), making  
> any compilations in tty terminals impossible. I have only xfce and 
> therefore no kde-terminals.


  Edgar,

You should always have another terminal application available in
case your normal one ever goes down, preferably one with few
dependencies. I recommend rxvt:

http://www.linuxfromscratch.org/blfs/view/svn/xsoft/rxvt-unicode.html


  Cheers,

  Mike


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] MP4 video playback not working in Firefox 57

[Michael Shell]

On Sat, 18 Nov 2017 11:13:04 +0100
Vaclav Masin  wrote:

> both FF56 and FF57 (I can switch back and forth easily having both
> installed in a versioned dir in /opt)


  Vaclav,

I do it that way too. Just a side note, and one that might not be even
applicable to such recent and close version numbers:

Be sure and make a backup of your .mozilla config directory before
switching FF versions - in the past I've had a new version of FF
"trash" my settings, bookmarks, etc. in .mozilla/firefox/*.default
such that I could no longer switch back to the previous version
without going through the tedious process of exporting bookmarks,
manually reentering settings, etc.


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Fluxbox-1.3.7: fbsetroot fails

[Michael Shell]

On Tue, 14 Nov 2017 10:28:10 -0800
Paul Rogers  wrote:


> I've searched fluxbox.org.  It seems like a duplicate of Bug #1093, for
> which there was a patch.  Tried it, no joy.  There's a prerelease
> version 1.4.0.  Tried it, no joy.


  Paul,

As I understand it, the original problem was triggered by color depths
of 32bits. It might be helpful to the fluxbox developers to know if
your problem still happens at, say, 16 or 24bit color depths.

FWIW, there was/is a similar problem with nedit back in 2006:

http://lists.golug.org/pipermail/tech/2006-December/004668.html

Does this workaround:

XLIB_SKIP_ARGB_VISUALS=1 fbsetroot -solid black

allow fbsetroot to work?



  Cheers,

  Mike


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] TypeError: %d format: a number is required, not float when building Firefox 52.4.1esr

[Michael Shell]

On Tue, 31 Oct 2017 16:18:12 +
Ken Moffat  wrote:

> From: Gunner Hooper 
> To: Ken Moffat 
> Subject: Re: [blfs-support] TypeError: %d format: a number is required, not 
> float when building
>   Firefox 52.4.1esr
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 
> Thunderbird/52.4.0
> X-Clacks-Overhead: GNU Terry Pratchett
> 
> I got this error after building Firefox 51.0.1:
>.
>.
> make[3]: *** [/root/sources/firefox-51.0.1/config/recurse.mk:33: compile]
> Error 2


Isn't there supposed to be a more specific error that happened prior to
to this one?

> When I build Firefox 52.4.1 with all of the updated Python files in
> toolkit/components/telemetry, I get this error:
> 
> /root/sources/firefox-52.4.1esr/toolkit/components/telemetry/moz.build
> 
> The error was triggered on line 105 of this file:
> 
>     PYTHON_UNITTEST_MANIFESTS += [
> 
> The underlying problem is an attempt to read a reserved UPPERCASE variable
> that does not exist.


Yeah, it isn't looking good. That said, the variable is defined in

python/mozbuild/mozbuild/frontend/context.py

http://webcache.googleusercontent.com/search?q=cache:zbmnx_GkZbMJ:https://dxr.mozilla.org/mozilla-central/rev/74566d5345f4cab06c5683d4b620124104801e65/python/mozbuild/mozbuild/frontend/context.py%2B%22A11Y_MANIFESTS%22+%22FIREFOX_UI_FUNCTIONAL_MANIFESTS%22=en=1=clnk

   'PYTHON_UNITTEST_MANIFESTS': (ManifestparserManifestList, list,
"""List of manifest files defining python unit tests.
"""),


just before 'XPI_NAME' is defined. And as before, it is a long
shot to try to add the definition above to context.py and hope
it is just otherwise ignored.


About how long into the build does 51.0.1 error? And about
how long into the stock 52.4 build do you get the TypeError
error?


   Cheers,

   Mike

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] TypeError: %d format: a number is required, not float when building Firefox 52.4.1esr

[Michael Shell]

On Mon, 30 Oct 2017 13:56:25 +
Ken Moffat  wrote:

> Michael, please don't top post.

Well, I looked carefully at my post again and don't believe I did. However,
I did reply to three different posts within that one post, but in each
case my reply was after the relevant quoted material. This is OK - much
better than breaking that single post into three separate posts, right?


> It seems very unlikely that the released version contains
> inconsistent python files.

Yes, but Gunner tried updating (only) gen-event-data.py thus
(probably) causing an inconsistency.  I was just saying that he
might, just might, be able to get away with that approach (in an
attempt to try overcome the TypeError) if the other related/library
.py files in the same dir are also updated as well. Of course, it's
still a bit of a long shot though.


  Cheers,

  Mike


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] TypeError: %d format: a number is required, not float when building Firefox 52.4.1esr

[Michael Shell]

On Sat, 28 Oct 2017 17:10:47 -0500
Gunner Hooper  wrote:

> I tried using the new gen-event-data.py file. This is the output:
> "/root/sources/firefox-52.4.1esr/toolkit/components/telemetry/gen-event-data.py",
>  
> line 9, in 
>      from shared_telemetry_utils import StringTable, static_assert, 
> ParserError
> ImportError: cannot import name ParserError


  Gunner,

If I had to guess, the error resulted because of a version mismatch
between gen-event-data.py and the other python files within
components/telemetry. In particular, shared_telemetry_utils.py
will likely need to be updated. If you should ever want to
proceed down this path again, I would try updating all the files
within components/telemetry.
  
On Sun, 29 Oct 2017 01:14:31 -0500
Gunner Hooper  wrote:

> I decided to try building Firefox 51.0.1. It's been building for a
> few hours and it hasn't given me any error yet. I will report
> back when it finishes.

This is a good idea. You might also want to try the test with
a more recent version (e.g., 53.0.3 which should not require rust),
even if you can't overcome the SSE issue, at least you would know
if the python issue persists in the recent versions. And it's
good that that problem shows up early on, before you've gotten
many hours into the build.

It could be the case that a recent gcc/python/etc. breaks
something around 52.4 and that the problem does not exist
somewhat earlier or later.

Also, it seems it *is* still possible to build Firefox 54
without rust - but you have to patch the code to reverse a
change in moz.configure/rust.configure that (simply) removes
the --disable-rust option:

https://reviewboard.mozilla.org/r/108876/diff/3#index_header

In any case, please do post the result of your 51.0.1 build
attempt. 

On Sun, 29 Oct 2017 01:00:12 +0100
Ken Moffat  wrote:

> Missed this part, so only replying now: I assume a pIII only has the
> old IDE connectors (40 or 80 pin cable) - SSDs are SATA (or M2 or
> whatever) and might require newer SATA : one of my boxes had a VIA
> (I think) chip which could do SATA1 but could not do the negotiation
> for faster speeds - and failed to recognize SSDs because of that.

This can be overcome with an add-on SATA card such as the
SYBA/IOcrest SY-PCI40010:

https://www.newegg.com/Product/Product.aspx?Item=N82E16816124028
 
> Using machines which are even 5 years old, but only consumer
> quality, is already painful if building current packages from source
> using recent gcc.  I really don't think it's worth the effort of
> using older machines unless they are high-end (e.g. 8 threads,
> fast-ish memory).

I think he understands. Many factors contribute to whether
something is worth it, including if there are no constraints on
the build time and how the machine is actually used (e.g., as an
emergency backup system). For some, the endeavor/challenge may even
have value/entertainment in and of itself.


   Cheers,

   Mike



-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] TypeError: %d format: a number is required, not float when building Firefox 52.4.1esr

[Michael Shell]

On Sat, 28 Oct 2017 10:52:23 -0500
Bruce Dubbs <bruce.du...@gmail.com> wrote:

> Michael Shell wrote:
> 
> > Another, in my opinion better, option (given the enormous bloat of QT)
> > is WebkitGTK+ based browsers, ...
> 
> LOL.  You have to be kidding.


  Bruce,

Interesting ... and a surprise to me - I had based my opinion only
on my memory of the relative size of packages:

Qt-5.9.2  => Download size: 288 MB 
WebKitGTK+-2.18.1 => Download size: 15 MB

After Qt's package size went over 100MB some time ago, I wrote its
developers off as having lost their mind.

Any ideas as to why Qt compiles so much faster than WebKitGTK
given the large disparity in the package sizes? Is the Qt package
including large amounts of code/data that is not complied under Linux,
but is still included due to the cross-platform nature of Qt?

In anycase, I do think an SBU of 27*4 = 108 is "doable" on an old
machine. So, the Qt browser route is also an option, if he can
(still) disable the use of SSE in Qt 5.


  Cheers,

  Mike


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] TypeError: %d format: a number is required, not float when building Firefox 52.4.1esr

[Michael Shell]

On Fri, 27 Oct 2017 13:23:25 -0500
gunnersky2...@gunnerhooper.tk wrote:

> File 
> "/root/sources/firefox-52.4.1esr/toolkit/components/telemetry/gen-event-data.py",
>  line 82, in write_common_event_table
> e.dataset),
> TypeError: %d format: a number is required, not float


Well, it looks like a ("simple") python issue to me and might not even
be related to older systems:

https://stackoverflow.com/questions/27030856/python-typeerror-d-format-a-number-is-required-not-nonetype
https://stackoverflow.com/questions/27324102/typeerror-d-format-a-number-is-required-not-getset-descriptor
https://stackoverflow.com/questions/34113421/pymysql-query-formatting-typeerror-d-format-a-number-is-required-not-str

It might be a good idea to ask some Python folks what is, or could be,
going wrong here. It also might be very helpful to insert some python
test code to print out all the affected field values to see what the
incorrectly passed value actually is.

But, given that I, like Ken, can't find any other example this particular
error on the net, it might be caused by a lack of RAM or SWAP problem.
It could also be triggered (only) by a very recent GCC. A hardware
problem is another possibility - most especially if the exact error
is not repeatable.


What does the Python code in gen-event-data.py", line 82, in
write_common_event_table look like? I think a (very similar,
newer version?) copy of it can be found online here:

https://github.com/mozilla/gecko-dev/blob/master/toolkit/components/telemetry/gen-event-data.py

From:

https://github.com/rg3/youtube-dl/issues/8299

note that this type of error happens when a nonnumerical option is
assigned a value that requires a number. e.g., --retries infinite
instead of --retries 100

Could anything like this be going on in your mozconfig or some
other typo in a setup/patch/config parameter?


On Fri, 27 Oct 2017 20:17:10 +0100
Ken Moffat  wrote:

> I suspect there are no maintained graphical browsers which will work
> for you.



IMHO, when buiding from source, non-SSE should always be an option even
if performance suffers as a result. Sometimes/often/always
requirements like this are simply the result of "lazy or indifferent"
developers rather the result of a real technical need.


Anyway ...
I have some old notes on getting such things to work with older CPUs
that may be of help to someone. However, I have not tried any of this
with the most recent versions of packages, but I do suspect it will
still work.

For QT stuff, configure with the -no-sse2 option. For QtWebKit invoke
the --no-force-sse2 option.

Another, in my opinion better, option (given the enormous bloat of QT)
is WebkitGTK+ based browsers, especially Midori:

http://www.linuxfromscratch.org/blfs/view/svn/xsoft/midori.html

However, SSE instructions must be disable in WebkitGTK+. To do this,
apply the disable-jit-nonsse2.patch from debian:

https://packages.debian.org/source/sid/webkitgtk

found in webkitgtk_2.4.11-3.debian.tar.xz

http://http.debian.net/debian/pool/main/w/webkitgtk/webkitgtk_2.4.11-3.debian.tar.xz

*as well as* invoking the --disable-jit configure option 

The Debian fix-ftbfs-gcc6.patch and x32_support.patch might also be
helpful/needed.

Those who have an older Xorg system might have to disable some other
things as well:

../configure --prefix=/usr --with-gtk=2.0 --disable-webkit2
--disable-gamepad --disable-webgl --disable-geolocation
--disable-glx --disable-accelerated-compositing
--disable-jit


The following won't be a problem for Gunnersky2002 because he is using
gcc 7.2.0, but just for the record here, some older versions of gcc
(pre 5.x series), may error with:

  CXXLDlibwebkitgtk-1.0.la
./.libs/../DerivedSources/WebInspectorUI/.libs/libWebCore_la-GResourceBundle.o: 
In function `read':
GResourceBundle.c:(.text+0x0): multiple definition of `read'

which can be overcome by disabling -O2 and -D_FORTIFY_SOURCE=2 
in CFLAGS - before running configure, edit .configure and
and change lines 21968-21982 from:

# Add the appropriate 'O' level for optimized builds.
if test "$enable_optimizations" = "yes"; then
CXXFLAGS="$CXXFLAGS -O2"
CFLAGS="$CFLAGS -O2"

if test "$c_compiler" = "gcc"; then
CFLAGS="$CFLAGS -D_FORTIFY_SOURCE=2"
fi
if test "$cxx_compiler" = "g++"; then
CXXFLAGS="$CXXFLAGS -D_FORTIFY_SOURCE=2"
fi
else
CXXFLAGS="$CXXFLAGS -O0"
CFLAGS="$CFLAGS -O0"
fi


to:


# Add the appropriate 'O' level for optimized builds.
if test "$enable_optimizations" = "yes"; then
CXXFLAGS="$CXXFLAGS -O1"
CFLAGS="$CFLAGS -O1"
else
CXXFLAGS="$CXXFLAGS -O0"
CFLAGS="$CFLAGS -O0"
fi

https://mail-index.netbsd.org/tech-pkg/2014/05/25/msg013114.html


Anyway, as Ken said, be sure you have at least 4GB of swap space lest
you encounter gcc errors such as "g++: internal compiler error".

In older machines of limited RAM, it might be helpful to provide
swap via a SSD drive, but I have not tested this so I don't know
what 

[blfs-support] Python 3 only? (was: error building gnome-desktop)

[Michael Shell]

On Tue, 24 Oct 2017 10:56:55 -0500
Bruce Dubbs  wrote:

> We have Python-2.7.14 as a required dep 


This prompts me to ask: What is the current status of going to a
"pure python 3" BLFS system (one that no longer supports Python 2)?

I know the v3 syntax change is a real pain, but shouldn't we be able
to finally jetison Python 2 by now? After all, it's been 8 years
since Python 3 has been released and automated 2->3 code conversion
scripts exist.


  Cheers and thanks in advance,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Upgrading Binutils

[Michael Shell]

On Tue, 17 Oct 2017 23:56:24 +0200
DGSJ  wrote:

> My question is if it is possible to upgrade binutils directly, I mean,
> simply building binutils-2.29 as indicated in paragraph 6.26 of LFS 8.1,
> for example.


In my own experience, you can upgrade binutils by itself without
any problem - it is *downgrading* that may cause a problem with
gcc, which might use a feature that requires a binutils of
a certain release or newer.

> Should I have any precautions?

You might want to do a backup of all installed binutils programs,
scripts and libraries:

Installed programs: addr2line, ar, as, c++filt, elfedit, gprof, ld, ld.bfd,
ld.gold, nm, objcopy, objdump, ranlib, readelf, size,
strings, and strip
Installed libraries: libbfd.{a,so} and libopcodes.{a,so}
Installed directory: /usr/lib/ldscripts


before you install the new version of binutils.



  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Adobe Acribat Reader (acroread) stopped working after upgrades.

[Michael Shell]

On Wed, 06 Sep 2017 00:11:28 -0700
James Richard Tyrer  wrote:

> [ ~ ]# cat  /tmp/acroCrashLogs/0906_0001_wJDhzR
> /usr/bin/acroread [0x850ab41] [@0x8048000]
> linux-gate.so.1(__kernel_sigreturn+0x0) [0xe400] [@0xe000]
> 
> This doesn't look like much information to me.


  James,

Yeah, but what there is of it looks just like that glibc-2.18 problem you
mentioned:

https://bugs.gentoo.org/show_bug.cgi?id=488918

and there is a known stack alignment issue with the acroread binary that
can only be removed by recompiling acroread with a newer compiler.
Perhaps the issue is back once again with the most recent versions
of glibc?

From the link above, can you also produce a gdb backtrace like the one
on comment #3?

One test you can do is to install a (temporary) test version of your
current version of glibc, but one with SSE instructions turned off.
Check the glibc configure options, and/or set your CFLAGS when compiling glibc 
to:

-mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-ssse3 -mno-sse4.1 -mno-sse4.2

and see if your special version of glibc allows acroread to work. Also,
invoking full optimization ( -O3 ) might overcome the problem as well
(because doing so inlines the functions that would cause a stack crash):

http://www.sourceware.org/ml/libc-alpha/2013-08/msg00257.html

You can also create a special (or older, what you were using before the
upgrade) version of glibc and then use LD_PRELOAD to preload that
library for acroread. You can also do the LD_PRELOAD trick with just
the specific function as mentioned in comment 7 in the gentoo link
above (if that function is the only thing that trips acroread).

However, beware: do not allow any older version of glibc to install
its headers into your (include) system, better to just copy its
libc-X.so manually to a special place or with a special name in /lib.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Seg fault when starting Gnome

[Michael Shell]

On Wed, 30 Aug 2017 19:06:46 +0200
"Cliff McDiarmid"  wrote:


> and no, PAM it would seem isn't to blame. Still getting messages about
> logind and PAM(see attached log).



   Cliff,

It could be a PAM setup issue:

https://ubuntuforums.org/archive/index.php/t-2230602.html
(last post)


Also, are you using hidepid=2 in the mounting of /proc
(within /etc/fstab)?

https://bugs.archlinux.org/task/31814

 "Well after hours of debugging and just trying random things I could
  think of, I straced gdm... And wading through the megabytes of noise
  was worthwhile, I found this critical line:
  [pid 2063] open("/proc/1/cgroup", O_RDONLY|O_CLOEXEC) = -1 ENOENT
  (No such file or directory)
  
   I'm mounting /proc with options hidepid=2 -- which hides other users'
   processes. It never caused me a problem so far. But apparently
   Gnome 3.6 relies on poking around in the details of the init process."

and also:

https://unix.stackexchange.com/questions/370597/is-systemds-logind-or-gnome-wayland-session-incompatible-with-hidepid-2/370607


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Adobe Acribat Reader (acroread) stopped working after upgrades.

[Michael Shell]

On Sat, 26 Aug 2017 18:56:23 -0700
James Richard Tyrer  wrote:

> So, it appears that a Segmentation Fault crash is the problem.  I have 
> no clue exactly what the cause is.



 James,

Try this and see if it shows something more helpful:


ACRODEBUG=1 ACRO_CRASHLOG=1 acroread


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Seg fault when starting Gnome

[Michael Shell]

On Sat, 26 Aug 2017 00:08:44 +0200
"Cliff McDiarmid"  wrote:

> I have log and have attached it. Looks like a Linux Pam issue(not installed), 
> do you know
> if Gnome requires this before it can start?


  Cliff,

It looks that way. It seems we should always keep in mind that gnome
is fragile in the sense that a problem early on (no PAM) can cause it
to spiral down - and the final failure mode (segfault) can obscure
the triggering misstep. Such later crashes are indeed bugs (even if
triggered by the lack of something gnome needs).

Searching for 

"gnome.Shell.desktop" "Unsupported session type"

I found this:

https://www.linuxquestions.org/questions/linux-from-scratch-13/anyone-good-with-gnome3-4175608979/


  "Solved...
   I had to setup Linux-PAM properly for it to start, and it turns out...
   I do NOT like Gnome 3, ;p
   Going to be using XFCE4"


and then FWIW, someone else suggested MATE which is continuation of GNOME 2:

https://mate-desktop.org/


In any case, do let us know if PAM was to blame.


  Cheers,

  Mike


  
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Seg fault when starting Gnome

[Michael Shell]

On Thu, 24 Aug 2017 13:11:49 +0200
"Cliff McDiarmid"  wrote:

> gnome-session-f[3065]: segfault at 0 ip 7f17482e79a9 sp 
  7ffcfe694900 error 4 in libgtk-3.so.0.2200.4[7f1748013000+6e5000]



I did a search and here are some more things to try.

It would be very helpful if you could produce a log like the 
"bug.log" posted by Pierre Durand (Pierrre):

https://bugs.archlinux.org/task/51791?project=1[0]=2=mutter

However that log is from journalctl, which does requires systemd.

The mutter issue was "fixed" by reverting this change:

http://git.net/ml/commits.gnome/2016-11/msg00443.html?PageSpeed=noscript


It also may be related to a bug related to libinput:

https://bugs.freedesktop.org/show_bug.cgi?id=99245

"I can not get gnome or even gdm started since I get a segfault
 for gnome-session. I traced the issue down to libinput switch
 from synaptics. Switching back to synaptics+evdev resolves
 the issue. This is what I see in journal ..."

and so switching back to Xorg evdev might be something to try.

There is also:

https://bugs.archlinux.org/index.php?do=details_id=51908

   "Command `gdk-pixbuf-query-loaders --update-cache` 
allowed me to login into gnome-session."

Note the gotcha mention in the posts:

  "The fail whale screen (gnome-session-failed) crashing is most
   likely a red herring. Something must have caused the screen
   to be launched in the first place; perhaps the components
   that gnome-session attempted to launch crashed similarly.
   That said, the fail whale screen shouldn't be crashing,
   either, so that's another issue."

  "Don't focus on the backtraces. You're debugging the 'Oh no
   something is wrong' screen that should show up when gnome
   can't start.
   Look at journalctl logs why gnome-session is not working."


So, there also could be two different crashes going on - the initial
one and then a later crash of the "fail whale" screen:

https://bugzilla.gnome.org/show_bug.cgi?id=775463

where Ray Strode has a patch that fixes the "fail whale"
crash:

https://bugzilla.gnome.org/attachment.cgi?id=352892=diff


Another bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=1384508

suggests trying 

gsettings set org.gnome.SessionManager auto-save-session false



  Cheers,
  Mike Shell


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Gobject-introspection

[Michael Shell]

On Sun, 11 Jun 2017 20:02:31 +1200
Simon Geard  wrote:
 
> But given the ease of installing it, versus the difficulty of going 
> back and reinstalling packages if you later find that you need it,
> well... personally, I wouldn't skip it unless I was absolutely certain
> that none of the packages I intended to build was dependent on it.


Yeah, there can be some surprises out there with regard to the
requirement of Gobject-introspection. For example, IIRC, libqmi
(once had?) required Gobject-introspection which meant that modemmanager
required Gobject-introspection, at least for QMI based wireless broadband
modems. However, according to BLFS today, it seems this is no longer
the case:

http://www.linuxfromscratch.org/blfs/view/svn/general/libqmi.html
http://www.linuxfromscratch.org/blfs/view/svn/general/ModemManager.html

Although I don't know what disadvantage there is here if (the recommended)
Gobject-introspection is not installed. In anycase, I'm glad to see it
no longer is a requirement for libqmi or (a strict requirement for)
modemmanager.


  Cheers,

  Mike Shell


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] BLFS-7.10 X fails

[Michael Shell]

On Sat, 03 Jun 2017 15:12:15 -0700
Paul Rogers  wrote:

> Errm, but this seems strictly related to trying to use the Nouveau 
> driver. It has been reliable with the VESA-fb driver.

The Nouveau might be more RAM intensive, also it might pull more
power which could trigger hardware issues. It is easy enough to
slow the RAM speed down and see if it helps any. I recommend
checking RAM speed issues for any mysterious kernel panics.

> However, this CPU is a "Bloomfield" i7-940, the first generation 
> socket 1366 processors.

Not the CPU, I was asking about microcode updates for the video
card (GPU). Some video cards require the kernel to load microcode
for modesetting to work. See "Firmware for Nvidia video chips" at
the LFS page:

http://www.linuxfromscratch.org/blfs/view/svn/postlfs/firmware.html

Let's see all of your kernel's video driver log lines from

dmesg | less

The first lines should involve "agpgart: Detected ..."
(if you are using an AGP interface card)
"[drm] Initialized", "[drm] ... kernel modesetting enabled."

If firmware is loaded it will say something like
"[drm] Loading  Microcode"
the last lines will be something like
" [drm] Initialized ... on minor ..."


Does anyone know if his Nvidia GTS 450 card needs firmware?

> Actually, I really don't mind using the VESA driver on this box.

You can always fall back on that, but I would try to find out
what is going wrong. Doing so might fix a problem that might
bite in another way in the future.

I would even try the Nvidia proprietary driver before I would
give up on the card.

BTW, if you ever want to try another card, I've had good results
with the XFX Radeon R7-360P-2SF5:

https://www.newegg.com/Product/Product.aspx?Item=N82E16814150753

(Well so far, but I haven't yet got around to upgrading to the
latest BLFS, and I haven't tried the amdgpu driver with it
either, just radeon.) Also, this card does require the 
supplemental 6 pin power supply connector. 

The R7-360P is a "Bonaire" card. Gentoo has some info on these
newer Radeon cards:

https://wiki.gentoo.org/wiki/AMDGPU

FWIW, for the radeon cards, we can get kernel firmware at:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

I just copy the whole radeon directory to /lib/firmware/radeon
and then in the kernel config, I do:

CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="radeon/bonaire_ce.bin radeon/bonaire_k_smc.bin 
radeon/bonaire_mc.bin radeon/bonaire_me.bin radeon/bonaire_mec.bin 
radeon/bonaire_pfp.bin radeon/bonaire_rlc.bin radeon/bonaire_sdma.bin 
radeon/bonaire_uvd.bin radeon/BONAIRE_vce.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set

In this way, during a kernel build the needed firmware is
obtained in the /lib/firmware directory and compiled into
the kernel.


However, note from the LFS link above, for Nvidia cards, you will
have to extract the firmware yourself using a python script.
After that, the kernel procedure above should work (adjusting
paths and filenames as needed).


   Cheers,

   Mike



-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] BLFS-7.10 X fails

[Michael Shell]

On Fri, 02 Jun 2017 20:56:42 -0700
Paul Rogers  wrote:

> So I've got 4 paths: 1 kernel panics, three cannot start X.  It's
> getting deeper!  I do need help.


As far as the kernel panics go, you can try two things. First, try
slowing down your memory speed settings in the BIOS.

Also, I found this:

https://www.spinics.net/lists/stable/msg172825.html

It seems there have been a lot of race/timing issues fixed in the
kernel drm-nouveau driver for the 4.11 version. I would try the
latest 4.12-rc3 version (to make sure all those changes made it in
there) and see if that helps any:
https://www.kernel.org/

As far as startx goes, there might be something here that might
help:

https://bbs.archlinux.org/viewtopic.php?id=208251

In particular, theNerd247 wrote:


Ok. So weirdest thing happened. I went into the UEFI settings
and there is a setting called "3D Graphic Acceleration" and I
disabled it. I'm not sure if this disabled the GPU or not however.
After rebooting I ran startx and everything worked. Could it have
been the GPU?
---

Lastly, in your kernel log messages

dmesg | less

what does it say with regard to "[drm]", "kernel modesetting"
and "Loading . Microcode"?


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] radeon HD3000 freeze

[Michael Shell]

On Tue, 30 May 2017 17:47:57 -0400
Andrew Warshall  wrote:

> is there a way to check GPU temp?


  Andrew,

As Douglas mentioned, lm-sensors handles all that. However, getting
sensors configured can be involved. See the man pages for

sensors-detect
sensors.conf

See also:

https://askubuntu.com/questions/244577/temperature-and-other-statistics-from-radeon-open-source-drivers
https://gist.github.com/hamstar/7092276

After proper/detection and configuration, running 

sensors

will show the various temps and voltages. Remember that most
motherboards will require manual tweaking of the config file
in /etc/sensors.d - the INx voltages will have to be properly
labeled and many voltages over 3.3V will require a multipler
be set/used (i.e., the sensor chip can't handle voltages over
4V or so, so 5V, 12V must be divided down by a resistive
voltage divider before being input to the sensor input).

However, temps are usually much easier to setup out of the box -
it's usually just a question of determining whether a given
temp is: 1. internal to the CPU, 2. a sensor in the CPU socket,
or 3. a GPU temp sensor and then setting their labels.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] radeon HD3000 freeze

[Michael Shell]

On Fri, 26 May 2017 09:36:04 -0400
Andrew Warshall  wrote:

> I have a radeon HD3000 graphics chipset. It works fine unless I try
> to do something graphics-intensive (video game, say) in which case
> after ~half an hour the Xserver hangs with many messages written to
> the system console about how it "couldn't schedule IB".


With that length of time, I would not rule out a hardware/overheating
problem even if the symptoms do match that of a previously known
or suspected kernel problem:

http://www.phoronix.com/scan.php?page=news_item=MTMxMjI

Some motherboards are set to overclock the hardware. You can try slowing
down any GPU related settings in the BIOS.

If the GPU is overheating, upgrading its fan or reseating the heatsink
with new thermal compound might do the trick. Make sure the case itself
has enough ventilation. You could try testing it with the case open,
maybe even with a room fan blowing into it.

As Kuba said, you can boot multiple kernels, so there should not be
any reason you can't try the very latest version.

If you ever do find the problem, please do let us know what it
turned out to be.


  Cheers,

  Mike Shell





-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] BLFS 7.10 fonts less clear than in 7.9

[Michael Shell]

On Thu, 20 Apr 2017 12:39:26 -0500
rhubarbpie...@gmail.com wrote:

> However, the gist of the post was correct.

Yep, for the record in case someone ever runs into this, at least on
your system, freetype will yield a lighter font iff: (1) hintfull
is being used *and* (2) version 35 of the freetype truetype
interpreter is being used. And, of course, what fontconfig uses
by default varies by version.

With recent versions of freetype, we can now control which version of
the truetype interpreter freetype uses via an environment variable:

FREETYPE_PROPERTIES="truetype:interpreter-version=35 cff:no-stem-darkening=1 
autofitter:warping=1"

We can see what hinting settings are in effect via:

fc-match '' hinting hintstyle autohint

hintstyle 0=hintnone, 1=hintslight, 2=hintmedium, 3=hintfull

I for one would like to be able to tune the heaviness of the
rendered fonts. As I understand it, the "Infinality" patches
allow for such control:

export INFINALITY_FT_GAMMA_CORRECTION="0 100"
export INFINALITY_FT_BRIGHTNESS="0"
export INFINALITY_FT_CONTRAST="0"

However, these Infinality features have not yet made it into
fontconfig/freetype mainstream yet.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] ACPI errors and 4.9.9 kernel. LFS 8.0

[Michael Shell]

On Tue, 4 Apr 2017 10:43:29 -0500
Bruce Dubbs  wrote:

> This is what I found via google:
> 
> https://access.redhat.com/articles/65378
> https://forum.manjaro.org/t/acpi-error-on-boot-after-updating-to-4-9/12894


And for me, this one:
https://bugzilla.kernel.org/show_bug.cgi?id=43229

It seems it is a BIOS problem, but OEMS are reluctant to fix things
like this, especially if MS Windows "works".

On the off chance it could get percolated up to the powers-that-be,
I would make sure that it still happens when running the latest BIOS
and then file a report with the motherboard maker.

In bugzilla URL above, there is a kernel patch:
https://bugzilla.kernel.org/attachment.cgi?id=99271=diff==1=raw
that (re)enables support for the

libata.noacpi=1

kernel option (older kernels supported this option). Invoking that
option on boot will tell the kernel to ignore ACPI for the ATA devices.

Some people report that invoking that option improves drive performance
on boot (i.e., eliminating drive timeouts and reducing boot times) and
on wakeup:

https://bugzilla.redhat.com/show_bug.cgi?id=629315

I would invoke it on any system that is so improved.


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Qtwebkit - bash: qmake: command not found. BLFS 7.10/development

[Michael Shell]

On Wed, 8 Mar 2017 14:41:20 -0600
rhubarbpie...@gmail.com wrote:

> What am I missing?


I think rhubarbpieguy is hitting at a more general issue - that the BLFS
book, if followed exactly, does result in the proper *installation* of a
given package, but strictly following it is not in itself sufficient to
make every package *available* for further use by the system - most
every package, but some, such as qt here, are exceptions.

This issue is probably of most importance when porting the book's
instructions into scripts - e.g., without the required updates to PATH,
ldconfig, etc., later steps will fail. Of course, one could always
resource, ldconfig, restart the shell, etc., after *every* package, but
that would slow the build process a bit. i.e., the need to reboot or run
ldconfig is generally already noted, but the need to resource, etc.
isn't. (The latter is omitted only because that is supposed to be obvious
to a user.)

So, I think he wants a type of note at the end (e.g., a "Due to changes
in the environment, the build shell will now have to be restarted for
this package to be made available" boilerplate sentence) so that
steps/packages that require a resource, etc., can be quickly and
"fool proofly" identified as such. For without that, a person has to
review the entire installation context to make a judgement (even if
an easy and obvious one) about what else has to be done before
proceeding to actually use the package.



  Just my $0.02,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Why no PDF version of BLFS?

[Michael Shell]

On Wed, 1 Mar 2017 11:46:49 -0600
Bruce Dubbs  wrote:

> fop -q  $(RENDERTMP)/blfs-pdf.fo $(BASEDIR)/$(PDF_OUTPUT) 2>fop.log


For those who might be interested, the needed fob package can be found
here:

https://xmlgraphics.apache.org/fop/


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Should the libpng patch be listed as a dependency in the Firefox documentation? BLFS 7.10/BLFS development

[Michael Shell]

On Sat, 7 Jan 2017 10:35:51 -0600
Bruce Dubbs  wrote:

> I'll change the patch from optional to recommended in libpng.

As a general rule, shouldn't each application page list/mention any and
all special patches/functionality that an application specifically needs?

For example, suppose, heaven forbid, Firefox ever needed half a dozen
different special library patches. Ditto for GNUcash or some such.
Anything special an application needs that deviates from the "standard"
build should be noted on that application's page to document them in
a single place (most relevant to them) otherwise we might have to look
through the entire BLFS library pages to find every "way back" option
we need.

I myself have always applied the png animation patch because I didn't
see any reason why *not* to. But, if I hadn't done so it might have
been a real head scratcher when I got to Firefox.

On Sat, 7 Jan 2017 07:39:09 -0600
rhubarbpie...@gmail.com wrote:

> However, if Firefox is compiled after building BLFS it seems
> the optional patch could be missed as gtk/gdk-pixbuf/libpng
> were compiled without Firefox in mind. 

For the record, what exactly happens if we miss doing this patch and
try to build Firefox using system libpng anyway? e.g., do we get a
compile error, runtime fault, or does Firefox simply not render
PNG animations?

Does anyone know if any other applications also rely on this
animation patch for libpng? Kind of a bad spot to be in to depend
on functionality that the libpng developers won't accept into the
mainstream. AFAIK, the argument was that the libpng folks want the
mng media type to handle all animation stuff, but the Firefox folks
thought that was an overkill and that png should at least be able
to do everything gif does. Thank goodness situations like this are
not very common.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] mesa-12.0.1 build error

[Michael Shell]

On Fri, 28 Oct 2016 14:19:44 -0400
Richard  wrote:

> The errors appear to be in building the swr driver and specifically it
> complains about INT64 not being defined.


According to this:

https://www.mail-archive.com/mesa-commit@lists.freedesktop.org/msg64402.html

the mesa developers have since removed all references (at around lines 41
and 56) to INT64 in
 
src/gallium/drivers/swr/rasterizer/core/utils.h

and replaced them with int64_t . This type is defined in 
/usr/include/stdint.h and on 32bit platforms is defined as a long long int

AFAIK, mesa should compile OK on 32bit platforms.


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Boost-1.62.0 md5sums

[Michael Shell]

On Sun, 9 Oct 2016 14:12:28 +0200
Pierre Labastie  wrote:

> http://lists.linuxfromscratch.org/pipermail/blfs-dev/2016-October/032486.html

Just goes to show how something can go right through our inbox and
we won't even notice let alone recall it ... until we run into the
problem outselves. LOL.


  Thanks for the answer! ;)

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-support] Boost-1.62.0 md5sums

[Michael Shell]

I recently downloaded Boost

http://www.linuxfromscratch.org/blfs/view/svn/general/boost.html

using wget:

wget -O boost_1_62_0.tar.bz2 
http://downloads.sourceforge.net/boost/boost_1_62_0.tar.bz2

as well as from within firefox. In each case, the resulting md5sum
doesn't match that on the BLFS page.

For both downloads, I get an md5sum of

5fb94629535c19e48703bdb2b2e9490f

instead of BLFS'

21ff584b29094aa78c607f27cf296af3 

Has there been a mistake, or is Sourceforge (or someone worse!) playing
with the files again?


  Thanks in advance,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] BLFS 7.10 fonts less clear than in 7.9.

[Michael Shell]

On Sat, 24 Sep 2016 01:41:18 +0100
Ken Moffat  wrote:

> I've just had the opportunity to compare /etc/fonts/fonts.conf in
> 7.9 and 7.10.  Yes, they do differ in size by about 3.5K.  The
> reason is that the table of valid blank characters almost at the end
> of the file has been removed.
.
.
> I'm puzzled why the absence of that table would alter things for an
> English speaker running LFS ... 


  Ken,

Watch out - both those config files load all the links in
/etc/fonts/conf.d:


conf.d

So, we've also got to compare the list of the links in /etc/fonts/conf.d as
well as what is in (or just the sizes) the config files those links are
pointing to /etc/fonts/conf.avail

This is likely where the difference resides.


  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] BLFS 7.10 fonts less clear than in 7.9.

[Michael Shell]

On Thu, 22 Sep 2016 14:26:02 -0500
rhubarbpie...@gmail.com wrote:

> I don't understand how to get the freetype version, I see only
> freetype-config as the installed freetype program.

That one can reveal it with the proper chant:

freetype-config  --ftversion

> fontconfig-2.11.1  fontconfig-2.12.1  

There have been a lot of changes from 2.11.1 to 2.12.1 as that span
includes the 2.11.9x series:

https://www.freedesktop.org/software/fontconfig/release/

However, from a brief glance over the change logs I don't see any big
changes with regard to the default configuration settings.

> Would an error with freetype affect fontconfig?

My guess is that a run problem/bug with freetype would not affect
the default configuration of fontconfig as long as the former is
actually installed/detected.

If you get a chance, could you post (or if you prefer, email to me)
your fonts.conf for 7.9 as well as that of 7.10.



  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] BLFS 7.10 fonts less clear than in 7.9.

[Michael Shell]

On Wed, 21 Sep 2016 16:30:57 -0500
rhubarbpie...@gmail.com wrote:
 
> antialias - Changing the antialias setting from 'true' to 'false' helped 
> significantly.  The fonts are just a touch 'blotchy' but the bold 
> problem is eliminated.  However, if I change /etc/fonts/local.conf to 
> include only an antialias setting the fonts are acceptable.


I'm surprised that a change in fontconfig is causing this. Most of the
time problems in this regard are caused by changes in freetype:

https://www.freetype.org/

Mote the changes they are doing all the time (e.g., 2.6.5 versus 2.7).

I've encountered a lot of freetype woes like what you are seeing
over the years.


Do you see any differences in /etc/fonts/fonts.conf, which is the system
default, for fontconfig? Are you running any of the /etc/fonts/conf.d
stuff in your startup files?

You can try creating copies of the fontconfig files:

cp -a /etc/fonts /etc/fonts-blfs7.9
or
cp -a /etc/fonts /etc/fonts-blfs7.10

and then overwriting a 7.10 /etc/fonts with that of 7.9 and see if that
corrects the problem with everything else being the same. If so, then
fontconfig did indeed change some of its defaults.

What are the two different versions of fontconfig you are using under
7.9 and 7.10?

Looking at the changelogs:

https://www.freedesktop.org/software/fontconfig/release/

The only thing that catches my eye for 2.12.1

https://www.freedesktop.org/software/fontconfig/release/ChangeLog-2.12.1

is at the end:

"Add --with-default-hinting to configure"


Are you sure that you are not running different versions of freetype
as opposed to fontconfig between your 7.9 and 7.10 systems?


  Cheers and thanks,

  Mike


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] BLFS 7.10 fonts less clear than in 7.9.

[Michael Shell]

On Tue, 20 Sep 2016 06:56:24 -0500
rhubarbpie...@gmail.com wrote:

> Perhaps things differ by box, but your file accentuates what I got with
> the standard 7.10 fontconfig. It produces fonts bolder than I like.
> ...  It's good to know I can fight back should the problem worsen with
> future versions of fontconfig.


In the past, the too-bold-fonts problem has generally been caused by the
autohinter:

http://lifehacker.com/5693492/disable-auto-hinting-to-fix-windows-fonts-in-linux

but autohinting was disabled in my config.

If you get a chance to investigate, you can delete the various sections
in my config file one at a time until the problem is affected - that will
reveal what has changed. Hinting and autohinting are the prime suspects.

However, in your case, because my hintless config exhibits the problem,
I suspect the problem area is with lcdfilter. For a great overview of
font options, see

https://wiki.archlinux.org/index.php/font_configuration

For the lcdfilter, try lcdlight or lcdnone in place of lcddefault and see
what happens.

Please do let us know if you learn anything in this regard because
in the future others will probably run into the same problem.


   Cheers,

   Mike Shell
 
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] BLFS 7.10 fonts less clear than in 7.9.

[Michael Shell]

On Mon, 19 Sep 2016 19:29:19 +0100
Ken Moffat  wrote:

> The internet has a plethora of suggestions for tweaking what happens
> in fontconfig.


The quality of on-screen font rendering under Linux has long irked me.
It seems that after I finally get things the way I like, some upgrade
to Freetype or GTK comes along that breaks something. There have been
some really bad releases of Freetype in the past, IMHO.

Anyway, below is my /etc/fonts/local.conf receipe (I'm running Freetype
2.6.3 with Fontconfig-2.11.1) that I like best on my system (so far).
Note that I am unusual in that I use the venerable Type 1 Nimbus fonts
for default on screen rendering. Try my font config, rhubarb pie guy,
and let us know if you like it or if it helps at all. Be sure and
adjust the paths for your case as needed.

  Cheers,

  Mike Shell








/usr/share/fonts
/usr/X11/share/fonts/X11/Type1





  
   
 
 false
 
   
  
 




  false

  






Helvetica


sans-serif





  
   true
  


 
 
  
none
  

 
 
  
   false
  
  
 
  
   hintnone
  
 



  false

  
 
 

  lcddefault

 



 
 
 
   112



# preferred/default serif, sans and monospace fonts
# use 
# fc-match --verbose sans-serif
# to check what is actually use for the given request

  serif
  Nimbus Roman No9 L


  sans-serif
  Nimbus Sans L


  monospace
  Nimbus Mono L



http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] plasma, now works for me (was Re: Black Desktop. Some improvements)

[Michael Shell]

On Wed, 24 Aug 2016 22:24:08 +0100
Ken Moffat  wrote:

> Mike, you continue to impress me with your ability to find useful
> links from the past!


Ken, glad to hear! I for one have learned a surreal amount of helpful
information from reading the BLFS list, so I'll probably never be able
to fully repay my debt to all the BLFS contributors.

Anyway, KDE under Intel graphics has been problematic and the
underlying video driver bugs seem to be a real challenge to fix.
Even as late as less than a year ago, someone posted an article:

https://www.reddit.com/r/kde/comments/3u2xjy/can_i_really_use_kde_with_intel_graphics/

with the title: "Can I really use KDE with Intel Graphics?"
That's not a good thing to see, in 2015 no less.

The consensus at this point seems to be yes, if one takes
the time to configure the right settings to side step
the bugs and limitations.


  Cheers and thanks,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Black Desktop. Some improvements

[Michael Shell]

On Wed, 24 Aug 2016 17:03:29 +0200
Edgar Alwers  wrote:

> By the way, if I start an xterm from fluxbox, I can enter 
> "/opt/kf5/bin/plasmashell" and plasma starts for about a second, braking 
> down inmediately.


  Edgar,

Then this would be something to investigate. There is/was a known
problem (mid 2015) with the Intel graphics driver and plasma although
that is supposed to have been fixed upstream by now:

https://www.phoronix.com/scan.php?page=news_item=Intel-Plasma-5-Driver-Crash
https://bugs.kde.org/show_bug.cgi?id=349519

It would help if you could provide more information about the crash
- backtrace, etc. (My apologies if you already have in previous posts
and I missed that.)

A workaround for the above problem is to use the uxa instead of sna
acceleration method in xorg.conf:

Section "Device"
Identifier  "Intel Graphics"
Driver  "intel"
Option  "AccelMethod"  "uxa"
EndSection

https://mail.kde.org/pipermail/kde-distro-packagers/2015-August/88.html


  Cheers,

  Mike


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Black Desktop. Some improvements

[Michael Shell]

On Mon, 22 Aug 2016 22:18:21 +0200
Edgar Alwers  wrote:

> Both machines are equiped with an vga compatible intel controller.


My guess is that there is a subtle hardware difference here that is causing
a rendering problem. One known cause of blank screens with an active cursor
under kde has to with the use of "compositing" to support all the special
effects kde has. If there is a quirk/difference/incompatibility in the
video hardware then whenever certain special effects are used, a problem can
happen.

FWIW, long ago (circa 1996) I recall a bug in a video driver that caused
MS Windows to crash when copying files - the flying-paper-between-folders
graphic effect is actually what triggered the problem.

This thread:

https://forum.kde.org/viewtopic.php?f=66=91932

mentions how to disable compositing within kde to see if that affects the
problem.


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Movin' and groovin'

[Michael Shell]

On Sun, 17 Jul 2016 20:05:03 +0100
Ken Moffat  wrote:

> I suspect the SATA cable on the add-in card had become slightly
> loose - my experience of SATA cables in the past week is
> discouraging, they do not seem to connect as reliably as the old ATA
> connectors.


A Google search for

SATA cable come loose

is really eye opening and features this rant:

http://arstechnica.com/civis/viewtopic.php?f=7=303806

Do your cables have locking clips?

An Ebay search for

SATA cable clips

shows many types that have locking clips.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Screen Resolution and Font Size of Virtual Consoles

[Michael Shell]

On Wed, 15 Jun 2016 00:39:43 +0100
Ken Moffat  wrote:

> It isn't a problem - it's the user's system, he or she can decide
> what suits.

Yeah, some monitors scale certain resolutions poorly. They supposedly
work best at their native (max) resolution, but with the fonts that
come with the base kernel, that often results in 160 columns+.

It's great to know about the terminus fonts Bruce mentioned.

However, even with the 16x32 size, a monitor running at 1920x1200
would still have 120 columns and 37 rows. A 24x48 font would yield
a standard 80 cols, but with a high resolution for fine glyph
details. I think the kernel developers could have done a better
job here with regard to the compiled-in fonts that are available
in the base kernel as well as with the framebuffer configuration
documentation that is out there.


BTW, has anyone here been bitten by "my modern IPS panel monitor
won't run over 60Hz (v. refresh) so I can't see the 70Hz BIOS
boot screen (when it's connected to an old machine)"?



  Cheers,

  Mike


 
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Screen Resolution and Font Size of Virtual Consoles

[Michael Shell]

On Mon, 13 Jun 2016 01:40:56 -0500
"Douglas R. Reno"  wrote:

> I would try appending "video=" to the end of your kernel
> command line, e.g.
> 
> video=1024x768


FWIW, this one can be tricky because if using the DRI/DRM framebuffer
drivers (e.g., DRM_RADEON, etc.) the video output port may also have
to be specified:

video=DVI-I-1:1024x768-16@60 fbcon=font:VGA8x16
video=DVI-I-1:1024x768-16@60 fbcon=font:SUN12x22
video=VGA-1:1024x768-16@60 fbcon=font:VGA8x16
video=HDMI-1:1024x768-16@60 fbcon=font:VGA8x16


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Internal compiler error ? SOLVED

[Michael Shell]

On Thu, 03 Mar 2016 17:20:26 +0100
"Dr.-Ing. Edgar Alwers"  wrote:

> Again, thank you very much  Bruce, Ken and Michael for the help


  Edgar,

And my apologies for not replying sooner - I was busy with other things
and got behind on all my mailing list email.


  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Internal compiler error ?

[Michael Shell]

On Mon, 1 Feb 2016 20:05:11 +
Ken Moffat  wrote:

> The only hardware-specific thing I recall "recently" was gmp - since
> September 2015 I have been using the configfsf.{guess,sub} over the
> config. versions.  Discussed on the lfs-dev list back then.


Yeah, I sure do remember that ordeal as I participated in it:

https://www.mail-archive.com/blfs-support@lists.linuxfromscratch.org/msg02166.html

and as the thread went on we finally tracked down the specific
illegal instruction.

The offender turned out to be the mulx instruction:

https://www.mail-archive.com/blfs-support@lists.linuxfromscratch.org/msg02228.html

and therein is a patch for the gmp source to lockout the use of bmi2
instruction set (of which mulx is one). 

Also, note from my post a way to check to see if a CPU supports
the bmi2 instruction set:

: cat /proc/cpuinfo
:
: To support mulx, the CPU must list bmi2 in the cpuinfo flags section:
:
: 
http://unix.stackexchange.com/questions/43539/what-do-the-flags-in-proc-cpuinfo-mean
:
: (see under "Intel-defined CPU features, CPUID level 0x0007:0 (ebx)")


In this way, Edgar can compare the CPUs of his two machines. I bet they
differ with regard to bmi2 capability.


  Cheers,

  Mike Shell


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] clang, gcc and --sysroot head-scratcher

[Michael Shell]

On Tue, 1 Dec 2015 20:12:27 -0500
alex lupu  wrote:

> 1.  Why 'clang' succeeds (when it does) and 'cc' does not?


You can try asking each preprocessor what their default search paths are:

gcc -x c -v -E /dev/null

These same options should also work with clang and then you can compare.


  Cheers,
 
  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] lfs7.7 atk internal compiler error

[Michael Shell]

On Tue, 6 Oct 2015 20:45:18 -0400
William Harrington  wrote:

> Another option for GMP to build a generic library is to use --build during
> configure. Distros will build GMP for a generic AMD64 or i386 build.


That's really good to know and probably the best way to go.


On Mon, 05 Oct 2015 14:04:42 -0400
Wayne Sallee  wrote:

> The one that I ran the test in is AMD.

AMD is often a tad slow to add Intel's newest commands. The BMI2 stuff is
not even in the Piledriver processors, it won't be until the Excavator
series that AMD will support BMI2:

https://en.wikipedia.org/wiki/Advanced_Bit_Manipulation

It can be understandable though - a lot of the newer commands don't add
as much performance as Intel suggests they do. For example, in 2007 Linus
Torvalds went on a rant about the lack of virtues of cmov:

http://yarchive.net/comp/linux/cmov.html

The BMI2 stuff might be an exception here when very large numbers need to
be manipulated (as libgmp does). This might explain why libgmp runs
noticably faster on Intel's stuff:

https://gmplib.org/pi-with-gmp.html

A 2.9 GHz Intel Haswell running more than 25% faster than a 4 GHz
AMD Piledriver? Sheezz. I'm still an AMD fan though. Note how it was the
inverse case in the GMP 4.2/4.3 days.

> One thing that I am wondering about; what about all of the programs that
> I have compiled with the previous install of gmp? I am wondering if I
> might run into problems with them working on a different computer.

You should be OK unless libgmp was statically compiled into something.
Note the standard LFS build of libgmp even disables the static ability:

http://www.linuxfromscratch.org/lfs/view/development/chapter06/gmp.html

Issues like this are the entire point of dynamic libraries - the library
can be updated without having to recompile everything. Furthermore, I
don't think many applications will link with gmp - it's gcc itself
that is using it. On my machine even bc does not link to gmp.

Gmp is a math library that supports the handling of numbers of arbitrary
precision and size. It's often used with cryptography applications because
they work with such large primes. I wonder why gcc needs it (and only
recently it seems this became true).



Cheers,

Mike Shell

 
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] lfs7.7 atk internal compiler error

[Michael Shell]

On Fri, 02 Oct 2015 09:53:03 -0400
Wayne Sallee  wrote:


OK, the backtrace shows that the actual illegal instruction happened
earlier - there are several error handlers that come after the problem
began and so we have to dissemble earlier.

From the backtrace, it looks to me that this is the exact place the
failure began:

#8  0x7fe021043dde in __gmpn_mul_1 () from /usr/lib/libgmp.so.10

Which is in libgmp as William Harrington suspected. mpn_mul_1 is known 
to use CPU-optimized assembly:

http://lists.gforge.inria.fr/pipermail/ecm-discuss/2007-November/003969.html

There they mention a --enable-fat gmp configure option that allows
gmp to autodetect the CPU at run time. So that's one option.
Let's see what the offending instruction is before passing judgment
on what to do:


Ok, try this chant:

gdb -c core /usr/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus

(gdb) disassemble 0x7fe021043dde,+8



  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] lfs7.7 atk internal compiler error

[Michael Shell]

On Mon, 28 Sep 2015 14:38:36 -0400
Wayne Sallee  wrote:

> package gdb:/usr/src/gdb> gdb g++ -c foo.cc


OK, try it like this:

gdb g++

(gdb) run -c foo.cc

Program received signal SIGILL, Illegal instruction.

(gdb) display/i $pc


That should show the offending opcode.



  Cheers,

  Mike




-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] lfs7.7 atk internal compiler error

[Michael Shell]

On Sun, 27 Sep 2015 08:35:27 -0400
Wayne Sallee  wrote:

> I'll install gdb, then clone the disk to a real disk, and run the test
> in a real laptop to see the name of the illegal instruction.

Please do let us know if you find out. Sometimes these kinds of things
can signal a type of problem we'll see more of in the future - such as
when the otherwise "686" AMD K6-2 processors did not support cmov.


  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] lfs7.7 atk internal compiler error

[Michael Shell]

On Fri, 25 Sep 2015 03:07:58 +0100
Ken Moffat  wrote:

> My own A4, when it was alive, showed no problems (apart from only
> having two cores).  My A10 (kaveri) is fine, and there I use make
> -j5 because it has an SSD.  So, from my experience only the Phenom
> is a problem.


 Ken,

If it is a problem in the kernel or with make, then I'd say that is
something "somebody outta fix".

This may be something more relevant to the LFS list, but have you
heard about or tried the make 4.1 vfork patch (March 2015)? 

0001-Fix-paralellism-by-reverting-to-use-of-vfork.patch:

http://savannah.gnu.org/bugs/?44555
http://savannah.gnu.org/bugs/download.php?file_id=33382

In one of the comments it was stated:

"With make.git at 4.1-11-ga80a8b8, "make -j10" typically takes
 about 3 minutes. With the attached patch applied, "make -j10"
 typically takes about 11s."

Although they are discussing increasing the performance of recent
makes, perhaps it will also have an effect on segfaults with
higher values of -j.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] lfs7.7 atk internal compiler error

[Michael Shell]

On Sat, 26 Sep 2015 10:19:30 -0400
Wayne Sallee  wrote:

> I started the build inside a 64 bit Linux operating system, inside
> Virtualbox, inside a 32 bit operating system, inside a laptop with
> a 64 bit Intel CPU. Then it was moved into a real laptop with a
> 64 bit AMD processor, then moved to where it is now, inside a
> laptop with a 64 bit Intel processor.


Yeah, that's a lot of worlds. Even though you're on your way to
fixing it, it still might be good to know the offending instruction
so that you will know what you have to avoid in gcc's flags.


  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] lfs7.7 atk internal compiler error

[Michael Shell]

On Fri, 25 Sep 2015 01:06:12 +0100
Ken Moffat  wrote:

> An ICE (internal compiler error) means something *apparently* went
> wrong in your compiler.  On one of my machines (an AMD phenom - they
> are notorious for this), building with -j4 often provokes this sort
> of error, particularly when building a new kernel.


  Ken,

Do you have any knowledge about how the newer AMD processors
(Phenom II, A10, etc.) hold up in this regard?

As to the problem of the OP, is it possible that gcc was not complied
for the correct target such that in unusual circumstances it really
will attempt to execute an unsupported CPU instruction?

If a reattempt is made to build atk (after cleaning the source tree)
does the exact same error occur at the same place? If so, a hardware
problem is less likely.

Another possibility is some kind of stack corruption (caused by
a bug in gcc or one of the libraries it depends on) where data
is somehow overwriting exec code.


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] CMOS

[Michael Shell]

On Sun, 23 Aug 2015 23:04:46 -0700
Paul Rogers paulgrog...@fastmail.fm wrote:

 Eventually I went under the covers and did a hard CMOS reset,
 and it magically reapeared.

Although in many/most modern computers the BIOS NVRAM actually is in
flash, perhaps that machine uses/requires the CMOS battery to maintain
the BIOS settings. If the CMOS battery is getting weak, then errors can
start to occur in the BIOS settings. If that battery is more than 5
years old (and maybe regardless of its age), I'd go ahead and replace it.

I've always thought it was an oversight for BIOS makers not to have
standarized a way to export/import the BIOS settings (via serial port,
to DOS floppy, or even as ascii printer text through the parallel port)
from the earliest days, well, at least after the number of settings
exceeded a dozen.


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-support] WebKitGTK+-2.4.9 really requires Ruby?

[Michael Shell]

For the older WebKitGTK+-2.4.9 (assume a GTK+2 build here):

http://www.linuxfromscratch.org/blfs/view/svn/x/webkitgtk2.html

Ruby-2.2.2 is listed as a required dependency. But, I can't seem
to find this requirement mentioned anywhere except on LFS:

https://lists.webkit.org/pipermail/webkit-gtk/2015-May/002357.html

Is Ruby really required, or is this just for those who intend to
run Gnome? What later uses the Ruby WebKitGTK+ bindings?

Obviously not a big deal either way given that Ruby itself doesn't
have any significant dependencies.



  Thanks in advance,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] lm_sensors-3.3.5

[Michael Shell]

On Sat, 6 Jun 2015 12:43:59 +0100
Richard Melville richard.melvill...@googlemail.com wrote:

 The point where lm_sensors complains is: Do you
 want to probe the I2C/SMBus adapters now?  When I type yes, it replies:
 Using driver 'I2c-i801' for device :00:1f.3: Intel 82801G ICH7.  This
 is immediately followed by: Failed to load module I2c-i801
 
 As I've said already, I've built this driver into the kernel.


It may depend on the specific driver. I've got an older system
using lm_sensors 3.3.2 and it does not complain that a driver
is built statically in the kernel. The problem may be confined
to sensors-detect's detection routine and not the sensors
utility itself, at least once its config files are setup.

I found this from 2012:

https://forums.gentoo.org/viewtopic-t-817433-start-0.html

which refers to an article closely related to this one:

http://jviz.research.iat.sfu.ca/wiki/index.php?title=HOWTO_Setup_lm_sensors

Be forewarned that the information there may be out of date.
That said, they suggest putting

LOADMODULES=no
INITSENSORS=yes 

in /etc/sensors.conf or /etc/sensors3.conf for kernels in
which everything is compiled in. You can also make your
local changes in files located in the /etc/sensors.d
directory.

If sensors-detect always tries to load a module rather
than first checking if the driver is available, I'd
consider that to be a bug that should be reported.


  Cheers,

  Mike Shell


-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] UEFI

[Michael Shell]

On Tue, 24 Mar 2015 17:02:39 -0400
alex lupu alup...@gmail.com wrote:

 Any plans to add 'efibootmgr' to (B)LFS offerings?


Just for future reference on the topic - gummiboot gets a lot of praise:

http://freedesktop.org/wiki/Software/gummiboot/

... comments like it's sane and actually works. LOL.


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Iptables fails after kernel upgrade.

[Michael Shell]

On Wed, 11 Mar 2015 09:41:12 +
Richard Melville richard.melvill...@googlemail.com wrote:

 Although, in order to avoid using an initrd I am now having to hack each
 new kernel to stop the rootfs being mounted too soon,


Sounds like a worthwhile feature. Did you ever mention this to the kernel
developers for them to consider officially supporting?


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Further adventures with BLFS-7.2

[Michael Shell]

On Sat, 28 Feb 2015 22:02:30 -0800
Paul Rogers paulgrog...@fastmail.fm wrote:

 arch/x86/kernel/apic/apic.c:475:2: error: 'MSR_IA32_TSC_DEADLINE'
 undeclared

Possibly a corrupt kernel tree because that is what happened in the
previous known case:

http://www.spinics.net/lists/linux-tip-commits/msg18902.html


MSR_IA32_TSC_DEADLINE is defined in arch/x86/include/uapi/asm/msr-index.h


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] BLFS - system hangs when i issue xinit or startkde

[Michael Shell]

On Sat, 21 Feb 2015 06:23:22 +0530
Manish Thatte manishjagdishtha...@gmail.com wrote:


 [ 106.563] (II) Loading /usr/local/lib/xorg/modules/input/evdev_drv.so
 [ 106.563] (EE) Failed to load
 /usr/local/lib/xorg/modules/input/evdev_drv.so: libmtdev.so.1: cannot open
 shared object file: No such file or directory
 [ 106.563] (II) UnloadModule: evdev
 [ 106.563] (II) Unloading evdev
 [ 106.563] (EE) Failed to load module evdev (loader failed, 7)
 [ 106.563] (EE) No input driver matching `evdev'
 [ 106.594] (EE) Server terminated successfully (0). Closing log file.


Xorg tells you exactly what is wrong. You need Libevdev and should have
mtdev-1.1.5:

http://www.linuxfromscratch.org/blfs/view/svn/x/x7driver.html
http://www.linuxfromscratch.org/blfs/view/svn/general/mtdev.html

Another possibility is that you do have the needed libraries, but they
are located somewhere other than where Xorg is looking for them.
Did you really intend to install them in /usr/local/lib/xorg/  ?

 (**) ModulePath set to /usr/local/lib/xorg/modules

or are they in /usr/lib/xorg/modules and ModulePath is set wrong?


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Xorg in qemu - no mouse cursor with the 1.17.0 server

[Michael Shell]

On Tue, 10 Feb 2015 23:58:33 +
Ken Moffat zarniwh...@ntlworld.com wrote:

  I had got as far a building fluxbox, then discovered that it was very
 hard to use because the mouse pointer no longer shows up.


I dunno if this is the problem, but:

http://stackoverflow.com/questions/19665412/mouse-and-keyboard-not-working-in-qemu-emulator
http://osdir.com/ml/qemu-devel/2007-03/msg00220.html
http://comments.gmane.org/gmane.linux.redhat.fedora.virtualization/2586


In short try: 

-show-cursor -display sdl


  Cheers,

  Mike Shell




-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Question based on the as_root() script (BLFS Ch. 24. X Window System)

[Michael Shell]

On Mon, 9 Feb 2015 22:28:29 -0500
alex lupu alup...@gmail.com wrote:

 2.  The tee construct.  It seems without the 'tee' even a BAD
 script would work correctly:


  Alex,

I have not went over what you posted very deeply, but the above sentence
immediately stood out to me.

See:

http://steve-parker.org/sh/functions.shtml

under Scope of Variables:

 A function will be called in a sub-shell if its output is piped
  somewhere else - that is, myfunc 1 2 3 | tee out.log will
  still say x is 1 the second time around. This is because a
  new shell process is called to pipe myfunc(). This can make
  debugging very frustrating; Astrid had a script which suddenly
  failed when the | tee was added, and it is not immediately
  obvious why this must be. 



   Cheers,

   Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Knowing when to ditch an old (desktop) system

[Michael Shell]

On Mon, 29 Dec 2014 21:40:51 +
Ken Moffat zarniwh...@ntlworld.com wrote:

 Summary - it is probably easiest to build a new system rather than
 try to keep a desktop running safely for years.

Well, I suppose it depends on the specific definition of safely.
You are defining it to mean no known exploits which are either
open to the outside (e.g., a flaw in the kernel's TCP/IP stack,
a browser exploit) or that are open to normal users (e.g., running
a command that can elevate a normal account to root access, trick
an application into doing something it is not supposed to, etc.).
And that goal can be a real tall order these days.

---
I am more concerned about the former than the latter because there
aren't any potentially hostile users on the system. Of course,
a malicious data/audio/video file does have the potential to turn
an unsuspecting user into a hostile force, but some thought always
should be given to the origin of any data files that are to be
processed. With browsers, we often aren't even aware what is running
within it. The Noscript plugin can help here, but so many sites won't
operate without javascript - I do so wish this were not the case.

I think we are approaching a time in which some thought needs to be
given to changing the system architecture at a more fundamental level
because it is becoming increasingly difficult to ensure all the various
applications are secure. i.e., even if a browser does have a flaw,
it should still not be able to do very harmful things.

Something like system-wide enforced application individualized sandboxing
is what I have in mind - each application should have an associated set
of permissions (installed as a text file in something like
/etc/perms/theapp) that sets limits on just what it is allowed to do - 
that are passed on to any other applications that may be started by it.
And perhaps the rules could be defined in ways such that only half a dozen
or so predefined rule sets are needed for 99%+ of the applications so as
to make administration easy.

For example, rules such as no modification of system files (thus even
if root were running mplayer it could not touch /boot),  no modification
of user .config or startup files except for those in the config directory
for the application itself (which should apply to most applications),
no other outside exec ability except for any already linked-in libraries.

Maybe something like the SELinux concept, but perhaps lighter and easier
to apply to every application on the system.

We may be burdened by this, but we are also burdened by having to upgrade
all the time and even this does not provide assurance that hackers are
not using flaws that are not yet known by developers.

I also think that man-in-the-middle in-network alteration of downloaded
program files and source code tar balls is of increasing concern (esp.
with regard to sudo make install) - along with the simultaneous compromise
of any corresponding .sig check files. The entire net needs to go https
and even that has a weakness with regard to the certificate authority
system.

https://www.grc.com/fingerprints.htm
https://bitsandchaos.wordpress.com/2010/03/29/certificate-patrol-can-really-save-your-pocket/
http://patrol.psyced.org/
http://files.cloudprivacy.net/ssl-mitm.pdf 


Finally, on the hardware level there should be stricter enforced
separation of code and data so that things like buffer overruns cannot
alter the code path to be executed (also code could be declared to be 
read only so as to not allow any self-modification). CPUs should have
hardware dedicated to enforcing such policies including data object
boundary limits (and these limits should be more tightly linked to
structures such as arrays in C).
---

Anyway, there also are differences with regard to how big a deal it is
to upgrade a package. In my view, a kernel tends to be easy, gcc is
easy/mid range (the largest hurdle tends to be the run time needed to
compile it) and glibc can either be easy or a really big deal depending
on whether upgrading that will break anything.

Generally speaking:

 1. Most individual apps, kernels and libraries tend to be easy.
 2. If you need to upgrade gcc, do go ahead and do it as that
is often easier than dealing with all the work arounds.
 3. IMHO, Xorg is a big deal
 4. Heavy weight applications and libraries with many dependencies
such as browsers can turn into big deals.

When encountering a big deal we should give serious consideration
to rebuilding the whole system.

Another angle is the obsolescence of the *hardware* itself. Has anyone
attempted to maintain a very latest system on older hardware, and if so,
what was the result - increasing slowness due to ever increasing demands
on the hardware, or is this at least partly countered by coding
improvements? How does GTK3 fare in this regard compared to GTK2?


  Cheers,

  Mike Shell








-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: 

Re: [blfs-support] How Do You Folks Write the LFS/BLFS Books?

[Michael Shell]

I just wanted to add some kudos - it really is well done. :) 

The *clean* presentation, the consideration of what is really important
and what is not, the additional information and tips some users are really
grateful for (e.g., what certain options and commands do), the table of
contents and hierarchical structuring - it all adds up to one winning
combination.

I wish more documentation out there followed such a saner path. When writing
documentation, it is all too easy to either clog the material with too
many details, ignore the bigger picture (because the package author is so
knowledgeable that he cannot understand the mindset of less-than-experts or
see how his part fits into the system as a whole) or to give too shallow a
treatment (because the author did not want to go through the extra effort
needed for a more through write up).

Without the proper documentation, a lot of the work done on a project ends
up being wasted and unappreciated in that many people will not even know
of it and will not be able to use it.

Perhaps in a better world, a good government (which we don't have today)
would periodically give out awards for volunteer efforts such as LFS,
which improved society, but perhaps was not rewarded in the marketplace
- Here's a couple hundred thousand bucks each to those who made this happen.
   Enjoy!. ;)


  Cheers and thanks,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Cannot Get lpr or lp to work

[Michael Shell]

  On Fri, 2014-10-03 at 23:37 -0400, Alan Feuerbacher wrote:

Cups lists the Description as: EPSON_Epson_Stylus_NX420


I don't know if this has already been mentioned, and/or will help, but
Google found:

http://ubuntuforums.org/showthread.php?t=1585380
http://www.openprinting.org/driver/epson-nx420/

So, with the correct setup and the above CUPS driver (supplied by Epson),
that model printer is known to be able to work OK under Linux even using
the wireless link.


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Compressing Man and Info Pages

[Michael Shell]

On Mon, 14 Jul 2014 17:08:35 -0500
Bruce Dubbs bruce.du...@gmail.com wrote:

 It's not really useful. I think I calculated the space saving as less 
 than 20M.


Years ago, could you imagine ever saying such a thing?! Why, that's
almost two dozen 3.5in floppies right there. LOL!

I think so it will go with regard to music files - uncompressed will
become the norm of the future and we will be back closer to the format
of the CDs of the 80's than that of the mp3 decades.

Dunno about uncompressed video though - that would be far in the
future. 

In each case, the tradeoff is between transmission bandwidth and
storage requirements versus the added CPU load and complexity of
format creation, use and management.


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page