[blfs-support] Critical security updates to glib2 and JasPer

[Douglas R. Reno via blfs-support]

Hello everyone,

Today, a critical 0day security vulnerability was discovered in glib2. 
This vulnerability has to do with the g_bytes_new and g_memdup 
functions, which are very commonly used in applications that use GLib. 
The vulnerability is an integer-overflow in the g_bytes_new function. 
More information on this vulnerability can be found here:


https://gitlab.gnome.org/GNOME/glib/-/issues/2319

https://mail.gnome.org/archives/desktop-devel-list/2021-February/msg0.html

As the maintainer mentions, this security vulnerability should be taken 
as a "matter of urgency, since this is a zero-day". In addition, every 
application that uses these functions from GLib is vulnerable. New 
versions of various packages will probably be released over the next few 
days to fix the issue from their side, but you should update to 
GLib-2.66.6 as soon as possible in order to be protected from this 
security vulnerability.


It should be safe to upgrade from 2.62.x and later to 2.66.6. The fixed 
version, glib2-2.66.6, has been committed to SVN, and should be in the 
book at the next render.


In addition to the update to glib2, an update to JasPer was performed 
today that fixed 25 security vulnerabilities. It's suggested that you 
update your system to JasPer-2.0.24 as soon as possible too, if you have 
JasPer installed. The new version of JasPer will be in the next render 
as well.



Thank you,

- Doug

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

Re: [blfs-support] Has something happened with the LFS/BLFS repos?

[Douglas R. Reno via blfs-support]

On 12/15/20 4:34 PM, Pierre Labastie via blfs-support wrote:

On Tue, 2020-12-15 at 21:32 +, Ken Moffat via blfs-support wrote:

On Wed, Dec 16, 2020 at 08:25:34AM +1100, Wayne Blaszczyk via blfs-
support wrote:

I cannot seem to pull anything down this morning, either LFS or
BLFS.
Is there some maintenance going on?

wblaszcz [ ~/LFS-Patches ]$ svn up
Updating '.':
svnserve: E210005: No repository found in
'svn+ssh://svn.linuxfromscratch.org/patches/trunk'
svn: E170013: Unable to connect to a repository at URL
'svn+ssh://svn.linuxfromscratch.org/patches/trunk'
svn: E210005: No repository found in
'svn+ssh://svn.linuxfromscratch.org/patches/trunk'

Wayne.


Trac is mostly timing out too.

Yes something happened to the repos, and it is my fault. I asked Bruce
to run "svnadmin upgrade" on the ALFS repo, and then svn+ssh:// was
answering No repository found. svn:// was still working though. Then
Bruce and Douglas tried to fix it, and I think that the svn server was
put off. Note that it still works for me as svn:// .

Pierre

It should be working again for now. Bruce and I fixed it about 45 
minutes ago.


- Doug

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

Re: [blfs-support] gpm mouse server

[Douglas R. Reno via blfs-support]

On 12/14/20 5:36 PM, James Read via blfs-support wrote:
I installed the gpm mouse server and ran /etc/rc.d/rc3.d/S70gpm start 
and got the output


   *   Starting GPM console mouse service

However, no mouse pointer appears in my terminals and the mouse 
doesn't seem to be working. Any ideas?


James Read


Hi James,

What are the contents of your "/etc/sysconfig/mouse" file?

You can try running mouse-test to find out what mouse type your mouse is 
presenting itself as, as well as what the device node is.


Also, make sure you have CONFIG_INPUT_MOUSEDEV enabled in your kernel 
configuration.


Also, a random tip for you - you can go to the Index and look at all of 
the packages that might need kernel configuration. If you're going to 
need audio, for example, you can find a link to the ALSA kernel 
configuration there.


- Doug

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

Re: [blfs-support] Kernel configuration observations/questions - BLFS 10.0/development

[Douglas R. Reno via blfs-support]

On 11/26/20 4:58 PM, rhubarbpieguy--- via blfs-support wrote:


Hi rhubarbpieguy,

I looked into the ones that Ken didn't do, and I have some feedback.


autofs

File systems --->
  <*/M> Kernel automounter version 4 support (also supports v3) 
[CONFIG_AUTOFS4_FS]


   I believe Kernel automounter support has no options.  Should the 
above lines be deleted?



I don't think the line should be deleted, but it did need to be corrected.

File systems  --->
  [*] Network File Systems ---> [CONFIG_NETWORK_FILESYSTEMS]
    <*/M> NFS client support  
[CONFIG_NFS_FS]
    <*/M> CIFS support (advanced network filesystem, SMBFS successor) 
[CONFIG_CIFS]


   Should CIFS support (advanced network filesystem, SMBFS successor) 
be SMB3 and CIFS support (advanced network filesystem)?

Ken did this one :-)
-- 



BlueZ

[*] Networking support --->    [CONFIG_NET]
   Bluetooth subsystem support --->    [CONFIG_BT]

   Is  correct?  Should it be ?  <*/M>?


Yes, I've corrected that

<*/M> RF switch subsystem support --->   [CONFIG_RFKILL]

   Should RF switch subsystem support ---> be RF switch subsystem 
support ?


Yes, I've corrected that. It's mandatory for WiFi, WiMAX, and Bluetooth 
at least, and has no options.

[*] Networking support --->    [CONFIG_NET]

This was extraneous :-)

-*- Cryptographic API ---> [CONFIG_CRYPTO]
   User-space interface for hash algorithms 
[CONFIG_CRYPTO_USER_API_HASH]
   User-space interface for symmetric key cipher algorithms 
[CONFIG_CRYPTO_USER_API_SKCIPHER]


   I believe Cryptographic API has no options.  Could [CONFIG_CRYPTO] 
be deleted as in cryptsetup?


Cryptographic API does have plenty of options, at least on my 
configuration (5.9.12)
   As with the above, should the hash algorithms and key cipher lines 
be ?  <*/M>?

Yes these should, I've corrected that
-- 



lm-sensors

[*] Enable loadable module support  --->  [CONFIG_MODULES]

Bus options (PCI etc.)  --->
  [*] PCI support [CONFIG_PCI]

   Should Enable loadable module support and Bus options be reversed 
to follow the order displayed with menuconfig?



Yes it should, I've corrected that :-)

Device Drivers  --->
  I2C support --->
    <*/M> I2C device interface [CONFIG_I2C_CHARDEV]
    I2C Hardware Bus support  --->
   (configure all of them as modules)
  <*/M> Hardware Monitoring support  ---> [CONFIG_HWMON]

   I believe Hardware Monitoring support has no options.  Should it be 
-*- Hardware Monitoring Support?  If so, could [CONFIG_HWMON] be deleted?

It does have many options, at least on my configuration.
-- 



UPower

General Setup --->
    [*] Namespaces support ---> [CONFIG_NAMESPACES]

   I believe Namespaces support has no options.  Should it be -*- 
Namespaces support?  If so, could [CONFIG_NAMESPACES] be deleted?


Namespaces support does have the following options:

--- Namespaces support

[*] UTS namespace

[*] TIME namespace

[*] IPC namespace

[*] User namespace

[*] PID Namespaces

[*] Network namespace


Note that the most important for UPower is the User namespace. Without 
that option, you'll get "ERROR 213/USER"


-- 



Cheese

Device Drivers  --->
  Multimedia support --->
    <*> Cameras/video grabbers support [CONFIG_MEDIA_CAMERA_SUPPORT]
    <*> Media USB Adapters  ---> [CONFIG_MEDIA_USB_SUPPORT]

  Should the above be:

Device Drivers  --->
   <*> Multimedia support  --->
  Media device types  --->
 <*> Cameras and video grabbers [CONFIG_MEDIA_CAMERA_SUPPORT]
  Media drivers  --->
    <*> Media USB Adapters ---> [CONFIG_MEDIA_USB_SUPPORT]

  The documentation implies nothing is to be built as a module.

I believe this has been corrected already
-- 



alsa-lib

Device Drivers --->
  <*/m> Sound card support ---> [CONFIG_SOUND]
    <*/m> Advanced Linux Sound Architecture ---> [CONFIG_SND]

   Should the <*/m>'s above be <*/M> for consistency with the 
documentation?

Ken got this :-)
-- 



cryptsetup

Cryptographic API  --->
  <*/M> XTS support [CONFIG_CRYPTO_XTS]
  <*/M> SHA224 and SHA256 digest algorithm [CONFIG_CRYPTO_SHA256]

   Should Cryptographic API  ---> be -*- Cryptographic API --->?

   I believe SHA224 and SHA256 digest algorithm has no options Should 
the line be deleted?
No it shouldn't, even if it's 

Re: [blfs-support] nss-3.50 & nss-3.55

[Douglas R. Reno via blfs-support]

On 12/2/20 5:59 AM, Fosca via blfs-support wrote:



I have just been working on BLFS and came across a slight hitch 
regarding nss-3.50 & nss-3.55 in 9.1 and 10.0 respectively.


So in 9.1 - 
http://www.linuxfromscratch.org/blfs/view/9.1/postlfs/nss.html - we 
find "The unit tests were run during the build."


Whereas in 10.0 - 
http://www.linuxfromscratch.org/blfs/view/10.0/postlfs/nss.html - we 
find :


To run the tests, execute the following commands:

cd tests &&
HOST=localhost DOMSUF=localdomain ./all.sh &&
cd ../

The previous "make BUILD_OPT=1  . . . command sequence reads the same 
for both 9.1 and 10.0.


Hence why the test in 10.0 ?

The point is that I had that test fail on me.
The screen went into a loop with the last line reading as follows:

HOSTNAME=localhost.localdomain
tstclnt:error looking up host: PR_DIRECTORY_LOOKUP_ERROR: A directory 
lookkup on a network address has failed



Can you make sure that you have the following line in /etc/hosts:

127.0.0.1 localhost.localdomain localhost



And a few lines up from there we have:
Trying to connect to selfserv at Wed ..AEDT

After crashing out, I rebooted in and continued on with cd ../dist in 
root.


Are your running in chroot? I don't think those tests have been run on a 
system in chroot.

Just thought I'd let you all know about this glitch.

Cheers  Fosca




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

Re: [blfs-support] libsoup will not build with sysprof

[Douglas R. Reno via blfs-support]

On 12/1/20 1:08 PM, Ken Moffat via blfs-support wrote:

On Tue, Dec 01, 2020 at 09:27:32AM -0600, Douglas R. Reno via blfs-support 
wrote:

Ah, I missed that (rebuilt meson, retried libsoup).

I'll upload the patch to patches, but I really don't think we need
to recommend sysprof for libsoup.

ĸen

Xi and I were the ones who found the issue. If you don't have sysprof
installed, on our systems, libsoup downloaded a git copy of
libsysprof-capture-4. Turning sysprof off is an option of course, but it
does remove some functionality and it remains to be seen (I guess I'll see
here in a day or two since I'm doing a full rebuild for systemd-247) what
having that functionality removed actually does...


I'm vaguely interested in what showed up during the download (if
details are available).

In theory the choice for sysprof (in libsoup) is auto, so I would
expect it to be disabled if sysprof is not found, but obviously my
expectations and what actually happens may differ.

However, if it does download a git copy and you therefore want to
use system sysprof then meson will need to be patched until the next
meson release comes out.


Hi Ken,

I just moved /usr/lib/libsysprof-capture-4.a and 
/usr/lib/pkgconfig/sysprof-capture-4.pc out of the way so I can test 
this. Here's the output:


renodr [ /sources ]$ sh SCRIPTS/libsoup-2.72.0-update.sh
Making libsoup-2.72.0
Tue Dec  1 02:06:48 PM CST 2020
patching file tests/ssl-test.c
Initialized empty Git repository in 
/sources/libsoup-2.72.0/libsoup-2.72.0/subprojects/sysprof/.git/

From https://gitlab.gnome.org/GNOME/sysprof
 * branch    1bb0eb7798f6a88667681229dde415ed663b1053 -> FETCH_HEAD
Note: switching to '1bb0eb7798f6a88667681229dde415ed663b1053'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c 

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 1bb0eb7 Merge branch 'collector-libraries' into 'master'

[...]

Run-time dependency sysprof-capture-4 found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency sysprof-capture-4

|Executing subproject sysprof method meson
|
|Using 'PKG_CONFIG_PATH' from environment with value: 
'/opt/kf5/lib/pkgconfig:/opt/qt5/lib/pkgconfig'
|Using 'PKG_CONFIG_PATH' from environment with value: 
'/opt/kf5/lib/pkgconfig:/opt/qt5/lib/pkgconfig'

|Project name: sysprof
|Project version: 3.37.1
|C compiler for the host machine: cc (gcc 10.2.0 "cc (GCC) 10.2.0")
|C linker for the host machine: cc ld.bfd 2.35
|Compiler for C supports arguments -fvisibility=hidden: YES
|Has header "execinfo.h" : YES
|Checking for function "strlcpy" : NO
|Run-time dependency libunwind-generic found: NO (tried pkgconfig and cmake)
|Checking whether type "struct perf_event_attr" has member "use_clockid" 
: YES

|Checking whether type "struct perf_event_attr" has member "clockid" : YES
|Compiler for C supports arguments -Wcast-align: YES
|Compiler for C supports arguments -Wdeclaration-after-statement: YES 
(cached)

|Compiler for C supports arguments -Wformat-nonliteral: YES
|Compiler for C supports arguments -Wformat-security: YES
|Compiler for C supports arguments -Wmissing-include-dirs: YES (cached)
|Compiler for C supports arguments -Wnested-externs: YES
|Compiler for C supports arguments -Wno-missing-field-initializers 
-Wmissing-field-initializers: YES

|Compiler for C supports arguments -Wno-sign-compare -Wsign-compare: YES
|Compiler for C supports arguments -Wno-unused-parameter 
-Wunused-parameter: YES
|Compiler for C supports arguments -Wno-cast-function-type 
-Wcast-function-type: YES

|Compiler for C supports arguments -Wpointer-arith: YES (cached)
|Compiler for C supports arguments -Wredundant-decls: YES
|Compiler for C supports arguments -Wswitch-default: YES
|Compiler for C supports arguments -Wswitch-enum: YES
|Compiler for C supports arguments -Wuninitialized: YES
|Compiler for C supports arguments -Werror=format-security 
-Werror=format=2: YES

|Compiler for C supports arguments -Werror=empty-body: YES
|Compiler for C supports arguments 
-Werror=implicit-function-declaration: YES (cached)

|Compiler for C supports arguments -Werror=incompatible-pointer-types: YES
|Compiler for C supports arguments -Werror=pointer-arith: YES
|Compiler for C supports arguments -Werror=init-self: YES
|Compiler for C supports arguments -Werror=int-conversion: YES
|Compiler for C supports arguments -Werror=misleading-indentation: YES
|Compiler for C supports arguments -Werror=missing-include-dirs: YES
|Compiler for C supports arguments -We

Re: [blfs-support] libsoup will not build with sysprof

[Douglas R. Reno via blfs-support]

On 11/30/20 5:30 PM, Ken Moffat via blfs-support wrote:

On Fri, Nov 27, 2020 at 09:14:40PM +, Ken Moffat via blfs-support wrote:

On Fri, Nov 27, 2020 at 09:46:39PM +0100, Pierre Labastie via blfs-support 
wrote:

On Fri, 2020-11-27 at 17:50 +, Ken Moffat via blfs-support wrote:

On Tue, Nov 10, 2020 at 06:34:21PM +0100, Christopher Gregory via
blfs-support wrote:

I notice that arch have dropped the need to make sysprof a
requirement.  I have not found any patch to date to actually get it
to work.  I am using the svn version of systemd blf from 2020-11-
01.  There has been no update to sysprof so I could not see if a
later version worked.


Starting a fresh sub-thread to reply to this, because we were
floundering.  I've just hit this, and apart from Christopher's post
google found
https://github.com/mesonbuild/meson/issues/7929

Seems to be a problem with meson-0.56.0, apparently will be fixed
with 0.56.1 by
https://github.com/mesonbuild/meson/commit/2b923f532c3e16687910fecb09cedb80a76597cf.diff
but that didn't make any difference for me.

Just to be sure:  it is not enough to just patch meson and recompile
libsoup. Sysprof has to be recompiled to after the change to meson: the
problem is in the .pc file for sysprof (-pthread not present in the
"public" part of the .pc file).


Ah, I missed that (rebuilt meson, retried libsoup).

I'll upload the patch to patches, but I really don't think we need
to recommend sysprof for libsoup.

ĸen


Xi and I were the ones who found the issue. If you don't have sysprof 
installed, on our systems, libsoup downloaded a git copy of 
libsysprof-capture-4. Turning sysprof off is an option of course, but it 
does remove some functionality and it remains to be seen (I guess I'll 
see here in a day or two since I'm doing a full rebuild for systemd-247) 
what having that functionality removed actually does...


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

Re: [blfs-support] Installation of the kernel systemd documentation - LFS 10.0/development

[Douglas R. Reno via blfs-support]

On 11/11/20 5:42 PM, rhubarbpieguy--- via blfs-support wrote:


General setup -->

   [*] Control Group support [CONFIG_CGROUPS]
   [ ] Enable deprecated sysfs features to support old userspace tools 
[CONFIG_SYSFS_DEPRECATED]
   [*] Configure standard kernel features (expert users) 
[CONFIG_EXPERT] --->

  [*] open by fhandle syscalls [CONFIG_FHANDLE]
   [ ] Auditing support [CONFIG_AUDIT]

Would it make sense to move [ ] Auditing support [CONFIG_AUDIT] to the 
top of the General setup options?  That appears to be the order shown 
with menuconfig.



Yes it would! Thank you for reporting this, I moved it over.
- 



File systems  --->
   [*] Inotify support for userspace [CONFIG_INOTIFY_USER]
   <*> Kernel automounter support (supports v3, v4, and v5) 
[CONFIG_AUTOFS_FS]


Kernel automounter support (supports v3, v4, and v5) now appears hard 
coded with no option available.  Could/should the line be deleted?


Thank you again for reporting these both! This line should be deleted as 
well as there is no reason to keep it around if the option is unable to 
be set. If you come across any other issues, please be sure to report them.


Fixed at r12059

- Doug

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

Re: [blfs-support] Rebuilding gst-plugins-base after installing Qt

[Douglas R. Reno via blfs-support]

On 10/27/20 8:48 PM, Ken Moffat via blfs-support wrote:

On Tue, Oct 27, 2020 at 10:00:15PM +, Ken Moffat via blfs-support wrote:

(Cc: to support if I remember, in case anyone else hits this)

Starting to upgrade my systems for whatever has caused today's
gstreamer releases.  Most are still running 9.1 with 1.16.2.
Normally I build gstreamer well before qt, but trying to upgrade has
changed that.

In gst-plugins-base it finds all the Qt items it tests for, but then
fails:


(etc)

On one of my 9.1 systems I had installed OpenEXR in February (a
dependency of blender).  On that system gst-plugins-bad-0.16.3 gave
some warnings about a missing include direcotry for OpenEXR
(include/OpenEXR) - presumably the pkgconfig file (for 2.4.1) was
incorrect and not pointing to the prefix (/usr), then it failed to
find a specific header which indeed was not installed by that
version.

The workaround is to hide the pc file during the build, although a
better workaround is probably not to build these packages in the
first place.

ĸen


Hi Ken,

I know you've probably already tried this, but can you try doing an 
'ldconfig' and logging in and out? I experienced this issue a few weeks 
ago, and that's what I did to solve it. I have no idea why it happened 
though or if that was even the true solution unfortunately.


- Doug

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

[blfs-support] glib2 and European Daylight Savings Time

[Douglas R. Reno via blfs-support]

Good evening,

Earlier today it was discovered that there are complications with the 
combination of tzdata2020b and glib2-2.66.2 that result in invalid times 
after European Daylight Savings Time ends on October 25th, 2020. This 
update should make it into the next render of the book as I just 
submitted it.


I'm writing this email to urge everyone who has glib2 installed (2.64.x 
or 2.66.x) to update to 2.66.2 if you have tzdata2020b or later 
installed, since it provides fixes for that problem as well as one that 
affects systems in the rest of the world (invalid timezone maps when 
using GNOME Control Center). From the upstream announcement this morning:


News


