Re: [blfs-dev] Fwd: BLSF-10.1: polkit / shadow; nspr

[Xi Ruoyao via blfs-dev]

On Thu, 2021-04-22 at 08:31 -0500, Bruce Dubbs via blfs-dev wrote:
> 
> 
> 
>  Forwarded Message 
> Subject: BLSF-10.1: polkit / shadow; nspr
> Date: Thu, 22 Apr 2021 12:23:51 +0200
> From: Rainer Fiebig 
> To: Bruce Dubbs 
> 
> Hi!
> 
> polkit / shadow
> ***
> The following command doesn't work, the directory  /etc/polkit-1  is
> *not* being created:
> 
> useradd -c "PolicyKit Daemon Owner" -d /etc/polkit-1 -u 27 \
>  -g polkitd -s /bin/false polkitd
> 
> That's obviously due to a change in shadow, as its manpage (-4.8.1)
> now
> states that  - if missing - the homedir will *not* be created. For
> version 4.6 it says the opposite.

It won't break anything.  /etc/polkit-1 is installed by make install
then (though it now belongs to root, nothing bad is happening).

It seems polkit does not need a home directory for its user at all. 
Arch Linux uses / as the "home directory" of polkitd user.

> 
> Apart from that I suggest that
> 
> --enable-libelogind=no
> 
> be mentioned in the config-options for polkit because otherwise it
> won't
> build if elogind is not installed (as in my case).
> 
> 
> nspr
> 
> The following line doesn't work, bash-5.1 complains about a missing
> ']':
> 
> $([ $(uname -m) = x86_64 ] && echo --enable-64bit)
> 
> This does work, however:
> 
> $( if [[ $(uname -m) == x86_64 ]]; then  echo "--enable-
> 64bit"; fi )
> 
> 
> The first line does work in bash-4.4.18, though.

I can't reproduce this.  On my system and rivendell it works perfectly.
I believe the OP mistyped the command somehow (for example, missed the
space between x86_64 and ]).
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] libblockdev-2.25 doesn't compile

[Xi Ruoyao via blfs-dev]

On 2021-04-15 16:49 +0100, John Burrell via blfs-dev wrote:
> On Thu, 15 Apr 2021 at 15:25, Xi Ruoyao via blfs-dev
>  wrote:
> > 
> > On 2021-04-15 10:43 +0100, John Burrell via blfs-dev wrote:
> > > On Sat, 10 Apr 2021 at 16:10, Xi Ruoyao via blfs-dev
> > >  wrote:
> > > > 
> > > > On 2021-04-10 15:05 +0100, John Burrell via blfs-dev wrote:
> > > > > Using the systemd version of the development book, libblockdev-2.25
> > > > > gives:
> > > > > 
> > > > > vdo.c: In function ‘bd_vdo_stats_copy’:
> > > > > vdo.c:84:5: error: ‘g_memdup’ is deprecated: Use 'g_memdup2' instead
> > > > > [-Werror=deprecated-declarations]
> > > > >    84 | return g_memdup (stats, sizeof (BDVDOStats));
> > > > >   | ^~
> > > > > In file included from /usr/include/glib-2.0/glib.h:82,
> > > > >  from vdo.c:20:
> > > > > /usr/include/glib-2.0/glib/gstrfuncs.h:257:23: note: declared here
> > > > >   257 | gpointer  g_memdup (gconstpointer mem,
> > > > >   |   ^~~~
> > > > > cc1: all warnings being treated as errors
> > > > > 
> > > > > I didn't see a way to stop warnings being treated as errors in the
> > > > > configure script. I tried -Wno-error=deprecated-declarations, but that
> > > > > didn't work, so I added
> > > > > 
> > > > > CFLAGS=-Wno-error
> > > > > 
> > > > > to the configure command to allow it to compile.
> > > > 
> > > > sed 's/g_memdup/g_memdup2/' makes more sense.  g_memdup is deprecated
> > > > because
> > > > using it may cause security issues and there is no way to fix without
> > > > changing
> > > > the API.
> > > > --
> > > > Xi Ruoyao 
> > > > School of Aerospace Science and Technology, Xidian University
> > > 
> > > I now have glib-2.66.8 installed and this seems to fix the problem
> > > with g_memdup in libblockdev-2.25
> > > I assume that this is also the case with the latest version,
> > > glib-2.68.1, but I haven't tried it yet.
> > > It would appear that the sed in libblockdev-2.25 is no longer required
> > > and in fact now causes the compile to fail if included.
> > 
> > Negative.  It's not a "fix".  It's just g_memdup is deprecated *since* 2.68.
> > 
> > g_memdup is insecure by its nature.  Any new code should use g_memdup2
> > instead.
> > --
> > Xi Ruoyao 
> > School of Aerospace Science and Technology, Xidian University
> 
> Have you tried compiling libblockdev-2.25 with the sed in there and
> with glib-2.68.1
> because it doesn't work with glib-2.66.8?

I just tried again.  No issue.

The sed command is:

sed 's/g_memdup/&2/' -i \
src/lib/plugin_apis/vdo.{c,api} \
src/plugins/vdo.c

It won't work for 2.66.8: in 2.66.6 g_memdup2 was added, but as a private
symbol.

ref:
https://discourse.gnome.org/t/port-your-module-from-g-memdup-to-g-memdup2-now/5538
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] libblockdev-2.25 doesn't compile

[Xi Ruoyao via blfs-dev]

On 2021-04-15 10:43 +0100, John Burrell via blfs-dev wrote:
> On Sat, 10 Apr 2021 at 16:10, Xi Ruoyao via blfs-dev
>  wrote:
> > 
> > On 2021-04-10 15:05 +0100, John Burrell via blfs-dev wrote:
> > > Using the systemd version of the development book, libblockdev-2.25 gives:
> > > 
> > > vdo.c: In function ‘bd_vdo_stats_copy’:
> > > vdo.c:84:5: error: ‘g_memdup’ is deprecated: Use 'g_memdup2' instead
> > > [-Werror=deprecated-declarations]
> > >    84 | return g_memdup (stats, sizeof (BDVDOStats));
> > >   | ^~
> > > In file included from /usr/include/glib-2.0/glib.h:82,
> > >  from vdo.c:20:
> > > /usr/include/glib-2.0/glib/gstrfuncs.h:257:23: note: declared here
> > >   257 | gpointer  g_memdup (gconstpointer mem,
> > >   |   ^~~~
> > > cc1: all warnings being treated as errors
> > > 
> > > I didn't see a way to stop warnings being treated as errors in the
> > > configure script. I tried -Wno-error=deprecated-declarations, but that
> > > didn't work, so I added
> > > 
> > > CFLAGS=-Wno-error
> > > 
> > > to the configure command to allow it to compile.
> > 
> > sed 's/g_memdup/g_memdup2/' makes more sense.  g_memdup is deprecated
> > because
> > using it may cause security issues and there is no way to fix without
> > changing
> > the API.
> > --
> > Xi Ruoyao 
> > School of Aerospace Science and Technology, Xidian University
> 
> I now have glib-2.66.8 installed and this seems to fix the problem
> with g_memdup in libblockdev-2.25
> I assume that this is also the case with the latest version,
> glib-2.68.1, but I haven't tried it yet.
> It would appear that the sed in libblockdev-2.25 is no longer required
> and in fact now causes the compile to fail if included.

Negative.  It's not a "fix".  It's just g_memdup is deprecated *since* 2.68.

g_memdup is insecure by its nature.  Any new code should use g_memdup2 instead.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Failure starting X/lxdm with glib 2.68.0

[Xi Ruoyao via blfs-dev]

On 2021-04-12 11:43 +0200, Tim Tassonis via blfs-dev wrote:
> 
> 
> On 4/12/21 11:35 AM, Tim Tassonis via blfs-dev wrote:
> > 
> > 
> > On 4/12/21 11:16 AM, Pierre Labastie via blfs-dev wrote:
> > > On Mon, 2021-04-12 at 09:46 +0200, Tim Tassonis via blfs-dev wrote:
> > > > Hi all
> > > > 
> > > > I just tried to upgrade my qemu virtual machine to glib 2.68.0, which
> > > > lead to lxdm/X not starting anymore. /var/log/lxdm.log reports:
> > > > 
> > > > MESA-LOADER: failed to open bochs-drm:
> > > > /opt/X11/lib/dri/bochs-drm_dri.so: cannot open shared object file: No
> > > > such file or directory (search paths /opt/X11/lib/dri)
> > > > failed to load driver: bochs-drm
> > > > 
> > > > 
> > > > The file /opt/X11/lib/dri/bochs-drm_dri.so really does not exist, but
> > > > with older glib (2.66.8) this is no problem.
> > > > 
> > > > A downgrade to glib 2.66.8 does actually fix the problem, so glib 2.68.0
> > > > really seems to be the problem here. I will try to investigate further,
> > > > but for the moment, I would advise people to stay away from glib 2.68.0,
> > > > at least on qemu vm's running X.
> > > 
> > > Just to be sure: the VM has been updated, but the host has not been 
> > > touched (no
> > > upgrade of glib2/qemu/whatever on host).
> > 
> > 
> > Correct. I now read a bit about that bochs thingy, it seems to get 
> > triggered by
> > 
> > qemu -vga std
> > 
> > 
> > I now switched to
> > 
> > qemu -vga virtio
> > 
> > which makes the message disappear. However, lxdm still fails to start. 
> > dmesg now shows:
> > 
> > 
> > [    9.140449] lxdm-greeter-gt[2868]: segfault at 0 ip 7f0b73b4c73d 
> > sp 7ffefc16b600 error 4 in libglib-2.0.so.0.6800.0[7f0b73b21000+87000]
> > [    9.140460] Code: 49 8a 02 00 49 89 c6 48 85 c0 0f 84 0e 03 00 00 f6 
> > 43 2c 02 75 48 8b 53 30 48 8b 43 38 85 d2 75 09 48 85 c0 0f 84 e4 03 00 
> > 00 <48> 8b 38 48 85 ff 0f 84 f9 02 00 00 bd 08 00 00 00 eb 15 48 8b 43
> > 
> > 
> > So, there seems to be an incompatibility with glib 2.68.0 and lxdm. I 
> > try to re-build lxdm with glib 2.68.0 and see if that fixes the problem. 
> > If not, I have to revert back to 2.66.8 again.
> 
> 
> 
> I re-built lxdm with glib 2.68.0, it didn't help, so the problem clearly 
> lies with lxdm/latest glib, tne bochs thing probably just was a warning 
> and not the cause of the error. I assume therefore, it is not related to 
> qemu at all, but only to lxdm. I try to find out something on lxdm 
> forums or whatever, maybe there's a patch.

Maybe there is a bug in glib-2.68.0.  Try 2.68.1?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] libblockdev-2.25 doesn't compile

[Xi Ruoyao via blfs-dev]

On 2021-04-10 15:05 +0100, John Burrell via blfs-dev wrote:
> Using the systemd version of the development book, libblockdev-2.25 gives:
> 
> vdo.c: In function ‘bd_vdo_stats_copy’:
> vdo.c:84:5: error: ‘g_memdup’ is deprecated: Use 'g_memdup2' instead
> [-Werror=deprecated-declarations]
>    84 | return g_memdup (stats, sizeof (BDVDOStats));
>   | ^~
> In file included from /usr/include/glib-2.0/glib.h:82,
>  from vdo.c:20:
> /usr/include/glib-2.0/glib/gstrfuncs.h:257:23: note: declared here
>   257 | gpointer  g_memdup (gconstpointer mem,
>   |   ^~~~
> cc1: all warnings being treated as errors
> 
> I didn't see a way to stop warnings being treated as errors in the
> configure script. I tried -Wno-error=deprecated-declarations, but that
> didn't work, so I added
> 
> CFLAGS=-Wno-error
> 
> to the configure command to allow it to compile.

sed 's/g_memdup/g_memdup2/' makes more sense.  g_memdup is deprecated because
using it may cause security issues and there is no way to fix without changing
the API.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] curl build with ./configure or cmake

[Xi Ruoyao via blfs-dev]

On 2021-04-01 10:52 +0200, Tim Tassonis via blfs-dev wrote:
> Hi all
> 
> I just discovered that curl apparently now also optionally supports 
> cmake as build system. Per official documentation however, ./configure 
> still seems first choice, or at least as supported as cmake.
> 
> As I personally don't see the benefits of cmake over autotools from a 
> builders perspective (I have used neither as a developer), I suggest to 
> stay on autotools for the moment.

The most stupid thing of autotools is .la files.  If they are removed (by
script, or manually) I think autotools is fine.

> However, there might be a lfs/blfs policy regarding preference for cmake 
> that I am not aware of?

If the upstream has a recommendation, just follow the upstream.  Otherwise, for
autotools vs meson we usually prefer meson (unless it causes problems), since
meson is installed in LFS.  But for autotools vs cmake I'm not sure.

cmake has a recommended dependency on cURL.  So if we build cURL with cmake, the
only "rational" way is:

1. build cmake without cURL
2. build cURL with cmake
3. rebuild cmake with cURL

So I think we'll keep to use autotools for cURL (until the upstream says "don't
use it").
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] (I know it's the wrong list) Be careful of binutils 2.36

[Xi Ruoyao via blfs-dev]

On 2021-01-25 19:33 -0500, Marty Jack via blfs-dev wrote:
> I found that during the install phase the just installed ld won't run against
> the prior libctf which had not yet been installed.  I ended up with a
> nonfunctional ld and had to recover it from another system and reinstall
> 2.35.1.  Now holding off to see what others discover.  I do not see anyone
> reporting a problem on their mailing list at this point.

It's not so fatal.  You can set LD_LIBRARY_PATH during make install to
workaround.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] python2 as default python?

[Xi Ruoyao via blfs-dev]

On 2020-10-22 16:14 +0100, Ken Moffat via blfs-dev wrote:
> On Thu, Oct 22, 2020 at 06:25:59AM -0500, Bruce Dubbs via blfs-dev wrote:
> > On 10/22/20 12:56 AM, DJ Lucas via blfs-dev wrote:
> > > On October 21, 2020 10:48:39 PM CDT, Bruce Dubbs via blfs-dev
> > >  wrote:
> > > > On 10/21/20 10:06 PM, DJ Lucas via blfs-dev wrote:
> > > > > 
> > > 
> > > > 
> > > > In LFS, we can make the symlink to p3.  For p2 in BLFS, we will use
> > > > 'make altinstall'.  Everything else would be for non-python packages
> > > > that either use p2 or create a p2 module.
> > > > 
> > > 
> > > Ok, I'll go back and fix it that way locally then. I'm not too far. I have
> > > only like 8 packages that have py2 optional deps listed.
> > > 
> > > So for BLFS, just do it and fix on the fly, or create a tracker bug and
> > > let the devs run through it a time or two? I don't think it's going to be
> > > all that big of a deal, but might be nice to avoid any interim breakage,
> > > do as one big commit or a small series of commits to make it easier on
> > > people who are upgrading.
> > 
> > My thought is to fix it in LFS and python2 in BLFS and fix everything else
> > as the issues come up.  It is a development release right now and we are
> > early in the cycle.
> > 
> >   -- Bruce
> > 
> 
> I still think that creating a symlink for python in LFS is a bad
> idea (it will create unnecessary work).  On my current build I
> removed /usr/bin/python and gimp found python2 without problems.
> Compare Arch where I think htey made the python3 -> python2 symlink
> years ago : they specify PYTHON=/usr/bin/python2 ./configure
> https://github.com/archlinux/svntogit-packages/blob/packages/gimp/trunk/PKGBUILD
> 
> Is there anything in the book which uses python3 and looks for python
> but does not look for python3 ?

Some test scripts, for which we are using a sed.

I don't like python -> python3 symlink, either.  Maybe someone can submit patch
to upstream to improve their building system and avoid those sed?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] llvm-11 and rust

[Xi Ruoyao via blfs-dev]

On 2020-10-14 02:45 +0100, Ken Moffat via blfs-dev wrote:
> On Wed, Oct 14, 2020 at 02:21:39AM +0100, Ken Moffat via blfs-dev wrote:
> > On Mon, Oct 12, 2020 at 09:15:30PM +0100, Ken Moffat via blfs-dev wrote:
> > > People might remember that I looked at llvm-11-rc1 in early August,
> > > and discovered that rustc-1.42.0 could not use it.  I see that
> > > llvm-11.0.0 is now out, and the release notes for rust-1.47.0 say
> > > that it ships with llvm-11 (although it 'should' build with older
> > > llvm).
> > > 
> > > I've just started a fresh build, with linux-5.9.0 (I understand why
> > > the book is waiting, but 5.9-rc has been ok on this box), llvm-11.0
> > > and rustc-1.47.0.  Except for things like nss and nspr my LFS and
> > > BLFS package versions are still at 10.0 (too much change to catch up
> > > with in the short term), so this is just an experimental build to
> > > try this llvm/rust combination and see if everything using rust will
> > > build.  I do not intend to build my whole desktop.
> > > 
> > > I aim to update my builds for the packages which use rust (cbindgen,
> > > librsvg, thunderbird to whatever is currently in the book) and to
> > > use firefox-78.3.0, current seamonkey.
> > > 
> > > If these all build, we will be able to update rustc along with llvm.
> > > If not, I assume we will need to revert to rustc using its shipped
> > > llvm whenever llvm-11 goes into the book.
> > > 
> > > Have I overlooked anything ?
> > > 
> > > ĸen
> > 
> > Unfortunately, I _did_ overlook something - I've got several scripts
> > to build rustc (different versions with prefix and sysllvm or
> > shipped) and I accidentally built 1.46.0 on llvm-11.0.0.  That did
> > build, and built all of cbindgen, firefox-esr, frefox-82.0 candidate
> > 1, librsvg, seamonkey, thunderbird.  Currently building
> > rustc-1.47.0, will attempt to rebuild them all in due course.
> > 
> Second fault in that first attempt - I was using the shipped llvm,
> so of course it built.

I can confirm that rustc-1.47.0 builds OK with system LLVM-11.0.0, and it can
build librsvg & js78 with no problem.

I didn't test firefox 78, though.

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] gnome-terminal (SysV) book

[Xi Ruoyao via blfs-dev]

On 2020-10-04 21:48 -0500, Bruce Dubbs via blfs-dev wrote:
> On 10/4/20 9:09 PM, Xi Ruoyao via blfs-dev wrote:
> > On 2020-10-04 17:10 -0500, Bruce Dubbs via blfs-dev wrote:
> > > On 10/4/20 5:03 PM, Joe Locash wrote:
> > > > 
> > > > 
> > > > On Sun, Oct 4, 2020 at 5:46 PM Bruce Dubbs via blfs-dev
> > > >  > > > <mailto:blfs-dev@lists.linuxfromscratch.org>> wrote:
> > > > 
> > > >  On 10/4/20 3:45 PM, Joe Locash via blfs-dev wrote:
> > > >   > Why are --disable-search-provider and --without-nautilus-
> > > > extension
> > > >   > passed to configure for the SytemV buiild of this?  The command
> > > >   > explanations don't make much sense.
> > > >   >
> > > >   > /|--disable-search-provider|/: This switch disables the “search
> > > >   > gnome-shell” provider. This is necessary because gnome-shell is
> > > >  not in
> > > >   > BLFS. Remove this if you have gnome-shell installed.
> > > >   >
> > > >   > /|--without-nautilus-extension|/: This switch disables the a
> > > >  dependency
> > > >   > on the nautilus file manager.
> > > > 
> > > >  Those instructions support those that may want gnome-terminal, but
> > > > not
> > > >  the rest of gnome.
> > > > 
> > > > 
> > > > Then why is it only in the SysV book?
> > > 
> > > Why is what only in the SysV book?  gnome-terminal is certainly there.
> 
> > But now with elogind I think we can build a full GNOME environment in sysv? 
> > We
> > should make these two parameters optional.
> 
> We can change the explanations and add gmome-shell as an optional 
> dependency.  We already have nautilus as recommended, but honestly I do 
> not understand how a terminal emulator would use a file manager or gnome 
> shell if the user is not using the gnome desktop environment.

It does not use a file manager or gnome shell.

gnome-terminal attempts to build a nautilus extension so we can use "Open in
terminal" in nautilus.  And, it's acting as a "gnome-shell search provider" so
we can search for a terminal in gnome shell dashboard.  (See the image
appended.)

If we want to satisify those guys who use gnome-terminal but not other GNOME
components, we should add these two options for systemd book as well.  Not all
systemd users use GNOME DE.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] gnome-terminal (SysV) book

[Xi Ruoyao via blfs-dev]

On 2020-10-04 17:10 -0500, Bruce Dubbs via blfs-dev wrote:
> On 10/4/20 5:03 PM, Joe Locash wrote:
> > 
> > 
> > On Sun, Oct 4, 2020 at 5:46 PM Bruce Dubbs via blfs-dev 
> >  > > wrote:
> > 
> >     On 10/4/20 3:45 PM, Joe Locash via blfs-dev wrote:
> >  > Why are --disable-search-provider and --without-nautilus-extension
> >  > passed to configure for the SytemV buiild of this?  The command
> >  > explanations don't make much sense.
> >  >
> >  > /|--disable-search-provider|/: This switch disables the “search
> >  > gnome-shell” provider. This is necessary because gnome-shell is
> >     not in
> >  > BLFS. Remove this if you have gnome-shell installed.
> >  >
> >  > /|--without-nautilus-extension|/: This switch disables the a
> >     dependency
> >  > on the nautilus file manager.
> > 
> >     Those instructions support those that may want gnome-terminal, but not
> >     the rest of gnome. 
> > 
> > 
> > Then why is it only in the SysV book?
> 
> Why is what only in the SysV book?  gnome-terminal is certainly there.
> 
>    -- Bruce

But now with elogind I think we can build a full GNOME environment in sysv?  We
should make these two parameters optional.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Are the seds in gcr, seahorse, gsettings-desktop-schemas, and gnome-keyring really needed?

[Xi Ruoyao via blfs-dev]

On 2020-10-03 13:03 +0200, Pierre Labastie via blfs-dev wrote:
> Hi,
> 
> This morning, while updating to gcr-3.38, I realized that there was a
> sed to change the schema path from "/desktop/gnome/crypto/pgp/" to
> "/org/gnome/desktop/gnome/crypto/pgp/". It seemed a little weird, so I
> looked at what some distros do: neither archlinux nor debian change
> anything.
> 
> This sed, together with similar ones in the pages listed in the
> subject, were added long ago "to fix deprecated paths". I am almost
> sure this is not necessary. But even if it is, I'm almost sure (again)
> that "modern" paths are either of the form "/org/gnome/..." or
> "/org/freedesktop/...".
> 
> So the sed for gcr should be to "/org/gnome/crypto/pgp/", and a similar
> one in gnome-keyring. For seahorse and gsettings-desktop-schemas, the
> seds give a path of the right form.
> 
> But all in all do we need that? What does it fix?

I remember sometimes I missed it and glib-compile-schemas printed a warning
regarding this.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Disabling expensive nss tests

[Xi Ruoyao via blfs-dev]

On 2020-10-02 23:29 +0200, Tim Tassonis via blfs-dev wrote:
> Hi all
> 
> When building nss 3.57 and waiting ages for the tests to be compiled, I 
> checked the Makefile and found out that, by adding
> 
> NSS_DISABLE_GTESTS=1    \
> 
> 
> to the make command, the build time can quite drasctically be reduced, 
> as compiling (not even running) the tests seems to take way more time 
> than compiling the rest.
> 
> Maybe this could be added to the nss page, for people (like me) that 
> won't run the tests anyway.

I'll add it into the page.  But anyway I'll still run the tests since it's a
"security library", and some of my custom CFLAGS seems breaking it.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] js78 and jemalloc

[Xi Ruoyao via blfs-dev]

On 2020-09-21 17:59 +0100, Ken Moffat via blfs-dev wrote:
> On Mon, Sep 21, 2020 at 10:07:18AM -0500, Douglas R. Reno via blfs-dev wrote:
> > 
> > On 9/21/20 9:36 AM, Ken Moffat via blfs-dev wrote:
> > > I'm now looking at js78 because firefox-78.3.0 is out.  For the
> > > moment I'm still using js68, but I can at least compare the js build
> > > against 78.2.0.
> > > 
> > > Looking at that, we have '--disable-jemalloc' with the explanation:
> > > This switch disables the internal memory allocator used in JS78.
> > > jemalloc causes a conflict with glibc.
> > > 
> [...]
> > > I've now looked at fedora,
> > > https://src.fedoraproject.org/rpms/mozjs78/blob/master/f/mozjs78.spec
> > > 
> > > It seems to me that they are not disabling jemalloc.

They are:


https://src.fedoraproject.org/rpms/mozjs78/blob/master/f/mozjs78.spec#_158

> > > I think dropping --disable-jemalloc is a good idea. I think that's a
> > holdover from when we first added it, I think js60 or js52? It was around
> > the time that Gjs started requiring later versions of the Spidermonkey JS
> > engine.
> > 
> > - Doug
> > 
> 
> Thanks. I've remeasured without it (faster, but might be normal rust
> variation), will do that.

From
https://github.com/mozilla-spidermonkey/spidermonkey-embedding-examples/blob/esr78/docs/Building%20SpiderMonkey.md
：

> Disabling jemalloc
> 
> One important configuration when getting started is the --disable-jemalloc
> flag. This will cause SpiderMonkey to use the system allocator functions
> instead of a custom build of jemalloc. The custom configuration, which is the
> default, is intended for a browser environment and requires linking the final
> application with a matching version of a library called mozglue. If one
> accidentally builds SpiderMonkey for their embedding without including the --
> disable-jemalloc flag, they usually quickly encounter strange crashes as items
> allocated in jemalloc allocator are freed on system allocator.

So don't do that.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] clang as a hard dependency, was Re: firefox (and js) -> rust -> llvm dependency

[Xi Ruoyao via blfs-dev]

On 2020-09-09 10:31 +0100, Ken Moffat via blfs-dev wrote:
> On Tue, Sep 08, 2020 at 12:50:16PM -0500, Bruce Dubbs via blfs-dev wrote:
> > On 9/8/20 6:19 AM, Ken Moffat via blfs-dev wrote:
> > > On Mon, Aug 17, 2020 at 07:00:08PM +0100, Ken Moffat via blfs-dev wrote:
> > > > On Mon, Aug 17, 2020 at 01:33:49PM +0800, Xi Ruoyao via blfs-dev wrote:
> > > > > I just drafted js78 page.  When it was built, the building system
> > > > > utilized some
> > > > > LLVM tools (llvm-objdump and llvm-profdata).
> > > > > 
> > > > > Is a rustc built with shipped LLVM providing llvm-objdump and llvm-
> > > > > profdata,
> > > > > which could be used during firefox or js build?  If not we should list
> > > > > LLVM as a
> > > > > firefox/js hard dependency.
> > > > 
> > > > It seems to.
> > > > 
> > > > On my experimental build last month with llvm-11-rc I had to build
> > > > rust with its shipped llvm.  Clearly I had already installed those
> > > > two programs, but looking at the log I see
> > > > 
> > > > [1656/1728] Linking CXX executable bin/llvm-objdump
> > > >   and
> > > > [1620/1728] Linking CXX executable bin/llvm-profdata
> > > > 
> > > > In my current build with system llvm neither of those is mentioend
> > > > in the log.
> > > > 
> > > Coming back to this, two points:
> > > 
> > > 1. It might be that we should anyway list clang from llvm as a hard
> > > dependency.  At some point before we released 10.0 I had hidden
> > > clang on this system - I guess that was while exploring thunderbird
> > > builds with gcc - and forgotten to reinstate it.
> > > 
> > > Today I was trying to build firefox-81beta (if anyone else wants to
> > > build 81, please read the wiki - creating the python virtual
> > > environments has been separated out of ./mach build) and eventually
> > > got it to run ./mach build, only to fail because it couldn't find
> > > clang which is apparently needed for cbindgen to use.
> > > 
> > > I have not yet played with current firefox-esr in the absence of
> > > clang, nor current js68, but I see from my firefox-78.2.0esr log:
> > > 
> > >   0:22.46 checking for cbindgen... /usr/bin/cbindgen
> > >   0:22.46 checking for rustfmt... /opt/rustc/bin/rustfmt
> > >   0:22.46 checking for clang for bindgen... /usr/bin/clang++
> > >   0:22.46 checking for libclang for bindgen... /usr/lib/libclang.so
> > >   0:22.46 checking that libclang is new enough... yes
> > > 
> > > In practice, at the moment with rust using system llvm we recommend
> > > clang, but when llvm has its next release we'll probably have to
> > > drop back to the shipped llvm again, so bigger and slower llvm
> > > compiles.
> > > 
> > > 2. In llvm, should we recommend clang instead of listing it as
> > > optional ?
> > 
> > Yes.
> > 
> > At the moment, both clang and compiler-rt are listed as
> > > optional.  On my less-capable desktop/notebook machines I don't
> > > build compiler-rt, but obviously I build clang on all of them.
> > > I guess the real question is:
> > > 
> > > Do BLFS users build llvm without clang, and if so, what do they use
> > > it for ?
> > 
> > I do not know.  I always build both clang and compiler-rt, but to be honest,
> > I don't know what we would use compiler-rt for.
> > 
> >   -- Bruce
> 
> Hi Bruce,
> 
> I've now confirmed that with firefox-78.2.0esr the initial configury
> fails in the same way if clang is not available.  That is, of
> course, on a build using CC=gcc CXX=g++.

But js78 builds successfully without clang.  (I moved libclang.so and clang
executables away.)

I'm still not sure about llvm-profdata and llvm-objdump.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] xfce4-pulseaudio-plugin

[Xi Ruoyao via blfs-dev]

On 2020-08-31 07:49 +0100, Ken Moffat via blfs-dev wrote:
> On Mon, Aug 31, 2020 at 01:20:52AM -0500, Bruce Dubbs via blfs-dev
> wrote:
> > On 8/31/20 1:10 AM, Ken Moffat via blfs-dev wrote:
> > > The download link works, but the download is
> > > xfce4-pulseaudio-plugin-xfce4-pulseaudio-plugin-0.4.3-
> > > 9de2b7865ecb95bdd2cbaae00a17b23ae8455fe5.tar.bz2
> > > 
> > > I wonder if we should remark on this - in places we remark on
> > > directory names which do not match the tarball.  This one's
> > > direcotry does match the tarball, but hte tarball name is
> > > certainly not what I was expecting.
> > 
> > Yes, it's pretty ugly.  I did put in a note about it.
> > 
> >   -- Bruce
> > 
> Ah, yeah, I see now 'This package extracts to a very non-standard
> directory.' but I will argue that the directory, although very ugly,
> is standard.  That is, it matches the tarball name.  It is the
> tarball name which does not match what the link claims to download
> 
> (xfce4-pulseaudio-plugin-0.4.3/xfce4-pulseaudio-plugin-0.4.3.tar.bz2)

If wget is used to retrieve the file, the tarball name will be correct.  But if
a browser is used, it will be wrong.

> ĸen
> -- 
> Juliet's version of cleanliness was next to godliness, which was to
> say it was erratic, past all understanding and was seldom seen.
>   -- Unseen Academicals
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Request to add firefox-78.2.0 to BLFS-10.0

[Xi Ruoyao via blfs-dev]

On 2020-08-25 11:07 -0500, Douglas R. Reno via blfs-dev wrote:
> On 8/25/20 8:00 AM, Ken Moffat via blfs-dev wrote:
> > Release notes for latest firefox esr now available, three security
> > issues were fixed.  Can I add this to 10.0, please ?
> > 
> > ĸen
> I know Bruce has to give the Final OK, but based off the security issues 
> in that one (being able to spoof websites to force extensions to 
> download), I think this is crucial.

No packages depend on Firefox, so it should be OK.  Mozilla JS is still 68.x.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[blfs-dev] firefox (and js) -> rust -> llvm dependency

[Xi Ruoyao via blfs-dev]

I just drafted js78 page.  When it was built, the building system utilized some
LLVM tools (llvm-objdump and llvm-profdata).

Is a rustc built with shipped LLVM providing llvm-objdump and llvm-profdata,
which could be used during firefox or js build?  If not we should list LLVM as a
firefox/js hard dependency.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] pulseaudio-13.0

[Xi Ruoyao via blfs-dev]

On 2020-08-11 18:29 +0100, spiky0011 via blfs-dev wrote:
> On 11/08/2020 18:23, Douglas R. Reno via blfs-dev wrote:
> > On 8/11/20 12:23 PM, spiky0011 via blfs-dev wrote:
> > > Hi
> > > 
> > > Just going through blfs on top of Lfs 20200810-systemd
> > > 
> > > I get an error with pulseaudio-13.0
> > > 
> > > "In file included from /usr/include/glib-2.0/glib/giochannel.h:33,
> > >  from /usr/include/glib-2.0/glib.h:54,
> > >  from pulse/glib-mainloop.c:31:
> > > /usr/include/glib-2.0/glib/gmain.h:681:8: note: declared here
> > >   681 | void   g_get_current_time (GTimeVal *result);
> > >   |^~
> > > In file included from tests/alsa-mixer-path-test.c:5:
> > > tests/alsa-mixer-path-test.c: In function ‘load_makefile’:
> > > tests/alsa-mixer-path-test.c:32:5: error: too few arguments to 
> > > function ‘_ck_assert_failed’
> > >32 | fail_unless(f != NULL); /* Consider skipping this test 
> > > instead of failing if Makefile not found? */
> > >   | ^~~
> > > /usr/include/check.h:502:27: note: declared here
> > >   502 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, 
> > > int line,
> > >   |   ^
> > > tests/alsa-mixer-path-test.c:35:13: error: too few arguments to 
> > > function ‘_ck_assert_failed’
> > >35 | fail_unless(feof(f));
> > >   | ^~~
> > > /usr/include/check.h:502:27: note: declared here
> > >   502 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, 
> > > int line,
> > >   |   ^
> > > tests/alsa-mixer-path-test.c: In function ‘mixer_path_test_fn’:
> > > tests/alsa-mixer-path-test.c:68:5: error: too few arguments to 
> > > function ‘_ck_assert_failed’
> > >68 | fail_unless(dir != NULL);
> > >   | ^~~
> > > /usr/include/check.h:502:27: note: declared here
> > >   502 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, 
> > > int line,
> > >   |   ^
> > > tests/alsa-mixer-path-test.c:77:9: error: too few arguments to 
> > > function ‘_ck_assert_failed’
> > >77 | fail_unless(path != NULL);
> > >   | ^~~
> > > /usr/include/check.h:502:27: note: declared here
> > >   502 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, 
> > > int line,
> > >   |   ^
> > > tests/alsa-mixer-path-test.c:85:13: error: too few arguments to 
> > > function ‘_ck_assert_failed’
> > >85 | fail_unless(found);
> > >   | ^~~
> > > /usr/include/check.h:502:27: note: declared here
> > >   502 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, 
> > > int line,
> > >   |   ^
> > > make[3]: *** [Makefile:10032: 
> > > tests/alsa_mixer_path_test-alsa-mixer-path-test.o] Error 1
> > > make[3]: *** Waiting for unfinished jobs
> > > make[3]: Leaving directory '/home/spiky/build/pulseaudio-13.0/src'
> > > make[2]: *** [Makefile:5348: all] Error 2
> > > make[2]: Leaving directory '/home/spiky/build/pulseaudio-13.0/src'
> > > make[1]: *** [Makefile:828: all-recursive] Error 1
> > > make[1]: Leaving directory '/home/spiky/build/pulseaudio-13.0'
> > > make: *** [Makefile:643: all] Error 2"
> > > 
> > > any Ideas
> > > 
> > > Spiky
> > > 
> > Hi Spiky,
> > 
> > 
> > This is due to the update to check-0.15.x. It doesn't look like there 
> > is a fix upstream yet. We might need to come up with one.
> > 
> > 
> > - Doug
> > 
> So you have encountered this problem?

I have. I used a stupid sed to edit the fail_if and fail_unless lines, in order
to make the test runable. But then check-0.15.2 is released and the release note
claims that the problem is fixed.  I've not tried to rebuild pulseaudio with
check-0.15.2 yet.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] pulseaudio-13.0

[Xi Ruoyao via blfs-dev]

On 2020-08-11 12:23 -0500, Douglas R. Reno via blfs-dev wrote:
> On 8/11/20 12:23 PM, spiky0011 via blfs-dev wrote:
> > Hi
> > 
> > Just going through blfs on top of Lfs 20200810-systemd
> > 
> > I get an error with pulseaudio-13.0
> > 
> > "In file included from /usr/include/glib-2.0/glib/giochannel.h:33,
> >  from /usr/include/glib-2.0/glib.h:54,
> >  from pulse/glib-mainloop.c:31:
> > /usr/include/glib-2.0/glib/gmain.h:681:8: note: declared here
> >   681 | void   g_get_current_time (GTimeVal *result);
> >   |^~
> > In file included from tests/alsa-mixer-path-test.c:5:
> > tests/alsa-mixer-path-test.c: In function ‘load_makefile’:
> > tests/alsa-mixer-path-test.c:32:5: error: too few arguments to 
> > function ‘_ck_assert_failed’
> >32 | fail_unless(f != NULL); /* Consider skipping this test 
> > instead of failing if Makefile not found? */
> >   | ^~~
> > /usr/include/check.h:502:27: note: declared here
> >   502 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, 
> > int line,
> >   |   ^
> > tests/alsa-mixer-path-test.c:35:13: error: too few arguments to 
> > function ‘_ck_assert_failed’
> >35 | fail_unless(feof(f));
> >   | ^~~
> > /usr/include/check.h:502:27: note: declared here
> >   502 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, 
> > int line,
> >   |   ^
> > tests/alsa-mixer-path-test.c: In function ‘mixer_path_test_fn’:
> > tests/alsa-mixer-path-test.c:68:5: error: too few arguments to 
> > function ‘_ck_assert_failed’
> >68 | fail_unless(dir != NULL);
> >   | ^~~
> > /usr/include/check.h:502:27: note: declared here
> >   502 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, 
> > int line,
> >   |   ^
> > tests/alsa-mixer-path-test.c:77:9: error: too few arguments to 
> > function ‘_ck_assert_failed’
> >77 | fail_unless(path != NULL);
> >   | ^~~
> > /usr/include/check.h:502:27: note: declared here
> >   502 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, 
> > int line,
> >   |   ^
> > tests/alsa-mixer-path-test.c:85:13: error: too few arguments to 
> > function ‘_ck_assert_failed’
> >85 | fail_unless(found);
> >   | ^~~
> > /usr/include/check.h:502:27: note: declared here
> >   502 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, 
> > int line,
> >   |   ^
> > make[3]: *** [Makefile:10032: 
> > tests/alsa_mixer_path_test-alsa-mixer-path-test.o] Error 1
> > make[3]: *** Waiting for unfinished jobs
> > make[3]: Leaving directory '/home/spiky/build/pulseaudio-13.0/src'
> > make[2]: *** [Makefile:5348: all] Error 2
> > make[2]: Leaving directory '/home/spiky/build/pulseaudio-13.0/src'
> > make[1]: *** [Makefile:828: all-recursive] Error 1
> > make[1]: Leaving directory '/home/spiky/build/pulseaudio-13.0'
> > make: *** [Makefile:643: all] Error 2"
> > 
> > any Ideas
> > 
> > Spiky
> > 
> Hi Spiky,
> 
> 
> This is due to the update to check-0.15.x. It doesn't look like there is 
> a fix upstream yet. We might need to come up with one.

check-0.15.2 seems fixed this regression.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] [lfs-dev] grub with uefi for LFS 10?

[Xi Ruoyao via blfs-dev]

On 2020-08-05 14:26 +0800, Kevin Buckley via lfs-dev wrote:
> On Sun, 2 Aug 2020 at 04:32, Timothy Russo via lfs-dev
>  wrote:
> > With efi being more the standard now, I'd like to ask if we could default
> > grub to supporting uefi instead of having to use the uefi hint.
> > 
> > Or at last maybe formalize it and make it an option, where you can pick
> > bios/mbr or uefi option.
> > 
> 
> As the last person to update that hint (and, yes, it's in need of more
> updating
> for newer package versions!), then you must have seen that there are extra
> packages, beyond those in the LFS core, that are needed to "enhance" Grub.
> 
> Note also, that as you are probably building LFS on a system that may have
> a UEFI-aware bootloader, you don't necessarily need a bootloader provided
> by LFS.
> 
> Maybe a UEFI-aware Grub could be part of BLFS though?

[Cross post to blfs-dev]

I personally agree.  Let's hear Bruce's opinion.