* Important and time-critical fix to DST transitions which will happen in Europe
  on 2020-10-25 on distributions which use the ‘slim’ tzdata format (which is
  now the default in tzdata/tzcode 2020b) (work by Claudi M., LRN) (#2224)

* Further timezone handling changes to restore support for changing the timezone
  when `/etc/localtime/` changes (work by António Fernandes, Sebastian Keller) 
(#2204)

A couple of other relevant changes from the changelog:

 - !1705 Backport !1683 “Fix the 6-days-until-the-end-of-the-month bug” to 
glib-2-66
 - #2224 top bar time is incorrect, timezone map in control center is broken

If you have tzdata2020b and live in a timezone in Europe where DST takes 
place, please update to glib2-2.66.2 to ensure that your DST transition 
occurs smoothly.


Thank you,

- Doug

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

Re: [blfs-support] Issues building gdk-pixbuf-2.40.0

[Douglas R. Reno via blfs-support]

On 10/14/20 10:50 PM, DJ Lucas - LFS via blfs-support wrote:
Being that nobody is reporting it, I'm guessing not, but I'll ask 
anyway. Has anybody had issues building gkd-pixbuf-2.40.0? From a 
related bug report, it looks like some missing dependency elsewhere. 
It really doesn't matter much as libpng is runtime, but the tests are 
unable to be compiled here:


Message:
GDK-Pixbuf 2.40.0
==
           prefix: /usr
           libdir: /usr/lib
          datadir: /usr/share
       libexecdir: /usr/libexec

  enabled loaders: png jpeg tiff

    documentation: false
        man pages: true
    introspection: true
              x11: true
  installed tests: true
      relocatable: false

Build targets in project: 86



[151/176] Generating loaders.cache with a meson_exe.py custom command
[152/176] Linking target thumbnailer/gdk-pixbuf-print-mime-types
[153/176] Linking target tests/pixbuf-read
[154/176] Generating resources.c with a custom command
failed to load 
"/home/pkguser/Main/gdk-pixbuf/src/gdk-pixbuf-2.40.0/tests/icc-profile.png": 
Couldn?t recognize the image file format for file 
?/home/pkguser/Main/gdk-pixbuf/src/gdk-pixbuf-2.40.0/tests/icc-profile.png?

../tests/resources.gresource.xml: Child process exited with code 1.
[155/176] Compiling C object 
contrib/gdk-pixbuf-xlib/libgdk_pixbuf_xlib-2.0.so.0.4000.0.p/gdk-pixbuf-xlibrgb.c.o

[156/176] Generating resources.h with a custom command
failed to load 
"/home/pkguser/Main/gdk-pixbuf/src/gdk-pixbuf-2.40.0/tests/icc-profile.png": 
Couldn?t recognize the image file format for file 
?/home/pkguser/Main/gdk-pixbuf/src/gdk-pixbuf-2.40.0/tests/icc-profile.png?

../tests/resources.gresource.xml: Child process exited with code 1.

Here may be a partial fix, but I don't entirely understand the 
comments in the bug report, looks like something misisng in 
gobject-introspection?

https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/123
​​
Patch is here:
​https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/commit/7f0b214ad921c0ad00ff4ef57b531a6f18f7ccc9

I simply worked around it by killing off the tests with a more direct 
method: sed "/  subdir('tests')/d" -i meson.build

May be an entirely me issue, but something is off. Any ideas?

Thanks.

--DJ

I don't have any ideas other than it just built fine for me. You did 
have libpng installed, right? :)


The build was complete for me with gobject-introspection-1.66.1 and 
glib-2.66.1. I did verify that I had the proper versions of all 
dependencies installed as well.


- Doug

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

[blfs-support] ZeroLogon vulnerability - Samba is affected and patched

[Douglas R. Reno via blfs-support]

Good afternoon,


On September 14th, 2020, Secura unveiled a vulnerability in the Windows 
NetLogon protocol, dubbed "ZeroLogon". The vulnerability is described as 
follows in the description at NIST.gov [1]:


"An elevation of privilege vulnerability exists when an attacker 
establishes a vulnerable Netlogon secure channel connection to a domain 
controller, using the Netlogon Remote Protocol (MS-NRPC), aka 'Netlogon 
Elevation of Privilege Vulnerability'."


Since this is a protocol level vulnerability in the NETLOGON protocol, 
Samba is also affected [3]. While our configuration is not directly 
affected for the File and Print server side, additional configuration 
changes may need to be made in order to continue to talk to domain 
controllers on a network. If you're running Samba in a corporate 
environment, this affects you the most. However, changes are being made 
on the client side as well to force secure connections by default in 
Windows, and this version of Samba also implements support for that 
modification of the protocol. The Samba developers offer advice on this 
in [5].


Due to the severity of this vulnerability (scores 10.0 on a CVSSv3 
scale), it's recommended that you update to Samba-4.12.7 as soon as 
possible, both in order to protect your system if you are running the 
File Server component (additional checks are put in place, and a 
proof-of-concept exploit is available [6]), and to allow the client to 
continue function if you're connecting to a Windows-based server for 
file shares. If you'd rather continue to use 4.12.6, a patch is 
available from the Samba team at [4].


In terms of build instructions, there are no changes required. Important 
statistics include:


Download URL: https://www.samba.org/ftp/samba/stable/samba-4.12.7.tar.gz

MD5SUM: 9f61a0ef23942179daad637ea84b7f37


Also, please note that ZeroLogon has a test in the quicktest suite of 
Samba now. Here's an additional email from Samba's security team [7] 
which provides further guidance and information. The bug report can be 
found at [8]. The update to Samba-4.12.7 will appear in the next render 
of the book, and an errata entry has been published.



Thank you,


Douglas R. Reno


LINKS:

[1]: NVD - CVE-2020-1472 [https://nvd.nist.gov/vuln/detail/CVE-2020-1472]

[2]: CVE-2020-1472 | Netlogon Elevation of Privilege Vulnerability 
[https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1472]


[3]: Samba 4.12.7 - Release Notes 
[https://www.samba.org/samba/history/samba-4.12.7.html]


[4]: 
https://download.samba.org/pub/samba/patches/samba-4.12.6-4.12.7.diffs.gz


[5]: Samba - Security Announcement Archive 
[https://www.samba.org/samba/security/CVE-2020-1472.html]


[6]: Zerologon Proof Of Concept = Packet Storm 
[https://packetstormsecurity.com/files/159190/Zerologon-Proof-Of-Concept.html]


[7]: oss-security - Samba and CVE-2020-1472 ("Zerologon") 
[https://www.openwall.com/lists/oss-security/2020/09/17/2]


[8]: 14497 - (CVE-2020-1472)[CVE-2020-1472][SECURITY] Samba impact of 
"ZeroLogon" [https://bugzilla.samba.org/show_bug.cgi?id=14497]


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

Re: [blfs-support] WebkitGTK compilation problem

[Douglas R. Reno via blfs-support]

On 9/9/20 10:05 AM, filbar--- via blfs-support wrote:

Hello,
I have problem with compiling webkitgtk:
--
[1722/4623] Building CXX object 
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/SymbolTable_autogen.cpp.o
FAILED: 
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/SymbolTable_autogen.cpp.o
/usr/bin/c++ -DANGLE_ENABLE_ESSL -DANGLE_ENABLE_GLSL -DBUILDING_GTK__=1 -DBUILDING_WITH_CMAKE=1 
-DEGL_EGL_PROTOTYPES=0 -DGETTEXT_PACKAGE=\"WebKit2GTK-4.0\" -DGL_GLES_PROTOTYPES=0 
-DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED -DLIBANGLE_IMPLEMENTATION -DSVN_REVISION=\"tarball\" 
-DWEBKITGTK_API_VERSION_STRING=\"4.0\" -I../Source/ThirdParty/ANGLE/include 
-I../Source/ThirdParty/ANGLE/include/KHR -I../Source/ThirdParty/ANGLE/src 
-I../Source/ThirdParty/ANGLE/src/common/third_party/base -I../Source/ThirdParty/ANGLE/third_party/zlib/google 
-ISource/ThirdParty/ANGLE/include -fdiagnostics-color=always -Wextra -Wall -Wno-expansion-to-defined 
-Wno-noexcept-type -Wno-psabi -Wno-maybe-uninitialized -Wwrite-strings -Wundef -Wpointer-arith 
-Wmissing-format-attribute -Wformat-security -Wcast-align  -fno-strict-aliasing -fno-exceptions -fno-rtti -O3 
-DNDEBUG -fPIC -Wno-cast-align -Wno-deprecated-copy -Wno-suggest-attribute=format -Wno-type-limits -Wno-undef 
-Wno-unused-parameter -std=c++17 -MD -MT
  Source/T
  
hirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/SymbolTable_autogen.cpp.o
 -MF 
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/SymbolTable_autogen.cpp.o.d
 -o 
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/SymbolTable_autogen.cpp.o
 -c ../Source/ThirdParty/ANGLE/src/compiler/translator/SymbolTable_autogen.cpp
../Source/ThirdParty/ANGLE/src/compiler/translator/SymbolTable_autogen.cpp:7484:50:
 error: 'isnan' is not a member of 'sh::BuiltInName'
  7484 | BuiltInName::isnan,
   |  ^
../Source/ThirdParty/ANGLE/src/compiler/translator/SymbolTable_autogen.cpp:7492:50:
 error: 'isnan' is not a member of 'sh::BuiltInName'
  7492 | BuiltInName::isnan,
   |  ^
../Source/ThirdParty/ANGLE/src/compiler/translator/SymbolTable_autogen.cpp:7500:50:
 error: 'isnan' is not a member of 'sh::BuiltInName'
  7500 | BuiltInName::isnan,
   |  ^
../Source/ThirdParty/ANGLE/src/compiler/translator/SymbolTable_autogen.cpp:7508:50:
 error: 'isnan' is not a member of 'sh::BuiltInName'
  7508 | BuiltInName::isnan,
   |  ^
../Source/ThirdParty/ANGLE/src/compiler/translator/SymbolTable_autogen.cpp:7516:50:
 error: 'isnan' is not a member of 'sh::BuiltInName'
  7516 | BuiltInName::isnan,
   |  ^
../Source/ThirdParty/ANGLE/src/compiler/translator/SymbolTable_autogen.cpp:7524:50:
 error: 'isnan' is not a member of 'sh::BuiltInName'
  7524 | BuiltInName::isnan,
   |  ^
../Source/ThirdParty/ANGLE/src/compiler/translator/SymbolTable_autogen.cpp:7532:50:
 error: 'isnan' is not a member of 'sh::BuiltInName'
  7532 | BuiltInName::isnan,
   |  ^
../Source/ThirdParty/ANGLE/src/compiler/translator/SymbolTable_autogen.cpp:7540:50:
 error: 'isnan' is not a member of 'sh::BuiltInName'
  7540 | BuiltInName::isnan,
   |  ^
../Source/ThirdParty/ANGLE/src/compiler/translator/SymbolTable_autogen.cpp:7548:50:
 error: 'isinf' is not a member of 'sh::BuiltInName'
  7548 | BuiltInName::isinf,
   |  ^
../Source/ThirdParty/ANGLE/src/compiler/translator/SymbolTable_autogen.cpp:7556:50:
 error: 'isinf' is not a member of 'sh::BuiltInName'
  7556 | BuiltInName::isinf,
   |  ^
../Source/ThirdParty/ANGLE/src/compiler/translator/SymbolTable_autogen.cpp:7564:50:
 error: 'isinf' is not a member of 'sh::BuiltInName'
  7564 | BuiltInName::isinf,
   |  ^
../Source/ThirdParty/ANGLE/src/compiler/translator/SymbolTable_autogen.cpp:7572:50:
 error: 'isinf' is not a member of 'sh::BuiltInName'
  7572 | BuiltInName::isinf,
   |  ^

Re: [blfs-support] 9.1-systemd: NSS-3.55 build fails

[Douglas R. Reno via blfs-support]

On 8/16/20 10:58 AM, Hans Malissa via blfs-support wrote:
On August 16, 2020 at 6:27 AM, Xi Ruoyao via blfs-support 
 wrote:

On 2020-08-16 02:27 +0100, Ken Moffat via blfs-support:

Playing with CFLAGS does not always do what you expect (it depends
on the individual packages as to whether you need to take special
action to force your own CFLAGS, and trying to detune released
packages seems like a bad idea. For the little it is worth, I did
some experiments just over a year ago with the aim of forcing my own
CFLAGS, CXXFLAGS and exploring some of the options. The results
(basically one run of each variation, but with some upgrades along
the way) were mostly inconclusive but somewhere in there are details
of what I had to do to the packages I build to get them to obey my
CFLAGS (or in some cases, to not use my optimization of -O2 or -O3)
because some default to -O3 but will detune to -O2 if you pass that,
and one some of my less-powerful machines I do generally use -O2.

But the problem was in nss. I do not regard that as a large
package, although it is a slow one when built using -j1.
AFAICS building nss-3.55 less than 300 MB which should be trivial.


Current version of NSS can be built with -jN. But I can tell that the 
test

suite just fails with -O3.


I followed the build with free from another terminal; the machine does 
indeed run out of memory (2GB on this system) during make.
I temporarily added some swap space (on an external hard drive), and 
the build succeeded - building NSS needs ~1GB of swap on top of my 2GB.
I'm planning to install NSS and remove the swap space again. Does the 
memory usage during the build have anything to do with memory usage 
during run-time? Will I be able to use NSS without the swap space?
By the way, the test suite (following the instructions on 
http://linuxfromscratch.org/blfs/view/systemd/postlfs/nss.html ) reports:


Tests summary:
--
Passed: 54674
Failed: 2442
Failed with core:   0
ASan failures:  0
Unknown status: 8
TinderboxPrint:Unknown: 8

Is it safe to proceed with 2442 failed tests?
Greetings,

Hans



You should be safe to proceed. The NSS test suite is quite buggy, and 
it's dependent on the contents of /etc/hosts as well as you passing 
"HOST=localhost DOMSUF=localdomain". On that note, make sure that you 
have the following line in /etc/hosts next time you run the tests:


127.0.0.1 localhost.localdomain localhost

I think that was changed after the 9.1 release cycle. That allows the 
NSS test suite to function properly.


You should be OK, NSS should work perfectly without swap space. I think 
you hit the memory ceiling when linking. You might want to invest in 
more RAM though in the future, if at all possible.



- Doug

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

Re: [blfs-support] Parole breakage on intel gpu.

[Douglas R. Reno via blfs-support]

On 8/9/20 6:35 PM, Ken Moffat via blfs-support wrote:

Two or three weeks ago I noticed a problem with parole on my latest
build on my haswell (LFS from 25th July, BLFS from the next day).
Whatever I try to view, the screen broken into horizontal stripes,
rather like venetian blinds but with a mix of colours not apparently
related to the video which should be visible.

On a machine using radeon (R600-series) video, parole works fine.

On my haswell, the following all work fine: ffplay, gst-play-1.0,
vlc.

Other things have, of course, got in the way, but I'm now ready to
document what has changed between working and broken versions, and
to ask for suggestions.

Looking back at previous builds on this machine, a build in May was
fine, the intermediate build in June showed the same problem.

The following packages, and versions, are common to both the good
and bad builds: running kernel 5.7.2, gcc-10.1.0, gstreamer-1.16.2,
fdk-aac-2.0.1, freetype-2.10.2, lame-3.100, libtheora-1.1.1,
libvorbis-1.3.7 (I upgraded older systems to that version),
libvpx-1.8.2, opus-1.3.1, x264-20200218, yasm-1.3.0, libvdpau-1.4,
libvdpau-va-gl-0.4.0, SDL2-2.0.12.

Looking at what had changed:

ffmpeg 4.2.2 on previous good systems, 4.3 and 4.3.1 on current.

libva-2.7.1 on last working system and on June non-working, 2.8.0 on
latest.

x265  3.3 on working, 3.4 on latest (now reverted to 3.3, symlink
fixed, gst-plugins-bad rebuilt)

intel-vaapi-driver 2.4.0 on good, 2.4.1 on latest, now reverted to
2.4.0.

xf86-video-intel 20200218 on good, 20200518 on latest, now reverted
to 20200218.

Before Bruce asks: I've used the same CFLAGS, CXXFLAGS throughout
these builds.

At this stage, this is just a request for suggestions, and a
question whether parole is working on anyone's current intel
machiens with integrated graphics ?

TIA

ĸen



I would say that I was able to get Parole working, but unfortunately I'm 
not able to:


[Current thread is 1 (Thread 0x7fb5315b2a00 (LWP 6876))]
(gdb) bt
#0  0x7fb5325379c2 in _XInternAtom
    (dpy=dpy@entry=0x7fb524003ee0, name=name@entry=0x438f75 
"_NET_WM_WINDOW_OPACITY_LOCKED", onlyIfExis
ts=onlyIfExists@entry=1, psig=psig@entry=0x7ffedf8e53b8, 
pidx=pidx@entry=0x7ffedf8e53b0, pn=pn@entry=0x

7ffedf8e53b4) at IntAtom.c:76
#1  0x7fb532537cfb in XInternAtom
    (dpy=dpy@entry=0x7fb524003ee0, name=name@entry=0x438f75 
"_NET_WM_WINDOW_OPACITY_LOCKED", onlyIfExis

ts=onlyIfExists@entry=1) at IntAtom.c:175
#2  0x0041f4f6 in parole_player_set_wm_opacity_hint 
(widget=0x1a28510 [GtkWindow])

    at parole-player.c:3071
#3  parole_player_init (player=0x1e98480 [ParolePlayer]) at 
parole-player.c:3734
#4  0x7fb5327d1571 in g_type_create_instance (type=) 
at ../gobject/gtype.c:1867

#5  0x7fb5327b8125 in g_object_new_internal
    (class=class@entry=0x1a77ed0, params=params@entry=0x7ffedf8e56a0, 
n_params=n_params@entry=1)

    at ../gobject/gobject.c:1937
#6  0x7fb5327b9bb4 in g_object_new_valist
    (object_type=, 
first_property_name=first_property_name@entry=0x438348 "client-id", v

ar_args=var_args@entry=0x7ffedf8e57e8) at ../gobject/gobject.c:2262
#7  0x7fb5327b9f0c in g_object_new
    (object_type=, 
first_property_name=first_property_name@entry=0x438348 "client-id")

    at ../gobject/gobject.c:1780
#8  0x0042127e in parole_player_new (client_id=0x0) at 
parole-player.c:3739
#9  0x004182af in main (argc=, argv=out>) at main.c:340

(gdb)

When I launch Parole, it crashes with a segmentation fault. This is on 
my Intel system, with Mesa-20.1.5, gst-*-1.16.2 of course, and 
libxfce4ui-4.14.1 with the rest of the stack.



I'm not sure what's causing this.

Ken, you are able to get it to start at least without a segfault, right?

I'll be building this on my elogind system later, will verify that it 
works there. Maybe it's something with the Iris driver. I'll research 
how to back down to i965 to see if I can fix it that way, but it's 
acting like its elsewhere.



- Doug

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

Re: [blfs-support] Problems with xine-lib on intel and amdgpu

[Douglas R. Reno via blfs-support]

On 8/9/20 6:57 PM, Ken Moffat via blfs-support wrote:

My second set of problems with video players ;)

I know that xine has always been rather fragile, partly related to
CFLAGS I use in oe of the dependencies - but a year ago those
detined flags made it mostly work.  With mov files and some of my
own mkv and (old: fmpeg-0.7!) mp4 conversions it has tended to
stutter (the picture jumps backwards).  On downloads they usually
play ok.

With my current (late July build) on my haswell, almost everything
that I try to play in xine crashes at startup.  On my machine using
radeon r600, my own mov files crash but everything else plays fine.
On my machien with amdgpu, the mov files from my camera similarly
crash, but everything else plays *until I use the xine control
slider to move forward through the video* (I don't wish to spend
hours looking at the files I'm using for testing).  As soon as I
touch the slider, xine crashes.

Looking back at older systems, that behaviour with amdgpu was
present in BLFS-9.1.

I've now reverted the string of packages I mentioned in my post
about parole (but again that has made no difference.

Summary: For me xine (technically xine-ui) crashes on intel igpu,
mostly works on radeon, works on amdgpu if I don't use the controls
and let it play through.

Again, I would be interested to hear of other people's successes.
Note that one or two files (one commercial mov, two commercial wmv)
do work with or without the reverts, other commercial wmv files
crash.

ĸen


Hi Ken,


I wanted to let you know that I was able to get Xine to play 
big_buck_bunny.mp4 properly on my Intel Skylake system (i5-6600k). I 
don't have any .mov files or any .wmv files sitting around here that I 
can use though, and I'm not sure converting would be much help here 
either. I did also scrub through the video using the slider, and watched 
it to completion.


I am using Mesa-20.1.5, with the Intel Iris driver that's built into 
Mesa (newer Intel systems won't be able to use i965 properly, especially 
once the Xe series of graphics cards comes out). FFMPEG-4.3.1 is in use 
too. The current driver loaded on my system is "iris". I did see an 
error regarding libvdpau_nvidia.so when starting though, but I don't 
think that's related. As far as I can tell, I do have the latest version 
of the related packages installed on this machine.


Here is my console output:

renodr [ /sources ]$ xine big_buck_bunny.mp4
This is xine (X11 gui) - a free video player 
v0.99.12. |

(c) 2000-2019 The xine Team.
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared 
object file: No such file or direct

ory
libva info: VA-API version 1.8.0
libva error: vaGetDriverNameByIndex() failed with unknown libva error, 
driver_name = (null)



Is it possible that it could be permissions? My intel system here is a 
systemd box. I am working on my elogind system at the moment to check on 
a couple things, and it has a Radeon in it. I'll let you know how that 
works, it's on my list to try next.



- Doug

--
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 ch.9 glib failure

[Douglas R. Reno via blfs-support]

On 7/24/20 4:13 PM, Alexey Orishko via blfs-support wrote:

On Fri, Jul 24, 2020 at 12:07 PM Alexey Orishko
 wrote:

I was trying to compile GLib-2.62.4 (BLFS 9.1) in chroot and ninja
command failed.

Finally, I found an old email, stating that "It would build if not
passing -Dman=true". It is the case, but it would be nice to have a
bit more detailed info on limitations.

/alexey


That's a very good point. We should consider saying something like 
"-Dman=true: This switch causes the build to create and install the 
package man pages. Note that this assumes that the stylesheets were 
installed as part of libxslt." This seems to be a common 
misunderstanding that we can address better in the future


Thank you for bringing it up Alexey!

- Doug

--
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 ch.9 glib failure

[Douglas R. Reno via blfs-support]

On 7/24/20 5:07 AM, Alexey Orishko via blfs-support wrote:

Hi guys,

I was trying to compile GLib-2.62.4 (BLFS 9.1) in chroot and ninja
command failed.
Last time I compiled glib/blfs-7.5 where ninja was not used. In the
current setup I have both recommended packages (libxslt-1.1.34 and
PCRE-8.44) compiled before building glib according to instruction. I
don't have networking in place, but it is not stated as a mandatory
requirement - should it be?

[1113/1157] Linking target tests/threadpool-test
[1114/1157] Compiling C object tests/thread-test.p/thread-test.c.o
[1115/1157] Generating gapplication-man with a custom command
FAILED: docs/reference/gio/gapplication.1
/usr/bin/xsltproc --nonet --stringparam man.output.quietly 1
--stringparam funcsynopsis.style ansi --stringparam
man.th.extra1.suppress 1 --stringparam man.authors.section.enabled 0
--stringparam man.copyright.section.enabled 0 -o
docs/reference/gio/gapplication.1
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
../docs/reference/gio/gapplication.xml
I/O error : Attempt to load network entity
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
warning: failed to load external entity
"http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl;
cannot parse 
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
[1116/1157] Generating gio-querymodules-man with a custom command
FAILED: docs/reference/gio/gio-querymodules.1
/usr/bin/xsltproc --nonet --stringparam man.output.quietly 1
--stringparam funcsynopsis.style ansi --stringparam
man.th.extra1.suppress 1 --stringparam man.authors.section.enabled 0
--stringparam man.copyright.section.enabled 0 -o
docs/reference/gio/gio-querymodules.1
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
../docs/reference/gio/gio-querymodules.xml
I/O error : Attempt to load network entity
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
warning: failed to load external entity
"http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl;
cannot parse 
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
[1117/1157] Compiling C object tests/module-test-plugin.p/module-test.c.o
[1118/1157] Linking target tests/module-test-library
[1119/1157] Linking target tests/thread-test
[1120/1157] Compiling C object tests/unicode-encoding.p/unicode-encoding.c.o
[1121/1157] Compiling C object tests/assert-msg-test.p/assert-msg-test.c.o
[1122/1157] Compiling C object tests/iochannel-test.p/iochannel-test.c.o
[1123/1157] Compiling C object tests/timeloop.p/timeloop.c.o
[1124/1157] Compiling C object tests/unicode-collate.p/unicode-collate.c.o
[1125/1157] Compiling C object tests/slice-color.p/slice-color.c.o
[1126/1157] Compiling C object tests/slice-color.p/memchunks.c.o
[1127/1157] Compiling C object tests/slice-test.p/memchunks.c.o
[1128/1157] Compiling C++ object tests/cxx-test.p/cxx-test.cpp.o
[1129/1157] Compiling C object tests/slice-test.p/slice-test.c.o
[1130/1157] Compiling C object
gio/tests/gdbus-test-codegen.p/meson-generated_.._gdbus-test-codegen-generated.c.o
[1131/1157] Compiling C object
gio/tests/gdbus-test-codegen-old.p/meson-generated_.._gdbus-test-codegen-generated.c.o
[1132/1157] Compiling C object tests/onceinit.p/onceinit.c.o
ninja: build stopped: subcommand failed.

Since I'm following glib compile steps as stated on its page, what am I missing?
At least, could I turn the building of the test suite off?

Regards,
Alexey



Hi Alexey,

This is probably because the XSLT/XML stylesheets were not installed. In 
the book, we say "Although it is not a direct dependency, many 
applications using libxslt will expect docbook-xml-4.5 and 
docbook-xsl-1.79.2 to be present.". If you install those stylesheets, 
you should be good to continue building glib


- Doug

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

Re: [blfs-support] OpenSSH

[Douglas R. Reno via blfs-support]

On 6/6/20 10:33 AM, Bruce Dubbs via blfs-support wrote:

On 6/6/20 5:01 AM, Greekforce1821 via blfs-support wrote:
The LFS/BLFS system is running on a Virtual Machine with bridged 
networking.
The output of the command ( ss-lt ) is the same one as you described 
earlier.

Ping the LFS using my ip address of my BLFS system?


Greek, bridged networking seems like the right option here (NAT mode, 
depending on the VM environment, would just forward the packets through 
your system using the same IP address that your host has).


However, as Bruce said below me, we need to know which VM software 
you're using (e.g. Bochs, QEMU, VirtualBox, VMWare, Hyper-V) to actually 
help further here.


However, as Ken mentioned before me - our default configuration does not 
allow you to login as root over SSH. That's been a bad security practice 
for as long as I can remember, and it allows a server to be compromised 
easier via brute-forcing attacks. Please make sure you have another user 
created on the system, and login using that user instead.




Please do not top post on this mailing list.

You will need to be able to ping both ways.  windows <--> LFS

On Windows, make sure you do "ping -4 IP.ADDRESS" or something similar 
to make sure that you're using IPv4 instead of V6-over-V4. Depending on 
your Windows Version (I'm assuming 8.1 or 10 since 7 is out of support), 
if you get any error output relating to the "-4" option, you can safely 
remove it. Enterprise versions of Windows generally are the only 
versions that have it, but it's still worth mentioning.



Since you are using a VM on windows, you need to configure the VM to 
route IP packets between the windows system and the LFS system.  I 
don't do windows so I can't help with that.


Perhaps someone else can help.  It would also help others to actually 
say which VM you are using.


  -- Bruce


Another thing I thought of:

If you have Virtualbox or VMWare, make sure the network adapters that 
are installed by the software are enabled (I don't recall where it is on 
Windows 10, but it should be under Network Connections in Windows 8.1). 
If they are, and you still can't ping in (do what we suggested further 
up on this email first), try disabling and re-enabling them. On Windows 
10, if they disappear out of the list once disabled (doesn't happen 
often, but I've seen it before), you can re-enable them via Device 
Manager (a shortcut for that: Open a Run dialog (Windows Key + R), and 
enter "devmgmt.msc" in the dialog box).


- Doug

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

Re: [blfs-support] Compiling systemd and dbus in chroot? - BLFS 9.1 systemd

[Douglas R. Reno via blfs-support]

On 4/3/20 11:26 AM, Douglas R. Reno via blfs-support wrote:


On 4/3/20 7:17 AM, rhubarbpieguy--- via blfs-support wrote:


Can/should systemd and dbus be compiled in chroot?  I assume so, 
partly due to the following in the dbus documentation:


Yes they can, and without those commands :) Those commands are only 
for if you're booted into the system, because you don't want to crash 
systemd by replacing it's libraries or dbus while it's running. I 
haven't encountered a problem with it, even with the system booted, in 
years though. I've never tried with a system booted into a GUI though.


   "If not in chroot, at this point, you should reload the systemd 
daemon, and reenter multi-user mode with the following commands (as 
the root user):"


   systemctl daemon-reload
   systemctl start multi-user.target

However, should a "If not in chroot" note also be applied to the 
Warning block "systemctl start rescue.target" command of the dbus 
documentation?


And should a chroot note be in the Warning block of the systemd 
documentation?  The Note block seems to indicate chroot isn't 
appropriate for the tests.  I didn't run the systemd tests when 
compiling systemd in chroot.


The last section I question in the systemd documentation is as follows:

   "At this point, you should reload the systemd daemon, and reenter 
multi-user mode with the following commands (as the root user):"


   systemctl daemon-reload
   systemctl start multi-user.target

Should a chroot note be added?

Another option might be a comprehensive note at the beginning of both 
packages stating something like "If in chroot, omit all systemctl 
commands for this package."


That is probably the best approach here I think. I'll have it in my 
next commit.
I built BLFS 9.1 systemd in chroot and it appears to be working well 
but I'm new to systemd.  The above are questions, not statements.
I normally build my system when it's booted (I build 10 packages 
before rebooting, primarily SSH, screen, sudo, and some network 
packages). I'm glad to hear that things worked well in chroot!



A correction:

We've decided to remove those instructions instead. They haven't been 
relevant for years now and none of us have encountered problems with it.


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

Re: [blfs-support] Compiling systemd and dbus in chroot? - BLFS 9.1 systemd

[Douglas R. Reno via blfs-support]

On 4/3/20 7:17 AM, rhubarbpieguy--- via blfs-support wrote:


Can/should systemd and dbus be compiled in chroot?  I assume so, 
partly due to the following in the dbus documentation:


Yes they can, and without those commands :) Those commands are only for 
if you're booted into the system, because you don't want to crash 
systemd by replacing it's libraries or dbus while it's running. I 
haven't encountered a problem with it, even with the system booted, in 
years though. I've never tried with a system booted into a GUI though.


   "If not in chroot, at this point, you should reload the systemd 
daemon, and reenter multi-user mode with the following commands (as 
the root user):"


   systemctl daemon-reload
   systemctl start multi-user.target

However, should a "If not in chroot" note also be applied to the 
Warning block "systemctl start rescue.target" command of the dbus 
documentation?


And should a chroot note be in the Warning block of the systemd 
documentation?  The Note block seems to indicate chroot isn't 
appropriate for the tests.  I didn't run the systemd tests when 
compiling systemd in chroot.


The last section I question in the systemd documentation is as follows:

   "At this point, you should reload the systemd daemon, and reenter 
multi-user mode with the following commands (as the root user):"


   systemctl daemon-reload
   systemctl start multi-user.target

Should a chroot note be added?

Another option might be a comprehensive note at the beginning of both 
packages stating something like "If in chroot, omit all systemctl 
commands for this package."


That is probably the best approach here I think. I'll have it in my next 
commit.
I built BLFS 9.1 systemd in chroot and it appears to be working well 
but I'm new to systemd.  The above are questions, not statements.
I normally build my system when it's booted (I build 10 packages before 
rebooting, primarily SSH, screen, sudo, and some network packages). I'm 
glad to hear that things worked well in chroot!

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

Re: [blfs-support] Configuring p11-kit

[Douglas R. Reno via blfs-support]

On 3/31/20 12:30 PM, Hans Malissa via blfs-support wrote:
I'm in the process of building p11-kit from BLFS 9.1. I have not 
installed NSS, and I will install make-ca as soon as p11-kit is done.
In the instructions 
(http://linuxfromscratch.org/blfs/view/stable-systemd/postlfs/p11-kit.html 
), in 
the section 'Configuring p11-kit' instructions are given in order to 
create a symlink to use the p11-kit trust module as a replacement for 
libnssckbi. The same symlink is explained on the NSS instructions 
(which I have not installed). Please clarify: does this apply for 
systems (i) which have NSS installed, (ii) which don't have NSS 
installed, or (iii) either way, independent on whether or not NSS is 
installed?

Thanks a lot,

Hans


Hi Hans,


As far as I know, these instructions only apply to systems that have NSS 
installed. You should be OK to continue without that symlink - although 
if/when you install NSS, you may want to use that symlink to allow 
NSS-aware applications to have additional access to certificates.



- Doug

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

Re: [blfs-support] Systemd-245 trial upgrade

[Douglas R. Reno via blfs-support]

On 3/11/20 5:42 AM, Tom Willhite via blfs-support wrote:
Hey just a post for those who might want this new version of systemd.  
  You will get a boot warning in journal about this dbus service file...
/lib/systemd/system/dbus (socket or service   I forget)   take out the 
/var from inside the file so it's just /run

not /var/run

Seems to work ok.   I think Doug does systemd so just a heads up here.



Thank you Archetech!


I've fixed it by adding "sed -i 's:/var/run:/run:' 
/lib/systemd/system/dbus.socket" to the D-Bus page since that's where it 
seems to fit best.



- Doug

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

Re: [blfs-support] libexif CVE-2019-9278

[Douglas R. Reno via blfs-support]

On 2/10/20 1:32 PM, Chris Gorman via blfs-support wrote:

Hello All,

Just found this CVE on bugtraq.  Thanks to the wonderful folks at
Debian security.  I've patched my libexif, but I thought others might
want to do so as well.  I am attaching the patch that fixes the
potential exploit, but you can find it at
https://github.com/libexif/libexif/commit/75aa73267fdb1e0ebfbc00369e7312bac43d0566.

Take care.

Chris


Hi Chris,

I backported the patch to 0.6.21 and added a patch to BLFS at r22652.

Thank you for reporting!

- Doug

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

Re: [blfs-support] Gimp-2.10.14 Pyton issue

[Douglas R. Reno via blfs-support]

On 1/30/20 9:57 AM, Ken Moffat via blfs-support wrote:

On Thu, Jan 30, 2020 at 10:59:39AM +, Stuart via blfs-support wrote:

I have built the latest BLFS Gimp-2.10.14 and I get the following issue on
startup.

Has anyone got any suggestions has to what may be wrong ?

Thanks Stuart

Traceback (most recent call last):
? File "/usr/lib/gimp/2.0/plug-ins/spyro_plus/spyro_plus.py", line 22, in

??? import gimpui
? File "/usr/lib/gimp/2.0/python/gimpui.py", line 33, in 
??? import gtk, gobject, gimp, gimpcolor
? File "/usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 40,
in 
??? from gtk import _gtk
? File 
"/usr/lib/python3.8/site-packages/pycairo-1.18.2-py3.8-linux-x86_64.egg/cairo/__init__.py",
line 1, in 
??? from ._cairo import *? # noqa: F401,F403
? File 
"/usr/lib/python3.8/site-packages/pycairo-1.18.2-py3.8-linux-x86_64.egg/cairo/_cairo.py",
line 7, in 
??? __bootstrap__()
? File 
"/usr/lib/python3.8/site-packages/pycairo-1.18.2-py3.8-linux-x86_64.egg/cairo/_cairo.py",
line 6, in __bootstrap__
??? imp.load_dynamic(__name__,__file__)
ImportError: 
/usr/lib/python3.8/site-packages/pycairo-1.18.2-py3.8-linux-x86_64.egg/cairo/_cairo.cpython-38-x86_64-linux-gnu.so:
undefined symbol: _Py_FalseStruct
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error


Google found various matches for things like this over the years.
The most recent was because someone had installed some gimp-fu
scripts for a much older version of gimp.  I assume that is not the
case for you ?

A rather older post on reddit suggested that an incompatible version
of cairo could cause this.  We have moved to a development version
of cairo, I forget the reason why but I suspect it might be the
cause.  I haven't made a new build with that version of cairo.

So, has anyone sucessfully run current gimp with current cairo ?

ĸen


I have successfully run the current GIMP with the latest Cairo, but I 
don't have the latest PyCairo installed. Also, it seems to be linking to 
python-3.8 on his system and not python-2.7, as far as I can tell based 
off the error text.


Stuart, can you make sure that you've built PyCairo with GTK+-2 support 
please? If using the existing instructions, make sure that you do this 
instead (using PyCairo-1.18.2):


python2 setup.py build

(as root)

python2 setup.py install --optimize=1

For reference, the latest PyCairo (1.19.0) has removed support for 
Python2 entirely, so there's a note on that page about building 
pycairo-1.18.2 for Python2 and pycairo-1.19.0 for Python3.


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

Re: [blfs-support] Problem Building alsa-tools-1.1.7 in BLFS

[Douglas R. Reno via blfs-support]

On 1/27/20 10:16 PM, Alan Feuerbacher via blfs-support wrote:

On 1/27/2020 7:44 PM, Douglas R. Reno via blfs-support wrote:

On 1/27/20 8:35 PM, Alan Feuerbacher via blfs-support wrote:

Building alsa-tools-1.1.7 in BLFS systemd development version:

The BLFS book has a script that builds a number of sub-programs. I 
got an

error with "make" for one of them, and tracked it down to a conversion
error in the sub-program hdspmixer. You get six errors like:

###
HDSPMixerWindow.cxx: In function ‘void readregisters_cb(void*)’:
HDSPMixerWindow.cxx:82:36: error: invalid conversion from ‘__u64*’ 
{aka ‘long long unsigned int*’} to ‘uint64_t*’ {aka ‘long unsigned 
int*’} [-fpermissive]

   82 | input_rms = hdspm_peak_rms.input_rms;
  | ~~~^
  |    |
  |    __u64* {aka long long 
unsigned int*}

. . .
###

I'm guessing that there is a problem here that needs to be fixed by
the alsa-tools people.

I got around the problem by changing the "for tool in *" script so 
that it
does not build the offending program "hdspmixer", but builds all the 
others.


I don't know if I'll need alsa-tools in the long run, but am building
it now because a number of other programs list it as a dependency.

Does this seem reasonable?

Alan


Hi Alan,

With alsa-lib-1.2.1.2 and alsa-tools-1.1.7, I can't produce this. Can 
you ensure that you used the sed in the book please? I remember 
adding one there to fix this problem. It's due to the Kernel API 
Headers being incompatible with alsa-tools after being synced into 
the alsa-lib tree (as part of this, they removed the user definitions 
from the API by accident, and the sed is designed to fix it).


Just to make sure:

sed -i -e "/#include/i #define __user" \ hdspconf/src/*.cxx \ 
hdspmixer/src/*.cxx \ hdsploader/hdsploader.c


Should be what you're inputting.


Hi Doug,

Yes, I double-checked that sed; it's correct.

I also rebuilt alsa-lib and then alsa-tools. Same error.

And again, when I cd into the hdspmixer directory, and execute 
"./configure --prefix=/usr; make", I get that same error.



Hi Alan,

I've tracked this down to another Kernel API change causing problems. 
Can you try the following seds for hdspmixer?


sed -i '39 s/uint32_t/__u32/' hdspmixer/src/HDSPMixerWindow.cxx

sed -i '40 s/uint64_t/__u64/' hdspmixer/src/HDSPMixerWindow.cxx


Please do this after the other seds that are already on that page.

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

Re: [blfs-support] Problem Building alsa-tools-1.1.7 in BLFS

[Douglas R. Reno via blfs-support]

On 1/27/20 8:35 PM, Alan Feuerbacher via blfs-support wrote:

Building alsa-tools-1.1.7 in BLFS systemd development version:

The BLFS book has a script that builds a number of sub-programs. I got an
error with "make" for one of them, and tracked it down to a conversion
error in the sub-program hdspmixer. You get six errors like:

###
HDSPMixerWindow.cxx: In function ‘void readregisters_cb(void*)’:
HDSPMixerWindow.cxx:82:36: error: invalid conversion from ‘__u64*’ 
{aka ‘long long unsigned int*’} to ‘uint64_t*’ {aka ‘long unsigned 
int*’} [-fpermissive]

   82 | input_rms = hdspm_peak_rms.input_rms;
  | ~~~^
  |    |
  |    __u64* {aka long long 
unsigned int*}

. . .
###

I'm guessing that there is a problem here that needs to be fixed by
the alsa-tools people.

I got around the problem by changing the "for tool in *" script so 
that it
does not build the offending program "hdspmixer", but builds all the 
others.


I don't know if I'll need alsa-tools in the long run, but am building
it now because a number of other programs list it as a dependency.

Does this seem reasonable?

Alan


Hi Alan,

With alsa-lib-1.2.1.2 and alsa-tools-1.1.7, I can't produce this. Can 
you ensure that you used the sed in the book please? I remember adding 
one there to fix this problem. It's due to the Kernel API Headers being 
incompatible with alsa-tools after being synced into the alsa-lib tree 
(as part of this, they removed the user definitions from the API by 
accident, and the sed is designed to fix it).


Just to make sure:

sed -i -e "/#include/i #define __user" \ hdspconf/src/*.cxx \ 
hdspmixer/src/*.cxx \ hdsploader/hdsploader.c


Should be what you're inputting.

Hopefully a new version of alsa-lib will fix this soon. :)

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

Re: [blfs-support] Instructions for installing libcap-2.31 with PAM

[Douglas R. Reno via blfs-support]

On 1/24/20 10:51 AM, Bruce Dubbs via blfs-support wrote:

On 1/24/20 10:38 AM, Douglas R. Reno via blfs-support wrote:


On 1/24/20 10:37 AM, Pierre Labastie via blfs-support wrote:

Le 24/01/2020 à 17:28, Chris Gorman via blfs-support a écrit :

Hello All,

I am trying to update my BLFS system to run the newest firefox and
thunderbird.  I have a working BLFS 9.0 installation and a working
with installing packages from the BLFS svn.

One of the packages I am trying to update is pulseaudio which calls
for libcap-2.31 with PAM.  When I go to build the libcap with pam tar
ball, I get an error message from the linker.

make testlink
make[1]: Entering directory 
'/home/chris/src/errata/libcap-2.31/pam_cap'

gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall
-Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline
-Wshadow -g  -o testlink test.c pam_cap.o -lpam -ldl
-L/home/chris/src/errata/libcap-2.31/pam_cap/../libcap -lcap
-L/home/chris/src/errata/libcap-2.31/pam_cap/../libcap
/usr/bin/ld: pam_cap.o: in function `set_capabilities':
/home/chris/src/errata/libcap-2.31/pam_cap/pam_cap.c:245: undefined
reference to `cap_max_bits'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:28: testlink] Error 1
make[1]: Leaving directory 
'/home/chris/src/errata/libcap-2.31/pam_cap'

make: *** [Makefile:7: all] Error 2
make: Leaving directory '/home/chris/src/errata/libcap-2.31/pam_cap'

I can get it built, however, without error by running make instead of
make -C pam_cap.  Has anyone else run into this error?  Do the build
instructions need to change for libcap-2.31?

As a side note, the instructions work properly if I try to rebuild
libcap-2.27.  Also the build instructions do produce the needed
libpam_cap.so, they just fail with the next build target.

I think the reason is that it is supposed that libcap (non pam) has 
been

installed in lfs...

Maybe we should add a note telling that, when upgrading to a new 
version, the
lfs instructions should be used (libcap-pam is automatically built 
if pam is

present).

Pierre
I agree, I think adding a note to BLFS would be a good idea, 
especially with how much more common upgrades to libcap are becoming


I also agree.  De we have a volunteer?

  -- Bruce


How does this sound?

    
  If you are upgrading libcap from a previous version, use the
  instructions in
  url="../../../../lfs/view/development/chapter06/libcap.html">LFS libcap 
page

  to upgrade libcap first.
    

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

Re: [blfs-support] Instructions for installing libcap-2.31 with PAM

[Douglas R. Reno via blfs-support]

On 1/24/20 10:37 AM, Pierre Labastie via blfs-support wrote:

Le 24/01/2020 à 17:28, Chris Gorman via blfs-support a écrit :

Hello All,

I am trying to update my BLFS system to run the newest firefox and
thunderbird.  I have a working BLFS 9.0 installation and a working
with installing packages from the BLFS svn.

One of the packages I am trying to update is pulseaudio which calls
for libcap-2.31 with PAM.  When I go to build the libcap with pam tar
ball, I get an error message from the linker.

make testlink
make[1]: Entering directory '/home/chris/src/errata/libcap-2.31/pam_cap'
gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall
-Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline
-Wshadow -g  -o testlink test.c pam_cap.o -lpam -ldl
-L/home/chris/src/errata/libcap-2.31/pam_cap/../libcap -lcap
-L/home/chris/src/errata/libcap-2.31/pam_cap/../libcap
/usr/bin/ld: pam_cap.o: in function `set_capabilities':
/home/chris/src/errata/libcap-2.31/pam_cap/pam_cap.c:245: undefined
reference to `cap_max_bits'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:28: testlink] Error 1
make[1]: Leaving directory '/home/chris/src/errata/libcap-2.31/pam_cap'
make: *** [Makefile:7: all] Error 2
make: Leaving directory '/home/chris/src/errata/libcap-2.31/pam_cap'

I can get it built, however, without error by running make instead of
make -C pam_cap.  Has anyone else run into this error?  Do the build
instructions need to change for libcap-2.31?

As a side note, the instructions work properly if I try to rebuild
libcap-2.27.  Also the build instructions do produce the needed
libpam_cap.so, they just fail with the next build target.


I think the reason is that it is supposed that libcap (non pam) has been
installed in lfs...

Maybe we should add a note telling that, when upgrading to a new version, the
lfs instructions should be used (libcap-pam is automatically built if pam is
present).

Pierre
I agree, I think adding a note to BLFS would be a good idea, especially 
with how much more common upgrades to libcap are becoming

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

Re: [blfs-support] xterm and Xorg legacy

[Douglas R. Reno via blfs-support]

On 1/23/20 1:23 PM, Eduardo Batalha via blfs-support wrote:

Hi,

I had to install the font-misc-misc legacy font package
in order to prevent xterm from crashing when changing
options with CTRL-MouseButton.
This font is not in the recommended legacy fonts at
the end of the X-org section.

Kind regards,
Ed


I can confirm this. Ctrl+Click in any Xterm session causes xterm to 
crash like so:


renodr [ ~/Documents/Sources and Scripts Backup ]$ xterm
Warning: Unable to load any usable ISO8859 font
Error: Aborting: no font found

I think we'll need to add font-misc-misc to the legacy fonts page to fix 
this.


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

Re: [blfs-support] GTK-doc Failures

[Douglas R. Reno via blfs-support]

On 1/22/20 8:42 PM, Alan Feuerbacher via blfs-support wrote:
In building several packages that allow making documents with the 
--enable-gtk-doc configure switch, I found that some succeed and 
others fail, apparently due to some bug in the gtk-doc build software. 
configure runs ok, but make fails with "/bin/sh: gtkdoc-mktmpl: 
command not found". This file is not built by the GTK-Doc-1.32 
package. So in some packages, make is looking for what I would guess 
is an obsolete program.


Success:
Cairo-1.17.2+f93fc72c03e
libidn-1.35

Failure:
GConf-3.2.6
libcanberra-0.30

I think there were a couple of others, but I won't try to find them 
for now.


Alan

Confirmed. I've attempted builds of GConf and libcanberra, both with 
"--enable-gtk-doc", and get the following error:


../../gconf/gconf-value.h:153:46: warning: 'GTime' is deprecated: Use 
'GDateTime' instead [-Wdeprecated-declarations]

  153 | GTime  mod_time);
  |  ^
  DOC   Rebuilding template files
/bin/sh: gtkdoc-mktmpl: command not found
make[3]: *** [Makefile:662: tmpl-build.stamp] Error 127
make[3]: Leaving directory '/sources/GConf-3.2.6/doc/gconf'
make[2]: *** [Makefile:496: all-recursive] Error 1
make[2]: Leaving directory '/sources/GConf-3.2.6/doc'
make[1]: *** [Makefile:539: all-recursive] Error 1
make[1]: Leaving directory '/sources/GConf-3.2.6'
make: *** [Makefile:422: all] Error 2

This seems to have been removed since August 11th of 2017 with the 
release of GTK-Doc 1.26 (implemented into BLFS at r19012)


I've updated the book accordingly at r22593.

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

Re: [blfs-support] Updated xterm-352 tarfile has problems

[Douglas R. Reno via blfs-support]

On 1/22/20 7:47 PM, Alan Feuerbacher via blfs-support wrote:
I'm going to post some emails detailing a few issues I've encountered 
building BLFS packages in the past several weeks. I believe some are 
real problems, others are probably the result of my ignorance of 
important things. Here we go:


I tried to build the updated xterm-352 in BLFS, but the
checksum for the tgz file did not match, and
"tar xf xterm-352.tgz" complained that this does not look
like a tar file. I checked the md5sum in the BLFS book
for this and it did not match.

I was able to find another download source:

https://fossies.org/linux/misc/xterm-352.tgz/

The checksum in the BLFS book matches with this file, and it
builds successfully. It works fine in X Windows.

Alan



Hi Alan,

I just downloaded it and extracted it to make sure that the link in the 
book worked. I didn't find any problems, and the MD5SUMs match. It was 
likely a transient problem upstream. Thank you for reporting though!


- Doug

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

Re: [blfs-support] Thunderbird Startup Error Message

[Douglas R. Reno via blfs-support]

On 1/22/20 7:37 PM, Alan Feuerbacher via blfs-support wrote:

On 1/22/20 6:10 PM, Alan Feuerbacher via blfs-support wrote:


On 1/22/20 5:28 PM, Douglas R. Reno via blfs-support wrote:


On 1/22/20 6:14 PM, Alan Feuerbacher via blfs-support wrote:

On 1/22/2020 4:25 PM, Bruce Dubbs via blfs-support wrote:

On 1/22/20 5:21 PM, Alan Feuerbacher via blfs-support wrote:

When I start up my just-built Thunderbird I get this message:

root [ ~ ]# console.log: WebExtensions: Loading packed extension 
from 
/root/.thunderbird/ortmmut8.default-default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi 

console.log: WebExtensions: Loading add-on preferences from 
/root/.thunderbird/ortmmut8.default-default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi 

console.log: WebExtensions: Firing profile-after-change listeners 
for {e2fda1a4-762b-4020-b5ad-a41df1933103}

[calBackendLoader] Using Thunderbird's builtin libical backend

(thunderbird:2253): libnotify-WARNING **: 14:10:04.156: Failed to 
connect to proxy


What should I do?


Don't run as root?

Alternatively remove  /root/.thunderbird/ or create a new user and 
try running as that user.


  -- Bruce

I ran as user lfs, but got a message I've seen when testing several 
programs:


#

Unable to init server: Could not connect: Connection refused

Error: cannot open display: :0

#

Then I removed /root/.thunderbird and ran Thunderbird as root. Same 
error message as before, except that when the program started up, 
it wanted me to configure it as a new user. So something changed.


Alan


Hi Alan,

Are you trying to run these programs in chroot? If you are, try 
running them on your LFS system when booted.


Hi Doug,

I'm running in my systemd LFS system. In fact, I've built all the 
dependencies for Firefox and Thunderbird in that system. I'm replying 
to this email in the new Thunderbird.




Also, are you running X as root (e.g. startx while root?) - if so, 
please run it as a normal user, as it's not recommended (primarily 
for security reasons) that you start/run X as root.



Yes, that's what I've been doing, not having known any better.

Now I've started up as myself rather than root. Now I get a similar 
but longer error message:


#

alan [ ~ ]$ thunderbird
console.log: WebExtensions: Loading packed extension from 
/home/alan/.thunderbird/zxc9f72n.default-default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi
console.log: WebExtensions: Loading add-on preferences from 
/home/alan/.thunderbird/zxc9f72n.default-default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi
console.log: WebExtensions: Firing profile-after-change listeners for 
{e2fda1a4-762b-4020-b5ad-a41df1933103}

[calBackendLoader] Using Thunderbird's builtin libical backend
console.warn: Lightning: Warning:  Using guessed timezone
  America/Denver (UTC-0700/-0600).
This ZoneInfo timezone seems to match the operating system timezone 
this year.

This ZoneInfo timezone was chosen based on the operating system timezone
identifier "/etc/localtime -> /usr/share/zoneinfo/America/Denver".
console.error: (new TypeError("allErrors is undefined", 
"chrome://messenger/content/accountcreation/emailWizard.js", 703))

client config xml = {"Autodiscover":{"Response":{"Account":{"AccountTy
console.error: "The config file XML does not contain an email account 
configuration."

client config xml = {"Autodiscover":{"Response":{"Account":{"AccountTy
console.error: "The config file XML does not contain an email account 
configuration."
console.error: (new TypeError("allErrors is undefined", 
"chrome://messenger/content/accountcreation/emailWizard.js", 703))
console.debug: "main/language-dictionaries 80 records loaded from 
JSON dump"
console.debug: "main/sites-classification 7 records loaded from JSON 
dump"


#

Alan

Now that I've configured Thunderbird for user alan, upon startup I get 
only the first three lines from the above:


##

alan [ ~ ]$ thunderbird
console.log: WebExtensions: Loading packed extension from 
/home/alan/.thunderbird/zxc9f72n.default-default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi
console.log: WebExtensions: Loading add-on preferences from 
/home/alan/.thunderbird/zxc9f72n.default-default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi
console.log: WebExtensions: Firing profile-after-change listeners for 
{e2fda1a4-762b-4020-b5ad-a41df1933103}

[calBackendLoader] Using Thunderbird's builtin libical backend

##

I just started the latest version on my development system and those 
messages appear to be normal.
This is using startx in the Linux console as user alan. X starts with 
the twm window manager, which so far as I can see, has very limited 
usefulness compared to others.


The only problem left, aside from the error m

Re: [blfs-support] Trouble Configuring JS-60.8.0

[Douglas R. Reno via blfs-support]

On 1/17/20 9:19 PM, Alan Feuerbacher via blfs-support wrote:
I'm trying to build JS-60.8.0 in BLFS systemd development version. The 
configure script immediately dies with the message:


NotImplementedError: /dev/urandom (or equivalent) not found

If I create an empty /dev/urandom file (touch /dev/urandom) I get:

RuntimeError: Failed to read %zi bytes from /dev/urandom

The only place in BLFS software where /dev/urandom appears is in 
BIND-9.14.9. So I installed that and again tried to configure 
JS-60.8.0, with the same error.


What to do?

Alan


Hi Alan,

If you're still on your Fedora host (in chroot), make sure that /dev and 
the virtual kernel filesystems are mounted. Also, if you're in chroot, do:


export SHELL=/bin/bash

(or /bin/sh would work too I think).

/dev/urandom should be part of the bind mount in chroot, or part of the 
actual devtmpfs when the system is booted in LFS.


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

Re: [blfs-support] In git-2.25.0 all test fail as normal user

[Douglas R. Reno via blfs-support]

On 1/15/20 4:09 PM, Alan Feuerbacher via blfs-support wrote:


On 1/15/2020 1:43 PM, Pierre Labastie via blfs-support wrote:

Le 15/01/2020 à 21:27, Alan Feuerbacher via blfs-support a écrit :
I just built the updated git-2.25.0 and ran the tests. The BLFS book 
says that
running them as a normal user should produce no failures, but I 
immediately

get this error:

cat: version: Permission denied

/bin/sh: GIT-BUILD-OPTIONS+: Permission denied

But if I run the tests as root, all tests pass.

I don't know if this is a problem.

Hmmm, Maybe you can try to figure out this one by yourself: first 
check who is
the owner of a "version" file, or GIT-BUILD-OPTIONS file (or file 
whose name
begin with version or GIT-BUILD-OPTIONS), explore your build tree, 
checking
for anything that could prevent a normal user to access the files, 
etc...


Pierre


In the build tree, there's a file "version" with owner "110493 5000" 
and permissions "-rw-r". This is the same owner as "configure". 
These are the only files not owned by "root root". If as user lfs I 
"cat version" I get the same error as above -- as expected, given the 
permissions for "other". If I cat some random file with owner "root 
root" and permissions "-rw-rw-r-", it works fine, as expected. If, as 
root, I "cat version" I get the expected "2.25.0". I don't know what 
to make of this.


What does owner "110493 5000" mean? Why would only two files have this 
odd ownership and why is there no read permission for "other"?


For GIT-BUILD-OPTIONS the owner is "root root" with permissions 
"-rw-r--r--". I would guess that, since bash is given this file to 
execute, and there is no "x" in the permissions, we get the 
"permission denied" error. But if this is part of the testing, why 
does whatever software that makes the build tree not add "x" to the 
permissions?


And of course, since the BLFS book specifically indicates that running 
the tests as a normal user is the way to go, why are the ownership and 
permissions of these files not such that a normal user can run the tests?


Alan


When developing the instructions, we assume that you're building as a 
normal user, and not as the root user. This is to follow the philosophy 
of UNIX Administration of only using your superpowers when necessary 
(see 
http://linuxfromscratch.org/blfs/view/systemd/introduction/notes-on-building.html 
). Seeing as you were able to get the tests to run as root though, you 
should be okay. We probably have that in there from a previous release 
where running the tests as root caused sporadic failures.


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

Re: [blfs-support] Error Running bash Download Script in Xorg Libraries

[Douglas R. Reno via blfs-support]

On 1/15/20 1:11 PM, Alan Feuerbacher via blfs-support wrote:


On 1/15/2020 12:06 PM, Douglas R. Reno via blfs-support wrote:


On 1/15/20 1:01 PM, Alan Feuerbacher via blfs-support wrote:
For about 4 hours I've been trying to execute the bash script in 
"Downloading Xorg Libraries" that downloads the needed files via 
wget, but keep getting this error:


Resolving www.x.org... failed: Temporary failure in name resolution.

I haven't seen this before. Any comments?

Alan


Hi Alan,


Are you using the systemd version or the sysv version? Can you check 
to make sure that your system has an IP address please?


On systemd, check that systemd-resolved is running by executing 
"systemctl status systemd-resolved". On both sides though, make sure 
/etc/resolv.conf is present and is filled in correctly (on systemd, 
resolved should take care of that automatically. It can't hurt to 
check though!). SysV just uses /etc/resolv.conf.



I'm running in chroot on the Fedora 31 host system, which is systemd.

Alan


Hi Alan,

I'm borrowing these commands from jhalfs since Pierre put these in a 
while back to allow DNS resolution while in chroot on systemd systems:


sudo mkdir -pv /mnt/lfs/run/systemd/resolve

sudo cp -v /etc/resolv.conf /mnt/lfs/run/systemd/resolve

This should set you up with DNS resolution in chroot.

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

Re: [blfs-support] Error Running bash Download Script in Xorg Libraries

[Douglas R. Reno via blfs-support]

On 1/15/20 1:01 PM, Alan Feuerbacher via blfs-support wrote:
For about 4 hours I've been trying to execute the bash script in 
"Downloading Xorg Libraries" that downloads the needed files via wget, 
but keep getting this error:


Resolving www.x.org... failed: Temporary failure in name resolution.

I haven't seen this before. Any comments?

Alan


Hi Alan,


Are you using the systemd version or the sysv version? Can you check to 
make sure that your system has an IP address please?


On systemd, check that systemd-resolved is running by executing 
"systemctl status systemd-resolved". On both sides though, make sure 
/etc/resolv.conf is present and is filled in correctly (on systemd, 
resolved should take care of that automatically. It can't hurt to check 
though!). SysV just uses /etc/resolv.conf.


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

Re: [blfs-support] Phonon-4.10.3: Cmake error: Could not find "Qt5LinguistToolsConfig.cmake"

[Douglas R. Reno via blfs-support]

On 2019-11-16 14:43, Trent via blfs-support wrote:

Phonenon-4.10.3 From this link

http://www.linuxfromscratch.org/blfs/view/stable-systemd/kde/phonon.html



Error displayed:

*

CMake Error at /usr/share/ECM/modules/ECMPoQmTools.cmake:144 
(find_package):
  Could not find a package configuration file provided by 
"Qt5LinguistTools"

  with any of the following names:

    Qt5LinguistToolsConfig.cmake
    qt5linguisttools-config.cmake

  Add the installation prefix of "Qt5LinguistTools" to 
CMAKE_PREFIX_PATH or

  set "Qt5LinguistTools_DIR" to a directory containing one of the above
  files.  If "Qt5LinguistTools" provides a separate development package 
or

  SDK, be sure it has been installed.
Call Stack (most recent call first):
  /usr/share/ECM/modules/ECMPoQmTools.cmake:234 
(ecm_process_po_files_as_qm)

  CMakeLists.txt:317 (ecm_install_po_files_as_qm)


-- Configuring incomplete, errors occurred!
See also "/usr/src/kde/phonon-4.10.3/build/CMakeFiles/CMakeOutput.log".

*


Doing a search,  I see the file it is looking for in:

/usr/src/kde/qt-everywhere-src-5.13.0/qttools/lib/cmake/Qt5LinguistTools/Qt5LinguistToolsConfig.cmake

/opt/qt-5.13.0/lib/cmake/Qt5LinguistTools/Qt5LinguistToolsConfig.cmake


Following the advice from the error,


I added in
-Qt5LinguistTools_DIR=/opt/qt-5.13.0/lib/cmake/Qt5LinguistTools like
so:


*

cmake -DCMAKE_INSTALL_PREFIX=/usr    \
-Qt5LinguistTools_DIR=/opt/qt-5.13.0/lib/cmake/Qt5LinguistTools \
           -DCMAKE_BUILD_TYPE=Release \
        -DPHONON_BUILD_PHONON4QT5=ON   \
        -Wno-dev .. &&
make

*

I am still getting the same result.

What is going on with this?


Thanks!


Hi Trent,

Can you try running:

source /etc/profile.d/qt5.sh
sudo /sbin/ldconfig

And then try building phonon again?
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Bluez test failure? BLFS 9.0

[Douglas R. Reno via blfs-support]

On 11/12/19 6:02 PM, rhubarbpieguy--- via blfs-support wrote:


Compiling Bluez with 'make test' fails with:

   ./test-driver line 107:   8971 
Aborted   "$@" > log_file 2>&1


   FAIL: unit/test-sdp

The process then locks.  What does the failure mean?  To that point 
the following pass:


   PASS: unit/test-eir
   PASS: unit/test-uuid
   PASS: unit/test-textfile
   PASS: unit/test-crc
   PASS: unit/test-crypto
   PASS: unit/test-ecc
   PASS: unit/test-ringbuf
   PASS: unit/test-queue
   PASS: unit/test-mgmt
   PASS: unit/test-uhid



Hello,

Please make sure you have the following enabled in your kernel - I 
encountered that with the last update that I did to that package:


CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
CONFIG_CRYPTO_USER_API_RNG=y
CONFIG_CRYPTO_USER_API_AEAD=y


That should allow it to surpass the test suite hangup

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

Re: [blfs-support] Issue with Admin Access in GNOME Desktop

[Douglas R. Reno via blfs-support]

On 11/11/19 3:57 PM, Jared Stevens via blfs-support wrote:


> I am not entirely sure what you are trying to do.  When you
first install gdm in blfs, you create a user "gdm" with group
"gdm" this is what it is run as.  In all my years of using gnome,
and it is around 30 years, I have never heard of having a separate
administrator account for gdm.
>
> All that the main stream distros like debian and fedora do, for
their "administrator" accounts is to add the user to the wheel and
in the case of fedora to the sudoers file.  In the past, the do
gooders that developed gdm/gnome and also KDE dictated that root
login was not allowed, despite the fact that they do not own the
hardware, and there fore have absolutely no right to push this
down peoples throats.  This may have been loosened up a little,
because in the case of kde they hard code it into the code base,
and check if the id is set to root, and then would not allow you
to login.

As is the case when doing a quick search, a better result is
found, this time on gnome's wiki:

https://help.gnome.org/admin/gdm/stable/security.html.en


Hi Christopher,

I may use your first link as a possible workaround, but just to 
reiterate I am not trying to login to GNOME using root. I am trying to 
give my standard account "user" the ability to edit the settings 
within GNOME Control Center and elsewhere within GDM.


On my Ubuntu system, the Authentication window will pop up (i.e. when 
accessing GParted) and my user account password will allow access. I 
assume this is because said user is part of the "sudo" group. 
Furthermore, my user account is listed as "Administrator" in GNOME 
Control Center and I am able to click the "unlock" button to make 
changes to user accounts (i.e. change an account from "Standard" to 
"Administrator). I never had to manually change this user in GNOME 
from standard to admin because it was already Adminstrator from the 
get-go.


In contrast, my LFS system has root login disabled by default (as it 
should for security reasons), and I can login no problem using my 
"user" standard account I created during the build. This user is added 
to the "wheel" group and the Sudo package is installed to allow root 
access through the wheel group.


Furthermore, I can run commands in the terminal application using 
"sudo" with my regular user. However, I cannot change any settings in 
GNOME Control Center (such as editing user accounts) by clicking the 
"unlock" button or open certain programs because the popup 
Authentication window in GDM refuses my user's password and the root 
account password. I understand why root's password wouldn't work 
seeing as I have disabled root login. And I assume that I cannot enter 
my user password in the Authentication window because the user account 
is listed as "Standard" in GNOME Control Center instead of 
"Administrator."


So I am trying to figure out how to set the necessary permissions so 
that my created user account is able to authenticate in the popup 
window in GNOME since apparently being in the "wheel" group is not 
enough besides having to allow root login in GNOME just to change the 
user account from "Standard" to "Administrator" in GNOME Control 
Center. It seems likely that I missed a step or made an error possibly 
when setting up PAM with GDM or something, but I am not sure what that 
would be.


Thanks,

Jared Stevens


Hi Jared,

In AccountsService, we setup a rule for administrator access. I'm not 
sure this is related, but ensure that your account is in the 'adm' group 
and then logout and log back into GNOME.


- Doug

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

Re: [blfs-support] LLVM-8.0.1 not building

[Douglas R. Reno via blfs-support]

On 10/29/19 12:51 AM, Trent via blfs-support wrote:


On 10/28/19 11:31 PM, Douglas R. Reno via blfs-support wrote:


On 10/28/19 11:17 PM, Trent via blfs-support wrote:


On 10/28/19 8:53 PM, Ken Moffat via blfs-support wrote:
On Mon, Oct 28, 2019 at 07:47:50PM -0500, Trent via blfs-support 
wrote:

On 10/28/19 5:25 PM, Ed Batalha wrote:

Trent via blfs-support wrote:


On 10/28/19 3:41 PM, Bruce Dubbs via blfs-support wrote:

On 10/28/19 3:02 PM, Trent via blfs-support wrote:
[8/1352] Building CXX object 
tools/clang/lib/ASTMatch...CMakeFiles/clangDynamicASTMatchers.dir/Registry.cpp.o 



FAILED: 
tools/clang/lib/ASTMatchers/Dynamic/CMakeFiles/clangDynamicASTMatchers.dir/Registry.cpp.o


/usr/bin/g++  -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Itools/clang/lib/ASTMatchers/Dynamic
-I../tools/clang/lib/ASTMatchers/Dynamic
-I../tools/clang/include -Itools/clang/include
-I/usr/include/libxml2 -Iinclude -I../include -fPIC
-fvisibility-inlines-hidden -Werror=date-time -std=c++11
-Wall -Wextra -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wno-missing-field-initializers -pedantic
-Wno-long-long -Wimplicit-fallthrough
-Wno-maybe-uninitialized -Wno-class-memaccess
-Wno-noexcept-type -Wdelete-non-virtual-dtor
-Wno-comment -fdiagnostics-color -ffunction-sections
-fdata-sections -fno-common -Woverloaded-virtual
-fno-strict-aliasing -O3 -DNDEBUG-fno-exceptions -MD -MT 
tools/clang/lib/ASTMatchers/Dynamic/CMakeFiles/clangDynamicASTMatchers.dir/Registry.cpp.o
-MF 
tools/clang/lib/ASTMatchers/Dynamic/CMakeFiles/clangDynamicASTMatchers.dir/Registry.cpp.o.d
-o 
tools/clang/lib/ASTMatchers/Dynamic/CMakeFiles/clangDynamicASTMatchers.dir/Registry.cpp.o

-c ../tools/clang/lib/ASTMatchers/Dynamic/Registry.cpp
g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.

A signal that kills the program usually is not releated to a failed
compilation - those more usually Error although with cmake anythong
is possible.  I associate compilations which are killed by a signal
with segmentation faults (hardware problems).


[13/1352] Building CXX object
tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaExpr.cpp.o

ninja: build stopped: subcommand failed.

That sounds more normal.  But on a recent -j8 verbose Release build
using my own CFLAGS and CXXFLAGS my compile of SemaExpr.cpp was *much*
later, and building all the parts I was compiling far more targets
than you were:

[1923/3276] /usr/bin/g++  -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/lib/Sema 
-I../tools/clang/lib/Sema -I../tools/clang/include 
-Itools/clang/include -I/usr/include/libxml2 -Iinclude -I../include 
-O3 -march=native -D_FORTIFY_SOURCE=2 -fstack-protector-strong 
-D_GLIBCXX_ASSERTIONS -fPIC -fvisibility-inlines-hidden 
-Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers 
-pedantic -Wno-long-long -Wimplicit-fallthrough 
-Wno-maybe-uninitialized -Wno-class-memaccess -Wno-noexcept-type 
-Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color 
-ffunction-sections -fdata-sections -fno-common 
-Woverloaded-virtual -fno-strict-aliasing -O3 -DNDEBUG 
-fno-exceptions -MD -MT 
tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaExprMember.cpp.o 
-MF 
tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaExprMember.cpp.o.d 
-o 
tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaExprMember.cpp.o 
-c ../tools/clang/lib/Sema/SemaExprMember.cpp


All I can really say is that something in what you are doing seems
to be different.



Only thing I am doing is following the guide as shown.




After some research, I was finally able to find the build
log ( CMakeFiles/CMakeError.log)



Run Build Command(s):/usr/bin/ninja cmTC_4c78c && [1/2]
Building CXX object CMakeFiles/cmTC_4c78c.dir/src.cxx.o
FAILED: CMakeFiles/cmTC_4c78c.dir/src.cxx.o
/usr/bin/g++    -fPIC -fvisibility-inlines-hidden
-Werror=date-time -std=c++11 -Wall -Wextra
-Wno-unused-parameter>
g++: error: unrecognized command line option '-Wthread-safety'
g++: error: unrecognized command line option '-Wthread-safety'
ninja: build stopped: subcommand failed.


Anyone know anything about this unrecognized command?

I'm not familiar with it but doing some searching it appears to
be clang only. Are you exporting CC=gcc CXX=g++? Tests probably
shouldn't be run with those set.

   -- Bruce

When we build llvm for the first time, we have to set CC and CXX to
use gcc, g++.  I don't seem to have any test logs for that (I mostly
only run llvm tests if I'm upgrading the version in the book), but
the error looks as if it is in the main build, not the tests.

I am doing as shown in the link ( 
http://www.linuxfromscratch.org/blfs/view/stable-systemd/general/llvm.html 


):


= 



CC=gcc CXX=g++ \
cmake -DCMAKE_INSTALL_PREFIX=/usr \
   -DLLVM

Re: [blfs-support] Fcron-3.2.1: /lib/systemd/system/fcron.service: No such file or directory

[Douglas R. Reno via blfs-support]

On 10/26/19 8:34 PM, Trent via blfs-support wrote:



On 10/26/19 7:13 PM, Douglas R. Reno via blfs-support wrote:



On 10/26/19 7:04 PM, Trent via blfs-support wrote:



From this section:

http://www.linuxfromscratch.org/blfs/view/stable-systemd/general/fcron.html


Last part:

sed -i 's:/var/run/fcron.pid:/run/fcron.pid:' \ 
/lib/systemd/system/fcron.service Is returning: sed: can't read 
/lib/systemd/system/fcron.service: No such file or directory 
Directory exists, but no fcron.service. Does not exist in the 2018, 
or 2019 BLFS Systemd Units package either.


You should have a /lib/systemd/system/fcron.service installed from 
the 'make install' command since it's provided by the package.


Can you check and see if you have the following files in your 
fcron-3.2.1 tarball (and verify the md5sum please):


renodr [ /sources/fcron-3.2.1.src/fcron-3.2.1 ]$ ls script/ | grep 
systemd

fcron.init.systemd.in

The makefile should generate a fcron.init.systemd which will then be 
installed to /lib/systemd/system as 'fcron.service'


I just checked my script against the book for verification and ran it 
again and came up with the expected result




There is also one other thing I forgot to mention on that installation.

The command "/etc/rc.d/init.d/sysklogd reload" is returning: -bash: 
/etc/rc.d/init.d/sysklogd: No such file or directory Trent



That should be in the systemd version only. In the SysV version of BLFS, 
running that after modifying the syslog.conf file will allow your system 
to begin logging cron events without restarting the system. In systemd, 
fcron logs to the journal (by default, you can modify that I've heard 
but I've never tried it).


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

Re: [blfs-support] Fcron-3.2.1: /lib/systemd/system/fcron.service: No such file or directory

[Douglas R. Reno via blfs-support]

On 10/26/19 7:04 PM, Trent via blfs-support wrote:



From this section:

http://www.linuxfromscratch.org/blfs/view/stable-systemd/general/fcron.html


Last part:

sed -i 's:/var/run/fcron.pid:/run/fcron.pid:' \ 
/lib/systemd/system/fcron.service Is returning: sed: can't read 
/lib/systemd/system/fcron.service: No such file or directory Directory 
exists, but no fcron.service. Does not exist in the 2018, or 2019 BLFS 
Systemd Units package either.


You should have a /lib/systemd/system/fcron.service installed from the 
'make install' command since it's provided by the package.


Can you check and see if you have the following files in your 
fcron-3.2.1 tarball (and verify the md5sum please):


renodr [ /sources/fcron-3.2.1.src/fcron-3.2.1 ]$ ls script/ | grep systemd
fcron.init.systemd.in

The makefile should generate a fcron.init.systemd which will then be 
installed to /lib/systemd/system as 'fcron.service'


I just checked my script against the book for verification and ran it 
again and came up with the expected result


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

Re: [blfs-support] Best approach for lvm2

[Douglas R. Reno via blfs-support]

On 10/26/19 9:20 AM, Pierre Labastie via blfs-support wrote:


Pierre
[1] I am not sure why Windows is using two small partitions + one big, but the
computer came with that, and I just shrank the big partition to make room for
linux.
The reason why Windows does that is so that the recovery tools and boot 
manager are always available in the first 100MB or so of the hard drive 
(I've seen Windows 10 dedicate over 500MB for "System Reserved" which is 
overkill). It's not the most convenient option for them, but it beats 
having to get a Windows DVD out anytime there's a problem that prevents 
the operating system from booting.

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

Re: [blfs-support] Systemd Units link incorrect?

[Douglas R. Reno via blfs-support]

On 10/23/19 10:55 PM, Ken Moffat via blfs-support wrote:

On Wed, Oct 23, 2019 at 10:05:20PM -0500, Trent via blfs-support wrote:

Sorry, I posted into the wrong mailing list.


As mentioned in LFS list,

http://www.linuxfromscratch.org/blfs/view/stable-systemd/introduction/systemd-units.html



The link seems to be wrong.

Even with wget, I am getting a 404 .


Trent


Thanks for the report, perhaps nobody has tried to download them
from the 9.0 release until now.  As a workaround, the link from the
development book seems to work:

  
http://www.linuxfromscratch.org/blfs/downloads/systemd/blfs-systemd-units-20180105.tar.bz2

ĸen


I've attempted to fix it, but I think Bruce will have to get this one. I 
theoretically have perms (part of the lfswww group), and can get to the 
proper folder, but I get a permission denied when trying to copy the 
units into the view/9.0-systemd directory.


Bruce, I wonder if we should modify the render script to copy them into 
place. The SVN version doesn't seem to have it in the proper directory 
either.


Thanks for reporting this Trent.

- Doug

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

Re: [blfs-support] Installing Python modules in BLFS - BLFS 9.0/development

[Douglas R. Reno via blfs-support]

On 9/21/19 7:46 AM, rhubarbpieguy--- via blfs-support wrote:


Although Python 3 is now installed in LFS, it appears necessary to 
reinstall Python 3 in BLFS to install Python modules.  From the Python 
3 documentation:


   "Python 3 was installed in LFS.  The only reason to install it here 
is if optional modules are needed."


I understand the note, but a user following dependency links doesn't 
see it.  For instance, Mako is required for Mesa, but the Mako link 
references the Mako page, which makes no mention of reinstalling 
Python 3.  As Python 3 was installed in LFS, a user would have no 
reason to suspect Python 3 must be reinstalled.


Would it make sense to add a note to Python modules using python3 
indicating Python 3 must be reinstalled?


Is it practical to amend the Python 3 LFS procedures to eliminate 
reinstalling Python 3 in BLFS?  That would eliminate the need for 
notes in BLFS and the Python 3 documentation.


Sadly it isn't practical to do that. We'd have to add Tk, Sqlite, and 
Berkeley DB to LFS. Sqlite has 0 dependencies, but Tk requires Xorg 
Libraries. I believe that the places where these modules are needed is 
properly marked in BLFS, but I'm not sure. The only places where an xref 
is done at is in:


general/genlib/libxml2.xml:  built by , run:
general/genutils/iso-codes.xml:  

I'm not sure if all of the places where those modules are used is 
marked. I know I personally rebuild Python3 with the SQLite module 
before GLib, but that's either due to an application I build / use or an 
artifact of a previous time when Python3 wasn't part of LFS.


As Bruce said earlier, none of the Python Modules in BLFS need Python3 
to be rebuilt.


- Doug

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

Re: [blfs-support] Minor documentation typo -D=LLVM_ENABLE_RTTI=ON - BLFS 9.0/development

[Douglas R. Reno via blfs-support]

On 2019-09-04 16:18, rhubarbpieguy--- via blfs-support wrote:

The LLVM-8.0.1 documentation lists -D=LLVM_ENABLE_RTTI=ON in the
Command Explanations section.  I believe it should be
-DLLVM_ENABLE_RTTI=ON.


Fixed at r22094. Thank you for the report!
--
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 and Libva correct install method

[Douglas R. Reno via blfs-support]

On 8/27/19 8:28 PM, Dan Ayre via blfs-support wrote:


Hi Friends,

I have a lot of confusion on what comes first with this install.

1-Build and install libva  "You must build libva first without EGL and 
GLX support" How is this done?


2- Build and install Mesa

3- Build Libva but do not install ?


Hello! I think the "without EGL and GLX support" might actually be 
redundant now, the switches for those come up unrecognized for me. What 
you'll want to do is the following:


1 - build libva
2 - Build Mesa
3 - Rebuild libva (and most certainly install it)


Otherwise, you won't get any hardware acceleration support on most video 
chipsets


I have built 8.0 , 8.1 , 8.3, and 8.4 and run into some issues down 
the line with glu.h not found. And problems with


QT-5  and VLC . Don't know if its related or not.

At least for the 'glu.h' issues, make sure that GLU (it's in Chapter 25: 
X Libraries) is installed. A long time ago, it was included with Mesa. I 
don't recall when that changed, it was soon after I started as an editor 
on BLFS (2015-ish).


- Doug


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

Re: [blfs-support] gdm: how to use a non us keyboard? [solved]

[Douglas R. Reno via blfs-support]

On 8/27/19 10:01 AM, Bruce Dubbs via blfs-support wrote:

On 8/27/19 2:54 AM, Pierre Labastie via blfs-support wrote:

Also, changing /etc/localtime to a symlink has an immediate effect of 
changing
the clock to the right timezone (that's really amazing, at the time 
you hit

return, the clock changes), thanks Bruce. I think we should change
/etc/localtime to a symlink in the Sysv book.


That would be in LFS Chapter 6 glibc.

It's curious why /etc/localtime needs to be a symlink.  If the file is 
just opened, the kernel should follow the symlink and do the right 
thing.  lxde and xfce do not have the problem and neither does xclock. 
Something in gnome and, IIRC, plasma, is looking specifically for a 
symlink.


The reason for using a cp instead of ln in the glibc instructions is 
to keep the time right in the unusual case that /usr is not mounted.  
Even if /usr is on a separate partition it is almost always mounted 
early (mount is the 7th bootscript) unless there is a problem.


I think I once did something like:

mv /etc/localtime /etc/localtime.file
ln -s  localtime.file /etc/localtime

but that's not a good solution for the book.

What do others think?  Should we just change LFS from

cp -v /usr/share/zoneinfo/ /etc/localtime

to

ln -sf /usr/share/zoneinfo/ /etc/localtime

I believe this is the best solution, and it's consistent with the 
systemd book and can remove another difference.



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

Re: [blfs-support] gdm: how to use a non us keyboard?

[Douglas R. Reno via blfs-support]

On 8/25/19 2:50 PM, Pierre Labastie via blfs-support wrote:

On 25/08/2019 20:09, DJ Lucas via blfs-support wrote:


On 8/23/2019 7:56 PM, Ken Moffat via blfs-support wrote:

On Fri, Aug 23, 2019 at 09:39:41PM +0200, Pierre Labastie via blfs-support 
wrote:

Will try using obconf in lxde.

Pierre

Hi Pierre,

not sure if https://issues.guix.info/issue/35118 might help for gdm.

Some of the details look to be very specific to guix, but in patch 2
localed is extracted from systemd and an xkeyboard patch is added.

But all the wiring-up seems to be specific to how guix do things.

Well, that seems like an interesting approach, and was fairly easy to do (took
me about 20m...less time than it took for me to write this email in fact), but
the Guix solution just uses "GUIX_XKB_*" environment variables. I hacked up a
patch to elogind to mimic what Guix did if you want to fiddle with it and see.
It does introduce a hard dependency on xkb-common. I renamed the workaround
environment variables without the GUIX_ prefix. I haven't done any testing
other than verifying that it builds and installs correctly (into DESTDIR, so
at least no linking issues with elogind). The additional source files in the
locale directory were taken directly from systemd-241. The variables that need
to make their way into GDM's environment are
XKB_{LAYOUT,MODEL,VARIANT,OPTIONS} (without configured /etc/vconsole.conf
anyway), so it's a lot of systemd cruft left for just a simple workaround, but
if it works, I could put a bit more time into it. Despite comment #6 in the
above thread, it really wouldn't be _that_ difficult to decouple from elogind,
but elogind would require a couple of small changes already in the patch below
(or the handful of reintroduced functions added directly to the targets or a
tiny libelocaled, but I'd much rather get these back into elogind and just
depend on it).

http://www.linuxfromscratch.org/~dj/elogind-241.3-add_localed-1.patch

--DJ


First, no joy trying to tweak greeter-dconf-defaults. This could have been
expected, since the source seems to rely on org.freedesktop.locale1

Will try the patch, to confirm that problems come from the lack of localed,
but I fear that we may encounter another problem: GNOME sets the local time to
UTC, and while I can open the time-date configuration, I cannot save the
settings, and it falls back to UTC on a minute change. I suspect the lack of
datetimed...


The same thing happens with Plasma actually. It's because we operate 
with /etc/localtime being a file instead of a symbolic link in SysV. 
With a symbolic link to the user's time zone (from /etc/localtime to 
/usr/share/zoneinfo//), the GNOME and KDE settings centers and 
clocks both will reflect the correct time instead of UTC.


I'd like to suggest a change for that, but I know it'll probably be met 
with opposition because we still support a split /usr system. We could 
do this to work around it though:


cp -v /usr/share/zoneinfo// /etc/timezone

ln -sv timezone /etc/localtime

(Or something similar, I was gone for a couple days and will be again 
for a short period this afternoon, so I'm trying to catch up on email. 
This may have already been addressed, and if it has, I apologize for the 
noise)


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

Re: [blfs-support] Issues with epiphany

[Douglas R. Reno via blfs-support]

On 8/14/19 1:54 PM, Ken Moffat via blfs-support wrote:

On my development system, I thought I'd give epiphany another trial,
using the development book, but with as few of the recommended deps
as possible.  Seems to work (for some value of work - see below),
but not something I'd recommend (e.g. no obvious way to get a blank
new tab - I don't want to get a set of sites I've previously used),
which is a pity because webkitgtk gets updated a lot sooner than
qtwebengine, and is a much quicker build.

But even for just testing it, there are two issues:

1. For many sites, images do not appear, instead I get empty boxes
where the image should be.  Or sometimes one or two images appear
and just text on a white background, e.g. www.theinquirer.net,
www.theregister.co.uk.

2. On almost every https: site, it tells me the certificate was not
issued by a known authority (but no details of the certificate) and
that it might be an impostor (both of the above sites, if my memory
is correct, but also google, amazon, ebay, lwn.net) although it does
let me take the risk of connecting.  Of course, these all work ok in
my other browsers.

If anyone uses this, do these things work for them ?  If so, maybe a
missing dependency solves it - any suggestions ?

The packages I've built for this (beyond my usual gtk3 /
introspection / vala and all of the gpg stuff) are:

ldns,
ruby,
gcr (a runtime dep, but meson wants it to be installed),
webkitgtk,
libseccomp,
gnome-desktop,
epiphany.



Hi Ken,

I just tried both of those websites on my workstation (which has 
Epiphany 3.32.3 and WebKitGTK+ 2.24.3 installed), and didn't have any 
problems. However, I'm wondering if it's a dependency issue.


Do you have gnome-keyring and seahorse installed? Also, what version of 
gdk-pixbuf, glib-networking, and libsoup do you have installed? You've 
got the latest version (1.4) of make-ca, right?


BTW, for a blank tab when creating new tabs, go to the 3-bar Menu 
Button, Preferences, and then select "Blank Page" under the Homepage 
option :-)



- Doug

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

Re: [blfs-support] wpa_supplicant and NetworkManager

[Douglas R. Reno via blfs-support]

On 7/20/19 3:37 AM, Hans Malissa via blfs-support wrote:
I've been reading through the installation instructions for 
wpa_supplicant 
(http://linuxfromscratch.org/blfs/view/stable-systemd/basicnet/wpa_supplicant.html) 
and NetworkManager 
(http://linuxfromscratch.org/blfs/view/stable-systemd/basicnet/networkmanager.html) 
on 8.4-systemd. There are a few questions I have:

Hi Hans,
a) NetworkManager lists UPower-0.99.9 as a recommended dependency. 
UPower comes with a systemd unit. Does this mean that UPower should be 
installed, or that the systemd unit should be started/enabled as well?
Yes, you should install UPower and the systemd unit should be enabled 
and started. This allows UPower to be seen and communicated with via D-Bus.
b) Similarly, NetworkManager lists BlueZ-5.50 and ModemManager-1.10.0, 
both of which have their own systemd units. Should the systemd units 
be started/enabled for NetworkManager?


The same applies here, you're going to want the systemd unit to be 
started/enabled.



c) The page on wpa_supplicant describes the installation of the 
systemd units:


# install -v -m644 systemd/*.service /lib/systemd/system/


You're going to need these enabled as well

and the D-Bus configurations files

# install -v -m644 
dbus/fi.{epitest.hostap.WPASupplicant,w1.wpa_supplicant1}.service \

/usr/share/dbus-1/system-services/ &&
install -v -d -m755 /etc/dbus-1/system.d &&
install -v -m644 dbus/dbus-wpa_supplicant.conf \
/etc/dbus-1/system.d/wpa_supplicant.conf

and its activation

# systemctl enable wpa_supplicant

I assume that the systemd units are only needed when using 
wpa_supplicant without NetworkManager. Are the D-Bus configuration 
files and the D-Bus service are needed for NetworkManager, is that 
correct?
Does the 'Configuration Information' apply for the use with 
NetworkManager as well?
The configuration information doesn't apply, but the D-Bus Configuration 
Files and the service are required. In addition, the systemd unit is needed.
d) The note on the NetworkManager page states: 'If using Network 
Manager to manage an interface, any previous configuration for that 
interface should be removed, and the interface brought down prior to 
starting Network Manager.'. I've configures my network interface using 
the /etc/systemd/network/10-eth-dhcp.network file during LFS 
(http://www.linuxfromscratch.org/lfs/view/stable-systemd/chapter07/network.html). 
Does this mean that I should delete that file, or is there something 
else that needs to be done? How do I bring down the interface? 
NetworkManager lists dhcpcd-7.1.1 as a recommended dependency; I 
assume that I shouldn't start/enable the systemd unit for dhcpcd, correct?


Your best bet is to run the following:

mv -v /etc/systemd/network/10-eth-dhcp.network{,.NOUSE}

That way if anything goes wrong, you'll be able to go back to the old 
configuration.


You should enable the DHCP unit for systemd because it will install the 
dhcpcd@ services in /lib/systemd, which NetworkManager will spawn when 
bringing up an interface. Don't worry about bringing down the interface, 
at the next reboot (or the next time you run 'systemctl restart 
systemd-networkd'), it will be managed by NetworkManager.


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

[blfs-support] Critical Firefox and Thunderbird 0days

[Douglas R. Reno via blfs-support]

Good morning folks,

Last week, critical security vulnerabilities were unveiled in Mozilla 
Firefox and Mozilla Thunderbird [1]. These vulnerabilities allowed for 
arbitrary code execution, sandbox escape, and denial of service. The 
problem with these vulnerabilities is that they are being actively 
exploited against users in the wild, as noted by several different 
security companies. As a result, we highly recommend updating 
immediately to Firefox 67.0.4 and Thunderbird-60.7.2.


In addition to the two in Firefox [2] [3], there were two sets 
discovered in Thunderbird as well [4] [5] [6] [7]. Two of the 
vulnerabilities pertain to the Gecko rendering engine, which contains 
the security fixes from Firefox. Four of them are new 0days that were 
found in the libical implementation in Thunderbird. By receiving an 
email with a corrupted .ics file with a payload in it, a heap-based 
buffer overflow will occur [8] [9] [10] [11] or type confusion will 
occur, leading to an exploitable crash, possible arbitrary code 
execution, and complete destruction of the user's Thunderbird Email 
profile. This is because of the way that Thunderbird indexes email as it 
receives it. When Thunderbird processes these emails, it will attempt to 
index the .ics file, and in the process of opening it to read it's 
contents, will crash. Upon launching Thunderbird again, it will once 
again attempt to download the mail and index it, and crash repeatedly as 
a result. These vulnerabilities were reported to Mozilla in 2016 
(2016-06-19) and were never fixed by Mozilla even after they were fixed 
in libical upstream (2016 as well). A recent development has made it so 
that PoCs are available and the vulnerabilities are being exploited in 
the wild.


When upgrading Thunderbird, no new package updates will be required if 
you are running BLFS 8.4. I did not attempt to upgrade an 8.3, 8.2, 8.1, 
or 8.0 system because I do not have them around at the moment. 
Unfortunately, if you are upgrading Firefox on a stock 8.4 system, some 
upgrades need to be done:


- NSS (I recommend 3.44, it's got a new root certificate installed)

- NSPR (4.21 at minimum, I recommend the latest)

- cbindgen (0.8.2 at minimum, I recommend the latest)

- SQLite (3.27.2 at minimum, 3.28 is recommended)

- Recommended but not required to fix a security flaw: Node.JS to 10.16.0

- Recommended but not required to fix a set of security flaws: wget to 
1.200.3


- Recommended but not required to fix another set of security flaws: 
cURL to 7.65.1



Thank you,

Douglas R. Reno


LINKS:

[1]: https://thehackernews.com/2019/06/firefox-0day-vulnerability.html

[2]: https://www.mozilla.org/en-US/security/advisories/mfsa2019-18/

[3]: https://www.mozilla.org/en-US/security/advisories/mfsa2019-19/

[4]: https://www.mozilla.org/en-US/security/advisories/mfsa2019-17/

[5]: https://www.mozilla.org/en-US/security/advisories/mfsa2019-20/

[6]: https://www.thunderbird.net/en-US/thunderbird/60.7.2/releasenotes/

[7]: https://www.thunderbird.net/en-US/thunderbird/60.7.1/releasenotes/

[8]: https://seclists.org/oss-sec/2019/q2/157

[9]: https://seclists.org/oss-sec/2019/q2/158

[10]: https://seclists.org/oss-sec/2019/q2/159

[11]: https://seclists.org/oss-sec/2019/q2/160

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

Re: [blfs-support] ffmpeg pulseaudio --enable-libpulse

[Douglas R. Reno via blfs-support]

On 6/15/19 10:23 AM, Wayne Sallee via blfs-support wrote:
When building ffmpeg, pulseaudio is listed as an optional dependency. 
But if one has pulseaudio, ffmpeg will still not work with pulse, 
unless ffmpeg is compiled with --enable-libpulse .


https://www.ffmpeg.org/ffmpeg-devices.html

Since pulseaudio is listed as an optional dependency, it would 
probably be good to include --enable-libpulse in the Command 
Explanations.


Wayne Sallee
wa...@waynesallee.com
http://www.WayneSallee.com


Good morning Wayne,

I added a Command Explanation for "--enable-libpulse" at r21687. Thanks 
for spotting this and reporting!


- Doug

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

Re: [blfs-support] Minor issue in Wireshark

[Douglas R. Reno via blfs-support]

On 5/28/19 10:09 AM, Waleed Hamra via blfs-support wrote:

On 28/05/2019 18:04, Waleed Hamra wrote:

Hi guys;

in the Wireshark page, the command to install the documents assumes
we're in the top level directory, when we're actually inside the build
dir. Either we should cd .. , or adjust the command:

install -v -m644../README.linux ../doc/README.*
../doc/{*.pod,randpkt.txt} \
 /usr/share/doc/wireshark-3.0.1


Also what's up with this line:

-DCMAKE_INSTALL_DOCDIR=/usr/share/doc/PROGRAM=wireshark-3.0.1

:D

Regards
Waleed Hamra



Thanks for the report! Fixed at r21640

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

[blfs-support] HEADSUP - Firefox Addons Bug Fixed

[Douglas R. Reno via blfs-support]

Hi folks,

On May 4th, 2019, a bug surfaced in Firefox related to Addons. This was 
due to an internal certificate that expired, and was not renewed by 
Mozilla until problems were already present. The initial fix was 
deployed on May 5th, 2019, through a patch in Mozilla's Studies system. 
This fix expires soon, so we highly recommend updating to 66.0.5 or 67 
whenever it comes out. Once that fix expires, versions 66.0.4 all the 
way down to 52 (when the certificate was introduced) will stop working 
with any addons or extensions that you have installed. Other reports on 
Mozilla's bug tracker say that SSL support will be broken as well.


We highly recommend updating to Firefox 66.0.5 or later. On an 8.4 
system, I can confirm that it works perfectly without any updates. 
That's not to say that I wouldn't recommend updating certain 
dependencies such as node.js, SQLite, NSS, NSPR, Harfbuzz, and wget 
though, due to security vulnerabilities that have since been patched. 
Note that Firefox 66.x fixes a lot of vulnerabilities over 65.0.1 as 
well. Rust-1.32.0 and LLVM-7.0.1 should be perfectly fine as well.


An errata entry will be published to document this fix.

Thank you,

Douglas R. Reno

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

Re: [blfs-support] NSS on the systemd book out of date

[Douglas R. Reno via blfs-support]

On 5/12/19 4:54 AM, Waleed Hamra via blfs-support wrote:

Hi guys;

The development systemd version of the book still has 3.43, whereas the
svn one is on 3.44. This wouldn't usually be a problem, except that the
3.43 patch is now 404ing.

Regards
Waleed Hamra


Can you try again please? The systemd book renders a couple of hours 
later than the SVN one, and they're both based off the same source tree now.


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

Re: [blfs-support] polkitkit patch

[Douglas R. Reno via blfs-support]

On 5/10/19 7:02 AM, spiky via blfs-support wrote:
http://www.linuxfromscratch.org/patches/blfs/svn/polkit-0.115-security_patch-3.patch 



returns 404

where is the patch?



If you're looking for the patch for Polkit-0.115, here it is:

http://linuxfromscratch.org/patches/downloads/polkit/polkit-0.115-security_patch-3.patch


Note though that Polkit-0.116 doesn't need a patch, and we recommend 
updating to that because the security fixes it has are more stable than 
the ones provided in that patch.


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

Re: [blfs-support] Firmware for video controller

[Douglas R. Reno via blfs-support]

On 5/3/19 10:40 PM, Hans Malissa via blfs-support wrote:

Hi,

I'm trying to figure out whether I need additional firmware for my 
video controller.


# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Device 3185 (rev 03)

# dmesg | grep firmware
[...] [drm] GuC: No firmware known for this platform!
[...] [drm] HuC: No firmware known for this platform!
[...] i915 :00:02.0: Direct firmware load for 
i915/glk_dmc_ver1_04.bin failed with error -2
[...] i915 :00:02.0: Failed to load DMC firmware 
i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
[...] i915 :00:02.0: DMC firmware homepage: 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915

...

But the file /lib/firmware/i915/glk_dmc_ver1_04.bin does exist. I'm 
wondering what's wrong here, is there anything else needed?

Greetings,

Hans


Hello!

Did you build it into the kernel? I've noticed that I have to build my 
firmware into the kernel, or otherwise it fails to load at runtime.


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

Re: [blfs-support] giflib-5.1.6 zero byte Makefile

[Douglas R. Reno via blfs-support]

On 4/24/19 6:53 PM, Mark Mohr via blfs-support wrote:
Well I used Nautilus File Manager 'Extract Here' menu option. There 
lies the problem and the first time that has happened.


Was this Nautilus in 8.4 or SVN? I really should investigate this, as 
it's a major problem with it's functionality, and should probably be 
reported upstream and fixed!


Also, were there any other files that were 0 bytes? Can you verify that 
the MD5SUM matches again please?


Thank you,

Douglas R. Reno

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

Re: [blfs-support] Actions to install unbound and bind on systemd

[Douglas R. Reno via blfs-support]

On 4/20/19 3:36 AM, Pierre Labastie via blfs-support wrote:

Writing to -support, because I am very newbie to systemd.

On the systemd book, both for bind and unbound, there is an instruction to
modify the /etc/resolv.conf file, such as:

# unbound
echo "nameserver 127.0.0.1" > /etc/resolv.conf

# bind
cat > /etc/resolv.conf << "EOF"
search 
nameserver 127.0.0.1
EOF

But if /etc/resolv.conf is a symlink (as advised in the LFS book), this will
write to the symlinked file, not recreate /etc/resolv.conf as a regular file.

So I think those settings would be lost at next reboot...

Also, it is advised to do:

# bind
systemctl start named

but not for unbound.

Shouldn't systemd-resolved be stopped and disabled first?

And actually, isn't systemd-resolved enough, and do we need bind or unbound?


Pierre


Generally what I do is disable systemd-resolved, run a 'rm -f 
/etc/resolv.conf', and then create a static one. I had to do this 
recently after Comcast's upstream DNS services went down for two days in 
my area (actually the whole Chicago-land area - their official guidance 
was (for Windows only) set the DNS servers to 8.8.4.4 and 8.8.8.8), and 
I just setup a BIND server instead. It has been a while since I've 
tested this configuration in a production environment though, this was 
just a quick hack to bypass an upstream DNS problem.


I have only ever tested/used Unbound once, and that was when I took over 
systemd in July of 2015. systemd-resolved should be enough in most 
cases, unless you need a DNS server - that's where BIND comes in :-)


Similar to unbound, systemd-resolved also caches requests.

This is a rather low priority suggestion, but I think we should add 
instructions about removing the symlinked /etc/resolv.conf file to BIND 
and Unbound's page, and then disabling systemd-resolved, to prevent 
confusion for users.


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

Re: [blfs-support] libseccomp-2.3.3 test error

[Douglas R. Reno via blfs-support]

On 3/28/19 1:46 AM, Hans Malissa via blfs-support wrote:
On Mar 27, 2019, at 04:07 PM, Bruce Dubbs via blfs-support 
 wrote:

On 3/27/19 4:17 PM, Hans Malissa via blfs-support wrote:

Hi,

I'm installing libseccomp-2.3.3 on BLFS 8.4-systemd following the
instructions on
http://linuxfromscratch.org/blfs/view/stable-systemd/general/libseccomp.html.
When I run the test suite, I get a strange error:

$ make check
...
CC   35-sim-negative_one.o
CCLD   35-sim-negative_one
error: install "head" and include it in your $PATH
FAIL: regression
===
1 of 1 test failed
===
make[2]: *** [Makefile:1005: check-TESTS] Error 1
make[1]: *** [Makefile:1129: check-am] Error 2
make: *** [Makefile:498: check-recursive] Error 1

I don't quite understand what that means. "head" from Coreutils-8.30
(http://linuxfromscratch.org/lfs/view/stable-systemd/chapter06/coreutils.html)
is available and working. It is located in /bin, which is in my $PATH.


It is hard to say without more information. All tests bass for me.

Looking at the code, I'll bet that you do not have 'which' installed.


That was it, thanks a lot. After installing 'which', all tests pass.
The instructions for 'libseccomp' don't list 'which' as a dependency, 
though.


Hans


Hello,


I just added Which as a required dependency for libseccomp at r21405

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

Re: [blfs-support] webkitgtk link

[Douglas R. Reno via blfs-support]

On 2019-03-11 15:50, spiky0011 via blfs-support wrote:

Hi

The link

https://webkitgtk.org/releases/webkitgtk-2.22.6.tar.xz is returning

You don't have permission to access /releases/webkitgtk-2.22.6.tar.xz
on this server.


It seems that Upstream is having problems.

Pull it from here:

http://ftp.osuosl.org/pub/blfs/conglomeration/webkit/webkitgtk-2.22.6.tar.xz
--
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.4 - Firefox 65.0.1 showing up as Nightly on my system

[Douglas R. Reno via blfs-support]

On 2019-03-09 17:11, Ken Moffat via blfs-support wrote:
On Sat, Mar 09, 2019 at 04:54:56PM -0600, Bruce Dubbs via blfs-support 
wrote:


I found build/moz.configure/init.configure

is_nightly = is_release_or_beta = None

if 'a1' in milestone:
is_nightly = True
elif 'a' not in milestone:
is_release_or_beta = True


I salute your expertise with searching :)


It is a python script and I'm not exactly fluent in python, but it 
should

return is_release_or_beta = True and is_nightly = None

  -- Bruce



I would expect the milestone to be 65.0.1 (although I only recall
'version' notation when looking at diffs beweeen betas/releases).

ĸen
--
  It is said that there are two great unsolved problems in computer
  science: naming, cache invalidation, and off-by-one errors.
 -- Ben Bullock


Alright guys, after a long night of troubleshooting, I figured it out.

There must have been something wrong with my original script. It 
installed Firefox Nightly into /usr/local/bin and /usr/local/lib/firefox 
respectively. My guess is that it was a problem with my script. Here was 
the whole process:


- Upgrade to latest node, cbindgen, NSPR, sqlite
- Install Firefox-65.0.2
- Determine that for some reason Firefox Nightly was still being opened
- Run 'update-desktop-database' and find out that it was pulling from 
/usr/local/* before /usr/*
- Read the desktop file and determine that "Exec=firefox" means that 
it'll pull any firefox that it can find, often times being the first in 
the search path (which seems to be /usr/local)

- Remove firefox nightly from /usr/local and...
- VOLIA! I have a working Firefox-65.0.2.

Now with this, I uncovered another problem (although I'm comfortably in 
firefox).


For some reason, xterm installed it's binaries to /usr/local/bin! Can 
someone else confirm this? I verified that $XORG_CONFIG was present at 
build-time and even rebuilt it, and found that it still placed binaries 
in the wrong location.

--
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.4 - Firefox 65.0.1 showing up as Nightly on my system

[Douglas R. Reno via blfs-support]

On 2019-03-09 14:33, Bruce Dubbs wrote:

On 3/9/19 12:52 PM, Douglas R. Reno wrote:

On 2019-03-09 11:28, Bruce Dubbs via blfs-support wrote:

On 3/9/19 11:17 AM, Douglas R. Reno via blfs-support wrote:

Good morning (or afternoon),

I setup a build of Firefox to run overnight on one of my 8.4 
systems. Using my pre-existing script and mozconfig, which worked 
for 8.4's release testing to give me a Firefox Quantum install, gave 
me a Firefox Nightly install, in which the commands after ./mach 
install don't work because /usr/lib/firefox/ doesn't exist.


Grepping my log somehow shows that it picked up that it was supposed 
to be part of the nightly channel, so I'll rebuild Firefox without a 
script and see what happens. My question is though...


Has anyone ever encountered this, and how does it happen? Does 
Firefox assume that it's nightly if it has a problem with the 
mozconfig or something of that nature?


I've not seen this.  I can check my log.  What should I look for?


Try grepping for 'nightly'. My mozconfig specified nothing about it, 
and it still got picked up.


I didn't run this one with mach in verbose mode, but this one is 
almost out of the oven. When it's done, I'll see if it remains or not.



$ grep night firefox-65.0.2.log

returns nothing for me.

Are we using the same source?

$ tail -n5 firefox-65.0.2.log
SBU=26.343
273056 /usr/src/firefox/firefox-65.0.2.source.tar.xz SIZE (266.656 MB)
9612248 kilobytes BUILD SIZE (9386.960 MB)
md5sum : e4ddf50ea701995287461c2170ceca9b
/usr/src/firefox/firefox-65.0.2.source.tar.xz

  -- Bruce


I saw Ken note that Nightly is supposed to be binary only. After 
rebuilding Firefox, I'm still showing nightly. Time for some info:


In About Nightly (where About Firefox would be in the menu):

Nightly
65.0.1 (64-bit)

My mozconfig:

# If you have a multicore machine, all cores will be used by default.

# If you have installed dbus-glib, comment out this line:
# ac_add_options --disable-dbus

# If you have installed dbus-glib, and you have installed (or will 
install)
# wireless-tools, and you wish to use geolocation web services, comment 
out

# this line
#ac_add_options --disable-necko-wifi

# API Keys for geolocation APIs - necko-wifi (above) is required for MLS
# Uncomment the following line if you wish to use Mozilla Location 
Service

ac_add_options --with-mozilla-api-keyfile=$PWD/mozilla-key

# Uncomment the following line if you wish to use Google's geolocaton 
API

# (needed for use with saved maps with Google Maps)
ac_add_options --with-google-api-keyfile=$PWD/google-key

# Uncomment this line if you have installed startup-notification:
ac_add_options --enable-startup-notification

# Uncomment the following option if you have not installed PulseAudio
#ac_add_options --disable-pulseaudio
# and uncomment this if you installed alsa-lib instead of PulseAudio
#ac_add_options --enable-alsa

# If you have installed GConf, comment out this line
#ac_add_options --disable-gconf

# From firefox-61, the stylo CSS code can no-longer be disabled

# Comment out following options if you have not installed
# recommended dependencies:
ac_add_options --enable-system-sqlite
ac_add_options --with-system-libevent
# current firefox fails to build against libvpx-1.8.0
#ac_add_options --with-system-libvpx
# firefox-65 understands webp and ships with an included copy
ac_add_options --with-system-webp
ac_add_options --with-system-nspr
ac_add_options --with-system-nss
ac_add_options --with-system-icu

# The gold linker is no-longer the default
ac_add_options --enable-linker=gold

# You cannot distribute the binary if you do this
ac_add_options --enable-official-branding

# If you are going to apply the patch for system graphite
# and system harfbuzz, uncomment these lines:
ac_add_options --with-system-graphite2
ac_add_options --with-system-harfbuzz

# Stripping is now enabled by default.
# Uncomment these lines if you need to run a debugger:
ac_add_options --disable-strip
ac_add_options --disable-install-strip

# The BLFS editors recommend not changing anything below this line:
ac_add_options --prefix=/usr
ac_add_options --enable-application=browser

ac_add_options --disable-crashreporter
ac_add_options --disable-updater
# enabling the tests will use a lot more space and significantly
# increase the build time, for no obvious benefit.
ac_add_options --disable-tests

# With clang, unlike gcc-7 and later, the default level
# of optimization produces a working build.
ac_add_options --enable-optimize

# From firefox-61 system cairo is not supported

ac_add_options --enable-system-ffi
ac_add_options --enable-system-pixman

# From firefox-62 --with-pthreads is not recognized

ac_add_options --with-system-bz2
ac_add_options --with-system-jpeg
ac_add_options --with-system-png
ac_add_options --with-system-zlib

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/firefox-build-dir


This is Firefox 65.0.1.
renodr [ /sources ]$ md5sum firefox-65.0.1.source.tar.xz
38c01a14e58cce894dda513739bd15d3

Re: [blfs-support] BLFS 8.4 - Firefox 65.0.1 showing up as Nightly on my system

[Douglas R. Reno via blfs-support]

On 2019-03-09 11:28, Bruce Dubbs via blfs-support wrote:

On 3/9/19 11:17 AM, Douglas R. Reno via blfs-support wrote:

Good morning (or afternoon),

I setup a build of Firefox to run overnight on one of my 8.4 systems. 
Using my pre-existing script and mozconfig, which worked for 8.4's 
release testing to give me a Firefox Quantum install, gave me a 
Firefox Nightly install, in which the commands after ./mach install 
don't work because /usr/lib/firefox/ doesn't exist.


Grepping my log somehow shows that it picked up that it was supposed 
to be part of the nightly channel, so I'll rebuild Firefox without a 
script and see what happens. My question is though...


Has anyone ever encountered this, and how does it happen? Does Firefox 
assume that it's nightly if it has a problem with the mozconfig or 
something of that nature?


I've not seen this.  I can check my log.  What should I look for?

  -- Bruce


Try grepping for 'nightly'. My mozconfig specified nothing about it, and 
it still got picked up.


I didn't run this one with mach in verbose mode, but this one is almost 
out of the oven. When it's done, I'll see if it remains or not.

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

[blfs-support] BLFS 8.4 - Firefox 65.0.1 showing up as Nightly on my system

[Douglas R. Reno via blfs-support]

Good morning (or afternoon),

I setup a build of Firefox to run overnight on one of my 8.4 systems. 
Using my pre-existing script and mozconfig, which worked for 8.4's 
release testing to give me a Firefox Quantum install, gave me a Firefox 
Nightly install, in which the commands after ./mach install don't work 
because /usr/lib/firefox/ doesn't exist.


Grepping my log somehow shows that it picked up that it was supposed to 
be part of the nightly channel, so I'll rebuild Firefox without a script 
and see what happens. My question is though...


Has anyone ever encountered this, and how does it happen? Does Firefox 
assume that it's nightly if it has a problem with the mozconfig or 
something of that nature?

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

Re: [blfs-support] Make-ca errors

[Douglas R. Reno via blfs-support]

On 2/23/19 2:52 PM, Bruce Dubbs via blfs-support wrote:

On 2/23/19 2:38 PM, Douglas R. Reno via blfs-support wrote:


On 2/23/19 2:35 PM, Bruce Dubbs via blfs-support wrote:

On 2/23/19 1:59 PM, DJ Lucas via blfs-support wrote:


On 2/23/2019 3:54 AM, Ken Moffat wrote:
On Sat, Feb 23, 2019 at 09:32:18AM +, DJ Lucas via 
blfs-support wrote:

On 2/23/2019 3:14 AM, Ken Moffat via blfs-support wrote:

I had a reply off-list suggesting that I try without the local cert
directory. So I renamed that, and retried. Running make-ca -g
succeeded but told me that the certs were up to date. Running 
make-ca

-f succeeded, the final output was: Certificate: Global Chambersign
Root - 2008 Keyhash: 0c4c9b6c Added to p11-kit anchor directory 
with

trust 'C,C,'. Extracting OpenSSL certificates to
/etc/ssl/certs...Done! Extracting GNUTLS server auth 
certificates to

/etc/pki/tls/certs/ca-bundle.crt...Done! Extracting GNUTLS S-Mime
certificates to /etc/pki/tls/certs/email-ca-bundle.crt...Done!
Extracting GNUTLS code signing certificates to
/etc/pki/tls/certs/objsign-ca-bundle.crt...Done! Extracting Java
cacerts (JKS) to /etc/pki/tls/java/cacerts...Done! And running 
links
to an https: site from chroot now works. I'll keep this around 
for a
bit in case you are replying to my earlier reply, but I need to 
sort
out some food, then I'll probably go shopping and then wind down 
and

go to bed.

Bad cert in the /etc/ssl/local directory caused that to cascade like
that? I can't see how, but I'll have to figure it out. If you 
still have

it around and it's not too much trouble (and nothing private in
/etc/ssl/local), could you tar up the contents and send, or is it 
just

the example cacert.org certs?
--DJ


I don't have any current use for local certs, I was just trying to
follow the book.  Maybe something in what I thought I had copied
from the book is wrong.  So here is the commented-out part. KM_LOG
points to my log for this package, and apologies if I've mis-pasted
or failed to update this and wasted your time.


#install -vdm755 /etc/ssl/local >$KM_LOG 2>&1
#wget http://www.cacert.org/certs/root.crt >>$KM_LOG 2>&1
#wget http://www.cacert.org/certs/class3.crt >>$KM_LOG 2>&1
#openssl x509 -in root.crt -text -fingerprint -setalias "CAcert 
Class 1 root" \
#    -addtrust serverAuth -addtrust emailProtection -addtrust 
codeSigning \

#    > /etc/ssl/local/CAcert_Class_1_root.pem >>$KM_LOG 2>&1
#openssl x509 -in class3.crt -text -fingerprint -setalias "CAcert 
Class 3 root" \
#    -addtrust serverAuth -addtrust emailProtection -addtrust 
codeSigning \

#    > /etc/ssl/local/CAcert_Class_3_root.pem >>$KM_LOG 2>&1

But, looking at the contents: clearly wget has failed.

-rw-r--r-- 1 root root 0 Feb 23 05:15 CAcert_Class_1_root.pem
-rw-r--r-- 1 root root 0 Feb 23 05:15 CAcert_Class_3_root.pem


Is there something more pertinent out there? In addition to those, I
install the US military CAs and intermediates, but that's a mess of 
111

certificates and a nasty script in and of itself (I just cleaned it up
and pushed it to 
http://www.linuxfromscratch.org/~dj/get-us-gov-certs.sh

if anybody needs them). I think we should just drop the example all
together, and leave the instructions in the man page. I figure for
better than 99% of our users, the Mozilla CAs are sufficient. Only a
handful of users would want to do overrides or append for local use
cases. Even Windows domains (if named properly) can use LE certs.

Any objections?


I'm not sure I understand the issue.   I've used the current 
instructions on my workstation, development system, and just 
yesterday on my laptop without problem.


In the dependencies, we might want to add wget.


I have had a problem with p11 configuration.  We now have

if [ -e /usr/lib/libnssckbi.so ]; then
  readlink /usr/lib/libnssckbi.so ||
  rm -fv /usr/lib/libnssckbi.so    &&
  ln -sfv ./pkcs11/p11-kit-trust.so /usr/lib/libnssckbi.so
fi

I think this could be replaced by just:

ln -sfvn ./pkcs11/p11-kit-trust.so /usr/lib/libnssckbi.so

  -- Bruce


The problematic instructions in question reside in this block:

install -vdm755 /etc/ssl/local &&
wgethttp://www.cacert.org/certs/root.crt  &&
wgethttp://www.cacert.org/certs/class3.crt  &&
openssl x509 -in root.crt -text -fingerprint -setalias "CAcert Class 
1 root" \
 -addtrust serverAuth -addtrust emailProtection -addtrust 
codeSigning \

 > /etc/ssl/local/CAcert_Class_1_root.pem &&
openssl x509 -in class3.crt -text -fingerprint -setalias "CAcert 
Class 3 root" \
 -addtrust serverAuth -addtrust emailProtection -addtrust 
codeSigning \

 > /etc/ssl/local/CAcert_Class_3_root.pem

They seem to cause problems and are confusing. They also seem to be 
unnecessary. All I run is 'make install && make-ca -g' when I need to 
install this pac

Re: [blfs-support] Make-ca errors

[Douglas R. Reno via blfs-support]

On 2/23/19 2:35 PM, Bruce Dubbs via blfs-support wrote:

On 2/23/19 1:59 PM, DJ Lucas via blfs-support wrote:


On 2/23/2019 3:54 AM, Ken Moffat wrote:
On Sat, Feb 23, 2019 at 09:32:18AM +, DJ Lucas via blfs-support 
wrote:

On 2/23/2019 3:14 AM, Ken Moffat via blfs-support wrote:

I had a reply off-list suggesting that I try without the local cert
directory. So I renamed that, and retried. Running make-ca -g
succeeded but told me that the certs were up to date. Running make-ca
-f succeeded, the final output was: Certificate: Global Chambersign
Root - 2008 Keyhash: 0c4c9b6c Added to p11-kit anchor directory with
trust 'C,C,'. Extracting OpenSSL certificates to
/etc/ssl/certs...Done! Extracting GNUTLS server auth certificates to
/etc/pki/tls/certs/ca-bundle.crt...Done! Extracting GNUTLS S-Mime
certificates to /etc/pki/tls/certs/email-ca-bundle.crt...Done!
Extracting GNUTLS code signing certificates to
/etc/pki/tls/certs/objsign-ca-bundle.crt...Done! Extracting Java
cacerts (JKS) to /etc/pki/tls/java/cacerts...Done! And running links
to an https: site from chroot now works. I'll keep this around for a
bit in case you are replying to my earlier reply, but I need to sort
out some food, then I'll probably go shopping and then wind down and
go to bed.

Bad cert in the /etc/ssl/local directory caused that to cascade like
that? I can't see how, but I'll have to figure it out. If you still 
have

it around and it's not too much trouble (and nothing private in
/etc/ssl/local), could you tar up the contents and send, or is it just
the example cacert.org certs?
--DJ


I don't have any current use for local certs, I was just trying to
follow the book.  Maybe something in what I thought I had copied
from the book is wrong.  So here is the commented-out part. KM_LOG
points to my log for this package, and apologies if I've mis-pasted
or failed to update this and wasted your time.


#install -vdm755 /etc/ssl/local >$KM_LOG 2>&1
#wget http://www.cacert.org/certs/root.crt >>$KM_LOG 2>&1
#wget http://www.cacert.org/certs/class3.crt >>$KM_LOG 2>&1
#openssl x509 -in root.crt -text -fingerprint -setalias "CAcert 
Class 1 root" \
#    -addtrust serverAuth -addtrust emailProtection -addtrust 
codeSigning \

#    > /etc/ssl/local/CAcert_Class_1_root.pem >>$KM_LOG 2>&1
#openssl x509 -in class3.crt -text -fingerprint -setalias "CAcert 
Class 3 root" \
#    -addtrust serverAuth -addtrust emailProtection -addtrust 
codeSigning \

#    > /etc/ssl/local/CAcert_Class_3_root.pem >>$KM_LOG 2>&1

But, looking at the contents: clearly wget has failed.

-rw-r--r-- 1 root root 0 Feb 23 05:15 CAcert_Class_1_root.pem
-rw-r--r-- 1 root root 0 Feb 23 05:15 CAcert_Class_3_root.pem


Is there something more pertinent out there? In addition to those, I
install the US military CAs and intermediates, but that's a mess of 111
certificates and a nasty script in and of itself (I just cleaned it up
and pushed it to http://www.linuxfromscratch.org/~dj/get-us-gov-certs.sh
if anybody needs them). I think we should just drop the example all
together, and leave the instructions in the man page. I figure for
better than 99% of our users, the Mozilla CAs are sufficient. Only a
handful of users would want to do overrides or append for local use
cases. Even Windows domains (if named properly) can use LE certs.

Any objections?


I'm not sure I understand the issue.   I've used the current 
instructions on my workstation, development system, and just yesterday 
on my laptop without problem.


In the dependencies, we might want to add wget.


I have had a problem with p11 configuration.  We now have

if [ -e /usr/lib/libnssckbi.so ]; then
  readlink /usr/lib/libnssckbi.so ||
  rm -fv /usr/lib/libnssckbi.so    &&
  ln -sfv ./pkcs11/p11-kit-trust.so /usr/lib/libnssckbi.so
fi

I think this could be replaced by just:

ln -sfvn ./pkcs11/p11-kit-trust.so /usr/lib/libnssckbi.so

  -- Bruce


The problematic instructions in question reside in this block:

install -vdm755 /etc/ssl/local &&
wget http://www.cacert.org/certs/root.crt &&
wget http://www.cacert.org/certs/class3.crt &&
openssl x509 -in root.crt -text -fingerprint -setalias "CAcert Class 1 root" \
-addtrust serverAuth -addtrust emailProtection -addtrust codeSigning \
> /etc/ssl/local/CAcert_Class_1_root.pem &&
openssl x509 -in class3.crt -text -fingerprint -setalias "CAcert Class 3 root" \
-addtrust serverAuth -addtrust emailProtection -addtrust codeSigning \
> /etc/ssl/local/CAcert_Class_3_root.pem

They seem to cause problems and are confusing. They also seem to be 
unnecessary. All I run is 'make install && make-ca -g' when I need to 
install this package. It seems those instructions were part of Ken's 
problem.


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

Re: [blfs-support] MiniBrowser question

[Douglas R. Reno via blfs-support]

On 2/23/19 7:40 AM, Cliff McDiarmid via blfs-support wrote:

Hi
  
The MiniBrowser that is part of WebKitGTK+.  Silly question maybe.  Can you save websites with this browser?  I can't see how.
  
thanks
  
Cliff
I don't think you can. You can try Ctrl+S if you want, but last time I 
checked, MiniBrowser's got no such functionality.

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

[blfs-support] Fwd: KDE Project Security Advisory: kauth: Insecure handling of arguments in helpers

[Douglas R. Reno via blfs-support]

If anyone has Frameworks below 5.55.0 installed, I recommend updating if 
it's not too disruptive.




 Forwarded Message 
Subject: 	KDE Project Security Advisory: kauth: Insecure handling of 
arguments in helpers

Date:   Sat, 09 Feb 2019 12:13:05 +0100
From:   Albert Astals Cid 
To: kde-annou...@kde.org



KDE Project Security Advisory
=

Title: kauth: Insecure handling of arguments in helpers
Risk Rating: Medium
CVE: CVE-2019-7443
Versions: KDE Frameworks < 5.55.0
Date: 9 February 2019


Overview

KAuth allows to pass parameters with arbitrary types to helpers running 
as root

over DBus. Certain types can cause crashes and trigger decoding arbitrary
images with dynamically loaded plugins.

Solution

Update to kauth >= 5.55.0

Or apply the following patch to kauth:
https://cgit.kde.org/kauth.git/commit/?id=fc70fb0161c1b9144d26389434d34dd135cd3f4a

Credits
===
Thanks to Fabian Vogt for the report and Albert Astals Cid for the fix.




-- 
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

[Douglas R. Reno via blfs-support]

On 2/8/19 9:37 AM, Cliff McDiarmid via blfs-support wrote:

lHi
I'm building a new LFS.  I've got to the Xorg testing and I'm booting 
into the three windows and clock.   I haven't got a left click twm 
menu though.  So i can't move the windwos etc.

Have googled this problem with no luck.   Any ideas?
thanks
Cliff


Hi Cliff,


Can you try installing the fonts in the Xorg Legacy Fonts page? I 
remember a report similar to this last year that was solved by doing that.


If so, I'll go update the book for it at my next commit.

Thank you!

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

Re: [blfs-support] regulatory.db

[Douglas R. Reno via blfs-support]

On 2/2/19 10:43 AM, Pol Vangheluwe via blfs-support wrote:



Op 19 jan. 2019, om 20:28 heeft Pol Vangheluwe 
mailto:pol.vanghel...@icloud.com>> het 
volgende geschreven:



Google brought me to Linux Wireless.  The regulatory database 
contains all national regulations about WiFi signals and can be 
downloaded form that site.
The site also hosts crda (Central Regulatory Domain Agent) and the 
following can be found in the README of that package:


CRDA is no longer needed as of kernel v4.15 since commit 007f6c5e6eb45
("cfg80211: support loading regulatory database as firmware file") added
support to use the kernel's firmware request API which looks for the
firmware on /lib/firmware. Because of this CRDA is legacy software for
older kernels. It will continue to be maintained.

My kernel is 4.15.7, so this may explain the error line in kern.log.
The problem is solved by downloading wireless-regdb (no install 
needed) and copying reg* to /lib/firmware.


pvg


It’s lonely here at BLFS, so I keep mailing with myself…

I have the same problem on my iMac G4, running LFS-8.1-systemd.  The 
solution is also the same:


*pol [ *~*]$ *git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git

*pol [ *~*]$ *cd wireless-regdb
*pol [ *~*]$ *sudo cp -v regu* /lib/firmware
*pol [ *~*]$ *cd ..
*pol [ *~*]$ *rm -rf wireless-regdb

My iMac G5 (64bit) is currently broken, it is also running 
LFS-8.1-systemd, but I have no journal logs to check if the same 
problem also popped up on this system.


The following questions remain:
1. am I really the only one in the LFS universum that got this error 
report?  Possibly due to a very particular kernel setting?
2. should the installation of the regulatory database be added to the 
instructions for wpa-supplicant?
3. is iwconfig indeed obsolete (as pretended by 
wireless.wiki.kernel.org ) and should 
it be replaced in BLFS by iw?


pvg

Can you try using packages out of BLFS SVN, or wait for the new release 
on March 1st? I have a PowerPC Mac, but it's not an iMac - it's a 
PowerMac G4 with the Airport card. It's unfortunately not high on my 
priority list though, with updates in BLFS taking priority for me. I 
have analyzed your reports though, and am trying to reproduce them.


In BLFS SVN, we do have iw.

-- 
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 older systems (python3, rust)

[Douglas R. Reno via blfs-support]

On 1/30/19 9:14 AM, Ken Moffat via blfs-support wrote:

Just a Heads Up to anyone else who updates firefox on older systems
(and thereefore needs to update rust for 1.32.0 : If using
python-3.6 (i.e. 8.2 and older) there are 223 extra tests failures,
all in rustdoc.

For the book's firefox (docs omitted to save time and space), that
probably doesn't matter - but for using it more generally it seems a
bad idea.  The obvious quick fix is to use python2 in this
situation.

The alternative is to upgrade python3 to the current 3.7 series -
this mail is intended as a reminder that ALL packages which
installed modules for 3 need to be rebuilt when upgrading to a newer
minor version (technically, the same is true for python2, but 2.7 is
hopefully the last-ever minor version).

I happened to list my installed modules a bit over a year ago (which
fits well with the need to update my 8.1, 8.2 BLFS systems).  other
people maybe installed other programs which also had python3
modules, but for me the following programs will need to be updated if
they are currently installed, in the correct order:

Now in LFS:
  meson
  Python3 (of course)

Modules
  dbus-python
  lxml
  Mako
  MarkupSafe
  pycairo
  pygobject3
  pyparsing
  Six

Other programs
  gedit
  gexiv2
  lensfun (not in the book, I tried this a couple of times in the past)
  newt

ISTR there is also an optional dependency for Falkon - PySide2.
But people who use that have probably moved on to using pip to
install modules.

ĸen


I'd like to add an addendum to this post.

If you upgrade minor (NOT point) versions of Ruby, you have to reinstall 
all applications that have bindings for them. On my development system, 
that included:


SWIG
Subversion
Graphviz

So for example, going from Ruby 2.5 to Ruby 2.6 makes all 2.5.x modules 
unusable with 2.6. This is similar to how Perl does things for minor 
versions as well I think.


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

Re: [blfs-support] Error compiling ICU4C-63.1 on a RaspberryPi 3B+

[Douglas R. Reno via blfs-support]

On 1/27/19 4:46 PM, Jim Baize via blfs-support wrote:

Hello list.

This is my first time posting to this list but I will try to be as 
thorough as I can be.


I installed LFS on my RPi3B+ following the instructions found here 
(http://intestinate.com/pilfs/guide.html) and here 
(http://www.linuxfromscratch.org/lfs/view/development/). (Technically, 
I let the RPi scripts install LFS in both Ch 5 & 6).


Everything seemed to install without a hitch.  I was able to boot up 
the RPi and I got my SSH server working so I can SSH into the machine.


After this, I started following the "package_users" install method 
found here 
(https://www.javacrypt.com/lfs/my_lfs_7_4_notes_for_1.6.2.txt). Other 
than the "package_users" scripts, I did not install any packages from 
those instructions.


I installed several packages using this method with little issue, 
until I came to ICU4c-63.1.  Neither the "package_users" install 
method nor the BLFS install method were able to install this package.  
They both gave the same error message.


I even tried to make the changes as noted here 
(https://github.com/unicode-org/icu/commit/9ec2c332c1c9156323944ea2b15c2b91952efae4) 
which seemed to have no effect.


The package seems to configure just fine.  It is only when I try to do 
"make" does it fail.  I believe the relevant lines are:


../../common/unicode/ustring.h:931:63: note: in definition of
macro 'U_STRING_DECL'
 #   define U_STRING_DECL(var, cs, length) static const UChar
*var=(const UChar *)U_DECLARE_UTF16(cs)
       ^~~

LD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY_PATH
 ../../bin/genrb -e UTF-8 -s resources -d uconvmsg root.txt
../../bin/genrb: error while loading shared libraries:
../../lib/libicudata.so.63: internal error
make[2]: Leaving directory '/usr/src/icu/icu/source/extra/uconv'
make[2]: *** [Makefile:175: uconvmsg/root.res] Error 127
make[1]: Leaving directory '/usr/src/icu/icu/source/extra'
make[1]: *** [Makefile:49: all-recursive] Error 2
make: *** [Makefile:153: all-recursive] Error 2


(Full make output is in this pastebin 
(https://pastebin.com/8iu9xrTZ))  (if using pastebin in this manner is 
inappropriate, please let me know.)


If anyone could help point me in the right direction, I would be much 
obliged.



Hi Jim,


I found a patch at Arch Linux ARM that might help you out, but I am not 
100% certain if it will or not. Try making the changes in the following 
patch and get back to us:



https://archlinuxarm.org/packages/arm/icu/files/icudata-stdlibs.patch


Jim

 
	Virus-free. www.avg.com 
 




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

Re: [blfs-support] exiv2-0.27.0 update breaks gexiv2-0.10.8 on blfs-svn

[Douglas R. Reno via blfs-support]

On 1/3/19 2:54 PM, Thanos Baloukas via blfs-support wrote:

On 3/1/19 10:22 μ.μ., Armin K. via blfs-support wrote:

On 3.1.2019. 20:40, Thanos Baloukas via blfs-support wrote:
../gexiv2/gexiv2-startup.cpp:10:10: fatal error: exiv2/xmp.hpp: No 
such file or directory


The header name changed to xmp_exiv2.hpp, but if I substitute all
occurrences with sed, it still fails with

In file included from ../gexiv2/gexiv2-stream-io.cpp:13:
../gexiv2/gexiv2-stream-io.h:28:23: error: missing binary operator 
before token "("

  #if EXIV2_TEST_VERSION(0,26,0)

The soname changed. Arch Linux and Fedora are still on exiv2-0.26
Am I missing something?



You could try using gexiv2-0.10.10

 From 
http://ftp.acc.umu.se/pub/gnome/sources/gexiv2/0.10/gexiv2-0.10.10.news


gexiv2 0.10.10 - 01 Jan 2019

   * Fix building against exiv2 0.27


Thanks. I should have seen that in Package Currency. It builds fine.

It's queued in my sandbox. It'll be in my next commit, which should 
hopefully be later tonight assuming that Samba starts cooperating.


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

Re: [blfs-support] Linux-PAM-1.3.0 & Shadow-4.6 & Systemd-239 and dependencies

[Douglas R. Reno via blfs-support]

On 11/26/18 5:00 PM, Hans Malissa via blfs-support wrote:
On Nov 24, 2018, at 02:38 AM, Pierre Labastie via blfs-support 
 wrote:

On 24/11/2018 08:16, Hans Malissa via blfs-support wrote:
Hi all, 

I would like to install Linux-PAM-1.3.0 (LFS 8.3-systemd), and in 
the chapter
on the package it says that I should reinstall Shadow-4.6 and 
Systemd-239
afterwards. Since these three packages need to be installed 
consecutively, I'm
now trying to figure out which dependencies need to be installed and 
in which

order. It seems to me that there are some circular dependencies:
1.) Linux-PAM-1.3.0 depends on libtirpc-1.0.3, which makes use of 
MIT Kerberos

V5-1.16.1, which depends on OpenLDAP-2.4.46, which depends on Cyrus
SASL-2.1.26, which makes use of Linux-PAM-1.3.0, MIT Kerberos 
V5-1.16.1, and
OpenLDAP-2.4.46. This seems to be a circular dependency, and I 
wonder in which

order these need to be installed.
2.) Systemd-239 depends on Polkit-0.114, which depends on 
GLib-2.56.1. GLib
depends on shared-mime-info-1.10 and desktop-file-utils-0.23 (at 
least for the
tests), but both of them depend on GLib-2.56.1 -- this is mentioned 
in the
chapter on GLib, but it is still not clear to me in which order I 
need to
install those. GLib also depends gobject-introspection-1.56.1 which 
also needs
GLib-2.56.1. GLib also has an optional dependency on dbus-1.12.10, 
but that in
turn depends on Systemd-239. I'm quite confused in which order these 
need to

be installed.
In which order do you usually install Linux-PAM-1.3.0, Shadow-4.6, and
Systemd-239 along with all dependencies?
Thanks a lot,



All circular dependencies need a double install. For instance, if 
package a

depends on package b, which depends on package a, you may install:
package a, then package b, then package a again

But you could as well install:
package b, then package a, then package b again

To choose the first package to install, as a rule of thumb, you 
should begin

with those who are required/recommended before those who are optional...
When there is a circular dependency between packages both at the
required/recommended level, the book tells which one to build first. 
When both
are optional, the book doesn't tell anything: the developers of the 
book do

not test optional dependencies on a regular basis, so they do not put
information which could become obsolete in the book.

Now, you do not have always to rebuild a package, even if there is an 
optional

dependency: it depends on whether you want the functionality added by the
circular dependency. For example, I've never built libtirpc before 
Linux-PAM,
because I do not need the added functionality (I don't even know what 
it is,

actually :).

To answer your question, here is the order I use:
cracklib, linux-PAM, libcap-PAM, shadow, systemd, cyrus-sasl, 
openldap. I do

not need Kerberos, so I do not build it (except for testing the book).

For glib, first build it, then gobject-instrospection, then dbus. 
Note that
you have already dbus and systemd from LFS (or after installing 
linux-PAM).
Once you have all those, you may install the dependencies for the 
glib tests,

and rebuild and test glib... But are you sure you need testing glib?


Thanks for the explanation. I've successfully compiled & installed 
glib following your instructions. The glib tests are successful when I 
build it for the second time (I try to test all packages as far as 
possible, following the instructions in the BLFS book).
I am aware that systemd and dbus were installed during LFS 
8.3-systemd; but what about BLFS 8.3-systemd packages that explicitly 
list either of these two as a dependency? I used to think that the 
BLFS book implicitly assumes that LFS packages are installed, so when 
a package like systemd or dbus (from LFS) is listed explicitly as 
dependency in BLFS, I was assuming that I need to re-build it at this 
point. Is this not correct?

Thanks a lot,

Hans



That is correct. Some packages such as xorg-server explicitly link to 
systemd-logind for seat and session management. systemd-logind needs PAM 
and Polkit for seat/authentication management (it makes a common 
interface for distributions to use since some have /etc/passwd and 
/etc/group in non-standard locations [Manjaro as an example]). You'll 
need to rebuild both dbus and systemd here using the BLFS instructions.


I highly doubt we'll ever add Linux-PAM to LFS. It's too complex.


Douglas R. Reno

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

Re: [blfs-support] network manager-1.18.6 error

[Douglas R. Reno]

On Sun, Aug 26, 2018, 9:56 AM spiky0011  wrote:

>
> On 26/08/2018 15:42, lei niu wrote:
>
> No. You have to install libnetworknanager-glib first.
>
> lei niu
> 邮箱：niuneil...@gmail.com
>
> 
>
> 签名由 网易邮箱大师  定制
>
> On 08/26/2018 22:16, spiky0011  wrote:
> Systemd-svn version
>
> Building network manager-1.18.6 i get an error
>
> "Native dependency libnotify found: YES 0.7.7
> Determining dependency 'libnm' with pkg-config executable
> '/usr/bin/pkg-config'
> Called `/usr/bin/pkg-config --modversion libnm` -> 0
> 1.12.2
> Called `/usr/bin/pkg-config --cflags libnm` -> 0
> -pthread -I/usr/include/libnm -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include
> Called `/usr/bin/pkg-config libnm --libs` -> 0
> -L/usr/lib -lnm -lgio-2.0 -lgobject-2.0 -lglib-2.0
> Called `/usr/bin/pkg-config libnm --libs` -> 0
> -lnm -lgio-2.0 -lgobject-2.0 -lglib-2.0
> Native dependency libnm found: YES 1.12.2
> Determining dependency 'libnm-glib' with pkg-config executable
> '/usr/bin/pkg-config'
> Called `/usr/bin/pkg-config --modversion libnm-glib` -> 1
>
>
> meson.build:191:2: ERROR:  Native dependency 'libnm-glib' not found"
>
> I have all the deps installed
>
> Any ideas plz?
>
>
> --
> http://lists.linuxfromscratch.org/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>
>
> Sorry When I build network-manager-applet I get the error not
> NetworkManager, yes NM was built with glib-2.56.1 and dbus-glib
> --
> http://lists.linuxfromscratch.org/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>

Did you ensure that -Dlibnm_glib (or something similar. I'm not at my PC)
was on? I could have sworn I just fixed that.

What init system are you on?

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

Re: [blfs-support] Unbound slow to start with recent kernels on some machines

[Douglas R. Reno]

On Wed, Jul 18, 2018 at 8:04 PM Ken Moffat  wrote:

> On Sat, Jun 02, 2018 at 10:02:39PM +0100, Ken Moffat wrote:
>
> > I've been seeing problems on some of my machines with recent kernels
> > (first noticed in 4.17-rc, but it also now happends in 4.16.4 or
> > later).  The problem is that instead of unbound taking a handful of
> > seconds to start (often, it is all-but immediate), on the affected
> > machines it now takes up to two and a half minutes.
> >
>
> Finally, making slow progress on this.  The problem is caused by the
> fix for CVE-2018-1108.  A little while ago Ted Ts'o offered a patch,
> possibly as an RFC, to use entropy from the hwrng (unsafe for
> critical things like key generation, but it allows less-important
> things, e.g. in systemd units, to run and therefore it lets the box
> boot in the absence of real entropy.
>
> Apparently he did this because fedora are starting to derive
> "entropy" from jitter so that e.g. VMs can boot in a meaningful
> time.
>
> For my haswell that was great, but for my kaveri it made no
> difference - turns out that the kaveri does NOT have a hwrng (I
> enabled the option, and /dev/hwrng exists, but reading it with dd
> reports 'No such file').
>
> And the patch which introduced this fix can no-longer be reverted,
> parts of the file, at least in 4.18-rc5, have been rewritten.
>
> What I will now be looking at is twofold:
>
> 1. start the random bootscript earlier (currently it is S25, but
> unbound is S21; S15 - just after sysklogd - looks likely).
> For systemd, I've no idea how to change the dependencies.
>
>
>

While option 2 is nice, for systemd, it'll be a one-liner configuration
change.

We could probably even do it as a sed.

We'd have to change it to Requires=haveged
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Build v4l-utils-1.14.2 error, missing glx.h.

[Douglas R. Reno]

On Mon, Jul 16, 2018 at 8:24 AM niuneilneo  wrote:

> Hi everyone,
>
> I am building Gnome from scratch, and this time I stuck at building
> v4l-utils-1.14.2 (sorry for Chinese character, but I still think you can
> understand where are the problem lines):
>
> make[3]: 进入目录“/home/neil/gnome/v4l-utils-1.14.2/contrib/test”
>   CC v4l2gl.o
> v4l2gl.c:28:10: 致命错误：GL/glx.h：没有那个文件或目录
>  #include 
>   ^~
> 编译中断。
> make[3]: *** [Makefile:599：v4l2gl.o] 错误 1
> make[3]: 离开目录“/home/neil/gnome/v4l-utils-1.14.2/contrib/test”
> make[2]: *** [Makefile:471：all-recursive] 错误 1
> make[2]: 离开目录“/home/neil/gnome/v4l-utils-1.14.2/contrib”
> make[1]: *** [Makefile:582：all-recursive] 错误 1
> make[1]: 离开目录“/home/neil/gnome/v4l-utils-1.14.2”
> make: *** [Makefile:509：all] 错误 2
>
> I only digest the part of log related with my problem. I think this is
> caused by missing GL/glx.h. Before I come to this phase, I download
>  andfrom the khronos.org website to
> overcome the same problems like missing glx.h.
>
> My question is which LFS package containing these gl*.h headers, because I
> know to solve these problems by downloading headers is not the correct
> solution.
>
>
> Yours sincerely,
> Lei
> --
> http://lists.linuxfromscratch.org/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>

Try installing GLU
-- 
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-Basic

[Douglas R. Reno]

On Tue, Jul 10, 2018, 5:52 PM Bruce Dubbs  wrote:

> On 07/10/2018 05:46 PM, Douglas R. Reno wrote:
>
> > Would this be the time to suggest a change in policy on tickets? I'd
> > like to see tickets have the changelog for the package and security
> > updates marked as such. It would make people's lives a lot easier.
>
> I'm not sure what you mean Douglas.  Most of the time we add the release
> notes or change log to the tickets.  However some packages do not say
> what changed (e.g. libinput).
>
>--
>

I have seen it with the most recent package updates. Most of the time,
depending on the editor, the changes are listed. The samba, php, etc.
updates that were recently completed were not listed with changes.

Another thing - would it be worth adding a page to tell potential
contributors how to contact you (Bruce) regarding contributions?

I dont know if anyone here has heard of Discord, but there is a LFS discord
ran unofficially there with lots of people who use it daily and could
possibly contribute. I lurk there occasionally. It can be used over both a
web browser or a desktop application.

>
-- 
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-Basic

[Douglas R. Reno]

On Tue, Jul 10, 2018, 5:44 PM Ken Moffat  wrote:

> On Tue, Jul 10, 2018 at 02:23:38PM -0700, Jalus Bilieyich wrote:
> > Having multiple parts of the book being split up and teams working on
> > each part is a good idea in my opinion.
> >
>
> Except at the moment we have one small team and in general people
> pick things they think they can handle.  In my case, a lot of the
> things I care about are spread throughout the 'Basic' and 'Advanced'
> parts, and I'm sure the other editors will say the same.  So I'm not
> convinced that separate teams is going to work.
>
> For the moment I'm mostly stepping aside, as previously noted.
>
> I hope to keep an eye on firefox (past experience suggests that
> trying to pick up the new version only when it is released is too
> painful), and almost every release has CVE fiexes, even 61.0 did
> (although those were not initially in the Release Notes).
>
> Eventually I hope to be able to devote a bit more time to this, but
> for the next few months that is now less likely.
>
> But the big problems as I see them are:
>
> · lack of people building the development book and finding issues
>
> · lack of people willing and able to edit
>
> And of those, the second is the greater problem.
>
> So, since we are now hopefully looking at longer-term changes,
> anybody else got other suggestions for changed format/process ?
>
> Please ?
>
> ĸen
> --
>   Keyboard not found, Press F1 to continue
> --
> http://lists.linuxfromscratch.org/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>

Would this be the time to suggest a change in policy on tickets? I'd like
to see tickets have the changelog for the package and security updates
marked as such. It would make people's lives a lot easier.

>
-- 
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-Basic

[Douglas R. Reno]

On Mon, Jul 9, 2018 at 3:09 PM Bruce Dubbs  wrote:

> As most of you know, BLFS is huge.  If it is printed on paper, it would
> take over 2000 pages.  There are over a thousand individual packages in
> the book.
>
> In addition, upstream changes are released often.  The average is about
> 3.5 packages every day, seven days a week.
>
> Since LFS/BLFS contributions are done completely by volunteers, the
> upstream change rate is overwhelming our ability to keep up to date.
> The problem is not LFS.  That is doable.  The problem is the size and
> change rate of BLFS.
>
> To address this, I am proposing to split BLFS into two (or possibly
> more) books.  My tentative names are BLFS-Basic and BLFS-Advanced.
> BLFS-Basic is primarily command line tools and programs plus the basic
> Xorg section of BLFS.  This would be updated regularly and a 'stable'
> version released every six months with the LFS book.  The BLFS-Advanced
> book will be a 'rolling release'. We did this with BLFS between LFS
> versions 6.3 and 7.4 (August 2008 until September 2014).
>
> With a rolling release, there is less consistency and a comprehensive
> check against the current stable LFS is not done.  Packages would be
> frequently out of date.
>
> For BLFS-Basic I am attaching a straw man for the contents.  I
> anticipate that an experienced LFS builder could complete all the
> packages in BLFS-Basic in a day or two.
>
> I am now looking for feedback.  Are there other solutions?  Is my list
> for BLFS-Basic too large?  Is there something missing?
>
>-- Bruce
> --
> http://lists.linuxfromscratch.org/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>

After spending hours attempting to come up with something, considering the
amount of variations, I'll share what I have.

I'm of the opinion that we should do one more release of the book as it is
and then discuss things after that. I'm  willing to put in as much time as
needs to be put in to keep everything in the book that is currently in
there, for one more release at minimum. Consistency is the thing that is
the most important to me, and one more release would also give people who
use LFS in production the time to adapt their systems for the new changes.
It's way too big of a change to make 1-2 months before release, this should
really be done after.

I've got permission from those around me to contribute as much time as
necessary. I'll test both sysvinit and systemd before release if necessary
as well.

I'm saying this as a person who used to work for a company (not to be named
publicly) that used LFS in production on factory and CNC systems. I'm also
saying this as one who uses it in PROD for weather modeling systems. We
need more than 1-2 months for a huge structure change.
-- 
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

[Douglas R. Reno]

On Thu, Aug 24, 2017 at 6:11 AM, Cliff McDiarmid <cliffhan...@gardener.com>
wrote:

> Hi
>
> Just finished compiling Gnome as part of BLFS 8.0 systemd.   This is my
> first venture into Gnome, been with KDE for 17 years!
>
> When starting from the command line, i.e. gnome-session, I get the
> following seg, fault:
>
> gnome-session-f[3065]: segfault at 0 ip 7f17482e79a9 sp
> 7ffcfe694900 error 4 in libgtk-3.so.0.2200.4[7f1748013000+6e5000]
>
> This has been a problem.  Found the following thread here:
>
> https://bbs.archlinux.org/viewtopic.php?id=218168
>
> It mentions everything from Microcode to Mutter.   None of it makes a
> difference.  Any ideas from yourselves?
>
> thanks
>
> Cliff
> --
> http://lists.linuxfromscratch.org/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>


Hi Cliff,

I'm in the process of building GNOME for BLFS 8.1 currently.

I'll report back when it's done and see if I have the same problem.

In the meantime, what GPU are you using? I know Nouveau has been weird with
GNOME Shell / Mutter recently.

Douglas R. Reno
--LFS/BLFS systemd maintainer
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Runtime dependency? (It doesn't say.)

[Douglas R. Reno]

On Thu, Jun 15, 2017 at 2:23 PM, Paul Rogers 
wrote:

> > >> Patches accepted.
> > >
> > > I've seen your HTML source, it's rather more involved than the HTML-3 I
> > > learned to hand-code many years ago.  I just used pico to make my
> > > website.  Apparently you have a much more complex infrastructure.  I'm
> > > not at all sure I CAN make an insertion without messing something up.
> I
> > > suppose you have some sort of WYSIWYG editor, DocBooks (which I've
> never
> > > installed nor used) or some such?  I dunno.
> >
> > First you need subversion:
>
> Got that--only to fetch things without tarballs.
>
> >
> > svn co svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK/
> >
> > See INSTALL and README there, but you will need:
> >
> > libxml2
> > libxslt
>
> And those, of course.
>
> > docbook-xsl-1.79.1
> > docbook-xml-4.5
> > tidy
>
> Last one too.
>
> I will try to come back to it once I get this new 7.10 (Hey, it's new to
> me!) build working--can't figure why I get no sound from ALSA even after
> finding the speakers got pushed off so many times they no longer work.
> (Using earbuds!  :o )  And that Nouveau issue is still outstanding.
> --
> Paul Rogers
> paulgrog...@fastmail.fm
> Rogers' Second Law: "Everything you do communicates."
> (I do not personally endorse any additions after this line. TANSTAAFL :-)
>
>
Paul,

If you haven't already, unmute the audio in alsamixer, it's muted by
default
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] ImageMagick and Emacs-25.2 Version 2017-06-13

[Douglas R. Reno]

On Wed, Jun 14, 2017 at 6:01 AM, Richard Melville <6tric...@gmail.com>
wrote:

> I'm finding the book a little hard to follow on the emacs page.  Is it
> saying that emacs-25.2 doesn't support ImageMagick-7.0.4-8 but does support
> ImageMagick-6.9.7-8?  I don't have ImageMagick installed at all at present,
> so I'm assuming that if I install the full (but older) ImageMagick-6.9.7-8,
> then I'll be able to build emacs-25.2 against it in the normal fashion.  Is
> that correct?  I'm assuming that there are no known security issues
> associated with ImageMagick-6.9.7-8.
>
> Richard
>
> --
> http://lists.linuxfromscratch.org/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>
>
There are always known security issues with ImageMagick, but it releases
far too often for us to keep track of. If we were to update it more, we
probably would need an editor dedicated just to ImageMagick updates.
-- 
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

[Douglas R. Reno]

On Sun, Jun 11, 2017 at 4:02 AM, Michael Shell 
wrote:

> 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
>
>
It might still be. I maintain that set of packages in BLFS, and I install
gobject-introspection directly after glib2.

Chances are that if it does require it, we won't know until someone
mentions it.
-- 
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

[Douglas R. Reno]

On Tue, May 30, 2017 at 4:47 PM, Andrew Warshall 
wrote:

> On Sat, 27 May 2017 01:20:18 -0400
> Michael Shell  wrote:
>
> > 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".
> > 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.
>
>
> So the combination of (a) upgrading to kernel 3.12 (which is still old,
> but not as old as 3.10) and (b) turning off special graphical effects
> that I could live without anyway seems to have worked. It did, however,
> cause my USB to behave weirdly --- the mic wasn't recognized and the
> printer was on bootup but not if I unplugged and then replugged --- so
> I had to recompile enabling config option CONFIG_OHCI_HCD_PCI --- but
> then it worked. I'm not particularly inclined to experiment with
> whether it was (a) or (b) that fixed the problem, b/c I don't enjoy
> creating X server crashes --- but in case I'm feeling scientific (or
> for future reference) is there a way to check GPU temp? I put the
> machine together myself, so it's entirely possible I did a lousy job
> with the heatsink.
>
>  Thanks,
>
>  Andrew Warshall
>
>
You want to install lm-sensors and run the "sensors" command to check those
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] LFS on Windows

[Douglas R. Reno]

On Mon, May 15, 2017 at 10:30 AM, Paul Rogers <paulgrog...@fastmail.fm>
wrote:

> Not too long ago we had a question about installing LFS on/with Windows,
> but it'd be fair to say there was little to say about it.  I ran across
> this article today:
>
> https://arstechnica.com/information-technology/2017/
> 05/windows-server-will-add-the-linux-subsystem-join-the-insider-program/
>
> Not too much info there, but it does have some links.
>


I've been working on it a little bit recently. One of my friends gave me
remote access (RDP and Chrome Remote Desktop) to a Windows Server 2016 and
Windows 10 PC. I've run into some interesting issues with the standard
Ubuntu install, in particular because the syscalls are emulated, and it's
VERY slow... but it works (with a ton of modifications).

When I get a system completed, I'll take notes and spread the knowledge.

It's also worth noting that parallelization doesn't work, and because of
the emulation, the overhead is HUGE.If I run -j4, it actually slows it down
by a factor of four because it can only run one large process at a time.

For future reference, the system that I've been playing with this on has an
i7-7700k with 16GB of RAM (it's his gaming rig). The SBU value is over 15
minutes...

I've been using jhalfs on it, but I'm tempted to do a build manually and
record it so that we have a general idea of how long it takes.

Also, sudo barely works (I had to modify jhalfs to let me run as root), and
it's impossible to mount filesystems, even if you create a file for LFS and
mount that as an ext4 in /mnt/lfs instead. I also had to create a symlink
from /proc/self/mounts to /etc/mtab as well, as that did not come as
default.

I actually needed autoconf/automake/autogen because GCC wanted to try
compiling for a new architecture and requested it.

TL;DR - finished the temporary toolchain after 16 hours, and it's really
slow... but it's functional.

Douglas R. Reno
--LFS/BLFS systemd maintainer
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] geoclue-2.4.6

[Douglas R. Reno]

On Fri, May 5, 2017 at 6:38 PM, Ian Macdonald  wrote:

> Trying to configure geoclue-2.4.6 without ModemManager and Avahi seems
> to require --disable-cdma-source and --disable-nmea-source as well as
> the switches mentioned.
>
> Or, as usual, is it just me.
>

I'll add this to the Command Explanations section at my next commit, but it
should be noted that we assume that all users have the recommended
dependencies installed when updating packages. I think we have a policy in
the book somewhere (not in front of my PC currently) where we state that
Recommended dependencies are dependencies that we assume are installed, but
may need special switches to disable if the user doesn't have them
installed.
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Starting the avahi-daemon under systemd

[Douglas R. Reno]

On Sun, Apr 30, 2017 at 10:10 AM, Pol Vangheluwe <pol.vanghel...@icloud.com>
wrote:

> Just want to report this small problem (without functional impact at first
> sight).
> The BLFS book says to simple “enable" the avahi-daemon systemd unit, but I
> find this in the system logs:
>
> apr 30 14:49:12 ppc125 avahi-daemon[222]: *chroot.c: open() failed: No
> such file or directory*
> apr 30 14:49:12 ppc125 avahi-daemon[212]: *Failed to open
> /etc/resolv.conf: Invalid argument*
>
> This is a symlink:
>
> lrwxrwxrwx 1 root root 32 10 okt  2015 /etc/resolv.conf ->
> /run/systemd/resolve/resolv.conf
>
> Looks like the avahi-daemon is launched before the configuration file is
> created by systemd-resolved.
> There is maybe a need to add a systemd unit file for avahi, describing the
> dependency to systemd-resolved?
>
> Remark: my system is LFS-7.7 and I followed BLFS-7.6, but the BLFS-8.0
> instructions are very similar, so I expect the same problem there.
>
> pvg
>
>
Hello,

Those are harmless and to be expected. I've had them on every single
version of BLFS systemd that I've used (and as the maintainer, that's all
of them). Avahi continues to work fine. It's actually an issue in glibc,
but we're waiting for a new version of Avahi to fix this up.  In the
meantime, it should be fine.

Thanks,

Douglas R. Reno
LFS/BLFS systemd maintainer
-- 
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-dev] IBus-1.5.15 build failure

[Douglas R. Reno]

On Sat, Apr 29, 2017 at 11:29 PM, Wayne Blaszczyk <wblas...@bigpond.net.au>
wrote:

> Moving to BLFS Support.
>
> On Sat, 2017-04-29 at 10:49 -0500, Bruce Dubbs wrote:
> > Wayne Blaszczyk wrote:
> > > Ibus fails to build (during make) for me due to the sed command.
> > > Removing the sed command fixes the build.
> > > Sorry, I didn't capture the error.
> >
> > Wayne, we need to know more than that.   I just did a quick build with
> the
> > sed and is builds fine for me.   I don't use it, so I did not test other
> > than make check which passes for me.
> >
> >-- Bruce
> >
> >
> >
> >
>
> Here's the last bit of the output:
>
>   CC   ibus_x11-main.o
>   CC   ibus_x11-gdk-private.o
>   CCLD ibus-x11
> make[3]: Leaving directory '/opt/sources/ibus-1.5.15/client/x11'
> make[3]: Entering directory '/opt/sources/ibus-1.5.15/client'
> make[3]: Nothing to be done for 'all-am'.
> make[3]: Leaving directory '/opt/sources/ibus-1.5.15/client'
> make[2]: Leaving directory '/opt/sources/ibus-1.5.15/client'
> Making all in data
> make[2]: Entering directory '/opt/sources/ibus-1.5.15/data'
> Making all in annotations
> make[3]: Entering directory '/opt/sources/ibus-1.5.15/data/annotations'
> make[3]: Nothing to be done for 'all'.
> make[3]: Leaving directory '/opt/sources/ibus-1.5.15/data/annotations'
> Making all in icons
> make[3]: Entering directory '/opt/sources/ibus-1.5.15/data/icons'
> make[3]: Nothing to be done for 'all'.
> make[3]: Leaving directory '/opt/sources/ibus-1.5.15/data/icons'
> Making all in keymaps
> make[3]: Entering directory '/opt/sources/ibus-1.5.15/data/keymaps'
> make[3]: Nothing to be done for 'all'.
> make[3]: Leaving directory '/opt/sources/ibus-1.5.15/data/keymaps'
> Making all in dconf
> make[3]: Entering directory '/opt/sources/ibus-1.5.15/data/dconf'
>   GEN  org.freedesktop.ibus.gschema.xml.in
> /bin/sh: gsettings-schema-convert: command not found
> make[3]: *** [Makefile:767: org.freedesktop.ibus.gschema.xml.in] Error 127
> make[3]: Leaving directory '/opt/sources/ibus-1.5.15/data/dconf'
> make[2]: *** [Makefile:569: all-recursive] Error 1
> make[2]: Leaving directory '/opt/sources/ibus-1.5.15/data'
> make[1]: *** [Makefile:682: all-recursive] Error 1
> make[1]: Leaving directory '/opt/sources/ibus-1.5.15'
> make: *** [Makefile:589: all] Error 2
>
> Regards,
> Wayne
>

Greets, Wayne.

We're missing a dependency in the book, you need to install GConf. I'll
update it at my next commit.

Thanks,

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

Re: [blfs-support] gdk-pixbuf and shared-mime-info

[Douglas R. Reno]

On Thu, Mar 9, 2017 at 7:05 AM, Hazel Russman 
wrote:

> May I suggest that shared-mime-info be added as a run-time dependency of
> gdk-pixbuf. The library doesn't function properly without it. For example,
> gtk programs that use gtk_file_filter_add_pixbuf_formats() as a file
> filter don't let anything through unless shared-mime-info is installed.
>

Hello Hazel,

We have shared-mime-info as a runtime dependency of glib currently. Users
should build it after glib as all of the functions that glib provides that
need MIME support use it.
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Upcoming release of BLFS 8.0

[Douglas R. Reno]

On Fri, Feb 24, 2017 at 2:57 AM, Wayne Blaszczyk 
wrote:

> On Thu, 2017-02-23 at 14:34 -0600, Bruce Dubbs wrote:
> > We are very close to being able to release BLFS-8.0.  All packages have
> > been built with current instructions and package versions in the
> > development book.  A few remain to be tested.
> >
> > If you have any inputs, please let us know asap.  We may be able to
> > release both LFS and BLFS as early as Saturday.
> >
> >-- Bruce
>
> I haven't built LFS 8.0 rc, so I would just like to confirm where usermod
> is
> installed, /usr/sbin or /sbin? This in in relation to the networkmanager
> instructions. On my current system I have it installed under /usr/sbin.
>
> Wayne.
> --
> http://lists.linuxfromscratch.org/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>

Hi Wayne,

On my system, it's installed in /usr/sbin.

ls /usr/sbin | grep usermod
usermod
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] systemd LFS build 8.0-rc1

[Douglas R. Reno]

On Thu, Feb 23, 2017 at 1:07 PM, Riccardo G Corsi 
wrote:

> Hi, I had a problem in compiling systemd-232 in the (new) LFS 8.0-rc1
> (Linux From Scratch - Version 8.0-rc1-system)
>
> Configure alerts: configure: error: *** POSIX caps library not found
>
> I have libcap.so and libattr.so installed this is my ls:
>
> -rwxr-xr-x 1 root root 67344 Feb 20 20:09 /lib/libattr.so.1.1.0
> -rw-r--r-- 1 root root 62200 Feb 23 18:38 /lib/libcap.so.2.25
>
> In config.log I read:
>
> configure:16517: gcc -o conftest -g -O2   conftest.c -lcap >&5
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../lib/libcap.so: file
> not recognized: Is a directory
> collect2: error: ld returned 1 exit status
> configure:16517: $? = 1
>
> (lrwxrwxrwx 1 root root 10 Feb 20 20:12 /usr/lib/gcc/x86_64-pc-linux-g
> nu/6.3.0/../../../../lib/libcap.so -> ../../lib/)
>
> Until now all tests seems to me ok.
>
> Thanks a lot as usual to all LFS team.
>
>

Hi Riccardo,

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

Re: [blfs-support] Error in GnuTLS-3.5.9 "Optional"

[Douglas R. Reno]

On Thu, Feb 23, 2017 at 5:26 AM, Richard Melville <6tric...@gmail.com>
wrote:

> GnuTLS-3.5.9 is shown as an optional dependency for itself.
>
> Richard
>
> --
> http://lists.linuxfromscratch.org/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>
>
Thanks for reporting that. I'm fixing it now.

I will admit that I may have had a little bit of a laugh after I saw it
myself.
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Bug in GPM-1.20.7. Could easily be patched.

[Douglas R. Reno]

On Sun, Feb 12, 2017 at 11:55 AM, Hazel Russman <hazeldeb...@googlemail.com>
wrote:

> On Sun, 12 Feb 2017 11:21:51 -0600
> Bruce Dubbs <bruce.du...@gmail.com> wrote:
>
> > Hazel Russman wrote:
> > > The program src/progs/display-buttons.c contains a reference to
> > > , a header that doesn't exist until gmp installs it. The
> > > reference should be to "src/headers/gpm.h" (or whatever the correct
> > > path is for finding internal header files).
> >
> > I agree that the build log shows these errors, but they do not affect the
> > program as far as I can tell.
> >
> > prog/display-buttons.c
> > prog/display-coords.c
> > prog/get-versions.c
> >
> > The easiest way to fix the build would be to just copy gpm.h to
> > /usr/include before configure, but what do these failed programs provide?
> >
> >-- Bruce
>
> The first two seem to be a sort of mouse equivalent to showkey. They only
> run on the console. They report on mouse coordinates and clicks until you
> interrupt them. Amusing, but I don't know what you would use them for in
> real life. The third one gives access to version information, probably
> because unprivileged users can't get this directly from gpm, which can only
> be launched by root.
>
> The point is, it's very alarming for the user to see actual failures
> during a build. At least I was alarmed. Maybe the book could say that you
> will see these failures and not to worry.
>
> --
>

Hazel,

I'm generating a patch for this now. It will be in the book in about an
hour.

Douglas R. Reno
--LFS/BLFS systemd maintainer
-- 
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 Systemd

[Douglas R. Reno]

On Fri, Feb 3, 2017 at 6:49 AM, Cliff McDiarmid <cliffhan...@gardener.com>
wrote:

> Right I'll try again.  Just seen the problem.
>
> Hi
>
> Am I right in saying that if I upgrade I will lose the enabled unit
> files?  I'm talking about the Systemd package here.
>
> thanks
>
> Cliff
>

It isn't often that I say this, but I'm not 100% sure. I don't think that
it will, but I've never upgraded systemd in place.

If we can assume that systemd in BLFS is an upgrade, then I would say that
it won't lose the enabled unit files. They are only symlinks, after all :-)

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

Re: [blfs-support] ghostscript 'make so' fails

[Douglas R. Reno]

On Thu, Feb 2, 2017 at 5:39 PM, Ken Moffat  wrote:

> On Thu, Feb 02, 2017 at 06:23:57PM +, Ken Moffat wrote:
> > In a fresh system, ghostscript's 'make so' fails - several warnings
> > which seem to be unchanged from my last build in November, but then
> >
> > In file included from ./psi/dxmain.c:38:0:
> > ./psi/iapi.h:215:1: note: expected 'char **' but argument is of type
> 'const char **'
> >  gsapi_get_default_device_list(void *lib, char **list, int *listlen);
> >  ^
> > make[2]: Leaving directory '/scratch/working/ghostscript-9.20'
> > make[1]: Leaving directory '/scratch/working/ghostscript-9.20'
> >
> > I'm way out of my depth on this, with no idea what changed. Any
> > suggestions, pretty please ?
> >
>
> Sat scratching my head, looked all through the log from the
> beginning of 'make so' but couldn't see any errors only warnings.
> Added some instrumentation to shout $? to my log after each command,
> gave it anther try and this time it sailed through.
>
> Odd, but works for me.
>
> > Meanwhile, I looked at Arch - they don't seem to make so - and then
> > at Fedora : nothing there for this problem, but a whole string of
> > CVE fixes - some in the last few days, some earlier - for
> > CVE-2016-7976/7977/7978/7979/8602/9601 although not all applied in
> > that order.
> >
> > I am tempted to apply all of these as security fixes (assuming, for
> > the moment, that they do apply), but it doesn't look as if they will
> > solve my FTBFS so I'm stalled.
> >
> I intended to post this to -dev, maybe I'll take that there or maybe
> I'll just let it lie for the moment - it's not as if details of the
> issues are at Mitre yet, although redhat and debian seem to know
> about them.
>
>
That is because they are embargoed. That's unfortunately the *corporate*
nature of Linux now (Thanks Novell, Red Hat, Microsoft (they have a huge
part now), and Debian). They don't want us to know about those problems
until it is too late, or the embargo expires, or both. Any time that Red
Hat or Debian get their hands on a CVE assignment, they never give MITRE
any information. There's an uber-secret list that I want to be a part of,
but we have to have a place to hide issues from Users first, among a
website detailing security advisories and many other requirements.
-- 
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-dev] RFC - Remove WebKitGTK+-2.4.11

[Douglas R. Reno]

On Wed, Feb 1, 2017 at 12:23 PM, Bruce Dubbs <bruce.du...@gmail.com> wrote:

> I am proposing the removal of WebKitGTK+-2.4.11.
>
> Currently it is only referenced in two places: midori and gimp.
>
> In the midori instructions, we already bypass 2.4.11 so the removal there
> will only require some minor text changes.  The comment we have now are out
> of date.
>
> In gimp, the help system depends optionally on WebKitGTK+-2.4.11.  If it
> is not used, the system browser is used.
>
> If there are no objections, I will archive WebKitGTK+-2.4.11 this weekend.
>
>   -- Bruce
>
>
I have no objections whatsoever at this time. In fact, I'll be happy to see
it disappear.

I probably need to find a way to dump it off my development system in order
to make sure that certain older GNOME libraries will continue to function.
Those applications just label the dependency as "WEBKITGTK" or something
similar, with no other indication as to what version that they are looking
for. GtkHTML might be an example, although I don't have a book in front of
me and am several hours away from one.

Douglas R. Reno
--LFS/BLFS systemd maintainer
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page