If he agree I'll do it for BLFS 10.1, and reference it in LFS 10.1.  10.0 is too
hurry, I think.  For 10.0 I'll update the hint again.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] rustc in BLFS-10.0 : stick with 1.42.0 :-(]

[Xi Ruoyao via blfs-dev]

On 2020-08-01 04:57 +0100, Ken Moffat via blfs-dev wrote:

> From that I conclude that current versions of rustc with llvm-11
> will need their shipped llvm, which is slow and large to build (on
> this system, 1.42.0 with its shipped llvm took 40.8 SBU and
> installed 394.3 MiB on this 8-thread machine, against 34.3 SBU and
> 250.8 MiB for a build from the beginning of June - both without
> running the tests).
> 
> Meanwhile, rustc-1.45.1 is out, but the release notes
> https://blog.rust-lang.org/2020/07/30/Rust-1.45.1.html do not
> mention llvm-11.  The 1.46.0 release is expected to be after 15th
> April and llvm-11 probably won't be released until September.  So I
> doubt that anyone will fix rustc for building with sysllvm in the
> near future.
> 
> Therefore, for our 10.0 release rustc-1.42.0 looks like the way to
> go.

I can build rustc-1.45.0 with LLVM 10.  I'm lazy to build rustc-1.45.1 because
I'll start to rebuild everything with glibc-2.32 tomorrow.

I suggest to keep LLVM 10, and update to rustc-1.45.1 in BLFS-10.0 release. LLVM
11 is scheduled to be released on Aug. 26, but I remember that the release of
LLVM 9 and LLVM 10 were both overdue for about one week.  So it's not very
likely we'll use LLVM 11 in BLFS 10.0.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] JS68 and firefox-78

[Xi Ruoyao via blfs-dev]

I tried to build JS78 from Firefox 78.0b9 tarball.  The build finished
successfully (with rustc-1.44.0, I've not built the latest 1.44.1).

"--enable-unaligned-private-values" is no longer supported.  I think gjs guys
will need to do a lot of work :).
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] JS68 and firefox-78

[Xi Ruoyao via blfs-dev]

On 2020-06-19 19:49 -0500, Douglas R. Reno via blfs-dev wrote:
> On 6/19/20 5:04 PM, Bruce Dubbs via blfs-dev wrote:
> > On 6/19/20 4:57 PM, Ken Moffat via blfs-dev wrote:
> > > On Fri, Jun 19, 2020 at 04:46:26PM -0500, Bruce Dubbs via blfs-dev 
> > > wrote:
> > > > On 6/19/20 4:11 PM, Ken Moffat via blfs-dev wrote:
> > > > > Once firefox-78 is in, it will use python3.  JS68 is still python2 -
> > > > > last December xry111 had a patch to let JS68 use python3.  I
> > > > > remember building that on my py3 system, but since the polkit I was
> > > > > using did not use JS68 and I was not able to address that, I had to
> > > > > drop the polkit chain (JS68, polkit, elogind, rootless X). But
> > > > > since then we have dropped the cut-down JS68 from fdo and moved to
> > > > > using the JS shipped in firefox.  Maybe we should reconsider that ?
> > > > 
> > > > I'm not 100% sure I understand, but can't we use FF68 source for 
> > > > js68 and
> > > > polkit and use FF78 separately?
> > > Yes, we can use current FF68 source for js68.  That will still
> > > require python2, probably for ever.  And that is my initial plan
> > > (basically just reinstate a separate entity for js68).
> > > 
> > > A possible future alternative is to reinstate the cut-down FDO
> > > version of js68 source, with xry111's patch to use python3.

The patch can be applied to Firefox ESR tarball, but only to build standalone
JS.

> > Well it certainly would be nice to get polkit to do an update.

polkit js68 MR is merged.  Now the maintainer seems preparing a new release.

> Adding into this is the complexity of gjs. I'm not sure whether or not 
> gjs-1.66 (to go along with GNOME-3.38) is going to use js78 or not. I 
> haven't seen anything from the distributor-list at GNOME yet.

gjs policy is to upgrade mozjs version when a new ESR is released:

https://gitlab.gnome.org/GNOME/gjs/blob/master/CONTRIBUTING.md#L230

Firefox 78 is planned to be released on June 30th.  GNOME 3.38 is planned to be
released on late September.  So it seems they'll migrate to JS78. But OTOH BLFS-
10.0 will keep to use JS68.

> I'll let you guys know as soon as I know though. Normally they announce 
> those changes within a month or two before the next release of GNOME to 
> distributors so it's easier for them to package it upon the arrival of 
> the release.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Firefox and python3

[Xi Ruoyao via blfs-dev]

On 2020-06-05 18:20 +0800, Xi Ruoyao via blfs-dev wrote:
> On 2020-06-05 00:22 +0100, Ken Moffat via blfs-dev wrote:
> > On Fri, Jun 05, 2020 at 03:02:05AM +0800, Xi Ruoyao via blfs-dev wrote:
> > > One Mozilla developer once made a lecture in our university and said "do
> > > not
> > > try
> > > to build Firefox without a powerful workstation" :).
> > 
> > I bet that was years ago!  The build has got slower, and
> > continues to get slower.  And mozilla devs say that current
> > llvm makes rust compiles slower.  But against that, for firefox
> > development they run all the tests and do some LTO and PGO to
> > produce their binaries which of course adds a lot more overhead to
> > the build.  I've got a maximum of 8 cores (4 + hyperthreading) and
> > watching 'top' I can see that the build has several bottlenecks
> > where only one core is being used.
> 
> There is a key `rust.parallel-compiler` in rustc config.toml.  But I'm not
> sure
> if setting it to true would help.  I'll try it.

It's still a WIP and not very helpful, as in rustc-1.44.0.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Firefox and python3

[Xi Ruoyao via blfs-dev]

On 2020-06-05 00:22 +0100, Ken Moffat via blfs-dev wrote:
> On Fri, Jun 05, 2020 at 03:02:05AM +0800, Xi Ruoyao via blfs-dev wrote:
> > One Mozilla developer once made a lecture in our university and said "do not
> > try
> > to build Firefox without a powerful workstation" :).
> 
> I bet that was years ago!  The build has got slower, and
> continues to get slower.  And mozilla devs say that current
> llvm makes rust compiles slower.  But against that, for firefox
> development they run all the tests and do some LTO and PGO to
> produce their binaries which of course adds a lot more overhead to
> the build.  I've got a maximum of 8 cores (4 + hyperthreading) and
> watching 'top' I can see that the build has several bottlenecks
> where only one core is being used.

There is a key `rust.parallel-compiler` in rustc config.toml.  But I'm not sure
if setting it to true would help.  I'll try it.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Firefox and python3

[Xi Ruoyao via blfs-dev]

On 2020-06-04 12:38 +0100, Ken Moffat via blfs-dev wrote:
> (starting a new thread so that people will notice this :)
> 
> Back in December I built an experimental system to try doing without
> python2.  At that time it was less than useful (e.g. no graphical
> browsers, and I think I had to build suid xorg because I couldn't
> build mozilla's JS).  But I kept the system for testing.

I've been use such an "experimental" system for a while.  The main blockers for
me are js{60,68} and asciidoc.  For js68 I made a giant patch.  For js60 (which
is only required by polkit now) I made a small polkit patch to use js68 instead
(which is now a MR in polkit repo).  For asciidoc I used asciidoc-9.0.0rc{1,2}
(good news: 9.0.0 has been released).

> Main features -
> 
> python is symlinked to python3:
> ken@plexi ~ $ls -l /usr/bin/python*
> lrwxrwxrwx 1 root root 7 Dec 16 11:27 /usr/bin/python -> python3
> lrwxrwxrwx 1 root root 9 Dec 13 00:42 /usr/bin/python3 -> python3.8
> -rwxr-xr-x 1 root root 44936 Dec 13 00:42 /usr/bin/python3.8
> -rwxr-xr-x 1 root root  3128 Dec 13 00:42 /usr/bin/python3.8-config
> lrwxrwxrwx 1 root root16 Dec 13 00:42 /usr/bin/python3-config ->
> python3.8-config
> lrwxrwxrwx 1 root root14 Dec 16 06:26 /usr/bin/python-config -> python3-
> config
> 
> gcc is 9.2.0
> clang is 8.0.1
> 
> Today, I have managed to install firefox-78.0b2 and it is running
> while I type this :)

Finally I won't need to rebase giant patch :).

> NOTE: firefoxes >= 73 need a newer profile, keeping multiple
> profiles while old ESR is still in use is a good idea (I name them
> for the version of firefox where I created them).  Obviously, all
> customizations need to be recreated for a new profile.
> 
> General details of firefox changes are in the wiki (and you cannot
> just drop an unedited mozconfig from 68ESR into 78 and expect it to
> build).
> 
> Please note that for 78.0b2 I'm using the default compiler (clang) -
> on another machine where I do my firefox beta testing the build with
> gcc (9.3.0) failed (Error but without any obvious detailed error
> message to explain what happened - but of course lots of output which
> happend to mention error or :Error in compiler warnings) so for the
> moment I'm using clang.

It's either a Firefox bug or a GCC bug.  Normally I would make a bug report but
I'm too lazy to build Firefox (I would need 4 additional packages for it: GTK+-
2, cbindgen, nodejs, and libevent).

One Mozilla developer once made a lecture in our university and said "do not try
to build Firefox without a powerful workstation" :).
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] node: should we move to v14 ?

[Xi Ruoyao via blfs-dev]

On 2020-06-03 10:59 -0500, Douglas R. Reno via blfs-dev wrote:
> On 6/3/20 6:57 AM, Ken Moffat via blfs-dev wrote:
> > I started writing this in the ticket for node-v12.18.0 (#13628),
> > but the C++ scope errors when using system nghttp2 prompted me to go
> > with 12.18.0 for the moment.  And then I discovered that the same
> > FTBFS occurred in 12.18.0, but right at the end of the build instead
> > of very early on. 
> > 
> > I'm fairly sure we have stuck to v12 at my suggestion, based on
> > https://nodejs.org/en/about/releases/ (v12 is 'active' until 20th
> > October, v14 is now 'current' i.e. development).  However, python2
> > has had its last release and I keep hoping that browsers
> > (specifically firefox and falkon via qtwebengine) will eventually
> > no-longer require it.  Node v12 will always require python2, but
> > python3 was added in v13 (which is now EOL) and is preferred if
> > found.
> > 
> > I'm guessing that moving to v14 before October _might_ add one or
> > two extra versions compared to v12, but equally v12 gets fairly
> > frequent releases.
> > 
> > For my own builds, apart from one this morning where I installed
> > v12.18.0 on one machine to check it seems to work, I'll be moving to
> > v14.4.0, partly because I hope to again try firefox (78, this time)
> > with python3 - although given the number of times my hopes have been
> > raised by the changes I've seen in ff diffs, I won't be surprised if
> > it's still not ready.
> 
> Hi Ken,
> 
> 
> I'm sure you know by now that the new nghttp2 fixes this problem :)
> 
> Most of the reason why we stuck with the LTS release was due to the 
> update frequency I think. I think we should stay with v12 until the next 
> LTS comes out. The problem I have with Node is the amount of time it 
> takes to build (and subsequently update the book). Last time I did it, 
> it took me around 3 hours to complete. I think it makes more sense for 
> us to stay with an LTS release over a development release, especially 
> when it comes to releasing the book in September.
> 
> However, the potential move to python3 for Node.js is appealing too. I'm 
> not sure what to say here, because I think we should stay with the LTS 
> but it would be nice to get rid of another Python2 user.
> 
> Why does Mozilla insist on having node.js installed when building? It 
> seems kind of odd to me that they'd use a competing JavaScript engine 
> when they have their own that is built during the build process.

Is it really needed?  The doc from mozilla doesn't mention it:

https://firefox-source-docs.mozilla.org/setup/linux_build.html
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Can't install sudo-1.9.0 as a package user

[Xi Ruoyao via blfs-dev]

On 2020-06-01 10:58 +0100, John Burrell via blfs-dev wrote:
> I use MSB's package user package management system and up til now it
> has worked fine but I've come unstuck installing sudo-1.9.0.
> 
> I get:
> 
> make[1]: Entering directory '/usr/src/security/sudo/sudo-1.9.0/lib/util'
> /bin/sh ../../scripts/mkinstalldirs /usr/lib/sudo
> case "" in \
> *-no-install*) ;; \
> *)  if [ X"yes" = X"yes" ]; then \
> INSTALL_BACKUP='' /bin/sh ../../libtool --tag=disable-static --quiet
> --mode=install /bin/sh ../../install-sh -c -o 0 -g 0 libsudo_util.la
> /usr/lib/sudo; \
> fi;; \
> esac
> /sbin/chown: changing ownership of
> '/usr/lib/sudo/libsudo_util.so.0.0.0': Operation not permitted
> make[1]: *** [Makefile:284: install] Error 1
> 
> In the dir lib/util the relevant bit of the Makefile.in is:
> 
> install: install-dirs
> case "$(LT_LDFLAGS)" in \
> *-no-install*) ;; \
> *)  if [ X"$(shlib_enable)" = X"yes" ]; then \
> INSTALL_BACKUP='$(INSTALL_BACKUP)' $(LIBTOOL)
> $(LTFLAGS) --quiet --mode=install $(INSTALL) $(INSTALL_OWNER)
> libsudo_util.la $(DESTDIR)$(libexecdir)/sudo; \
> fi;; \
> esac
> 
> install-dirs:
> $(SHELL) $(scriptdir)/mkinstalldirs $(DESTDIR)$(libexecdir)/sudo
> 
> install-binaries:
> 
> install-includes:
> 
> install-doc:
> 
> install-plugin:
> 
> I assume the chown occurs as part of the install-binaries but I can't
> find the code for install-binaries. Could someone give me a clue as to
> where I might find this code?

I never use this package management approach but it does not make sense to
install sudo with a non-root user owning it.  sudo only works as a setuid-root
executable.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] gnome-shell bug

[Xi Ruoyao via blfs-dev]

On 2020-05-01 10:07 -0500，Bruce Dubbs via blfs-dev wrote:
> On 5/1/20 7:35 AM, Xi Ruoyao via blfs-dev wrote:
> > After upgrading to gnome-shell-3.32, it sometimes crashes.  I searched
> > gnome-
> > shell repo with the stack backtrace info and found it's
> > 
> > https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2709
> > 
> > A patch is avaliable at
> > 
> > https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1230
> > 
> > and it seems that this patch can fix this problem.
> > 
> > Should we add this patch?
> > 
> 
> Best I can tell, the only significant change is in 
> subprojects/extensions-app/data/ui/extensions-window.ui
> 
> and the change is:
> 
> -Extension Updates Ready
> +Extension Updates 
> Ready

I think you viewed wrong page :(.

!1230 is swapping line 290 and 291 in src/st/st-theme.c.

> So that would be an easy sed.
> 
>-- Bruce
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[blfs-dev] gnome-shell bug

[Xi Ruoyao via blfs-dev]

After upgrading to gnome-shell-3.32, it sometimes crashes.  I searched gnome-
shell repo with the stack backtrace info and found it's

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2709

A patch is avaliable at

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1230

and it seems that this patch can fix this problem.

Should we add this patch?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] new intel graphic driver

[Xi Ruoyao via blfs-dev]

On 2020-04-24 14:00 -0500, Douglas R. Reno via blfs-dev wrote:
> On 4/24/20 9:52 AM, Xi Ruoyao via blfs-dev wrote:
> > In mesa-20.x the default dri driver for Intel Gen8+ (Broadwell and later)
> > iGPUs
> > has been changed to "iris" gallium driver, instead of the old "i965" driver.
> > 
> > I've added "iris" to GALLIUM_DRV in mesa instruction.  If you encounter any
> > problem with it you can add "MESA_LOADER_DRIVER_OVERRIDE=i965" to
> > /etc/profile,
> > to switch back to old i965 driver.
> > 
> > And, for Ice Lake and upcoming new generation of Intel CPUs libva-intel-
> > driver
> > won't work.  intel-media-driver is necessary for libva on Ice Lake.  It
> > depends
> > on intel-gmmlib.  I tried it on my laptop and it works (playing videos with
> > gstreamer and gstreamer-vaapi, and 1080p online videos on bilibili.com with
> > epiphany, gstreamer, and gstreamer-vaapi).
> 
> When trying to get this to work with mesa-20.0.5 on my system, trying to 
> launch Plasma resulted in a SIGABRT:
> 
> Core was generated by `/opt/kf5/bin/kwin_x11 -session 
> 10504f4f4800015848152030187340003_1587753581'.
> Program terminated with signal SIGABRT, Aborted.
> #0  raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:50
> 50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> [Current thread is 1 (Thread 0x7f34ddfed700 (LWP 27335))]
> (gdb) bt
> #0  raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x7f34f8224134 in KCrash::defaultCrashHandler(int) () at 
> /opt/kf5/lib/libKF5Crash.so.5
> #2  0x7f34f6a126e0 in  () at /lib/libc.so.6
> #3  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #4  0x7f34f69fc53b in __GI_abort () at abort.c:79
> #5  0x7f34f6f77a29 in  () at /opt/qt5/lib/libQt5Core.so.5
> #6  0x7f34e47f0b09 in 
> QtPrivate::QFunctorSlotObject nt(KWin::Platform::OpenGLSafePoint)::{lambda()#1}, 
> 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, 
> QObject*, void**, bool*) () at 
> /opt/kf5-5.67.0/lib/plugins/org.kde.kwin.platforms/KWinX11Platform.so
> #7  0x7f34f71b45d3 in  () at /opt/qt5/lib/libQt5Core.so.5
> #8  0x7f34f71b7fba in QTimer::timeout(QTimer::QPrivateSignal) () at 
> /opt/qt5/lib/libQt5Core.so.5
> #9  0x7f34f71aca15 in QObject::event(QEvent*) () at 
> /opt/qt5/lib/libQt5Core.so.5
> #10 0x7f34f7c0661f in QApplicationPrivate::notify_helper(QObject*, 
> QEvent*) () at /opt/qt5/lib/libQt5Widgets.so.5
> #11 0x7f34f7c0f2b0 in QApplication::notify(QObject*, QEvent*) () at 
> /opt/qt5/lib/libQt5Widgets.so.5
> #12 0x7f34f7181632 in QCoreApplication::notifyInternal2(QObject*, 
> QEvent*) () at /opt/qt5/lib/libQt5Core.so.5
> #13 0x7f34f71d4900 in QTimerInfoList::activateTimers() () at 
> /opt/qt5/lib/libQt5Core.so.5
> #14 0x7f34f71d2dcf in 
> QEventDispatcherUNIX::processEvents(QFlags) 
> () at /opt/qt5/lib/libQt5Core.so.5
> #15 0x7f34f718034b in 
> QEventLoop::exec(QFlags) () at 
> /opt/qt5/lib/libQt5Core.so.5
> #16 0x7f34f6fae7ae in QThread::exec() () at /opt/qt5/lib/libQt5Core.so.5
> #17 0x7f34f6faf77d in  () at /opt/qt5/lib/libQt5Core.so.5
> #18 0x7f34f855def7 in start_thread (arg=) at 
> pthread_create.c:477
> #19 0x7f34f6ad423f in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> 
> Apr 24 13:42:10 POOH /usr/libexec/gdm-x-session[27226]: Freeze in OpenGL 
> initialization detected
> Apr 24 13:42:10 POOH /usr/libexec/gdm-x-session[27226]: Unable to start 
> Dr. Konqi
> Apr 24 13:42:10 POOH /usr/libexec/gdm-x-session[27226]: Re-raising 
> signal for core dump handling.
> Apr 24 13:42:10 POOH /usr/libexec/gdm-x-session[27169]: Service ":1.48" 
> unregistered
> 
> I did build Mesa with iris support as we have it in the book now, 
> however I'm hesitant to release the update to Mesa-20.0.5 unless we 
> decide to revert this (or if there is a fix available upstream, I'll go 
> look for that next). After exporting MESA_LOADER_DRIVER_OVERRIDE=i965 in 
> a file in /etc/profile.d, I was able to get Plasma to start again. If we 
> decide to revert it, I'll have to redo my stats.
> 
> This system is Skylake-based (which is one generation after Broadwell) 
> and uses Intel HD Graphics 530 as it's GPU. The kernel I have in use is 
> 5.5.3. The CPU in use is a Core i5-6600k.

I have an i5-6500 but unfortunately it's in my office, where I can't reach now
(because of the stupid COVID).

> Do you have any suggestions and am I missing anything? i965 seems to 
> work well for me in this case, but as I understand, it won't for newer 
> Intel CPUs?

I searched mesa repo and nothing useful is found.  So

[blfs-dev] new intel graphic driver

[Xi Ruoyao via blfs-dev]

In mesa-20.x the default dri driver for Intel Gen8+ (Broadwell and later) iGPUs
has been changed to "iris" gallium driver, instead of the old "i965" driver.

I've added "iris" to GALLIUM_DRV in mesa instruction.  If you encounter any
problem with it you can add "MESA_LOADER_DRIVER_OVERRIDE=i965" to /etc/profile,
to switch back to old i965 driver.

And, for Ice Lake and upcoming new generation of Intel CPUs libva-intel-driver
won't work.  intel-media-driver is necessary for libva on Ice Lake.  It depends
on intel-gmmlib.  I tried it on my laptop and it works (playing videos with
gstreamer and gstreamer-vaapi, and 1080p online videos on bilibili.com with
epiphany, gstreamer, and gstreamer-vaapi).
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] build dvisvgm within texlive (again)?

[Xi Ruoyao via blfs-dev]

On 2020-04-14 04:54 +0100, Ken Moffat via blfs-dev wrote:
> On Tue, Apr 14, 2020 at 10:30:43AM +0800, Xi Ruoyao via blfs-dev wrote:
> > Now we can simple change --disable-dvisvgm to --enable-dvisvgm, to build
> > dvisvgm
> > shipped in texlive source code.  So we can remove dvisvgm page completely.
> > 
> 
> I have not tried that.  It used to be very painful because the
> version in TL was very modified from upstream's version (modified
> _by_ upstream, to suit TL's build which prefers to use old versions
> of everything and static libs.
> 
> > And, potrace is only used by dvisvgm, in texlive.  If we keep --disable-
> > dvisvgm
> > in texlive then system potrace is not needed.
> 
> But this I disagree with, I looked at one point and saw in my log
> that -lpotrace was used for libptexenc.so.1.3.0
> 
> OTOH, I've now built the package at least a dozen times with various
> settings and I don't see -lpotrace in my latest logs for either svn
> or 9.1.

If we use --enable-dvisvgm for TL, it will build dvisvgm with internal shipped
potrace code.  --with-system-potrace is not honored (`grep -r system-potrace`
shows nothing).

The other parts doesn't use potrace.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[blfs-dev] build dvisvgm within texlive (again)?

[Xi Ruoyao via blfs-dev]

Now we can simple change --disable-dvisvgm to --enable-dvisvgm, to build dvisvgm
shipped in texlive source code.  So we can remove dvisvgm page completely.

And, potrace is only used by dvisvgm, in texlive.  If we keep --disable-dvisvgm
in texlive then system potrace is not needed.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] [lfs-dev] gnome-shell failure building man page

[Xi Ruoyao via blfs-dev]

(move to blfs-dev since we're discussing BLFS packages)

On 2020-04-13 10:45 +0800, Xi Ruoyao via lfs-dev wrote:
> On 2020-04-13 12:01 +1000, Christoph Willing via lfs-dev wrote:
> > gnome-shell-3.36.1 from svn Version 2020-04-11 fails with:
> > 
> > [19/187] Generating gnome-extensions.1 with a custom command.
> > FAILED: subprojects/extensions-tool/man/gnome-extensions.1
> > /usr/bin/a2x -D subprojects/extensions-tool/man --xsl-file
> > ../subprojects/extensions-tool/man/stylesheet.xsl -f manpage
> > ../subprojects/extensions-tool/man/gnome-extensions.txt
> >   File "/usr/bin/a2x", line 76
> > print '%s: %s' % (PROG,msg)
> >   ^
> > SyntaxError: invalid syntax
> > 
> > 
> > I initially worked around this by adding -Dman=false to the command line
> > i.e.
> > 
> > mkdir build && \
> > cd build && \
> > meson --prefix=/usr -Dsystemd=false -Dman=false .. && \
> > ninja
> > 
> > That enabled the build to succeed, although without addressing the
> > underlying a2x problem.
> > 
> > Looking at the a2x problem, I believe the invalid syntax problem is
> > because I have:
> > /usr/bin/python -> python3
> 
> Don't do that.
> 
> > If I change that to:
> > /usr/bin/python -> python2
> > 
> > then the build succeeds (although with a warning which I don't see when
> > /usr/bin/python -> python3):
> > [40/187] Generating gnome-extensions.1 with a custom command.
> > a2x: WARNING: --destination-dir option is only applicable to HTML based
> > outputs
> > 
> > 
> > I don't recall how /usr/bin/python became symlink to python3 - perhaps
> > it should be to python2. Maybe that should be made explicit somewhere?
> 
> BLFS book explicitly said asciidoc deps on Python 2.
> 
> > BTW I see there is an asciidoc-py3 available at:
> > https://github.com/asciidoc/asciidoc-py3
> > 
> > Is it worth moving to that?
> 
> It's 9.0.0rc2.  We are waiting for 9.0.0 release.  I'll create a ticket to
> track.

It's now http://wiki.linuxfromscratch.org/blfs/ticket/13404.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] proposal: add -DLLVM_BINUTILS_INCDIR=/usr/include for LLVM

[Xi Ruoyao via blfs-dev]

On 2020-04-04 07:40 +0200, Thomas Trepl via blfs-dev wrote:
> Am Freitag, den 27.03.2020, 22:13 +0800 schrieb Xi Ruoyao via blfs-
> dev:
> > It would make LLVM building system to build LLVMgold.so with Binutils
> > headers
> > installed in LFS, which is a linker plugin so we can use "clang -flto hw.c".
> 
> What impact does it have if we do not add the -DLLVM switch.
> In general, reusing whats already there is always a good idea.

LLVMgold.so won't be built.  And commands like "clang -flto hw.c" will fail.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Network-manager-applet and libnma split as well as package placement

[Xi Ruoyao via blfs-dev]

On 2020-04-01 18:48 -0500, Douglas R. Reno via blfs-dev wrote:
> Good evening,
> 
> While looking at #13243 and updating gnome-control-center, I noticed 
> that network-manager-applet has split it's library into "libnma", which 
> is what programs such as gnome-control-center itself will link to.
> 
> Network-manager-applet can be used in XFCE or LXDE to setup the network 
> through a graphical session - which is especially useful on laptops. I 
> recall Ken using it at one point as well.
> 
> I'd like to propose moving network-manager-applet to "Network Programs" 
> and adding libnma to "Networking Libraries".

I agree.  polkit-gnome and notification-daemon should also be moved out.

> On that note, it seems that Mutter will require Graphene (as Xi noted in 
> #13242 - thanks for telling me that it's M/N/NI). I'd like to propose 
> adding that to "X Libraries".
> 
> gnome-settings-daemon's tests also needed 'umockdev' to complete the 
> power section. Should we decide to add that, I'd like to propose it 
> going into General Libraries. It would also be used in libgusb and 
> upower for tests - however I'd say adding it is optional since we can 
> mark the test suite as not functional unless it's installed (it also 
> seems to use Mutter, which would cause a circular dependency - I'm not 
> sure how to handle that).

Just put mutter into "optional (required for tests)".
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Python multiprocessing checks in chroot

[Xi Ruoyao via blfs-dev]

On 2020-03-27 11:46 +, Ken Moffat via blfs-dev wrote:
> On Fri, Mar 27, 2020 at 07:03:29AM +0100, Pierre Labastie via blfs-dev wrote:
> > Le 27/03/2020 à 00:22, Ken Moffat via blfs-dev a écrit :
> > > On Thu, Mar 26, 2020 at 10:57:03PM +0100, Pierre Labastie via blfs-dev
> > > wrote:
> > > 
> > > (asking about only one item)
> > > > > If you do not do this, configuring will fail with a python traceback
> > > > > report referencing a /usr/lib/pythonN.N/multiprocessing/synchronize.py
> > > > > file and ending 'OSError: [Errno 38] Function not implemented'.
> > > > > (this explanation possibly in italics, i.e. emphasis, except for the
> > > > > filename markup)
> > > > 
> > > > As the starter of this thread, I do not see exactly this error, but
> > > > rather:
> > > > 
> > > > File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 59, in
> > > > 
> > > > " function, see issue 3770.")
> > > > ImportError: This platform lacks a functioning sem_open implementation,
> > > > therefore, the required synchronization primitives needed will not
> > > > function,
> > > > see issue 3770.
> > > > 
> > > 
> > > Which package is this which does not mention OSError, please ?
> > > 
> > 
> > Hmmm, I realize that "as the starter of the thread" may mean I started the
> > thread... Of course I did not. It is the message you mentioned earlier that
> > started that (from Nagasayanam, V.S. on March 21st). The message is about
> > mozjs-60.8.0. And you can see that there is no mention of OSError.
> 
> Thanks.  That was why it took me so long to originally find my notes
> (for which the key item to grep was OSError).  I assumed it might
> have been trimmed off.
> 
> > When trying today with host debian, I get:
> > --
> >  0:23.64 Creating config.status
> >  0:23.76 Traceback (most recent call last):
> >  0:23.76   File "/sources/firefox/firefox-68.6.0/configure.py", line 132, in
> > 
> >  0:23.76 sys.exit(main(sys.argv))
> >  0:23.76   File "/sources/firefox/firefox-68.6.0/configure.py", line 43, in
> > main
> >  0:23.76 return config_status(config)
> >  0:23.76   File "/sources/firefox/firefox-68.6.0/configure.py", line 127, in
> > config_status
> >  0:23.76 return config_status(args=[], **encode(sanitized_config,
> > encoding))
> >  0:23.76   File
> > "/sources/firefox/firefox-68.6.0/python/mozbuild/mozbuild/config_status.py",
> > line 132, in config_status
> >  0:23.76 reader = BuildReader(env)
> >  0:23.76   File
> > "/sources/firefox/firefox-
> > 68.6.0/python/mozbuild/mozbuild/frontend/reader.py",
> > line 854, in __init__
> >  0:23.77 self._gyp_worker_pool =
> > ProcessPoolExecutor(max_workers=max_workers)
> >  0:23.77   File
> > "/sources/firefox/firefox-
> > 68.6.0/third_party/python/futures/concurrent/futures/process.py",
> > line 285, in __init__
> >  0:23.77 EXTRA_QUEUED_CALLS)
> >  0:23.77   File "/usr/lib/python2.7/multiprocessing/__init__.py", line 218,
> > in
> > Queue
> >  0:23.77 return Queue(maxsize)
> >  0:23.77   File "/usr/lib/python2.7/multiprocessing/queues.py", line 63, in
> > __init__
> >  0:23.77 self._rlock = Lock()
> >  0:23.77   File "/usr/lib/python2.7/multiprocessing/synchronize.py", line
> > 147,
> > in __init__
> >  0:23.77 SemLock.__init__(self, SEMAPHORE, 1, 1)
> >  0:23.77   File "/usr/lib/python2.7/multiprocessing/synchronize.py", line
> > 75,
> > in __init__
> >  0:23.77 sl = self._semlock = _multiprocessing.SemLock(kind, value,
> > maxvalue)
> >  0:23.77 OSError: [Errno 13] Permission denied
> >  0:23.84 *** Fix above errors and then restart with\
> >  0:23.84"./mach build"
> >  0:23.84 make: *** [client.mk:115: configure] Error 1
> > 
> > So again different.
> 
> OK, Every example mentions multiprocessing/synchronize.py near the
> end, but the exact details of the error message vary.
> 
> I'll drop the
>   and ending 'OSError: [Errno 38] Function not implemented'
> text.
> 
> I guess debian is passing back -EPERM from an attempt to access shm,
> whereas when LFS is the host that gets replaced by Error 38.
> 
> > Note that:
> > mount -t tmpfs devshm /dev/shm
> > cures the error
> > 
> > Pierre
> 
> I can settle for that, but was this build on sysvinit ?  From
> xry111's reply, and your earlier points, I got the impression this
> is only a problem on BLFS sysvinit.
> 
> If so, the Note should only be added in the sysvinit book.

No.  It's only *not* a problem if the host is LFS-sysvinit or debian.  They uses
/dev/shm -> /run/shm and we explicitly handle this in LFS section 6.2.

For other hosts, /dev/shm is a mount point of a seperated tmpfs, with perm 0777.
In mount -v --bind /dev $LFS/dev, --bind is not recursive so $LFS/dev/shm
becames a empty directory, owned by root:root with perm 0755.  So normal users
won't be able to use POSIX shared memory and semaphore.

I think we should change the command in 6.2:

if [ -h $LFS/dev/shm ]; then
  mkdir -pv $LFS/$(readlink $LFS/dev/shm)
fi

to

mount -v -t tmpfs 

[blfs-dev] proposal: add -DLLVM_BINUTILS_INCDIR=/usr/include for LLVM

[Xi Ruoyao via blfs-dev]

It would make LLVM building system to build LLVMgold.so with Binutils headers
installed in LFS, which is a linker plugin so we can use "clang -flto hw.c".
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Python multiprocessing checks in chroot

[Xi Ruoyao via blfs-dev]

On 2020-03-26 23:22 +, Ken Moffat via blfs-dev wrote:
> On Thu, Mar 26, 2020 at 10:57:03PM +0100, Pierre Labastie via blfs-dev wrote:
> 
> (asking about only one item)
> > > If you do not do this, configuring will fail with a python traceback
> > > report referencing a /usr/lib/pythonN.N/multiprocessing/synchronize.py
> > > file and ending 'OSError: [Errno 38] Function not implemented'.
> > > (this explanation possibly in italics, i.e. emphasis, except for the
> > > filename markup)
> > 
> > As the starter of this thread, I do not see exactly this error, but rather:
> > 
> > File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 59, in
> > 
> > " function, see issue 3770.")
> > ImportError: This platform lacks a functioning sem_open implementation,
> > therefore, the required synchronization primitives needed will not function,
> > see issue 3770.
> > 

from tmpfs (5):

>A tmpfs filesystem mounted at /dev/shm is used for  the  implementation
>of   POSIX   shared   memory  (shm_overview(7))  and  POSIX  semaphores
>(sem_overview(7)).

In kernel doc (Documentation/filesystems/tmpfs.txt):

> 2) glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
>POSIX shared memory (shm_open, shm_unlink). Adding the following
>line to /etc/fstab should take care of this:
> 
> tmpfs   /dev/shmtmpfs   defaults0 0
> 
>Remember to create the directory that you intend to mount tmpfs on
>if necessary.
> 
>This mount is _not_ needed for SYSV shared memory. The internal
>mount is used for that. (In the 2.3 kernel versions it was
>necessary to mount the predecessor of tmpfs (shm fs) to use SYSV
>shared memory)

So I think we should mount a tmpfs to /dev/shm, anyway.

In lfs-systemd it's automatically done by systemd.  In lfs-sysv book the
mountvirtfs bootscript makes /run/shm and link it to /dev/shm.  I think it's a
"hack" which is deprecated, and shall be replaced with a line mounting a tmpfs
to /dev/shm, in /etc/fstab.

> Which package is this which does not mention OSError, please ?
> 
> ĸen
> -- 
> When alle is ſayed and all is done, ye must chooſe your faces wisely,
> for soon enouff ye will be playing with fyre."
>   The Nice and Accurate Prophecies of Agnes Nutter, Prophecy 5004
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Python multiprocessing checks in chroot

[Xi Ruoyao via blfs-dev]

On 2020-03-26 16:06 +0100, Pierre Labastie via blfs-dev wrote:
> Le 26/03/2020 à 14:41, Ken Moffat via blfs-dev a écrit :
> > On Thu, Mar 26, 2020 at 11:40:59AM +0100, Pierre Labastie via
> > blfs-dev wrote:
> > > Le 23/03/2020 à 03:49, Bruce Dubbs via blfs-dev a écrit :
> > > > On 3/22/20 9:25 PM, Xi Ruoyao via blfs-dev wrote:
> > > > > On 2020-03-23 01:44 +, Ken Moffat via blfs-dev wrote:
> > > > > > On Mon, Mar 23, 2020 at 09:12:18AM +0800, Xi Ruoyao via
> > > > > > blfs-dev wrote:
> > > > > > > On 2020-03-22 21:34 +, Ken Moffat via blfs-dev wrote:
> > > > > > > 
> > > > > > > >   # mount --bind /run /mnt/lfs/run
> > > > > > > 
> > > > > > > I think it's dangerous: potentially harmful to the host. 
> > > > > > > Some service running in the LFS chroot may overwrite the
> > > > > > > runtime directory of the service running on the host.
> > > > > > 
> > > > > > So, you are saying that packages from mozilla should not now
> > > > > > be built in chroot ?
> > > > > 
> > > > > No.  I think we need a better way.
> > > > > 
> > > > > > But, what do you mean by a service running in chroot ?  I
> > > > > > assume we are specifically talking of systemd here ?  Do
> > > > > > services not get started during the boot process ?  The
> > > > > > systemd instance in chroot has never started, so I assume it
> > > > > > will be ineffective and systemd on the host will only care
> > > > > > about services described in /etc/systemd ?
> > > > > 
> > > > > Maybe that's not a issue.  But still, /run contains lots of
> > > > > sockets of running services.  That means now we can connect
> > > > > host services from the chroot environment.  Even if it's not
> > > > > dangerous to host, it's polluting the new LFS system.
> > > > > 
> > > > > Consider /run/initctl.  We don't want something in chroot to
> > > > > switch the *host* to runlevel 1 :).
> > > > 
> > > > What about
> > > > 
> > > >  mount -t tmpfs /run
> > > > 
> > > > from within chroot?
> > > > 
> > > >   -- Bruce
> > > 
> > > FWIIW, here are my findings: On a debian host, we have:
> > > 
> > > lrwxrwxrwx 1 root root 8 mars  26 09:48 /run/shm -> /dev/shm
> > > drwxrwxrwt 2 root root 40 mars  26 11:02 /dev/shm
> > > 
> > > But when mounting /dev to $LFS with mount --bind, we have
> > > 
> > > drwxr-xr-x 2 root root 40 mars  26 11:01 /mnt/lfs/dev/shm
> > > 
> > > that is, the sticky bit and the write perm are lost for an average
> > > user.
> > > 
> > > Now trying to build FF in chroot (creating kernel virtual
> > > filesystems and chrooting with the lfs book instructions): - as
> > > root: needs to issue "export SHELL", but otherwise succeeds
> > > without anything else (/run exists as a tmpfs , but /run/shm does
> > > not exist) - as user: no need to run "export SHELL" (I guess "su -
> > > " does the export), but the perms to /dev/shm need to be
> > > changed to rwt
> > > 
> > > In both cases, the build goes to completion (not tried to install)
> > > after the indicated changes.
> > > 
> > > Another check I've done: on a lfs system (9.1-rc1 Sys V) as per
> > > the book, /dev/shm is drwxrwxrwt, and /run/shm does not exist. But
> > > everybody knows it is possible to build firefox Actually, if you
> > > just mount a devtmpfs:
> > > 
> > > mkdir tempdir-for-trying-something sudo mount -t devtmpfs devtmpfs
> > > tempdir-for-trying-something ls -ld
> > > tempdir-for-trying-something/shm
> > > 
> > > then the shm perms are drwxrwxrwt.
> > > 
> > > So I'd suggest our instructions be changed to mount a devtmpfs in
> > > $LFS/dev
> > > 
> > > But what makes me think I do something different from ĸen is that
> > > I never see: OSError: [Errno 38] Function not implemented
> > > 
> > > 
> > > Pierre
> > > 
> > I'll reply in a while with what I have now tested (after I've
> > assembled my notes).  I've gone with Bruce's suggestion to (only)
> > mount a tmpfs on /run when building in chr

Re: [blfs-dev] Python multiprocessing checks in chroot

[Xi Ruoyao via blfs-dev]

On 2020-03-26 09:41 +0100, Pierre Labastie via blfs-dev wrote:
> So my suspicion is that when we mount --bind /dev, we lose some permissions,
> and those permissions are needed for FF. I'll have to try again without
> /run/shm

The problem is /dev/shm is a seperated tmpfs, instead of a normal directory in
/dev.  mount --bind is not recursive so in the bind mount /dev/shm is a normal
directory, which is not writable.

I suggest to simply mount a tmpfs on /dev/shm:

mount --bind /dev $LFS/dev
mount -v -t tmpfs tmpfs $LFS/dev/shm

> Will report
> Pierre
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Python multiprocessing checks in chroot

[Xi Ruoyao via blfs-dev]

On 2020-03-23 01:44 +, Ken Moffat via blfs-dev wrote:
> On Mon, Mar 23, 2020 at 09:12:18AM +0800, Xi Ruoyao via blfs-dev wrote:
> > On 2020-03-22 21:34 +, Ken Moffat via blfs-dev wrote:
> > 
> > >  # mount --bind /run /mnt/lfs/run
> > 
> > I think it's dangerous: potentially harmful to the host.  Some service
> > running
> > in the LFS chroot may overwrite the runtime directory of the service running
> > on
> > the host.
> 
> So, you are saying that packages from mozilla should not now be
> built in chroot ?

No.  I think we need a better way.

> But, what do you mean by a service running in chroot ?  I assume we
> are specifically talking of systemd here ?  Do services not get
> started during the boot process ?  The systemd instance in chroot
> has never started, so I assume it will be ineffective and systemd on
> the host will only care about services described in /etc/systemd ?

Maybe that's not a issue.  But still, /run contains lots of sockets of running
services.  That means now we can connect host services from the chroot
environment.  Even if it's not dangerous to host, it's polluting the new LFS
system.

Consider /run/initctl.  We don't want something in chroot to switch the *host*
to runlevel 1 :).
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Python multiprocessing checks in chroot

[Xi Ruoyao via blfs-dev]

On 2020-03-22 21:34 +, Ken Moffat via blfs-dev wrote:

>  # mount --bind /run /mnt/lfs/run

I think it's dangerous: potentially harmful to the host.  Some service running
in the LFS chroot may overwrite the runtime directory of the service running on
the host.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] [was:Archive Seamonkey] libreoffice

[Xi Ruoyao via blfs-dev]

On 2020-03-16 02:50 +, Ken Moffat via blfs-dev wrote:
> On Mon, Mar 16, 2020 at 02:19:03AM +0100, Uwe Düffert via blfs-dev wrote:
> > Hi,
> > 
> > On Sun, 15 Mar 2020, Ken Moffat via blfs-dev wrote:
> > 
> > > [...] after I've worked out why I cannot get
> > > libreoffice to build ;-)
> > What's the problem? libreoffice-6.4.2.2 built flawlessly for me with the sed
> > I needed to get libreoffice-6.4.2.1 to build - which I posted March 4th!?
> > 
> > Uwe
> 
> Hi Uwe,
> 
> I know you posted those fixes for later versions, but I've been
> trying not to change too much in this experimental build (5.6-rc5
> headers from last week, JS68 tried but removed and reverted to JS60
> because polkit didn't like it (sysv, not systemd), rustc-1.39.0 and
> primarily librsvg-1.39.0.

JS68 can be installed together with JS60.  GNOME 3.36 requires JS68 so we'll add
it into the book anyway.  For polkit I raised a MR:

https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/48
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Gstreamer crashing X

[Xi Ruoyao via blfs-dev]

On 2020-03-14 00:25 -0500, Douglas R. Reno via blfs-dev wrote:
> Hi folks,
> 
> Have any of you experienced X crashing with a SIGABRT anytime a program using
> gstreamer attempts to run? I've been stuck on this all day while rebuilding my
> workstation.

I didn't.

> I originally noticed this while building Cheese. I normally use that to test
> my Webcam. When running the meson command, X would crash with a SIGABRT.
> Examining the meson.log file, it seems to crash running:
> 
> "gst-inspect-1.0 camerabin"
> 
> It's worth noting that if I run this at a VT, I have no issues at all. If I
> run this or any gst-* program in a terminal, Xorg SIGABRTs. I've spent about
> four hours so far scouring through upstream and I can't figure anything out.
> Switching my phonon backend in Plasma to gstreamer from VLC also causes it to
> crash (I've also tried this in LXDE and Fluxbox).
> 
> Launching Cheese results in a SIGABRT as well. I've attempted to use GDB to
> latch onto Xorg, but I haven't been able to get it to give me a stack trace. 
> 
> Can someone else please look into this or try to reproduce this? I'm not sure
> what else to do from here. 

Which graphic card and graphic driver do you use?  I guess it may be a driver
issue.

And can you load the coredump file into GDB?  (On systemd) try:

coredumpctl -1 gdb
(gdb) bt

to generate a stack backtrace.

Xorg.0.log may also help.  It's a SIGABRT (not SIGSEGV) so some information
causing the crash may be logged.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[blfs-dev] several patches fixing build with -fno-common (for GCC 10) prepared

[Xi Ruoyao via blfs-dev]

GCC 10 will enable -fno-common by default.  It would break some "legacy"
(actually buggy IMO) code.  I found some cases in the book with GCC 9 and -fno-
common explicitly enabled.

Patches uploaded to http://www.linuxfromscratch.org/~xry111/fno-common-patches/.
I hope the upstream can fix these cases before GCC 10 (for SDL2, xorg-server and
pipewire the fix is already commited).  But if they don't we can grab these
patches as needed.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[blfs-dev] strange dependencies: samba -> python3 -> lsb-tools

[Xi Ruoyao via blfs-dev]

Now samba requires python 3, and python 3 requires lsb-tools.  I don't think
these make any sense:

* I can rebuild Python 3 (for upgrading) w/o lsb-tools.
* I can build samba with Python 3 built in LFS, before I rebuilt Python 3.

Should we remove them, or explain why we need these strange dependencies?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] [lfs-dev] Rendering XML sources: some entities not expanded

[Xi Ruoyao via blfs-dev]

On 2020-02-24 10:22 +0800，Kevin Buckley via lfs-dev wrote:

Wrong list.

> Can anything think of a reason why, when I render the Book sources
> locally, some entities don't render ?
> 
> I've recently noticed this with the ssh-askpass section in the BLFS book
> but have seen similar with the LFS sources too, when adding to them.
> 
> In the source the title fo the section is
> 
> ssh-askpass-
> 
> however when I render the book I only see
> 
> ssh-askpass-
> 
> What I notice in the entities file is that
> 
> 
> 
> and it's my suspicion that the extra level of indirection is causing
> what I'm seeing.
> 
> It's the same for a couple of other setiocn with similar entities
> 
> Any clues ?

I can't reproduce this issue.  My local rendering shows "ssh-askpass-8.2p1"
correctly.

> Kevin
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] proposal: move polkit-gnome to XFCE

[Xi Ruoyao via blfs-dev]

On 2020-02-15 21:51 -0600, Bruce Dubbs via blfs-dev:
> On 2/15/20 9:00 PM, Xi Ruoyao via blfs-dev wrote:
> > Though it's named "polkit-gnome", but now it's only used by XFCE and GNOME
> > doesn't use it at all.  gnome-shell has built-in polkit agent.
> 
> It's not used by network-manager-applet?

n-m-a just uses "a polkit agent" at runtime.  Other agents (gnome-shell or
lxpolkit) works as well.

> > And, notification-daemon is not used by GNOME.  Maybe we should also move it
> > somewhere.
> 
> We only reference it in libnotify and lxde-common.  There is an 
> alternative (xfce4-notifyd) for it in both packages.  Should we remove 
> notification-daemon completely?  The differences though are the 
> dependencies.  notification-daemon seems simpler.

I'm not a XFCE user.  We'd like to hear some opinion from XFCE users about which
notify daemon they prefer.

> I do not have a problem moving n-d to Chapter 12, System Utilities.
> 
>-- Bruce
> 
> 
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[blfs-dev] proposal: move polkit-gnome to XFCE

[Xi Ruoyao via blfs-dev]

Though it's named "polkit-gnome", but now it's only used by XFCE and GNOME
doesn't use it at all.  gnome-shell has built-in polkit agent.

And, notification-daemon is not used by GNOME.  Maybe we should also move it
somewhere.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] proposal: archive gnome-themes-extra

[Xi Ruoyao via blfs-dev]

On 2020-02-15 01:32 -0600, Douglas R. Reno via blfs-dev wrote:
> On 2/14/20 10:03 PM, Xi Ruoyao via blfs-dev wrote:
> > The themes in gnome-themes-extra have been integrated into GTK+-3 long long
> > ago.
> > And, the only packages "depends on" it are gnome-shell and GTK+-3.  I've
> > tested
> > them w/o gnome-themes-extra.  I think we can remove it from the book.
> > 
> > Or, remove those two false dependencies and let GTK+-2 optionally depends on
> > gnome-themes-extra (to provide themes for GTK+-2 applications so we can make
> > them "look like" GTK+-3 applications).
> I think option two is better in this case (remove dependencies and make 
> GTK+-2 depend on runtime)

Done in r22694.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[blfs-dev] proposal: archive gnome-themes-extra

[Xi Ruoyao via blfs-dev]

The themes in gnome-themes-extra have been integrated into GTK+-3 long long ago.
And, the only packages "depends on" it are gnome-shell and GTK+-3.  I've tested
them w/o gnome-themes-extra.  I think we can remove it from the book.

Or, remove those two false dependencies and let GTK+-2 optionally depends on
gnome-themes-extra (to provide themes for GTK+-2 applications so we can make
them "look like" GTK+-3 applications).
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[blfs-dev] evince: can not find kpathsea library

[Xi Ruoyao via blfs-dev]

To use kpathsea we've added:

CFLAGS="$CFLAGS -I/opt/texlive/2019/include" \
CXXFLAGS="$CXXFLAGS -I/opt/texlive/2019/include" \

But they are not enough:

configure:18489: checking for kpse_init_prog in -lkpathsea
configure:18514: gcc -o conftest -O3 -march=native -mtune=icelake-client -pipe
-fgraphite-identity -floop-nest-optimize -fipa-pta -falign-functions=32  -
I/opt/texlive/2019/include   conftest.c -lkpathsea   >&5
/usr/bin/ld: cannot find -lkpathsea
collect2: error: ld returned 1 exit status

Then configure script disables kpathsea.  It seems we'll need

LDFLAGS="$LDFLAGS -L/opt/texlive/2019/lib"
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Heads-up: new intel video driver, needs testing

[Xi Ruoyao via blfs-dev]

On 2020-01-04 21:14 +0800, Xi Ruoyao via blfs-dev wrote:
> On 2020-01-02 20:36 +, Ken Moffat via blfs-dev wrote:
> > On Fri, Jan 03, 2020 at 12:58:22AM +0800, Xi Ruoyao via blfs-dev wrote:
> > > On 2020-01-02 00:26 +, Ken Moffat via blfs-dev wrote:
> > > 
> > > I have a new Core i7-1065G7 laptop.  The legacy libva-intel-driver just
> > > doesn't
> > > work on Gen 11 graphic so I tried the new iHD driver.
> > > 
> > > Gstreamer refuses to use iHD driver with libva (by default it only
> > > utilizes
> > > libva-intel-driver).  I tried to force Gstreamer to use iHD.  It works
> > > with
> > > "gst-play-1.0" but breaks video replay in WebKitGTK (I tried 1080p videos
> > > on
> > > YouTube and Bilibili).  So finally I had to build intel-media-sdk and gst-
> > > msdk
> > > plugin (in gst-plugins-bad) to use the Gen 11 iGPU to accelerate video
> > > replay.
> > > 
> > 
> > Useful to know, as with everything to do with media
> > encoding/decoding the situation seems to be complex.
> > 
> > > My kernels (one from Arch and one built by myself) don't try to load
> > > GuC/HuC
> > > firmwares.  /sys/kernel/debug says my iGPU doesn't need HuC, and GuC is
> > > disabled.
> > > 
> > 
> > OK, thanks for that.  Looking a bit more deeply at what I regard as
> > a very hard to follow set of documentation (like some others, it's
> > probably fine if you already understand all the details) I see that
> > HuC is only needed for Hardware Encoding, Low Power
> > Encoding(VDEnc/Huc) on Skylake and later, but only for limited AVC
> > and jpeg on most existing platforms.
> > https://github.com/intel/media-driver/blob/master/docs/media_features.md#supported-video-processing-cscscaling-format
> 
> Gstreamer msdk plugin is still causing problems in Web browser.
> 
> I'll just use my CPU to decode videos, for now.

Finally I can use libgstmsdk.so compiled from gstreamer-1.17 (not released yet)
code to decode online videos with iGPU.  Unfortunately, Bilibili (and several
other video websites) work but Youtube not.

I think the new driver stack is still too premature.  Arch don't use it for
Gstreamer, and just began to test it for ffmpeg:

https://www.archlinux.org/packages/testing/x86_64/ffmpeg/

Let's wait.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Heads-up: new intel video driver, needs testing

[Xi Ruoyao via blfs-dev]

On 2020-01-02 20:36 +, Ken Moffat via blfs-dev wrote:
> On Fri, Jan 03, 2020 at 12:58:22AM +0800, Xi Ruoyao via blfs-dev wrote:
> > On 2020-01-02 00:26 +, Ken Moffat via blfs-dev wrote:
> > 
> > I have a new Core i7-1065G7 laptop.  The legacy libva-intel-driver just
> > doesn't
> > work on Gen 11 graphic so I tried the new iHD driver.
> > 
> > Gstreamer refuses to use iHD driver with libva (by default it only utilizes
> > libva-intel-driver).  I tried to force Gstreamer to use iHD.  It works with
> > "gst-play-1.0" but breaks video replay in WebKitGTK (I tried 1080p videos on
> > YouTube and Bilibili).  So finally I had to build intel-media-sdk and gst-
> > msdk
> > plugin (in gst-plugins-bad) to use the Gen 11 iGPU to accelerate video
> > replay.
> > 
> 
> Useful to know, as with everything to do with media
> encoding/decoding the situation seems to be complex.
> 
> > My kernels (one from Arch and one built by myself) don't try to load GuC/HuC
> > firmwares.  /sys/kernel/debug says my iGPU doesn't need HuC, and GuC is
> > disabled.
> > 
> 
> OK, thanks for that.  Looking a bit more deeply at what I regard as
> a very hard to follow set of documentation (like some others, it's
> probably fine if you already understand all the details) I see that
> HuC is only needed for Hardware Encoding, Low Power
> Encoding(VDEnc/Huc) on Skylake and later, but only for limited AVC
> and jpeg on most existing platforms.
> https://github.com/intel/media-driver/blob/master/docs/media_features.md#supported-video-processing-cscscaling-format

Gstreamer msdk plugin is still causing problems in Web browser.

I'll just use my CPU to decode videos, for now.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[blfs-dev] many docdir have no version number

[Xi Ruoyao via blfs-dev]

Hi,

I just tried a `ls /usr/share/doc | grep -v "\-[0-9]"`.  It turns out many
directory names w/o a version number.

Most of these names are from Xorg libraries and applications, for example
libX11. The remaining ones are (on my system):

brotli
gnome-session
libnotify
librsvg
systemd

We should spend some time to fix them.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Heads-up: new intel video driver, needs testing

[Xi Ruoyao via blfs-dev]

On 2020-01-02 00:26 +, Ken Moffat via blfs-dev wrote:
> Apologies for breaking the thread, I thought I had _copied_
> Pierre's mail to my notes, and then I edited my note on microcode
> to include the TLAs for Broadwell etc so that I could understand the
> intel release notes next time, and deleted the copy.  But what I'd
> actually done was Save the mail, so I'm now posting the original
> from the archive.  Sorry about that, blame it on too much
> williewaught [1.]
> 
> And thanks for finding these explanations of the TLAs.
> 
> Pierre wrote:
> 
> > Hi,
> > 
> > While investigating the bug in libva-2.6.0, I realized that there was a new
> > vaapi driver for intel GEN8+ graphics: iHD_drv_video.so
> > 
> > The source is at https://github.com/intel/media-driver.
> > 
> > If anybody with the appropriate hardware wants to try...
> > Personally, I am at 4th gen intel (Haswell), so I cannot test.
> > Note that it also requires the gmmlib graphics memory management library:
> > https://github.com/intel/gmmlib.
> > 
> > Note that libva-2.6.0 has a bug (https://github.com/intel/libva/issues/355)
> > which prevents using the i965 driver if the iHD driver is also installed. I
> > have provided a patch to fix this issue
> > (https://github.com/intel/libva/issues/356), but I cannot test for lack of
> > hardware! So if anybody has a recent intel CPU (
> > BDW (Broadwell)
> > SKL (Skylake)
> > BXT (Broxton) / APL (Apollo Lake)
> > KBLx (KBL/Kaby Lake; CFL/Coffe Lake; WHL/Whiskey Lake; CML/Comet Lake;
> > AML/Amber Lake)
> > ICL (Ice Lake)
> > JSL (Jasper Lake)/EHL (Elkhart Lake)
> > TGL (Tiger Lake)
> > )
> > please try it, thanks

I have a new Core i7-1065G7 laptop.  The legacy libva-intel-driver just doesn't
work on Gen 11 graphic so I tried the new iHD driver.

Gstreamer refuses to use iHD driver with libva (by default it only utilizes
libva-intel-driver).  I tried to force Gstreamer to use iHD.  It works with
"gst-play-1.0" but breaks video replay in WebKitGTK (I tried 1080p videos on
YouTube and Bilibili).  So finally I had to build intel-media-sdk and gst-msdk
plugin (in gst-plugins-bad) to use the Gen 11 iGPU to accelerate video replay.

> I _do_ have a low-end skylake (i3 6100), but I don't think I'll have
> time to look at this in January, and probably not in February.  But
> nevertheless, some comments.
> 
> First, GEN8+ is not the same as 8nnn CPUs (Kaby Lake etc).
> Broadwell is 5nnn, Skylake are 6nnn (or 7nnn for some, but maybe
> those lack integrated graphics).  I think it means the 8th and later
> generations of intel integrated graphics.
> 
> Oddly, the link to the media-driver looks correct, but 404s when I
> click on it from the archive.  But looking at the README there are
> two types of build: Full Feature and Free Kernel.  I don't grok the
> explanation of the differences, but I see that Arch have a build
> which looks straightforward, ditto intel-gmmlib.
> 
> Importantly, HuC firmware is needed for several of the encoders,
> this is currently disabled by default in released kernels (I believe
> there is an attempt to get it enabled by default in 5.5 or perhaps
> 5.6).  The kernel docs apparently explain how to enable it on
> current kernels, but I would be very wary of doing that until it
> arrives in a released kernel, because there have been so many
> problems.  Back in July phoronix reported it would be loaded by
> default in IceLake (Gen 11).  In particular,
> https://wiki.archlinux.org/index.php/Intel_graphics#Enable_GuC_/_HuC_firmware_loading
> says that loading GuC/HuC firmware can cause freezing, e.g. when
> resuming from hibernation.  But the bottom of that page says it is
> out of date: Reason: GuC submission has been completely disabled in
> the kernel, due to it reducing performance and causing bugs. Setting
> enable_guc=3 has no effect.
> 
> Yes, that is GuC not HuC, but it doesn't give me a lot of
> confidence.  Once a release kernel enables HuC on 5nnn and 6nnn CPUs
> with integrated graphics, things ought to be fine.  But meanwhile, I
> would class it as "here might be dragons".
> 
> Hmm, found the phoronix article I was thinking of,
> https://www.phoronix.com/scan.php?page=news_item=Intel-GuC-HuC-Auto-Enable-Again
> With a link to the patch.  On this AMD machine I've got kernel 5.4.5
> source, the patch has NOT been applied there:
> 
> > diff --git a/drivers/gpu/drm/i915/i915_params.h  
> > > b/drivers/gpu/drm/i915/i915_params.h
> > > index d29ade3b7de6..5736c55694fe 100644
> > > --- a/drivers/gpu/drm/i915/i915_params.h
> > > +++ b/drivers/gpu/drm/i915/i915_params.h
> > > @@ -54,7 +54,7 @@ struct drm_printer;
> > > param(int, disable_power_well, -1) \
> > > param(int, enable_ips, 1) \
> > > param(int, invert_brightness, 0) \
> > > -   param(int, enable_guc, 0) \
> > > +   param(int, enable_guc, -1) \
> > > param(int, guc_log_level, -1) \
> > > param(char *, guc_firmware_path, NULL) \
> > > 

Re: [blfs-dev] RFC: remove '..' in our meson commands

[Xi Ruoyao via blfs-dev]

On 2020-01-01 00:14 +, Ken Moffat via blfs-dev wrote:
> On Wed, Jan 01, 2020 at 03:20:33AM +0800, Xi Ruoyao via blfs-dev wrote:
> > Hi:
> > 
> > Now most of our meson commands contains a '..' but a few does not.  Maybe we
> > should remove all '..' in meson commands.  Reasons:
> > 
> > (1)  '..' is unnecessary in meson command, with "mkdir build; cd build".
> > (2)  Sometimes we forgot to "mkdir build; cd build" and type the meson
> > command
> > in the source code directory, mistakenly.  With a '..' meson will believe
> > '..'
> > is the building directory and produce build.ninja and many other files in
> > '..'. 
> > It's hard to clean them because BLFS source code directory (/usr/src or
> > $HOME/src) contains lots of tarballs.  However, without '..' if we forgot to
> > type "mkdir build; cd build" meson would complain and exit, instead of
> > producing
> > the files.
> > 
> > Any thoughts?
> 
> While I'm still maybe sober - I've seen both.  The scattering of
> files around .. is certainly painful to clear up, and the exit if
> not in a build directory is useful.

I just done it again :(.

> But I see Bruce prefers to be explicit.  Dunno about that, in
> ./configure scripts we usually ignore options which are the defaults
> (compare various builds in AUR and gentoo).

Well we are already relying on the implicit behaviors a lot.
For example, "--buildtype=debugoptimized" (I almost always override it
with "--buildtype=release").
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[blfs-dev] RFC: remove '..' in our meson commands

[Xi Ruoyao via blfs-dev]

Hi:

Now most of our meson commands contains a '..' but a few does not.  Maybe we
should remove all '..' in meson commands.  Reasons:

(1)  '..' is unnecessary in meson command, with "mkdir build; cd build".
(2)  Sometimes we forgot to "mkdir build; cd build" and type the meson command
in the source code directory, mistakenly.  With a '..' meson will believe '..'
is the building directory and produce build.ninja and many other files in '..'. 
It's hard to clean them because BLFS source code directory (/usr/src or
$HOME/src) contains lots of tarballs.  However, without '..' if we forgot to
type "mkdir build; cd build" meson would complain and exit, instead of producing
the files.

Any thoughts?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] llvm-9.0.1 seems to break rustc-1.37.0

[Xi Ruoyao via blfs-dev]

On 2019-12-25 00:33 +, Ken Moffat via blfs-dev wrote:
> On Tue, Dec 24, 2019 at 04:59:53PM -0600, Douglas R. Reno via blfs-dev wrote:
> > On 12/24/19 3:14 PM, Ken Moffat via blfs-dev wrote:
> > > On Mon, Dec 23, 2019 at 10:09:17PM +, Ken Moffat via blfs-dev wrote:
> > > > Arch have a patch for thunderbird, described as for rustc-1.39.0.
> > > > https://git.archlinux.org/svntogit/packages.git/plain/trunk/thunderbird-rust-1.39.patch?h=packages/thunderbird
> > > > 
> > > There is also thunderbird beta in arch (currently 72.0b2 -
> > > thunderbird tracks firefox major releases, but non-ESR are only
> > > ever beta, although a comment suggests that might have changed) :
> > > https://aur.archlinux.org/packages/thunderbird-beta/?setlang=en
> > > 
> > > I'm mentioning this because at the moment it is noted as broken by
> > > rustc-1.40.0.
> > > 
> > > ĸen
> > 
> > Good evening guys,
> > 
> > Since we have LLVM-9 in the book now (since Sunday) and I had to leave the
> > house for a bit today, I ran a build of rustc-1.37 with the following
> > commit:
> > 
> > https://github.com/rust-lang/rust/commit/04304fcd16e40c936dc5ba71c9ac3c445597f8bb
> > 
> > I got past the LLVM build error, but now I have another one:
> > 
> > Copying stage1 std from stage1 (x86_64-unknown-linux-gnu ->
> > x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
> > Building stage1 test artifacts (x86_64-unknown-linux-gnu ->
> > x86_64-unknown-linux-gnu)
> >Compiling proc_macro v0.0.0 (/sources/rustc-1.37.0-src/src/libproc_macro)
> > error: Could not compile `proc_macro`.
> > 
> > Caused by:
> >   process didn't exit successfully:
> > `/sources/rustc-1.37.0-src/build/bootstrap/debug/rustc --edition=2018
> > --crate-name proc_macro src/libproc_macro/lib.rs --color always
> > --error-format json --crate-type lib --emit=dep-info,metadata,link -C
> > opt-level=2 -C metadata=b2a98432edc77a2f -C extra-filename=-b2a98432edc77a2f
> > --out-dir /sources/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage1-
> > test/x86_64-unknown-linux-gnu/release/deps
> > --target x86_64-unknown-linux-gnu -L dependency=/sources/rustc-1.37.0-
> > src/build/x86_64-unknown-linux-gnu/stage1-test/x86_64-unknown-linux-
> > gnu/release/deps
> > -L dependency=/sources/rustc-1.37.0-src/build/x86_64-unknown-linux-
> > gnu/stage1-test/release/deps
> > -C link-args=-lffi` (signal: 11, SIGSEGV: invalid memory reference)
> > command did not execute successfully:
> > "/sources/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo"
> > "build" "--target" "x86_64-unknown-linux-gnu" "-j" "1" "--release"
> > "--manifest-path" "/sources/rustc-1.37.0-src/src/libtest/Cargo.toml"
> > "--message-format" "json"
> > expected success, got: exit code: 101
> > failed to run: /sources/rustc-1.37.0-src/build/bootstrap/debug/bootstrap
> > build --exclude src/tools/miri
> > Build completed unsuccessfully in 0:00:05
> > 
> > I don't think that I"m doing anything differently from the book. I copied
> > and pasted the stuff in there.
> > 
> > One of the things that I dislike about Mozilla is that they expect the
> > version of rustc to be the same across the entire lifecycle of an ESR
> > release. From my interpretation of this thread, I think we only have a few
> > options:
> > 
> 
> I think that expectation is probably common in "enterprise" distros,
> it's just unusual that we happen to explicitly use such versions
> (thunderbird, and for convenience firefox).
> 
> > 1 - Revert LLVM to 8.0.1
> > 
> > 2 - Force rustc to use it's internal LLVM version
> > 
> > 3 - Backport the fix for rustc and LLVM, and then somehow fix the problems
> > with proc_macro
> > 
> > 4 - Update rustc, and then patch Thunderbird and Firefox (and potentially
> > other consumers)
> > 
> > I think the easiest will be number 2. I don't think we want to stay with
> > LLVM-8 for the rest of this release cycle at least. Eventually we will
> > encounter updates to Mesa and the like that may need a later LLVM.
> > Backporting that fix is the second easiest solution, but we might have a
> > chicken and egg problem with other rust consumers. IIRC the primary reason
> > why we had to upgrade rustc last time was due to librsvg.
> > 
> > - Doug
> > 
> 
> No. 2 certainly sounds easier.  The problem with no.4 is identifying
> the remaining fix(es).  I can't say that I like no.2, and for my own
> usage (avoid llvm if possible, because gcc tends to have better
> security options in its available flags) llvm-8.0.1 is fine.  But
> whether that is true in mesa releases before we release 9.1 is
> unknown.
> 
> The big problem with rust is its lack of stability - other compilers
> deprecate things and then often remove them in a release or two, but
> that typically means 6 months or a year - with rust two releases is
> only about 12 weeks.
> 
> BTW - since I've noted the time : Happy Xmas everyone.

I still perfer No. 3.  There is a PR for LLVM-9 in rust repo:

Re: [blfs-dev] Testing without python2 : dead halt at JS60.

[Xi Ruoyao via blfs-dev]

On 2019-12-16 00:53 +, Ken Moffat via blfs-dev wrote:
> Indeed.  The "patch" I found was 9800 lines.  I haven't counted how
> many lines are in my first attempt to update it.  I have a severe
> dislike of python, as is probably already apparent (the whitespace
> issue) and I mostly find the error messages unuseful - if it fails
> to find a specific thing, I would hope to get a more-specific
> message.

I uploaded a mozjs-60 tarball which can be built with /usr/bin/python ->
python3：

http://www.linuxfromscratch.org/~xry111/mozjs-60.8.0-py3-src.tar.xz

“Patching" won't work here.  Inside the source code tree there is a file n
amed pip-8.1.2-py2.py3-none-any.whl.  It's actually a zip file containing some
python code.  One .py file in the whl file have to be updated.  "Patching" can't
modify a zip file.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] gdm does not start on recent Sysv builds

[Xi Ruoyao via blfs-dev]

On 2019-12-16 09:11 -0600, Douglas R. Reno via blfs-dev wrote:
> On 12/16/19 3:19 AM, Pierre Labastie via blfs-dev wrote:
> > Hi,
> > 
> > I had 3 working BLFS builds of Gnome desktop over Sysv, but
> > somewhere between
> > one week ago and now, gdm got broken and does not start anymore
> > (begins
> > stating, but stops with a message "Oh no ! something has gone
> > wrong, contact a
> > system administrator" (how helpful !). I have not
> > been able to get useful messages from /var/log/gdm, but what I see
> > now in the
> > logs is that there are messages from the X server, which weren't
> > one week ago
> > (I think gdm was starting directly on wayland). Maybe it has
> > something to do
> > with this message from the log file:
> > gnome-session-binary[1370]: WARNING: Falling back to non-systemd
> > startup
> > procedure due to error:
> > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown:
> > The name org.freedesktop.systemd1 was not provided by any .service
> > files.
> > 
> > I have no time to investigate more, because I have to leave for a
> > few days.
> 
> I'm around two days out on my SysV system. I should be able to look
> into 
> it a couple days from now.
> 
> I think it may be related to one of the updates I did recently. One 
> suspect could be gnome-desktop. I don't think I updated GDM
> recently, 
> but it could also be gnome-session or gnome-control-center.

I remember once I upgraded gnome-desktop then seen "Oh no" from GDM. 
Then I fixed that by rebuilding GDM.

> > But I begin to be fed up of those repeated attempts from gnome
> > folks to
> > prevent using their desktop without systemd.
> > Pierre
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Continued GNOME issues - can you guys reproduce?

[Xi Ruoyao via blfs-dev]

On 2019-10-20 13:32 -0500，Douglas R. Reno via blfs-dev wrote:
> Hi guys,
> 
> I'm having some really annoying issues with GNOME-3.34.1 on my 
> development machine. One of them is with the tweaks app. I've added 
> libhandy to my system (I'll add it to the book soon), but I get the 
> following errors when trying to turn on the Window List extension (which 
> I use because it's hard for my single eye to focus well on the 
> Activities menu - being blind in one eye sometimes causes DEs to be very 
> difficult for me to use):
> 
> Oct 17 14:26:09 POOH gnome-shell[2583]: JS ERROR: Extension 
> window-l...@gnome-shell-extensions.gcampax.github.com: Error: Schema 
> org.gnome.shell.extensions.window-list could not be found for extension 
> window-l...@gnome-shell-extensions.gcampax.github.com. Please check your 
> installation.
> getSettings@resource:///org/gnome/shell/misc/extensionUtils.js:140:15
> enable@
> 
/usr/share/gnome-shell/extensions/window-l...@gnome-shell-extensions.gcampax.github.com
> /extension.js:1130:26
> _callExtensionEnable@resource:///org/gnome/shell/ui/extensionSystem.js:131:13
> _onEnabledExtensionsChanged/<@resource:///org/gnome/shell/ui/extensionSystem.j
> s:398:13
> _onEnabledExtensionsChanged@resource:///org/gnome/shell/ui/extensionSystem.js:
> 395:9
> 
> There are also a lot of JS warnings scattered throughout my logs from 
> when I had gnome-tweaks open.
> 
> In addition, the search bar is not functioning. When you click the 
> Activities menu, you're supposed to be able to type in the search bar 
> and find applications or files. Clicking on it results in nothing but a 
> blinking cursor, and you're completely unable to type in it. If you 
> attempt to right click to paste something, the options "Copy" and 
> "Paste" are grayed out. My guess is that tracker isn't starting 
> properly, but I'm not honestly sure. My autostart list is also 
> completely empty so I'm wondering if that has something to do with it.
> 
> I've spent a couple days looking for fixes and can't seem to find 
> anything. Do you guys have any suggestions, and can I get someone else 
> to install GNOME to attempt to reproduce these problems?

I can't reproduce this issue with GNOME-3.34.2 packages.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] rustc and DESTDIR

[Xi Ruoyao via blfs-dev]

On 2019-09-30 12:57 -0500, Bruce Dubbs via blfs-dev wrote:
> On 9/30/19 12:40 PM, Xi Ruoyao via blfs-dev wrote:
> > On 2019-09-30 12:37 -0500, Bruce Dubbs via blfs-dev wrote:
> > > On 9/30/19 12:25 PM, Xi Ruoyao via blfs-dev wrote:
> > > > On 2019-09-30 19:22 +0200, Thomas Trepl via blfs-dev wrote:
> > > > > Hi all,
> > > > > 
> > > > > so far i have built a nice Xfce system avoiding python2, gtk2 and
> > > > > rustc at all and Xfce-4.14 builds/runs fine without gtk2. For librsvg
> > > > > i use the old non-rust version 2.40.20 which still works pretty well -
> > > > > ok, i know, thats not really the way to go but building gigabytes of
> > > > > compiler stuff just for one lib?
> > > > > 
> > > > > But now, for firefox it seems that there's no way around. All of
> > > > > browsers have downsides (epihani needs webkitgtk needs gtk2, falcon
> > > > > needs Python2, seamonkey needs gtk2, firefox needs rustc,gtk2). All i
> > > > > need is a good browser so unfortunatly i need to "die some kind of
> > > > > death".
> > > > > 
> > > > > Well i started to fool around with rust and tried to package using the
> > > > > DESTDIR mechanism.
> > > > > 
> > > > > In rusts config file the prefix is specified
> > > > > 
> > > > > [install]
> > > > > prefix = "/opt/rustc-1.35.0"
> > > > > 
> > > > > and according to the instructions we create that dir upfront. Since
> > > > > book also uses DESTDIR strategy I thought "ah, its easy, just put my
> > > > > DESTDIR there instead of $pwd/install" and left out the creation of
> > > > > the /opt/rustc-1.35.0 out because i do not install in "real"
> > > > > locations.
> > > > > 
> > > > > Badly enough, install failed with an error message like "/opt/rustc-
> > > > > 1.35.0 cannot be canonicalized" or such.
> > > > > 
> > > > > After a few re-runs of building rustc (much fun it is to wait and do
> > > > > it again because of a typo in the build script...) I ended up with
> > > > > creating the $prefix dir on the build machine even DESTDIR install
> > > > > puts the files somewhere else.
> > > > > Looking at Arch's instructions, they do pretty much same but their
> > > > > $prefix is "/usr" which obviously already exists on building machine.
> > > > > 
> > > > > Have you ever tried to install rust via DESTDIR and if yes, did you
> > > > > see same issue and if yes, how did you work around?
> > > > 
> > > > Yes.  I had to "mkdir /opt/rustc-{version}".
> > > 
> > > Why not just use the instructions in the book?
> > > 
> > >   From the note in the book:
> > > 
> > > "Unusually, a DESTDIR-style method is being used to install this
> > > package. This is because running the install as root not only downloads
> > > all of the cargo files again (to /root/.cargo), it then spends a very
> > > long time recompiling. Using this method saves a lot of time, at the
> > > cost of extra disk space."
> > > 
> > > 
> > > DESTDIR=${PWD}/install python3 ./x.py install
> > 
> > The error message "/opt/rustc-1.35.0 cannot be canonicalized" shows up HERE,
> > before the "cp" command creating /opt/rustc-1.35.0.
> > 
> > > sudo chown -R root:root install
> > > sudo cp -a install/* /
> 
> Right, The book explicitly says:
> 
>   To install into the /opt directory, remove the symlink and create a 
> new directory (i.e. with a different name if trying a modified build). 
> As the root user:
> 
> mkdir /opt/rustc-1.35.0
> ln -svfin rustc-1.35.0 /opt/rustc
> 
> FBBG
> 
>-- Bruce

Oh, I didn't read carefully.  Sorry for that :(.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] rustc and DESTDIR

[Xi Ruoyao via blfs-dev]

On 2019-09-30 12:37 -0500, Bruce Dubbs via blfs-dev wrote:
> On 9/30/19 12:25 PM, Xi Ruoyao via blfs-dev wrote:
> > On 2019-09-30 19:22 +0200, Thomas Trepl via blfs-dev wrote:
> > > Hi all,
> > > 
> > > so far i have built a nice Xfce system avoiding python2, gtk2 and
> > > rustc at all and Xfce-4.14 builds/runs fine without gtk2. For librsvg
> > > i use the old non-rust version 2.40.20 which still works pretty well -
> > > ok, i know, thats not really the way to go but building gigabytes of
> > > compiler stuff just for one lib?
> > > 
> > > But now, for firefox it seems that there's no way around. All of
> > > browsers have downsides (epihani needs webkitgtk needs gtk2, falcon
> > > needs Python2, seamonkey needs gtk2, firefox needs rustc,gtk2). All i
> > > need is a good browser so unfortunatly i need to "die some kind of
> > > death".
> > > 
> > > Well i started to fool around with rust and tried to package using the
> > > DESTDIR mechanism.
> > > 
> > > In rusts config file the prefix is specified
> > > 
> > > [install]
> > > prefix = "/opt/rustc-1.35.0"
> > > 
> > > and according to the instructions we create that dir upfront. Since
> > > book also uses DESTDIR strategy I thought "ah, its easy, just put my
> > > DESTDIR there instead of $pwd/install" and left out the creation of
> > > the /opt/rustc-1.35.0 out because i do not install in "real"
> > > locations.
> > > 
> > > Badly enough, install failed with an error message like "/opt/rustc-
> > > 1.35.0 cannot be canonicalized" or such.
> > > 
> > > After a few re-runs of building rustc (much fun it is to wait and do
> > > it again because of a typo in the build script...) I ended up with
> > > creating the $prefix dir on the build machine even DESTDIR install
> > > puts the files somewhere else.
> > > Looking at Arch's instructions, they do pretty much same but their
> > > $prefix is "/usr" which obviously already exists on building machine.
> > > 
> > > Have you ever tried to install rust via DESTDIR and if yes, did you
> > > see same issue and if yes, how did you work around?
> > 
> > Yes.  I had to "mkdir /opt/rustc-{version}".
> 
> Why not just use the instructions in the book?
> 
>  From the note in the book:
> 
> "Unusually, a DESTDIR-style method is being used to install this 
> package. This is because running the install as root not only downloads 
> all of the cargo files again (to /root/.cargo), it then spends a very 
> long time recompiling. Using this method saves a lot of time, at the 
> cost of extra disk space."
> 
> 
> DESTDIR=${PWD}/install python3 ./x.py install

The error message "/opt/rustc-1.35.0 cannot be canonicalized" shows up HERE,
before the "cp" command creating /opt/rustc-1.35.0.

> sudo chown -R root:root install
> sudo cp -a install/* /
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] gnome tweaks 3.34

[Xi Ruoyao via blfs-dev]

On 2019-09-30 12:23 -0500, Bruce Dubbs via blfs-dev wrote:
> On 9/30/19 12:01 PM, Xi Ruoyao via blfs-dev wrote:
> > On 2019-09-30 10:52 -0500, Bruce Dubbs via blfs-dev write:
> > > On 9/30/19 4:14 AM, hykwok1--- via blfs-dev wrote:
> > > > GNOME TWEAKS 3.34.0 requires libhandy (
> > > > https://source.puri.sm/Librem5/libhandy) :
> > > > 
> > > > GIR files and libraries from:
> > > > 
> > > >   GLib (>= 2.58)
> > > >   GTK+ 3 (>= 3.12)
> > > >   gnome-desktop (>= 3.30)
> > > >   libhandy
> > > >   libsoup
> > > >   libnotify
> > > >   Pango
> > > > 
> > > > Reference: https://github.com/GNOME/gnome-tweaks
> > > 
> > > libhandy does not seem to be used anywhere in gnome-tweaks.  The only
> > > place 'handy' is mentioned in my build directory is in NEWS and
> > > README.md.   It is not mentioned at all in my build log.
> > 
> > It's a new runtime dependency in 3.34.0.  Without libhandy it won't
> > start.  It's
> > referenced with "Handy-0.0" (gobject typelib).
> > 
> > And epiphany also depends on libhandy (optionally, without system libhandy
> > it
> > would use shipped version).
> 
> What a PITA.  According to Arch, they don't release a tarball.  You can 
> only get it from git.
> 
> How should we handle this?  Create our own tarball?

https://source.puri.sm/Librem5/libhandy/-/archive/v0.0.11/libhandy-v0.0.11.tar.gz

Arch has some tendency to get packages from git :).
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] rustc and DESTDIR

[Xi Ruoyao via blfs-dev]

On 2019-09-30 19:22 +0200, Thomas Trepl via blfs-dev wrote:
> Hi all,
> 
> so far i have built a nice Xfce system avoiding python2, gtk2 and
> rustc at all and Xfce-4.14 builds/runs fine without gtk2. For librsvg
> i use the old non-rust version 2.40.20 which still works pretty well -
> ok, i know, thats not really the way to go but building gigabytes of
> compiler stuff just for one lib?
> 
> But now, for firefox it seems that there's no way around. All of
> browsers have downsides (epihani needs webkitgtk needs gtk2, falcon
> needs Python2, seamonkey needs gtk2, firefox needs rustc,gtk2). All i
> need is a good browser so unfortunatly i need to "die some kind of
> death".
> 
> Well i started to fool around with rust and tried to package using the
> DESTDIR mechanism.
> 
> In rusts config file the prefix is specified
> 
> [install]
> prefix = "/opt/rustc-1.35.0"
> 
> and according to the instructions we create that dir upfront. Since
> book also uses DESTDIR strategy I thought "ah, its easy, just put my
> DESTDIR there instead of $pwd/install" and left out the creation of
> the /opt/rustc-1.35.0 out because i do not install in "real"
> locations.
> 
> Badly enough, install failed with an error message like "/opt/rustc-
> 1.35.0 cannot be canonicalized" or such.
> 
> After a few re-runs of building rustc (much fun it is to wait and do
> it again because of a typo in the build script...) I ended up with
> creating the $prefix dir on the build machine even DESTDIR install
> puts the files somewhere else.
> Looking at Arch's instructions, they do pretty much same but their
> $prefix is "/usr" which obviously already exists on building machine.
> 
> Have you ever tried to install rust via DESTDIR and if yes, did you
> see same issue and if yes, how did you work around?

Yes.  I had to "mkdir /opt/rustc-{version}".
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] gnome tweaks 3.34

[Xi Ruoyao via blfs-dev]

On 2019-09-30 10:52 -0500, Bruce Dubbs via blfs-dev write:
> On 9/30/19 4:14 AM, hykwok1--- via blfs-dev wrote:
> > GNOME TWEAKS 3.34.0 requires libhandy (
> > https://source.puri.sm/Librem5/libhandy) :
> > 
> > GIR files and libraries from:
> > 
> >  GLib (>= 2.58)
> >  GTK+ 3 (>= 3.12)
> >  gnome-desktop (>= 3.30)
> >  libhandy
> >  libsoup
> >  libnotify
> >  Pango
> > 
> > Reference: https://github.com/GNOME/gnome-tweaks
> 
> libhandy does not seem to be used anywhere in gnome-tweaks.  The only 
> place 'handy' is mentioned in my build directory is in NEWS and 
> README.md.   It is not mentioned at all in my build log.


It's a new runtime dependency in 3.34.0.  Without libhandy it won't start.  It's
referenced with "Handy-0.0" (gobject typelib).

And epiphany also depends on libhandy (optionally, without system libhandy it
would use shipped version).
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Why is LLVM recommended for gst-plugins-bad?

[Xi Ruoyao via blfs-dev]

On 2019-09-25 14:33 -0500, Douglas R. Reno via blfs-dev wrote:
> On 9/25/19 2:24 PM, Xi Ruoyao via blfs-dev wrote:
> > I tried to grep "llvm" and "LLVM" in gst-plugins-bad-1.16.1 source code
> > tree.
> > All references seem related to Mac OS, nothing Linux.
> In gst-plugins-bad.1.14.4, when autotools was still supported, LLVM was 
> listed as a dependency in the configure script, which is why we 
> documented it

The only code snip containing "llvm" in configure:

> $as_echo_n "checking whether $CC is Clang... " >&6; }
> if ${ax_cv_PTHREAD_CLANG+:} false; then :
>   $as_echo_n "(cached) " >&6
> else
>   ax_cv_PTHREAD_CLANG=no
>  # Note that Autoconf sets GCC=yes for Clang as well as GCC
>  if test "x$GCC" = "xyes"; then
> cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> /* end confdefs.h.  */
> /* Note: Clang 2.7 lacks __clang_[a-z]+__ */
> #if defined(__clang__) && defined(__llvm__)
>  AX_PTHREAD_CC_IS_CLANG
> #endif
> 
> _ACEOF
> if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
>   $EGREP "AX_PTHREAD_CC_IS_CLANG" >/dev/null 2>&1; then :
>   ax_cv_PTHREAD_CLANG=yes
> fi
> rm -f conftest*

This is just for testing if the compiler is clang.  Absolutely not a dependency.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[blfs-dev] Why is LLVM recommended for gst-plugins-bad?

[Xi Ruoyao via blfs-dev]

I tried to grep "llvm" and "LLVM" in gst-plugins-bad-1.16.1 source code tree. 
All references seem related to Mac OS, nothing Linux.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[blfs-dev] proposal: archive fuse2

[Xi Ruoyao via blfs-dev]

Now gvfs-1.42 has been ported to use fuse3 and nothing depends on fuse2.
Should we archive it?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] What's left for the 9.0 release?

[Xi Ruoyao via blfs-dev]

On 2019-08-30 21:44 +0200, Pierre Labastie via blfs-dev wrote:
> On 30/08/2019 17:44, Xi Ruoyao via blfs-dev wrote:
> > On 2019-08-30 10:24 -0500, Douglas R. Reno wrote:
> > > On 2019-08-30 10:22, Xi Ruoyao via blfs-dev wrote:
> > > > On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote:
> > > > > All packages have now been tagged and all tickets closed for the 9.0
> > > > > release.  What other things are remaining that we need to address 
> > > > > before
> > > > > the Sunday release?
> > > > > 
> > > > >-- Bruce
> > > > 
> > > > It seems #12448 and #12459 contain various security fixes.  Should we 
> > > > backport
> > > > them to 9.0?
> > > > --
> > > > Xi Ruoyao 
> > > > School of Aerospace Science and Technology, Xidian University
> > > 
> > > #12456 (Ruby) has a fix for two vulnerabilities - one from 2012 and one 
> > > from 2015. The problem with backporting updates is that I believe that 
> > > everything that links to them has to be retested. That being said 
> > > though, I'd give a +1 to backporting them.
> > 
> > I'll try a full jhalfs build to verify 9.0 tomorrow.  I hope I can use
> > jhalfs
> > correctly and my 16-core workstation will work fine.  But I can't guarantee
> > any
> > success.
> > 
> 
> If you need anything, please tell me. I think a full blfs can be built by
> editing at most 30 scripts, most notably:

I failed.  Either I misused jhalfs or it has a bug.  I got some "Error 2" from
make and was able to "fix" some of them.  But at last I can't continue anymore.

I'll read its documentation again...
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] What's left for the 9.0 release?

[Xi Ruoyao via blfs-dev]

On 2019-08-30 23:44 +0800, Xi Ruoyao wrote:
> On 2019-08-30 10:24 -0500, Douglas R. Reno wrote:
> > On 2019-08-30 10:22, Xi Ruoyao via blfs-dev wrote:
> > > On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote:
> > > > All packages have now been tagged and all tickets closed for the 9.0
> > > > release.  What other things are remaining that we need to address 
> > > > before
> > > > the Sunday release?
> > > > 
> > > >-- Bruce
> > > 
> > > It seems #12448 and #12459 contain various security fixes.  Should we 
> > > backport
> > > them to 9.0?
> > > --
> > > Xi Ruoyao 
> > > School of Aerospace Science and Technology, Xidian University
> > 
> > #12456 (Ruby) has a fix for two vulnerabilities - one from 2012 and one 
> > from 2015. The problem with backporting updates is that I believe that 
> > everything that links to them has to be retested. That being said 
> > though, I'd give a +1 to backporting them.
> 
> I'll try a full jhalfs build to verify 9.0 tomorrow.  I hope I can use jhalfs
> correctly and my 16-core workstation will work fine.  But I can't guarantee
> any
> success.
> 
> And volume-key can be built with Python 3 now.  It should be OK to move the P2
> dependency to optional (for Python 2 binding).  Should it be done in 9.0 or
> 9.1?

Sorry not volume-key but I can't recall which one now...  I built "that" package
a week ago I think.  Defer it to 9.1.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] What's left for the 9.0 release?

[Xi Ruoyao via blfs-dev]

On 2019-08-30 10:24 -0500, Douglas R. Reno wrote:
> On 2019-08-30 10:22, Xi Ruoyao via blfs-dev wrote:
> > On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote:
> > > All packages have now been tagged and all tickets closed for the 9.0
> > > release.  What other things are remaining that we need to address 
> > > before
> > > the Sunday release?
> > > 
> > >-- Bruce
> > 
> > It seems #12448 and #12459 contain various security fixes.  Should we 
> > backport
> > them to 9.0?
> > --
> > Xi Ruoyao 
> > School of Aerospace Science and Technology, Xidian University
> 
> #12456 (Ruby) has a fix for two vulnerabilities - one from 2012 and one 
> from 2015. The problem with backporting updates is that I believe that 
> everything that links to them has to be retested. That being said 
> though, I'd give a +1 to backporting them.

I'll try a full jhalfs build to verify 9.0 tomorrow.  I hope I can use jhalfs
correctly and my 16-core workstation will work fine.  But I can't guarantee any
success.

And volume-key can be built with Python 3 now.  It should be OK to move the P2
dependency to optional (for Python 2 binding).  Should it be done in 9.0 or 9.1?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] What's left for the 9.0 release?

[Xi Ruoyao via blfs-dev]

On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote:
> All packages have now been tagged and all tickets closed for the 9.0 
> release.  What other things are remaining that we need to address before 
> the Sunday release?
> 
>-- Bruce

It seems #12448 and #12459 contain various security fixes.  Should we backport
them to 9.0?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Where are we with respect to keyboard settings in gdm (elogind book)

[Xi Ruoyao via blfs-dev]

On 2019-08-29 09:19 -0600, Roger Koehler via blfs-dev wrote:
> On Thu, Aug 29, 2019, 8:55 AM Bruce Dubbs via blfs-dev <
> blfs-dev@lists.linuxfromscratch.org> wrote:
> > On 8/29/19 8:40 AM, Pierre Labastie via blfs-dev wrote:
> > > Hi,
> > > 
> > > With the shortly coming release, I think it is time I give some
> > information
> > > about my findings relative to the setting of the keyboard layout for gdm.
> > Note
> > > that I have not come to a definitive answer, far from it!
> > > 
> > > The main conclusion is that gdm uses gnome-shell, and that gnome-shell
> > uses
> > > systemd-localed for getting the keymap when it detects it is on a login
> > > screen... So there are two approaches:
> > > - add systemd- localed to the system. DJ has provided a patch, but I have
> > been
> > > unable to use it: or at least localectl does not launch systemd-localed,
> > and
> > > if I launch it manually before calling localectl, I get either "Function
> > not
> > > Implemented (for the set-keymap functions) or n/a for both vc-keymap and
> > > x11-keymap... Note that systemd-localed runs for a short while, then
> > exits...
> > > But I think it would be the cleanest approach if we could make it work!
> > > - tweak gnome-shell so that it uses the gsettings database (Bruce has
> > provided
> > > a sed for that, which works). But this leads to another problem, how to
> > change
> > > user settings for the "gdm" user. I have a workaround, which works to a
> > > certain degree, but is not satisfactory, since it does not change the
> > > screen-keyboard layout: copy the user dconf database to gdm user's home. I
> > > still have to try Christopher's suggestions to override gsettings. It it
> > works
> > > it is cleaner I think. Now, I have a system where both keyboard layout and
> > > screen-keyboard are azerty, but I am unable to know what put it in this
> > state
> > > (tried too many things). So there is a third solution, but I do not know
> > what!
> > > It certainly does not use either the gsettings override nor the user db...
> > It
> > > might be the following that I have tried (inspired by
> > > 
> > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/desktop_migration_and_administration_guide/customizing-login-screen
> > )
> > > 
> > > I created /etc/dconf/profile/gdm with:
> > > user-db:user
> > > system-db:gdm
> > > file-db:/usr/share/gdm/greeter-dconf-defaults
> > > 
> > > Then I created a small gdm database in /etc/dconf/db/gdm.d/01-keyboard
> > > [org/gnome/desktop/input-sources]
> > > sources=[('xkb','fr)]
> > > 
> > > Then I run dconf update... At first, it did nothing, but I was still using
> > a
> > > non-sed'ed gnome-shell. Then, when I changed to a sed'ed one, I got the
> > French
> > > layout...
> > > 
> > > Something to try, but the gsettings override might be easier, if it works.
> > 
> > I hope you are staying interested in this, but for the book, I don't 
> > think it is relevant.  The intricacies of the interaction between gnome 
> > and systemd are what's wrong with the design of systemd and gnome.
> > 
> >  From the book's perspective I think we need to either remove gdm from 
> > the System V book or put in a big caveat that gdm does not work with 
> > non-us keyboards in the System V environment and to use another display 
> > manager or the command line to initiate gnome.
> 
> Does this mean that System V is dying and that I should start getting used to
> systemd?

And Bruce may believe GNOME is dying :).  Try not to start a flame war.

Though I'm a user of GNOME and systemd I believe GNOME is behaving stupidly with
locale settings.  Now I just leave /etc/locale.conf for GNOME (so I can use
Chinese in GUI) and set LANG=en_US.UTF-8 in .zshrc for my TTY.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] pango-1.44.5, version 2019-08-17, book adjustments (errata on my previous email, typo error)

[Xi Ruoyao via blfs-dev]

On 2019-08-18 10:09 -0400, Jean-Marc Pigeon via blfs-dev wrote:
> Hello
> 
> pango 1.44.5 was issued
> (revert a broken change (causing crashes on OS X))
> 
> More important, meson configuration variables changed
> 
> -Denable-docs is now -Dgtk_doc
> -Dgir is now -Dinstrospection
> 
> (this was done with 1.44.0)

It still requires a development version of cairo to work properly.  I don't
think we should update pango before BLFS-9.0.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[blfs-dev] proposal: add gstreamer-1.16.0 buffer size reset patch

[Xi Ruoyao via blfs-dev]

https://gitlab.freedesktop.org/gstreamer/gstreamer/commit/8a9b20a18b76bf9004f2f8004b4293e1ac7a48aa

This patch fixes an issue causing test failure on 32-bit and potentially memory
leaking on all platforms.  On 32-bit it also breaks test suite of gst-plugins.

I think we should fix this in 9.0.  Any option?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] ntfs-3g-2017.3.23

[Xi Ruoyao via blfs-dev]

On 2019-08-11 09:33 +, spiky0011 via blfs-dev wrote:
> Running configure on ntfs
> 
> i get an ugly output at end of configure
> 
> "config.status: executing libtool commands
> /bin/rm: cannot remove 'libtoolT': No such file or directory"
> 
> This dosn't seem to affect building, just looks like a fail/error.

I've seen this ugly output multiple times building BLFS packages.  I think
libtool is something just like an old piece of sh*t...

Though I don't get it but I think they're safe to be ignored.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] PyGTK broken by pango-1.44.1

[Xi Ruoyao via blfs-dev]

On 2019-08-05 10:54 +0800, Xi Ruoyao via blfs-dev wrote:
> On 2019-08-05 03:14 +0100, Ken Moffat via blfs-dev wrote:
> > For bitmap fonts, mw preference is to cast them into the outer
> > darkness, where there will be wailing and gnashing of teeth!  But
> > for CJK and double-width I'll take advice from xry211 ;-)
> 
> For Chinese, bitmap fonts would be stupidly large (there are too many glyphs!)
> so we almost never use bitmap fonts.
> 
> "Luckily" I've not upgraded Pango to 1.44.x yet.  I should backup my system
> and try, but later - after I finish my new LFS build with glibc-2.30.

I tried pango-1.44.3 with cairo-master (commit SHA is 52a7c79fd).

CJK fonts are fine.

Some powerline symbols became blank boxes but I fixed it by tweaking my
/etc/fonts/local.conf.

The font rendering LGTM.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] PyGTK broken by pango-1.44.1

[Xi Ruoyao via blfs-dev]

On 2019-08-05 03:14 +0100, Ken Moffat via blfs-dev wrote:
> On Sun, Aug 04, 2019 at 06:17:56PM -0500, Douglas R. Reno via blfs-dev wrote:
> > On 8/4/19 6:13 PM, Douglas R. Reno wrote:
> > > I'd like to start a discussion here on reverting Pango.
> > > 
> > > 
> > > As noted in the comments section here, this version of Pango drops
> > > support for bitmap fonts:
> > > 
> > > https://blogs.gnome.org/mclasen/2019/07/27/more-text-rendering-updates/
> > > 
> > > This causes terminal emulators to display empty boxes in double-width
> > > spaces, as just one example. In addition, there are countless rendering
> > > bugs here:
> 
> For bitmap fonts, mw preference is to cast them into the outer
> darkness, where there will be wailing and gnashing of teeth!  But
> for CJK and double-width I'll take advice from xry211 ;-)

For Chinese, bitmap fonts would be stupidly large (there are too many glyphs!)
so we almost never use bitmap fonts.

"Luckily" I've not upgraded Pango to 1.44.x yet.  I should backup my system and
try, but later - after I finish my new LFS build with glibc-2.30.

> > > https://gitlab.gnome.org/GNOME/pango/issues
> > > 
> > > The developers are also recommending an unreleased version of Cairo to
> > > fix "rendering issues" in some of those issues. I don't think we want
> > > that.
> > > 
> > > I'm most definitely sure that removing Python support from GIMP is NOT
> > > the way to go. Note that there is a bug here for moving to PyGObject
> > > from PyGTK, but little to no progress:
> > > 
> > > https://gitlab.gnome.org/GNOME/gimp/issues/339
> > > 
> 
> At the moment, python2 is top of my hated-languages list (above even
> rust and recent C++) but gimp's immediate priority is gtk3.  Since
> python2 is unfortunately still used by graphical web browsers,
> getting rid of it isn't going to happen any time soon. :-(

Python 2 is also on the top of my hated-lanauges list.

I can accept Rust and I've began to use it for some of my toy programs.  But I
still can't accept a "Rustified" bzip2.

> > > I propose that we revert Pango to 1.42.x from 1.44.3 because of their
> > > dropping of bitmap font support, recommendation to use an unstable
> > > cairo, problems with PyGTK, and rendering issues.
> > > 
> > https://gitlab.gnome.org/GNOME/pango/issues/386
> > 
> 
> Sad, but perhaps the right thing to do for 9.0 - more generally,
> using harfbuzz is a good idea - but other important things need to
> be ready for it.
> > I forgot to add that in - Type1 fonts in GTK+2 are affected as well.
> > 
> 
> That sounds odd - Type1 fonts are scalable.  Any examples (font(s),
> and application(s)), please ?

Harfbuzz just don't support this format, yet.  With new Pango, I think the users
will push Harfbuzz guys to implement loaders for traditional bitmap fonts and
Type1 fonts, in several months :).
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Ken's tuning experiments, part 4

[Xi Ruoyao via blfs-dev]

On 2019-07-10 19:22 +0100, Ken Moffat via blfs-dev wrote:
> On Wed, Jul 10, 2019 at 01:08:30PM +0800, Xi Ruoyao via blfs-dev wrote:
> > On 2019-07-09 23:11 +0100, Ken Moffat via blfs-dev wrote:
> > > Also, I had hoped to examine LTO (and I might take a stab at the
> > > first part of that - my previous attempt at recompiling gcc
> > > was a disaster in its testsuite, but maybe that was because I had
> > > not understood the problem of using -D_FORTIFY_SOURCE=2 on gcc at
> > > that point).  However, the big gains touted for LTO (smaller
> > > programs) come at a compile time cost - for those of us who
> > > frequently rebuild I'm not at all sure that the cost will be
> > > worthwhile.
> > 
> > I only build GCC with LTO using --with-build-config=bootstrap-lto.  There
> > are
> > annoying problems with LTO and shared objects with ".symver" directive so I
> > never use LTO for other packages.
> > 
> > You may want to consult https://github.com/InBetweenNames/gentooLTO .
> 
> Thanks, I've not seen that config option, nor references to the
> problems with .symver.  More things for me to read about.

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

I've tried to write some code for it but my code is just like some pieces of
sh*t.  I'll stay and wait for Jan Hubicka to do this work.

> The gentooLTO site was one of the places I started looking at before I
> decided to try any of this, but at least I went into it with my eyes
> wide open about never getting the time back.
> 
> On the bright side (for me), by doing this I don't have time to test
> Linus's kernels.  Congratulations on your testing!

Just encountered a bug in 5.2 release, which Linus also encountered :(.

Now I'm trying to do a Python-3.7.4 build with LTO (its configure script now
supports --with-lto to do a LTO build).
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Ken's tuning experiments, part 4

[Xi Ruoyao via blfs-dev]

On 2019-07-09 23:11 +0100, Ken Moffat via blfs-dev wrote:
> I've now completed a real "tuning" run of my experiment (i.e.
> specifying -falign-functions=32 -malign-data=cacheline because these
> have been said to be beneficial for haswell processors, which is
> what I have been using.
> 
> Summary in
> http://www.linuxfromscratch.org/~ken/tuning/tuning-4-alignment-tests.txt
> and updated spreadsheet of the tests I was able to run 10 times on
> the different builds:
> 
> (desktop-runtime-comparisons.ods in the same directory).
> 
> Conclusion for this experiment: case not proven.
> 
> I hope to get one more run done ("turn all the optimization up to
>  -O3") but I will not be playing with alignment again.
> 
> Also, I had hoped to examine LTO (and I might take a stab at the
> first part of that - my previous attempt at recompiling gcc
> was a disaster in its testsuite, but maybe that was because I had
> not understood the problem of using -D_FORTIFY_SOURCE=2 on gcc at
> that point).  However, the big gains touted for LTO (smaller
> programs) come at a compile time cost - for those of us who
> frequently rebuild I'm not at all sure that the cost will be
> worthwhile.

I only build GCC with LTO using --with-build-config=bootstrap-lto.  There are
annoying problems with LTO and shared objects with ".symver" directive so I
never use LTO for other packages.

You may want to consult https://github.com/InBetweenNames/gentooLTO .
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Critical Firefox and Thunderbird 0days

[Xi Ruoyao via blfs-dev]

On 2019-06-27 03:28 +0800, Xi Ruoyao via blfs-dev wrote:
> On 2019-06-26 13:52 -0500, Douglas R. Reno via blfs-dev wrote:
> > On 6/26/19 1:47 PM, Xi Ruoyao via blfs-dev wrote:
> > > On 2019-06-26 12:22 -0500, Douglas R. Reno via blfs-dev wrote:
> > > 
> > > > [2]: https://www.mozilla.org/en-US/security/advisories/mfsa2019-18/
> > > [2] affects mozjs as well.
> > > 
> > > Should we upgrade mozjs to 60.7.2 or provide a patch?
> > 
> > We should probably provide a patch, although upgrading is a good option 
> > too considering the fact that it's not a new major version.
> > 
> > Can you give upgrading a shot? :-)
> 
> I'll start to download Firefox ESR 60.7.2 and go to sleep.  Tomorrow I'll
> extract mozjs-60.7.2 from it and try upgrading.

Again, I had to rebuild gjs to make GNOME work after upgrading mozjs to 60.7.2. 
Maybe a patch is better.

I can't understand this symptom because 1) it's not a new major version, 2) Arch
Linux doesn't rebuild gjs for mozjs upgrading.  Maybe it's caused by my CFLAGS
or something.

The tarball I extracted has been uploaded: 
http://www.linuxfromscratch.org/~xry111/mozjs-60.7.2.tar.xz

You can test it on your system but remember to backup before installation...
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Critical Firefox and Thunderbird 0days

[Xi Ruoyao via blfs-dev]

On 2019-06-26 13:52 -0500, Douglas R. Reno via blfs-dev wrote:
> On 6/26/19 1:47 PM, Xi Ruoyao via blfs-dev wrote:
> > On 2019-06-26 12:22 -0500, Douglas R. Reno via blfs-dev wrote:
> > 
> > > [2]: https://www.mozilla.org/en-US/security/advisories/mfsa2019-18/
> > [2] affects mozjs as well.
> > 
> > Should we upgrade mozjs to 60.7.2 or provide a patch?
> 
> We should probably provide a patch, although upgrading is a good option 
> too considering the fact that it's not a new major version.
> 
> Can you give upgrading a shot? :-)

I'll start to download Firefox ESR 60.7.2 and go to sleep.  Tomorrow I'll
extract mozjs-60.7.2 from it and try upgrading.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Critical Firefox and Thunderbird 0days

[Xi Ruoyao via blfs-dev]

On 2019-06-26 12:22 -0500, Douglas R. Reno via blfs-dev wrote:

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

[2] affects mozjs as well.

Should we upgrade mozjs to 60.7.2 or provide a patch?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Proposal: remove --with-system-nspr from mozjs configuration

[Xi Ruoyao via blfs-dev]

On 2019-05-31 09:30 -0500, Douglas R. Reno via blfs-dev wrote:
> On 5/31/19 4:11 AM, Xi Ruoyao via blfs-dev wrote:
> > Hi folks,
> > 
> > Now we have --with-system-nspr in mozjs configure command.  This
> > introduced a hard dependency to NSPR.  However, the upstream has
> > switched the default on GNU/Linux to --enable-posix-nspr-emulation long
> > long ago.
> > 
> > We can just remove --with-system-nspr and use the default.  This would
> > remove the dependency to NSPR.
> > 
> > I'll build GNOME and see if this change would break anything...
> > 
> Please verify with that build, but I think you are correct here.

Built GNOME libraries and desktop components with no problem.

> https://www.mail-archive.com/release-team@gnome.org/msg07100.html
> 
> When we first added JS60, I followed the recommendations here. I'm on 
> ftp-list and distro-list @ GNOME, so I got this one ahead of time before 
> GJS needed it.
> 
> --with-system-nspr being gone looks good to me.

So I'll go ahead to move NSPR and --with-system-nspr into optional.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] harfbuzz-2.5.0 download url

[Xi Ruoyao via blfs-dev]

On 2019-05-31 18:40 +1000, Wayne Blaszczyk via blfs-dev wrote:
> Hi,
> 
> The url does not work. The extension to the file should be xz rather
> than bz2.

Sorry for the mistake.  Fixed at r21642.

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

[blfs-dev] Proposal: remove --with-system-nspr from mozjs configuration

[Xi Ruoyao via blfs-dev]

Hi folks,

Now we have --with-system-nspr in mozjs configure command.  This
introduced a hard dependency to NSPR.  However, the upstream has
switched the default on GNU/Linux to --enable-posix-nspr-emulation long
long ago.

We can just remove --with-system-nspr and use the default.  This would
remove the dependency to NSPR.

I'll build GNOME and see if this change would break anything...

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

Re: [blfs-dev] Tuning: part 1 - making packages obey my CFLAGS

[Xi Ruoyao via blfs-dev]

On 2019-05-31 07:12 +0100, Ken Moffat via blfs-dev wrote:
> The threatened details of the first part of my investigation into
> the general subject of tuning (for packages which I normally build
> on my desktop systems) are now uploaded to
> http://www.linuxfromscratch.org/~ken/tuning/ - this is mostly just a
> list of packages and versions, in the order in which I build them.
> Currently using '-O2 -march=native' or '-O3 -march=native' where the
> package defaults to -O3, and taking steps to ensure that -g is
> removed.  And a set of notes for differences in how I've achieved
> this.
> 
> No, I doubt that -march=native is generally worth using, but it
> does show if my CFLAGS or CXXFLAGS are getting used.
> 
> Also, some comments on a few packages, e.g. how to get perl to use
> flags, and how anything using qmake will use the flags qt uses, or
> has been forced to use.
> 
> My next stage is to look at what should be the first of the cheap
> hardening options, -D_FORTIFY_SOURCE=2 : I have applied that to
> everything using gcc/g++ from the start of LFS chapter 6 **EXCEPT
> GLIBC** with currently one annoyance in c-ares (it wants defines in
> CPPFLAGS) and a total failure in boost, which is where I'm currently
> stalled.

I'm building my system with "-O3 -march=native -fipa-pta -fgraphite-
identity -floop-nest-optimize -falign-functions=32".   It's safe for
most packages (all packages following the ISO C/C++ standard,
theoratically) but also breaks several packages.

I'll try adding "-fno-common" next time (building LFS-8.5-rc with
Glibc-2.30) and write a note like you.

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

Re: [blfs-dev] [blfs-book] r21631 - trunk/BOOK/gnome/platform

[Xi Ruoyao via blfs-dev]

On 2019-05-29 21:49 +0200, Pierre Labastie via blfs-dev wrote:
> On 29/05/2019 17:27, Bruce Dubbs via blfs-dev wrote:
> > On 5/28/19 10:43 PM, xry111--- via blfs-book wrote:
> > 
> > > Modified: trunk/BOOK/gnome/platform/libsecret.xml
> > > =
> > > =
> > > --- trunk/BOOK/gnome/platform/libsecret.xmlMon May 27
> > > 14:40:12 2019   
> > > (r21630)
> > > +++ trunk/BOOK/gnome/platform/libsecret.xmlTue May 28
> > > 20:43:34 2019   
> > > (r21631)
> > > @@ -96,7 +96,7 @@
> > >   
> > > ,
> > > , and
> > > -  
> > > +   (Python 2 module)
> >
> > 
> > Does libsecret need Python 2 or can it use Python 3?  I note that
> > we don't
> > mention Py2 itself in the dependencies.  I'm sure that's left over
> > from when
> > we switched to Py2 in LFS.

Originally it was pygobject2, and pygobject2 requires P2.

> Actually, looking at the source, it seems everything in libsecret has
> been
> ported to Python 3; isn't Python 2 a typo?

Yes it is using P3 now.  I just grep -r the source code and found some
scripts with "#!/usr/bin/env python".  But it seems they are actually
executed with P3.

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

Re: [blfs-dev] [systemd] Add a warning about /run/nologin in shadow

[Xi Ruoyao via blfs-dev]

On 2019-05-12 12:03 -0500, Douglas R. Reno via blfs-dev wrote:
> On 5/12/19 1:48 AM, Xi Ruoyao via blfs-dev wrote:
> > On 2019-05-12 13:10 +0800, Xi Ruoyao via blfs-dev wrote:
> > > On 2019-05-11 16:07 +，DJ Lucas via blfs-dev:
> > > > Note that the root user can always login, regardless of /run/nologin.
> > > I think I've tried to use root but it didn't work...  Let me retry.
> > You're right.  When I tried to login as root, though the warning showed up,
> > I
> > could continue to login.  Maybe I rebooted the system just after seeing the
> > warning before.
> > 
> > Updated the note in r21583.
> > 
> > However, `echo 'rm -rf /run/nologin' > /lib/systemd/systemd-user-sessions`
> > really won't work.  I created a PR making systemd not to create /run/nologin
> > if
> > PAM is not enabled at build:
> > 
> > https://github.com/systemd/systemd/pull/12543
> Thanks for this, I'll login to GitHub and +1 it. I'm listed as the 
> maintainer of LFS systemd in their MAINTAINERS file, so this might get 
> up to the top of their queue faster.

It's merged but we still need to workaround it until systemd-243.

Workaround added to LFS book at r11604.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] [systemd] Add a warning about /run/nologin in shadow

[Xi Ruoyao via blfs-dev]

On 2019-05-12 13:10 +0800, Xi Ruoyao via blfs-dev wrote:
> On 2019-05-11 16:07 +，DJ Lucas via blfs-dev:
> > Note that the root user can always login, regardless of /run/nologin.
> 
> I think I've tried to use root but it didn't work...  Let me retry.

You're right.  When I tried to login as root, though the warning showed up, I
could continue to login.  Maybe I rebooted the system just after seeing the
warning before.

Updated the note in r21583.

However, `echo 'rm -rf /run/nologin' > /lib/systemd/systemd-user-sessions`
really won't work.  I created a PR making systemd not to create /run/nologin if
PAM is not enabled at build:

https://github.com/systemd/systemd/pull/12543
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Update mozjs-60 version (?)

[Xi Ruoyao via blfs-dev]

On 2019-05-11 08:58 -0500, Douglas R. Reno via blfs-dev wrote:
> On 5/11/19 1:29 AM, Xi Ruoyao via blfs-dev wrote:
> > Hi folks,
> > 
> > Now BLFS is using mozjs-60 package from ftp.gnome.org.  But it's the
> > "original"
> > mozjs-60.1.0 without any update.  Arch is now using latest mozjs-60.6.3,
> > even
> > Ubuntu is using a newer mozjs-60.2.3.
> > 
> > I downloaded Firefox ESR 60.6.3 code and removed everything unrelated to JS
> > engine I could find.  Then I built and installed mozjs-60.6.3 into my
> > system.  I
> > found my GNOME was broken but I could rebuild Gjs to fix it.
> > 
> > The extracted mozjs-60.6.3 tarball (it's just a Firefox tarball with many
> > directories removed) has been uploaded to:
> > 
> > http://www.linuxfromscratch.org/~xry111/mozjs-60.6.3.tar.xz
> > 
> > Now, is it worthy to update mozjs-60 version in BLFS book, following Firefox
> > ESR
> > 60?
> 
> I honestly think we should keep it the same version. Based off the fact 
> that GJS needs to be recompiled, I feel it is too much work to implement 
> because users will install it, most likely not read any warnings, and 
> then write to the lists. That'll cause extra noise where all we can say 
> is "FBBG, READ".

I'm not very sure about this.  Arch doesn't rebuild gjs for mozjs upgrade and
Arch Linux just works fine.  Maybe the issue happens because my old BLFS build
is "too dirty" (I upgraded ICU-63 to 64 and had to rebuild many packages).

I'll test an upgrade after I finish my new BLFS build.

> Is there a changelog? if so, can you find any security fixes in there 
> (look for CVE numbers)?

https://github.com/mozilla/gecko-dev/commits/esr60/js

It seems there are no security fixes since mozjs-60 release.  And if there is a
security bug in Firefox ESR I think we'll see it on news.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] [systemd] Add a warning about /run/nologin in shadow

[Xi Ruoyao via blfs-dev]

On 2019-05-11 16:07 +，DJ Lucas via blfs-dev:
> I had worked around this in LFS a long time ago. I created 
> /lib/systemd/systemd-user-sessions with nothing more than 'rm -f 
> /run/nologin' as it will be replaced when systemd is reinstalled in 
> BLFS. Is this no longer working? If not, the note certainly does not 
> hurt, in fact, it is helpful to explain this behavior, but I think that 
> the issue should also be corrected here, possibly even move the addition 
> in LFS to here. We need to tell the system that user sessions are ready 
> (in this minimal configuration, they actually are despite systemd not 
> being aware of this - we have to make it aware by removing the file). I 
> understand that this needs to have a caveat of "Do not do this if you've 
> already reinstalled systemd."

I've been prohibited to login and used my rescue disk several times.

In systemd meson build system (241 or 242), if PAM doesn't exist, systemd-user-
sessions.service won't be created or installed.  That renders the custom
/lib/systemd/systemd-user-sessions useless.

> Note that the root user can always login, regardless of /run/nologin.

I think I've tried to use root but it didn't work...  Let me retry.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] Update mozjs-60 version (?)

[Xi Ruoyao via blfs-dev]

On 2019-05-11 09:33 -0500, Bruce Dubbs via blfs-dev wrote:
> On 5/11/19 1:29 AM, Xi Ruoyao via blfs-dev wrote:
> > Hi folks,
> > 
> > Now BLFS is using mozjs-60 package from ftp.gnome.org.  But it's the
> > "original"
> > mozjs-60.1.0 without any update.  Arch is now using latest mozjs-60.6.3,
> > even
> > Ubuntu is using a newer mozjs-60.2.3.
> > 
> > I downloaded Firefox ESR 60.6.3 code and removed everything unrelated to JS
> > engine I could find.  Then I built and installed mozjs-60.6.3 into my
> > system.  I
> > found my GNOME was broken but I could rebuild Gjs to fix it.
> > 
> > The extracted mozjs-60.6.3 tarball (it's just a Firefox tarball with many
> > directories removed) has been uploaded to:
> > 
> > http://www.linuxfromscratch.org/~xry111/mozjs-60.6.3.tar.xz
> > 
> > Now, is it worthy to update mozjs-60 version in BLFS book, following Firefox
> > ESR
> > 60?
> 
> It would be better to figure out where ESR got the files so we can keep 
> it current.  I suppose we could ask him.

Firefox is a giant monolithic repo containing a complete web browser.  We only
want the Javascript engine in it.  If we don't care the download size, we can
use the giant Firefox ESR tarball:

https://hg.mozilla.org/releases/mozilla-esr60/archive/FIREFOX_60_6_3esr_RELEASE.tar.bz2

To build mozjs:

tar -xf FIREFOX_60_6_3esr_RELEASE.tar.bz2
cd mozilla-esr60-FIREFOX_60_6_3esr_RELEASE
sed '/divert/d' js/src/configure.in > js/src/configure
chmod +x js/src/configure

Then follow the BLFS book.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

Re: [blfs-dev] [blfs-book] r21576 - trunk/BOOK/networking/netlibs

[Xi Ruoyao via blfs-dev]

On 2019-05-11 08:27 -0500, William Harrington wrote:
> > On May 11, 2019, at 02:33, Xi Ruoyao via blfs-dev <
> > blfs-dev@lists.linuxfromscratch.org> wrote:
> > 
> > On 2019-05-11 08:04 +0100, Ken Moffat via blfs-dev wrote:
> > > On Sat, May 11, 2019 at 11:56:29AM +0800, Xi Ruoyao via blfs-dev wrote:
> > > > On 2019-05-10 20:28 +0100, Ken Moffat via blfs-dev wrote:
> > > > > On Fri, May 10, 2019 at 06:35:15PM -, xry111--- via blfs-book
> > > > > wrote:
> > > > > > Author: xry111
> > > > > > Date: Fri May 10 11:35:15 2019
> > > > > > New Revision: 21576
> > > > > > 
> > > > > > Log:
> > > > > > Use autotools to build c-ares, instead of cmake
> > > > > > 
> > > > > 
> > > > > Why, please ?
> > > > 
> > > > Cmake is not listed as c-ares dependency so we should either add it, or
> > > > use
> > > > autotools.  I decided to remove the extra dependency.
> > > 
> > > Where there are alternatives, I would prefer to discuss changing the
> > > build method.  In this case, adding a link to cmake seems a lot easier
> > > than rewriting the instructions.
> > 
> > Then we'll get
> > 
> > c-ares depends on cmake (required)
> > cmake depends on curl (recommended)
> > curl depends on c-ares (optional)
> > 
> > I think we should always use autotools/make or meson/ninja if one of them
> > are
> > avaliable, rather than cmake. Autotools/make and meson/ninja are avaliable
> > on a
> > fresh LFS system. But to use cmake we have to install 4 packages: libuv,
> > curl,
> > libarchive, cmake.
> > 
> 
> Greetings,
> 
> Is it possible that someone will go directly to netlibs and filter back to a
> previous package? How about if they want a program that isn't in BLFS that
> needs cmake and the deps. I don't understand the idea that cmake isn't needed.
> Seems like it should be as a recommended or optional dep when going thru BLFS.
> Name a distro that doesn't have cmake.

Yes it is needed.  Nobody wants to remove it from the book.  But if a package
*can* be built with autotools or meson, why should we build it with cmake and
introduce a hard dependency?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[blfs-dev] Update mozjs-60 version (?)

[Xi Ruoyao via blfs-dev]

Hi folks,

Now BLFS is using mozjs-60 package from ftp.gnome.org.  But it's the "original"
mozjs-60.1.0 without any update.  Arch is now using latest mozjs-60.6.3, even
Ubuntu is using a newer mozjs-60.2.3.

I downloaded Firefox ESR 60.6.3 code and removed everything unrelated to JS
engine I could find.  Then I built and installed mozjs-60.6.3 into my system.  I
found my GNOME was broken but I could rebuild Gjs to fix it.

The extracted mozjs-60.6.3 tarball (it's just a Firefox tarball with many
directories removed) has been uploaded to:

http://www.linuxfromscratch.org/~xry111/mozjs-60.6.3.tar.xz

Now, is it worthy to update mozjs-60 version in BLFS book, following Firefox ESR
60?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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