Re: [blfs-dev] Failure starting X/lxdm with glib 2.68.0
On 4/12/21 5:18 AM, Tim Tassonis via blfs-dev wrote: On 4/12/21 11:53 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). So, the problem really seems to be glib 2.68.0, and thankfully 2.68.1 seems to have a fix for that: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2010 Overview of changes in GLib 2.68.1 == * Fix a crash in `GKeyFile` when parsing a file which contains translations using a `GKeyFile` instance which has loaded another file previously (#2361) So, I'm giving that a try in a minute. Can confirm that glib 2.68.1 fixes the problem. Already updated the glib page. Bye Tim Bumped the patch in git at eb174e76 - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] doxygen doc error
On 4/3/21 12:02 PM, Pierre Labastie via blfs-dev wrote: Trying to build doxygen docs by the book, I get: --- [ 81%] Generating language.doc Traceback (most recent call last): File "/sources/doxygen/doxygen-1.9.1/build/doc/translator.py", line 2018, in trMan.generateTranslatorReport() File "/sources/doxygen/doxygen-1.9.1/build/doc/translator.py", line 1688, in generateTranslatorReport dic = self.__checkForNotUsedTrMethods() File "/sources/doxygen/doxygen-1.9.1/build/doc/translator.py", line 1491, in __checkForNotUsedTrMethods self.__removeUsedInFiles(fname, trdic) File "/sources/doxygen/doxygen-1.9.1/build/doc/translator.py", line 1458, in __removeUsedInFiles cont = f.read() File "/usr/lib/python3.9/codecs.py", line 322, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) File "/usr/lib/python3.9/encodings/utf_8_sig.py", line 69, in _buffer_decode return codecs.utf_8_decode(input, errors, final) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb0 in position 45: invalid start byte make[3]: *** [doc/CMakeFiles/run_doxygen.dir/build.make:436: doc/language.doc] Error 1 make[3]: *** Deleting file 'doc/language.doc' make[2]: *** [CMakeFiles/Makefile2:703: doc/CMakeFiles/run_doxygen.dir/all] Error 2 make[1]: *** [CMakeFiles/Makefile2:657: doc/CMakeFiles/docs.dir/rule] Error 2 make: *** [Makefile:369: docs] Error 2 - I've found a patch in gentoo [1], but amazingly, there is nothing in arch. Actually, there is an "AppleDouble encoded Macintosh file" (according to "file") named src/._xmlgen.cpp, which is a binary. Removing it does not prevent building doxygen, and allows building the doc... Actually, according to [2], this file has been added in version 1.9.1, so it looks like an oversight! I propose to add a command to remove that file in the book. Gentoo patch is too complicated... Pierre [1] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b89f80cd9c20607ada13ec091a32cef4b44d29f3 [2] https://fossies.org/diffs/doxygen/1.9.0_vs_1.9.1/index.html Adding a command to the book to remove that file sounds good to me. It seems like that file is only compiled on Apple Mac systems. - Doug -- 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
On 4/1/21 3:52 AM, 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. However, there might be a lfs/blfs policy regarding preference for cmake that I am not aware of? Bye Tim Hi Tim, In this case, we definitely want to stay with autotools. cURL is a direct dependency of CMake, so we'd introduce problems (a circular dependency) there with trying to get CMake building before we build cURL. :-) - Doug -- 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 patch in sysutils
On 3/25/21 12:15 PM, John Burrell via blfs-dev wrote: The patch in the commands needs updating to fixes-2.patch instead of fixes-1 jb. Hi John, Thank you for reporting this! I've fixed it at r24401, and it should be present in the next render. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] efibootmgr url ?
On 3/24/21 12:46 PM, Ken Moffat via blfs-dev wrote: The link in the book gives a 404. If I go to https://github.com/rhboot/efibootmgr/releases I can use firefox to download 17 as efibootmgr-17.tar.gz from https://github.com/rhboot/efibootmgr/archive/refs/tags/17.tar.gz, but if I use wget for that the tarball is downloaded as 17.tar.gz. At various times we've had notes in the book for using wget at github, but they all seem to have been commented out after the URLs were changed. At the moment I can't find any URL which works to give me a tarball named efibootmgr-17.tar.gz when used with wget. Oddly, a couple of attempts to try different possible URLS gave me pages with only 'Not found' on them (i.e. not the github 404 page). ĸen Xi and Bruce have been discussing this in IRC - try https://salsa.debian.org/efi-team/efibootmgr/-/archive/17/efibootmgr-17.tar.gz - Doug -- 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 10.0 systemd-units Broken Link
On 3/17/21 4:05 PM, Bruce Dubbs via blfs-dev wrote: On 3/17/21 2:40 PM, David Gherghita via blfs-dev wrote: Hello, In the "BLFS Systemd Units" section of the BLFS 10.0-systemd book, the link to download the archive [1] is broken. Navigating to the directory [2], I noticed that the version of the archive available is 20180105, which seems to be pretty old, even older than the one present in version 9.1-systemd of the book. Was there an error uploading the 20200828 version of the systemd-units or is 20180105 really the version we should use? Thank you, David Gherghita [1] http://www.linuxfromscratch.org/blfs/downloads/10.0-systemd/blfs-systemd-units-20200828.tar.xz [2] http://www.linuxfromscratch.org/blfs/downloads/10.0-systemd/ For now I suggest using http://www.linuxfromscratch.org/blfs/downloads/systemd/blfs-systemd-units-20210122.tar.xz These are the most up-to-date. -- Bruce I just uploaded the file to the proper location as well, so you should be good to use 20200828 again as well if you want. The latest version of the systemd units only includes one change, and that's a new unit for git-daemon - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Commenting on assigned tickets (#14725: openssh-8.5p1)
On 3/3/21 5:54 AM, Tim Tassonis via blfs-dev wrote: Hi all I just saw that openssh has a new version and as I wondered about the changes, I visited their page. While the corresponding ticket http://wiki.linuxfromscratch.org/blfs/ticket/14725 was already assigned but had no changes comment, I added one, I hope that's ok. Wasn't meant to interfere in any way, just thought maybe other people would like to see the changes, too. I always like to look at them, to prioritize my updates. Bye Tim As Bruce mentioned, adding comments on any ticket is appropriate :) For openssh though, I suggest checking oss-security's archives as well anytime a new version come out. That often provides some more details. In this case (https://seclists.org/oss-sec/2021/q1/190): Security * ssh-agent(1): fixed a double-free memory corruption that was introduced in OpenSSH 8.2 . We treat all such memory faults as potentially exploitable. This bug could be reached by an attacker with access to the agent socket. On modern operating systems where the OS can provide information about the user identity connected to a socket, OpenSSH ssh-agent and sshd limit agent socket access only to the originating user and root. Additional mitigation may be afforded by the system's malloc(3)/free(3) implementation, if it detects double-free conditions. The most likely scenario for exploitation is a user forwarding an agent either to an account shared with a malicious user or to a host with an attacker holding root access. * Portable sshd(8): Prevent excessively long username going to PAM. This is a mitigation for a buffer overflow in Solaris' PAM username handling (CVE-2020-14871), and is only enabled for Sun-derived PAM implementations. This is not a problem in sshd itself, it only prevents sshd from being used as a vector to attack Solaris' PAM. It does not prevent the bug in PAM from being exploited via some other PAM application. GHPR#212 We do carry ssh-agent, so I suppose the top one would affect us. The bottom one is only applicable to Oracle Solaris. That email also lists potentially-incompatible changes, as well as a reminder about ssh-rsa being deprecated because it uses SHA1 and it's possible to perform attacks against the SHA-1 algorithm for less than USD$50k. I'll drop the contents of that email in the ticket when I get there :) Thank you, - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] p7zip has been forked (and is actively maintained)
On 2/5/21 10:17 AM, Ryan Marsaw via blfs-dev wrote: On Fri, 5 Feb 2021, Douglas R. Reno via blfs-dev wrote: On 1/30/21 1:44 PM, Ryan Marsaw via blfs-dev wrote: Hello all. When I noticed that p7zip hadn't had a new release in nearly 5 years I checked to see if perhaps this package was picked up by someone else. Sure enough, I came across a fork of p7zip here: https://github.com/jinfeihan57/p7zip/ The page has this under the "About" section: "A new p7zip fork with additional codecs and improvements (forked from https://sourceforge.net/projects/p7zip/)." The fixes introduced by the BLFS p7zip patch are incorporated in this fork, and as far as I can see the build process is exactly same as the one for the existing p7zip. Cheers, Ryan Hi Ryan, Just following up here - we moved to p7zip-17.03, which is the latest version of the new fork, at r24176. It should be in the next render. Thank you again for bringing this up! - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Just a quick addendum: p7zip 17.03 compresses its man pages before installing. I noticed this when testing the install and inspecting the files afterwards. The behaviour can be avoided by suppressing the compression of the man pages: sed '/^gzip/d' -i install.sh Cheers, Ryan Hi Ryan, I've implemented that sed at r24179. Thank you for bringing it up! - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] p7zip has been forked (and is actively maintained)
On 1/30/21 1:44 PM, Ryan Marsaw via blfs-dev wrote: Hello all. When I noticed that p7zip hadn't had a new release in nearly 5 years I checked to see if perhaps this package was picked up by someone else. Sure enough, I came across a fork of p7zip here: https://github.com/jinfeihan57/p7zip/ The page has this under the "About" section: "A new p7zip fork with additional codecs and improvements (forked from https://sourceforge.net/projects/p7zip/)." The fixes introduced by the BLFS p7zip patch are incorporated in this fork, and as far as I can see the build process is exactly same as the one for the existing p7zip. Cheers, Ryan Hi Ryan, Just following up here - we moved to p7zip-17.03, which is the latest version of the new fork, at r24176. It should be in the next render. Thank you again for bringing this up! - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Critical security updates to glib2 and JasPer
Hello everyone, Today, a critical 0day security vulnerability was discovered in glib2. This vulnerability has to do with the g_bytes_new and g_memdup functions, which are very commonly used in applications that use GLib. The vulnerability is an integer-overflow in the g_bytes_new function. More information on this vulnerability can be found here: https://gitlab.gnome.org/GNOME/glib/-/issues/2319 https://mail.gnome.org/archives/desktop-devel-list/2021-February/msg0.html As the maintainer mentions, this security vulnerability should be taken as a "matter of urgency, since this is a zero-day". In addition, every application that uses these functions from GLib is vulnerable. New versions of various packages will probably be released over the next few days to fix the issue from their side, but you should update to GLib-2.66.6 as soon as possible in order to be protected from this security vulnerability. It should be safe to upgrade from 2.62.x and later to 2.66.6. The fixed version, glib2-2.66.6, has been committed to SVN, and should be in the book at the next render. In addition to the update to glib2, an update to JasPer was performed today that fixed 25 security vulnerabilities. It's suggested that you update your system to JasPer-2.0.24 as soon as possible too, if you have JasPer installed. The new version of JasPer will be in the next render as well. Thank you, - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Security Advisories, v2 [ long :-( ]:wq
On 1/28/21 9:37 PM, Ken Moffat via blfs-dev wrote: A little while ago I proposed separating out our Security Advisories. What I would now like to do is create an *extra* page in the www/ repo listing (and in a couple of mutt cases creating[1]) advisories from 1st September when BLFS-10.0 was released. For changes to the books I would create a branch, but for security advisories, just as for errata, the page needs to be visible on the main LFS website otherwise the links will not work (at least in my case, where I have separate repos for LFS, BLFS and www2). So, I'd like to add an extra page with a bit more detail and crucially showing that Seamonkeyi as an example has had 5 advisories (one was a change to the patch we were using). If this flies, I suggest that eventually we reserve the Errata for things which are not vulnerabilities, and at the end of the Errata page add a link to the new BLFS Security Advisories page. I'm thinking the format will be something like the following (not necessarily what I originally suggested). (title: BLFS Security Advisories from September 2020 onwards) (heading: BLFS-10.0 was released on 2020/09/01 - intersperse a new heading for each release) For each advisory: something like (not sure how this will look, detail may change a bit, maybe initially with variations in the layout for people to form opinions on what looks best) SA 20YYMMNN Vulnerabilities in FuBar before version 1.2.3. (some details, according to what is available for individual advisories.) (possible links to CVEs or other notifications - sometimes there might be several CVEs) To fix this, (either: mention some workaround, or) update to FuBar-1.2.3 or later using the instructions in the development books: [link for sysv labelled as FuBar (sysv)] [link for systemd labelled as FuBar (systemd)] NB link labels will NOT include versions, and if a package is only in one book, the link for the other book would be marked as 'N/A'. So, for e.g. firefox there would be several advisories, some also for JS78, but all linking to the current development version (and perhaps on release those should link to the version in the released book). In some cases the instructions may differ, e.g. for gstreamer in October we told people to use the 1.16.3 series with the instructions from the 10.0 book because 1.18 would break things. Although the page will be on the lfs website, during this prototyping it will not be linked from other pages - I'll post here when I have something for people to review. There are "rather a lot" of items since 10.0 was released. Our main security guy is Doug, so I'd like to get his opinion before I start, together with any views of "No, because ...". I'm guessing the page should be at http://www.linuxfromscratch.org/blfs/advisories/index.html to fit in with blfs/errata/stable/index.html and stable-systemd/index.html. If this flies, perhaps also a direct link from http://www.linuxfromscratch.org/blfs/read.html e.g. "Security Advisories". ĸen 1. The patch for 2.0.4 had a CVE although the maintainer and reporter were ok without giving it one, and 2.0.5 has another similar fix without a CVE, so both probably deserve advisories. Hi Ken, This sounds like a long overdue and great change to me! As Bruce said, it's probably best to roll this in with the other changes on the new server. BTW, Arch has 44 security advisories so far for January 2021. It's been a busy month. For consistency purposes, could you roll your thoughts into a wiki entry or something like that so it's easier to find? :-) - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libnfsidmap no longer needed for nfs-utils
On 1/25/21 5:09 PM, Brendan L via blfs-dev wrote: Since I think, version 2.2.1 of nfs-utils, libnfsidmap has been merged into nfs-utils codebase. I believe libnfsidmap can be removed from the book. Hi Brendan, Thank you for the report! I've verified that the source tree is present in nfs-utils (and is built if --disable-nfsv4 is removed), and have archived the package as a result. libnfsidmap archived at r24140 - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Suggestion to mention webp-pixbuf-loader either on libwebp or gdk-pixbuf page
On 1/23/21 11:06 AM, Tim Tassonis via blfs-dev wrote: Hi all Hi Tim, When setting up my new xfce4 based system, I stumbled across webp-pixbuf-loader. It easily adds support for webp images in gdk-pixbuf-loader, which then automatically gets picked up by thunar, tumbler and ristretto and will allow you to view and preview those images. I suppose it would be the same for gnome folks. I think GPicView, Nautilus, EOG, and maybe PCManFM could use this for thumbnails :) The repository is at https://github.com/aruiz/webp-pixbuf-loader Current version is. https://github.com/aruiz/webp-pixbuf-loader/archive/0.0.2.tar.gz which should be downloaded to webp-pixbuf-loader-0.0.2.tar.gz Build and install is a simple matter of: mkdir build cd build || exit meson --prefix=/opt/X11 -Dbuildtype=release .. ninja || exit cd .. cd build || exit DESTDIR=$DESTDIR ninja install || exit cd .. /opt/X11/bin/gdk-pixbuf-query-loaders --update-cache Of course, DESTDIR is my own choice, as is the /opt/X11 prefix. Maybe this could be added as a suggestion to the libwebp or the gdk-pixbuf page? It looks simple enough, I think we should add it to the book, probably placing it into Graphics Libraries. Being able to read webp images is very useful now. I'd say mentioning it on the gdk-pixbuf page would be useful. Bruce and others, what do you think? - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Postgresql init script
On 1/21/21 10:43 PM, DJ Lucas via blfs-dev wrote: FYI, we are currently using a mkdir for the pidfile in postgresql script. We have a mechanism in place for this outside of the init script (createfiles): echo "/run/postgresql dir 755 postgres postgres" >> /etc/sysconfig/createfiles Any objections if I make the change? Of note, for later, this should be a .d directory. No objections, consistency is always nice - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Gimp-2.10.22 fails with gegl-0.4.28
On 1/22/21 5:50 AM, Tim Tassonis via blfs-dev wrote: Hi all After building and running gegl and gimp from the book, gimp failed to Gimp to launch, displaying a gegl:introspect error. This is also reported here: https://bugs.mageia.org/show_bug.cgi?id=27994 Maybe we should revert to gegl-0.46 (that's what I did), or can anyone run gimp with these versions? Hi Tim, I promoted Graphviz to recommended in the page for gegl a while back to solve this. Graphviz is required for the gegl plugin "gegl:introspect". I had to do a bit of research a couple weeks ago to figure that one out, because I couldn't get GIMP to launch either :-) Can you try tossing graphviz on your system and then upgrading gegl? - Doug -- 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 do we patch polkit for elogind ?
On 1/5/21 4:20 PM, Ken Moffat via blfs-dev wrote: On Tue, Jan 05, 2021 at 07:50:14PM +, Ken Moffat via blfs-dev wrote: On Tue, Jan 05, 2021 at 11:33:30AM -0600, Bruce Dubbs via blfs-dev wrote: On 1/5/21 9:34 AM, Ken Moffat via blfs-dev wrote: On Tue, Jan 05, 2021 at 02:33:35PM +0100, Pierre Labastie via blfs-dev wrote: On Wed, 2020-12-30 at 18:21 +, Ken Moffat via blfs-dev wrote: Just checking all packages, the following are present: Replying with the state of play before Pierre had identified that using -i is what can cause gtkdocize to be required (i.e. for packages which mention gtk-doc if I understood correctly) : networking/netprogs/cifsutils.xml: autoreconf -fiv I guess my mail to Doug got treated as spam, as will this one. There seems to be a perfectly usable configure script in all versions of cifs-utils that have been in the book since this autoreconf was added - I have not tried to run autoreconf on this. Unfortunately I can't find it in my spam folder over in GMail either :-( Yeah the autoreconf command can go from cifs-utils. There was a broken release of (6.9?), which later had a stealth release that restored the proper behavior. 6.9 (Broken) didn't ship with a pregenerated configure file. I'll get it at my next commit, unless you get to it first :-) - Doug -- 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.7.4 meson build requires git
On 1/1/21 6:55 PM, Wayne Blaszczyk via blfs-dev wrote: Hi All, The current meson build instructions requires git. I get the following: Program g-ir-scanner found: YES (/usr/bin/g-ir-scanner) Found pkg-config: /usr/bin/pkg-config (0.29.2) Build-time dependency gobject-introspection-1.0 found: YES 1.66.1 Program g_ir_scanner found: YES (/usr/bin/g-ir-scanner) Program g_ir_compiler found: YES (/usr/bin/g-ir-compiler) ../perf/meson.build:1:0: ERROR: Git program not found. A full log can be found at /opt/wbBuild/var/sources/harfbuzz-2.7.4/build/meson-logs/meson-log.txt The -Dbenchmark=disabled parameter removes this requirement. Regards, Wayne. Hi Wayne, I fixed this at r24055 by adding a recommended dependency on Git and then adding a command explanation for -Dbenchmark=disabled, so that folks who don't want Git installed can still build harfbuzz without it. Thank you for the report! - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] FriBidi-1.0.9 as a Required dependency of GTK+-3.24.22 seems superfluous
On 1/2/21 1:15 AM, Kevin Buckley via blfs-dev wrote: Appreciate that the various desktop environment dependency chains are a rat's nest but I just noticed that, in BLFS 10.0, FriBidi-1.0.9 is listed as a Required dependency for GTK+-3.24.22, as is Pango-1.46.0, however, FriBidi-1.0.9 is already listed as a Required dependency for Pango-1.46.0. FWIW, GTK+-2.24.32 does not list FriBidi-1.0.9 as a Required dependency, although it does list Pango-1.46.0. Kevin Hi Kevin, I've removed the required dependency on Fribidi from GTK3 at r24055. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] RFC: change the layout of Qt pages
On 12/12/20 3:07 AM, Pierre Labastie via blfs-dev wrote: Presently, in the book, we have two pages for the Qt library: one for full Qt, except we do not build qtwebengine, and another one for qtwebengine. This has a couple of drawbacks: - If a package needs only Qt core libraries, we require to build the whole Qt library. Building qtbase is just a couple of SBU, compared to the 22 SBU of the full Qt. Even KDE frameworks need just a handful of additional modules (which add not more than one SBU each, and several of them are much faster), and not the full qt. Also, building a full Qt for LXQt (which is supposed to be lightweight) is a big overkill... - when downloading the full Qt, qtwebengine is inside it. Then, when building qtwebengine, it is downloaded again. Since qtwebengine size is 247 MB, this is not insignificant... The proposition is the following: Two pages again, with: - first page for qtbase (~50 MB download, a couple of SBUs at -j4): this is where configure is run. Also the page would have /opt and startup file settings (as on the present Qt page), and .desktop file installation. - a second page with a layout similar to Xorg libs, KDE frameworks, and plasma, except the list of files would be divided into (tentative) "needed for LXQt", "needed in addition for KDE", "qtwebengine", and "optional not needed for the book", so that users would have information to build (and download) only what they need. The instructions for each module would be: qmake -- ; make; make install. But in most cases -- would not be needed. Maintenance would not be much harder (maybe a couple more measurements, but upstream provides a md5sum file). I do think this is a great idea, and I'm looking forward to seeing and using it when it's out of the oven! Pierre -- 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 latest version 247.1
On 12/4/20 11:16 AM, Wayne Blaszczyk via blfs-dev wrote:
On Sat, 2020-12-05 at 04:04 +1100, Wayne Blaszczyk wrote:
On Fri, 2020-12-04 at 09:17 -0600, Douglas R. Reno via blfs-dev wrote:
On 12/4/20 3:03 AM, Wayne Blaszczyk via blfs-dev wrote:
Hi Guys,
Spent the last hour racking my brain on why Gentoo, Arch, and Fedora had
version 247.1
Turns out that they are pulling from https://github.com/systemd/systemd-stable
I didn't know this repository existed.
Regards,
Wayne.
Hi Wayne,
They started doing that around 243 I think, but started tagging point
versions around 245.
In LFS, I have a patch that takes care of the changes in 247.1 and some
other fixes (for systemd-networkd). Generally I just backport fixes that
are applicable to {,B}LFS systems rather than trying to update it every
time.
Unfortunately, BLFS will be out of date when it comes to systemd for at
least the next render. I'm working on that as quickly as I can, but I
decided to do a full rebuild to see if any issues with udev rules come up.
- Doug
Thanks Doug,
My LFS build has just completed and on the reboot, the following failure occurs:
Dec 05 03:51:14 lfs02 systemd[212]: systemd-oomd.service: Failed to determine
user credentials: No such process
Dec 05 03:51:14 lfs02 systemd[212]: systemd-oomd.service: Failed at step USER
spawning /lib/systemd/systemd-oomd: No such process
Dec 05 03:51:14 lfs02 systemd[1]: systemd-oomd.service: Main process exited,
code=exited, status=217/USER
Dec 05 03:51:14 lfs02 systemd[1]: systemd-oomd.service: Failed with result
'exit-code'.
Dec 05 03:51:14 lfs02 systemd[1]: Failed to start Userspace Out-Of-Memory (OOM)
Killer.
Not sure if you have come across this. I'll investigate in the morning.
Wayne.
Found that a user systemd-oom is require. However there are still issues:
Dec 05 04:13:20 lfs02 systemd-oomd[197]: Pressure Stall Information (PSI) is
not supported
Dec 05 04:13:20 lfs02 systemd[1]: systemd-oomd.service: Main process exited,
code=exited, status=1/FAILURE
Dec 05 04:13:20 lfs02 systemd[1]: systemd-oomd.service: Failed with result
'exit-code'.
Dec 05 04:13:20 lfs02 systemd[1]: Failed to start Userspace Out-Of-Memory (OOM)
Killer.
Regards,
Wayne.
Hi Wayne,
Did you build with -Dmode=release? systemd-oomd is classified as
experimental, so we use -Dmode=release to prevent it from being built
and installed. We've got -Dmode=release in LFS. In BLFS, we're also
going to need to add -Dpamconfdir=/etc/pam.d to force the PAM files to
end up in /etc/pam.d rather than /usr/lib/pam.d.
- Doug
--
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 latest version 247.1
On 12/4/20 3:03 AM, Wayne Blaszczyk via blfs-dev wrote:
Hi Guys,
Spent the last hour racking my brain on why Gentoo, Arch, and Fedora had
version 247.1
Turns out that they are pulling from https://github.com/systemd/systemd-stable
I didn't know this repository existed.
Regards,
Wayne.
Hi Wayne,
They started doing that around 243 I think, but started tagging point
versions around 245.
In LFS, I have a patch that takes care of the changes in 247.1 and some
other fixes (for systemd-networkd). Generally I just backport fixes that
are applicable to {,B}LFS systems rather than trying to update it every
time.
Unfortunately, BLFS will be out of date when it comes to systemd for at
least the next render. I'm working on that as quickly as I can, but I
decided to do a full rebuild to see if any issues with udev rules come up.
- Doug
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Linux-PAM option --enable-db=no
On 12/1/20 7:48 AM, Tim Tassonis via blfs-dev wrote: Hi all When re-building pam version 1.5.1, I noticed that it links against bdb, because I had installed bdb since my last pam build. As I'm not really fond of including bdb in all installations using pam, I found out that by specifying --enable-db=no at configure time, pam will be build without it. It might be a good idea to add a remark about that option on the pam page. What do others think about it? Bye Tim Hi Tim, I think this is a good idea. A command explanation seems like the right fit -- 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.0.0 fails to compile
On 11/25/20 6:39 AM, Ryan Marsaw via blfs-dev wrote: On Wed, 25 Nov 2020, John Burrell via blfs-dev wrote: I'm using the development version of the book, 2020-11-24 I get these error messages: [2299/4643] Building C object projects/compiler-rt/...les/clang_rt.tsan-x86_64.dir/rtl/tsan_rtl_amd64.S.o FAILED: projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan-x86_64.dir/rtl/tsan_rtl_amd64.S.o ninja: build stopped: subcommand failed. I tried adding a symlink for python to python-3.9 but that makes no difference. jb. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page I believe your build errors are due to CMake. If you're using cmake 3.19.0 then the build will fail. Version 3.19.1 of cmake was released yesterday which fixes the issues. Cheers, --Ryan CMake 3.19.1 should be in the next render of the book. I've begun working on the update now - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] icu68 breakage
On 10/30/20 6:15 PM, Ken Moffat via blfs-dev wrote:
I see we've already had one set of fixes for changes in icu68, I
hope it is not going to trash a lot of things.
I've been building libxml2 --with-icu for some time, that breaks:
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I./include -I./include -pedantic -Wall -Wextra -Wshadow -Wpointer-arith
-Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes
-Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -Wno-long-long
-Wno-format-extra-args -D_REENTRANT -O3 -march=native
-fstack-clash-protection -D_FORTIFY_SOURCE=2 -fstack-protector-strong -MT
encoding.lo -MD -MP -MF .deps/encoding.Tpo -c -o encoding.lo encoding.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./include -I./include -pedantic
-Wall -Wextra -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings
-Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs
-Winline -Wredundant-decls -Wno-long-long -Wno-format-extra-args -D_REENTRANT
-O3 -march=native -fstack-clash-protection -D_FORTIFY_SOURCE=2
-fstack-protector-strong -MT encoding.lo -MD -MP -MF .deps/encoding.Tpo -c
encoding.c -fPIC -DPIC -o .libs/encoding.o
encoding.c: In function 'xmlEncOutputChunk':
encoding.c:1961:31: error: 'TRUE' undeclared (first use in this function)
1961 | TRUE);
| ^~~~
encoding.c:1961:31: note: each undeclared identifier is reported only once for
each function it appears in
make[2]: *** [Makefile:1287: encoding.lo] Error 1
This comes from encoding.c
#ifdef LIBXML_ICU_ENABLED
else if (handler->uconv_out != NULL) {
ret = xmlUconvWrapper(handler->uconv_out, 0, out, outlen, in, inlen,
TRUE);
}
#endif /* LIBXML_ICU_ENABLED */
For the moment I can't see anything online (it looks like we are on
the bleeding edge using icu68) so I'll just work around it by
omitting --with-icu for the moment so I can get on with looking at
the consequences of python2 using altinstall (more on that when I've
got more things built).
ĸen
Hi Ken,
I don't have the ability to test this at the moment (running Samba
tests), but try substituting TRUE with true. In ICU-68.1, the FALSE and
TRUE macros that were exported by ICU were removed. Check out this link
for more details:
http://site.icu-project.org/download/68
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] icu68 breakage
On 10/30/20 6:15 PM, Ken Moffat via blfs-dev wrote:
I see we've already had one set of fixes for changes in icu68, I
hope it is not going to trash a lot of things.
I've been building libxml2 --with-icu for some time, that breaks:
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I./include -I./include -pedantic -Wall -Wextra -Wshadow -Wpointer-arith
-Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes
-Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -Wno-long-long
-Wno-format-extra-args -D_REENTRANT -O3 -march=native
-fstack-clash-protection -D_FORTIFY_SOURCE=2 -fstack-protector-strong -MT
encoding.lo -MD -MP -MF .deps/encoding.Tpo -c -o encoding.lo encoding.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./include -I./include -pedantic
-Wall -Wextra -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings
-Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs
-Winline -Wredundant-decls -Wno-long-long -Wno-format-extra-args -D_REENTRANT
-O3 -march=native -fstack-clash-protection -D_FORTIFY_SOURCE=2
-fstack-protector-strong -MT encoding.lo -MD -MP -MF .deps/encoding.Tpo -c
encoding.c -fPIC -DPIC -o .libs/encoding.o
encoding.c: In function 'xmlEncOutputChunk':
encoding.c:1961:31: error: 'TRUE' undeclared (first use in this function)
1961 | TRUE);
| ^~~~
encoding.c:1961:31: note: each undeclared identifier is reported only once for
each function it appears in
make[2]: *** [Makefile:1287: encoding.lo] Error 1
This comes from encoding.c
#ifdef LIBXML_ICU_ENABLED
else if (handler->uconv_out != NULL) {
ret = xmlUconvWrapper(handler->uconv_out, 0, out, outlen, in, inlen,
TRUE);
}
#endif /* LIBXML_ICU_ENABLED */
For the moment I can't see anything online (it looks like we are on
the bleeding edge using icu68) so I'll just work around it by
omitting --with-icu for the moment so I can get on with looking at
the consequences of python2 using altinstall (more on that when I've
got more things built).
ĸen
Hi Ken,
Try changing 'TRUE' to 'true' in encoding.c (line 1961). I don't have
the ability to test that at the moment, but I think that might work.
Check out this link for more details on what has changed in ICU-68, the
most important thing being the removal of the FALSE and TRUE macros:
http://site.icu-project.org/download/68
- Doug
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Libsoup-2.72.0 won't compile with brotli installed
On 10/29/20 10:33 AM, John Burrell via blfs-dev wrote: Brotli has a -R parameter in each of its pkgconfig files and this causes libsoup to fail: [92/184] Linking target libsoup/libsoup-2.4.so.1.11.0 FAILED: libsoup/libsoup-2.4.so.1.11.0 , , , bject-2.0.so /usr/lib/libgio-2.0.so /usr/lib/libxml2.so /usr/lib/libsqlite3.so /usr/lib/libpsl.so -R/usr/ lib /usr/lib/libbrotlidec.so /usr/lib/libz.so -Wl,--end-group cc: error: unrecognized command-line option ‘-R’ Adding-Dbrotli=disabled \ to the configure allows it to compile. The issue was reported here: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11948 but the recommended changes obviously haven't occurred. jb. Hi John, In the Brotli page in SVN, there is currently the following sed which should fix this issue: sed -i 's@-R..libdir.@@' scripts/*.pc.in After reinstalling Brotli, you should be able to build libsoup with brotli support properly. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] If P2 modules are built for PyYaml and Markupsafe, then recommend P2
On 10/29/20 7:23 AM, Bruce Dubbs via blfs-dev wrote: On 10/29/20 5:22 AM, Pierre Labastie via blfs-dev wrote: As the subject says... But another possibility is to not propose P2 modules at all for those packages. I'm almost sure nothing uses P2 modules for those packages: Markupsafe is here only for Mako and Jinja2, and we build only P3 for those packages. PyYAML is optional for llvm and kf5, and I think those use P3 only now... Let's drop p2 from instructions where it is not needed by something in the book. I do not see a problem with having p2 as an optional dependency though. Agreed here Looking I now see p2 instructions for D-Bus Python, PyCairo-1.18.2, PyGObject-2.28.7, libxml2-2.9.10, lxml, MarkupSafe, PyYAML, and six. However as best I can tell in the python modules section only PyCairo-1.18.2, PyGObject-2.28.7, and libxml2-2.9.10 need p2. I think lxml, MarkupSafe, and PyYAML could probably have their Python2 modules removed. I'm not sure on 'six' though. Of course the biggest problem appears to be those packages that need pygtk which uses PyGObject-2.28.7 and PyCairo-1.18.2. On top of that, I think libxml2_python is used for GIMP IIRC. On that note, I do know that the NMAP developers are working on porting Zenmap to Pygobject3 and GTK3. That should remove another PyGTK dependency. I am not sure what's going on with Avahi though. If I'm not mistaken, bssh/bvnc, which allow you to search for VNC servers and SSH servers on a network, are still using PyGTK. I could be wrong there though. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] dbus needed for samba
On 10/29/20 3:52 AM, Pierre Labastie via blfs-dev wrote: When building samba with required and recommended and dependencies (but without dbus installed) on a SysV machine, I get (configure output): - [...] VFS_STATIC: vfs_default,vfs_not_implemented,vfs_posixacl VFS_SHARED: vfs_recycle,vfs_audit,vfs_extd_audit,vfs_full_audit,vfs_fake_perms,vfs_ default_quota,vfs_readonly,vfs_cap,vfs_expand_msdfs,vfs_shadow_copy,vfs _shadow_copy2,vfs_readahead,vfs_xattr_tdb,vfs_streams_xattr,vfs_streams _depot,vfs_acl_xattr,vfs_acl_tdb,vfs_preopen,vfs_catia,vfs_media_harmon y,vfs_unityed_media,vfs_fruit,vfs_shell_snap,vfs_commit,vfs_worm,vfs_cr ossrename,vfs_linux_xfs_sgid,vfs_time_audit,vfs_offline,vfs_virusfilter ,vfs_widelinks,vfs_snapper,vfs_fake_acls,vfs_nfs4acl_xattr,vfs_error_in ject,vfs_delay_inject,vfs_syncops,vfs_dirsort,vfs_fileid,vfs_aio_fork,v fs_aio_pthread,vfs_gpfs,vfs_btrfs,vfs_glusterfs_fuse PDB_STATIC: pdb_smbpasswd,pdb_tdbsam,pdb_ldapsam PDB_SHARED: AUTH_STATIC: auth_builtin,auth_sam,auth_winbind,auth_unix AUTH_SHARED: NSS_INFO_STATIC: nss_info_template NSS_INFO_SHARED: CHARSET_STATIC: CHARSET_SHARED: IDMAP_STATIC: idmap_tdb,idmap_passdb,idmap_nss,idmap_ldap IDMAP_SHARED: idmap_ad,idmap_rfc2307,idmap_autorid,idmap_rid,idmap_hash,idmap_tdb2,id map_script GPEXT_STATIC: GPEXT_SHARED: PERFCOUNT_STATIC: PERFCOUNT_SHARED: RPC_STATIC: rpc_mdssvc_module RPC_SHARED: Checking for dbus : not found vfs_snapper is enabled but prerequisite dbus-1 package not found. Use - -with-shared-modules=!vfs_snapper to disable vfs_snapper support. (complete log in /sources/samba/samba-4.13.0/bin/config.log) --- Note that "vfs_snapper" is in the long list after "VFS_SHARED:" This does not show up in systemd, and in my usual builds, I build dbus earlyn so it does not show up either. This time I have randomized the order of the requested packages (before running the blfs-tools dependency resolver), so it happens that samba is built before dbus. Owing to the fact that vfs_snapper may be disabled (see above), I'd add dbus to the recommended dependencies (only for SysV, of course). Is there a reason to either: - not do that - add it to required? Pierre Hi Pierre, A new security update for Samba came out early this morning. Normally we get 7 days of advance notice for a new Samba version that contains security fixes, but we didn't for this one. It looks like there are three CVEs fixed in it. Since they didn't give advance notice, I can only assume that this means that they're critical enough to warrant emergency releases. I'll add it to Required. I think it fits best there because vfs_snapper is used for Samba to take snapshots of filesystem metadata for folders that it shares files from. It does not show up on systemd because dbus is built in LFS (although it needs to be rebuilt in BLFS for dbus-launch support for X11). That explains why I generally miss it :-) - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] sysprof and libsoup
On 10/22/20 3:23 PM, Ken Moffat via blfs-dev wrote: I saw that sysprof was now recommended for libsoup, and I thought I'd seen a post about that, but I can't spot it in my mail or by searching on google ? Some related info: http://wiki.linuxfromscratch.org/blfs/ticket/14051 http://wiki.linuxfromscratch.org/blfs/changeset/23755 Anyway,for the current build I went along with the recommendation and added it, plus libdazzle. But building libsoup did not go smoothly: First, ld failed to find libsysprof-4.so. Invoking ldconfig solved that, but then ld failed to find libsysprof-capture-4 because it is a static lib which I automatically make unavailable - I *want* to know what uses static libs to indicate what needs to be rebuilt when upgrading. Obviously not the book's problem, but an annoyance - there are very few packages I now build where I need static libs (binutils, expect, libcap, libtool, qtwebengine, graphviz) and they were one of the reasons why I gave up on kf5. Part of the reason why libsysprof-capture-4 needs to be static is due to the fact that it's a hook which is used to capture information from a process. On a side note, I just found a typo in that page that I'll fix at my next commit :-) Unfortunateley, my later build attempts overwrote the original log, so I can't confirm that it was indeed libsysprof-4.so which was missing, and therefore I can't confirm that ldconfig needs to be run. It might not be a bad idea to add that in anyway to prevent any future problems. Now that my system is more or less complete I've taken a look at the meson filesi from libsoup and it seems to me that sysprof is expected to be optional and auto-detected. But perhaps I'm missing something ? Without sysprof installed, libsoup will download and install it's own version of sysprof as a submodule. We're trying to prevent meson from downloading external packages without our consent, so we added sysprof to the book (since it can also be used by GJS and Mutter) :-) ĸen -- 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?
On 10/22/20 1:43 AM, Pierre Labastie via blfs-dev wrote: On Thu, 2020-10-22 at 00:56 -0500, DJ Lucas via blfs-dev wrote: On October 21, 2020 10:48:39 PM CDT, Bruce Dubbs via blfs-dev < blfs-dev@lists.linuxfromscratch.org> 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. I think we have another problem besides gimp, which is lxde as it is in the book presently. Lxde with GTK+-2 wants pygtk, which is P2 only. I have changes in one of my sandboxes for moving LXDE to GTK+-3 (removing the need for P2), but there is one bug for which there is no patch available (in lxappearance-obconf, see https://sourceforge.net/p/lxde/bugs/768/). Upstream has done nothing about that bug, as with other bugs about GTK+-3, but for the other bugs, there are patches. So I have not put that into the book yet. If that bug is not considered a blocker, we could do the move. I do consider that one a blocker since you cannot see the preview for the window border before you apply it. That has to do specifically with LXDE + Openbox of course, not with LXAppearance in other desktop environments. Another possibility is to remove LXDE and move to LXQt. But it would require some changes to the book to add a "Qt5-base" page, with only the relevant parts of Qt5 needed, and same for KF5. It would be silly to build full Qt5 and kf5 for a "lightweight" package. I am thinking about that with a way to not add too much maintenance burden. I'd prefer this route solely based on the fact that LxQT is actively maintained. LXDE being unmaintained in it's current state leaves it susceptible to bit-rot, while also increasing the chance for security issues. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] glib2 and European Daylight Savings Time
Good evening, Earlier today it was discovered that there are complications with the combination of tzdata2020b and glib2-2.66.2 that result in invalid times after European Daylight Savings Time ends on October 25th, 2020. This update should make it into the next render of the book as I just submitted it. I'm writing this email to urge everyone who has glib2 installed (2.64.x or 2.66.x) to update to 2.66.2 if you have tzdata2020b or later installed, since it provides fixes for that problem as well as one that affects systems in the rest of the world (invalid timezone maps when using GNOME Control Center). From the upstream announcement this morning: News * Important and time-critical fix to DST transitions which will happen in Europe on 2020-10-25 on distributions which use the ‘slim’ tzdata format (which is now the default in tzdata/tzcode 2020b) (work by Claudi M., LRN) (#2224) * Further timezone handling changes to restore support for changing the timezone when `/etc/localtime/` changes (work by António Fernandes, Sebastian Keller) (#2204) A couple of other relevant changes from the changelog: - !1705 Backport !1683 “Fix the 6-days-until-the-end-of-the-month bug” to glib-2-66 - #2224 top bar time is incorrect, timezone map in control center is broken If you have tzdata2020b and live in a timezone in Europe where DST takes place, please update to glib2-2.66.2 to ensure that your DST transition occurs smoothly. Thank you, - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] mupdf
On 10/12/20 9:41 PM, Bruce Dubbs via blfs-dev wrote: I have been struggling today to get a satisfactory build of mupdf-1.18.0. I can get it to build, but it also builds its own copies of curl, freeglut, freetype, harfbuzz, lcms2, ligjpeg, openjpeg, and zlib and links them into the executables. There is supposedly a way to use system libraries for the above, but the procedure for using it in this version of the package breaks the build. The build procedure for this package is custom. There is a manually edited Makefile, but no configure. The details of a build are not documented and difficult to discern when reading the Makefile. In BLFS we already have evince and okular that provide the same functionality as mupdf. Is there any reason to not just archive mupdf. http://wiki.linuxfromscratch.org/blfs/ticket/14110 -- Bruce The primary reason not to archive MuPDF is that IIRC cups-filters needs it to function properly (it uses mutool) -- 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
On 10/12/20 3:15 PM, 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 That looks like a solid plan to me. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] gobject-introspection should be recommended for harfbuzz
On 10/7/20 2:38 AM, Pierre Labastie via blfs-dev wrote: Usually, the first thing I do after building a new lfs VM, and the necessary tools to run jhalfs, is to build elogind first. In that case, jhalfs builds gobject-introspection early. This time, I've decided to ask jhalfs to directly install lxde-common, using only required and recommended dependencies: it generated a build order where harfbuzz comes before gobject-introspection. That's not wrong since g-ir is optional for harfbuzz. But then, when building pango, it fails because it cannot find harfbuzz.gir. Since pango is pretty sure to be needed by users building harfbuzz, I think g-ir should be recommended instead of optional for harfbuzz (with a statement that it can be omitted if pango is not to be built). Is there a reason for not doing that? Pierre Honestly, it's probably an oversight. I do agree that we should fix it by putting gobject-introspection in as recommended for harfbuzz. However, does jhalfs interpret runtime dependencies? I'm asking because gobject-introspection, shared-mime-info, and desktop-file-utils are listed as Additional Runtime Dependencies in the glib page itself. - Doug -- 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
On 10/4/20 11:28 PM, Bruce Dubbs via blfs-dev wrote: On 10/4/20 10:26 PM, Xi Ruoyao via blfs-dev wrote: 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. OK, I agree that the page needs to be updated. I've asked Doug to review and update since he is our gnome goto guy. -- Bruce Hi folks, I made the modifications requested at r23785 These modifications included removing --without-nautilus-extension and --disable-search-provider from the configure line for SysV, changing -without-nautilus-extension and --disable-search-provider descriptions to Option from Parameter (and making them available on systemd), and also adding in gnome-shell as a recommended dependency for the search provider. For consistency purposes, I also changed "Required Runtime Dependencies" in the previous chapter to say "Desktop", matching the text in the systemd book. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] sysv: postgresql boot script does not report an error if server cannot be started
On 10/1/20 4:01 AM, Pierre Labastie via blfs-dev wrote: The postgresql boot script uses: su - postgres -c '/usr/bin/pg_ctl start -W -D /srv/pgsql/data \ -l /srv/pgsql/data/logfile -o "-i" ' to start the server. The problem is that the -W option prevents the command to exit with an error, even if the server is not started. From the man page for pg_ctl: -W --no-wait Do not wait for the operation to complete. This is the opposite of the option -w. If waiting is disabled, the requested action is triggered, but there is no feedback about its success. In that case, the server log file or an external monitoring system would have to be used to check the progress and success of the operation. --- When updating to major version 13, the database has to be recreated (see release notes), but I failed to do that, so the server could not start... And the only failure was when shutting down the machine, because the .pid file did not exist. So I think the -W switch should be removed. Also, pg_ctl outputs "server starting ...\n", so the green "success" is not aligned with the "starting ..." line (not a big deal, but maybe the "-s" (silent) switch could be used...). Will wait for your thoughts for a day or so, then commit those changes. Pierre I do agree that something needs to be changed here. As you mentioned above, there was no indication that the server failed to start, only that the pid file was missing when you tried to stop the server. -- 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
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 suspect we have carried that for a long time, but I think it is now out of date. I am in the middle of playing with blender (a maze of nasty cmake packages, a couple of which can use jemalloc). When I first tried blender a few months ago, I avoided jemalloc (trying to get a build of as little as possible, for 3D rendering). At that time I only had 16GB DRAM, less the amount used for video, and even for 'barbershop' with only a couple of terms I was into swap so I gave up trying to learn how to use blender. Now I have 32GB on one machine, so I retried. One of the questions was whether I should use jemalloc: the answer was yes, on this machine the memory usage for barbeshop goes down dramatically. As part of that investigation I discovered that firefox DOES use its own local copy of jemalloc when configuring js: 0:22.50 js/src> running /scratch/working/firefox-78.3.0/configure.py --enable-project=js --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu MOZILLA_OFFICIAL= MOZBUILD_STATE_PATH=/scratch/working/firefox-78.3.0/mozbuild --disable-tests --disable-debug --without-debug-label --disable-rust-debug MOZ_PGO= --enable-release --disable-optimize --without-ccache CCACHE_PREFIX= RUSTC_WRAPPER= --without-toolchain-prefix --disable-debug-symbols --disable-address-sanitizer --disable-memory-sanitizer --disable-thread-sanitizer --disable-undefined-sanitizer --disable-signed-overflow-sanitizer --disable-unsigned-overflow-sanitizer --enable-frame-pointers --disable-coverage RUSTC_OPT_LEVEL=2 --enable-cargo-incremental --disable-linker AS= --disable-clang-plugin --disable-clang-plugin-alpha --disable-mozsearch-plugin --disable-stdcxx-compat --disable-fuzzing --disable-cpp-rtti --enable-jemalloc --disable-replace-malloc --without-linux-headers --disable-warnings-as-errors --disable-profile-generate --disable-profile-use --without-pgo-profile-path --disable-lto MOZ_LD64_KNOWN_GOOD= --enable-new-pass-manager --disable-valgrind --disable-smoosh --with-system-nspr RUSTC= CARGO= RUSTDOC= RUSTFMT= --without-libclang-path --without-clang-path BINDGEN_CFLAGS= --disable-js-shell --enable-jit --disable-simulator --disable-instruments --disable-callgrind --disable-profiling --disable-vtune --disable-gc-probes --disable-gczeal --disable-small-chunk-size --disable-trace-logging --disable-oom-breakpoint --disable-perf --disable-jitspew --disable-masm-verbose --disable-more-deterministic --enable-ctypes --with-system-ffi --disable-pipeline-operator --disable-binast --disable-rust-simd --disable-cranelift --disable-wasm-codegen-debug --disable-typed-objects --disable-wasm-bulk-memory --disable-wasm-reftypes --disable-wasm-gc --disable-wasm-private-reftypes --enable-wasm-multi-value --enable-shared-memory --enable-new-regexp --disable-wasm-simd --without-qemu-exe --with-cross-lib=/usr/x86_64-pc-linux-gnu --without-sixgill --with-jitreport-granularity=3 --with-system-icu --with-intl-api --disable-dtrace --enable-icf --disable-strip --enable-install-strip STRIP_FLAGS= --with-system-zlib --prefix=/scratch/working/firefox-78.3.0/firefox-build-dir/dist JS_STANDALONE= and then one further reference: 12:35.42 [style 0.0.1] cargo:rerun-if-changed=/scratch/working/firefox-78.3.0/firefox-build-dir/dist/include/mozjemalloc_types.h 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. ĸen 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 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] ZeroLogon vulnerability - Samba is affected and patched
Good afternoon,
On September 14th, 2020, Secura unveiled a vulnerability in the Windows
NetLogon protocol, dubbed "ZeroLogon". The vulnerability is described as
follows in the description at NIST.gov [1]:
"An elevation of privilege vulnerability exists when an attacker
establishes a vulnerable Netlogon secure channel connection to a domain
controller, using the Netlogon Remote Protocol (MS-NRPC), aka 'Netlogon
Elevation of Privilege Vulnerability'."
Since this is a protocol level vulnerability in the NETLOGON protocol,
Samba is also affected [3]. While our configuration is not directly
affected for the File and Print server side, additional configuration
changes may need to be made in order to continue to talk to domain
controllers on a network. If you're running Samba in a corporate
environment, this affects you the most. However, changes are being made
on the client side as well to force secure connections by default in
Windows, and this version of Samba also implements support for that
modification of the protocol. The Samba developers offer advice on this
in [5].
Due to the severity of this vulnerability (scores 10.0 on a CVSSv3
scale), it's recommended that you update to Samba-4.12.7 as soon as
possible, both in order to protect your system if you are running the
File Server component (additional checks are put in place, and a
proof-of-concept exploit is available [6]), and to allow the client to
continue function if you're connecting to a Windows-based server for
file shares. If you'd rather continue to use 4.12.6, a patch is
available from the Samba team at [4].
In terms of build instructions, there are no changes required. Important
statistics include:
Download URL: https://www.samba.org/ftp/samba/stable/samba-4.12.7.tar.gz
MD5SUM: 9f61a0ef23942179daad637ea84b7f37
Also, please note that ZeroLogon has a test in the quicktest suite of
Samba now. Here's an additional email from Samba's security team [7]
which provides further guidance and information. The bug report can be
found at [8]. The update to Samba-4.12.7 will appear in the next render
of the book, and an errata entry has been published.
Thank you,
Douglas R. Reno
LINKS:
[1]: NVD - CVE-2020-1472 [https://nvd.nist.gov/vuln/detail/CVE-2020-1472]
[2]: CVE-2020-1472 | Netlogon Elevation of Privilege Vulnerability
[https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1472]
[3]: Samba 4.12.7 - Release Notes
[https://www.samba.org/samba/history/samba-4.12.7.html]
[4]:
https://download.samba.org/pub/samba/patches/samba-4.12.6-4.12.7.diffs.gz
[5]: Samba - Security Announcement Archive
[https://www.samba.org/samba/security/CVE-2020-1472.html]
[6]: Zerologon Proof Of Concept = Packet Storm
[https://packetstormsecurity.com/files/159190/Zerologon-Proof-Of-Concept.html]
[7]: oss-security - Samba and CVE-2020-1472 ("Zerologon")
[https://www.openwall.com/lists/oss-security/2020/09/17/2]
[8]: 14497 - (CVE-2020-1472)[CVE-2020-1472][SECURITY] Samba impact of
"ZeroLogon" [https://bugzilla.samba.org/show_bug.cgi?id=14497]
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Libsoup-2.70.0 does not build with brotli-1.0.9
On 9/20/20 8:04 AM, NicP via blfs-dev wrote:
Hello,
While building BLFS-10.0 systemd stable version, libsoup-2.70.0 fails
to build if brotli-1.0.9 is installed.
The build stops with this message : unrecognized command-line option
'-R'.
This '-R' (obviousli erroneous) provides from one of the pkgconfig
files coming with brotli
(/usr/lib/pkgconfig/libbrotli{common,dec,enc}.pc).
Adding -Dbrotli=disabled to the meson command of libsoup does the job
(but of course without brotli support).
Is it a known issue ?
Best regards.
This is an upstream regression that we're going to have to solve as
it'll affect the latest libsoup for GNOME-3.38 as well.
Can you try applying this fix to brotli and then recompiling it:
https://github.com/google/brotli/pull/838/commits/092446fafb4bfb81738853b7c7f76b293cd92a80
Thank you,
- Doug
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] glib-2.66.0 meson fallback and gtk-doc
On 9/19/20 7:46 AM, Wayne Blaszczyk via blfs-dev wrote: Hi All, Not sure if anyone else has noticed this, but with the right conditions, glib-2.66.0 will install gtk-doc-1.32.1. On a fresh build box I had gtk-doc-1.32 installed, and was in the process of building glib-2.66.0 (for the second time) when it failed with a git not found error. On closer inspection, it was trying to git clone gtk-doc repo due to not meeting the gtk-doc >= 1.32.1 requirement as a fallback. After installing git, this time the glib-2.66.0 build was successfully and on closer inspection, it had actually installed the gtk-doc-1.32.1 subproject. what make it worse is that there is no gtk-doc 1.32.1 release, but in fact just the latest from git repo from what I can tell. This is not the first time I had noticed a "fallback" with a meson gnome package build recently. I'm not happy that dependencies are being installed without consent. Regards, Wayne. Hi Wayne, Are you building glib with -Dgtk_doc=true by chance? A couple of us have tried building glib2 with gtk-doc installed, and without gtk-doc installed, and we're unable to reproduce this problem. We have known it to happen from time to time, but we'd like to know exactly what causes it as well. I'm not happy about dependencies being installed without consent either. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Linux-PAM (System V)
On 9/16/20 8:40 AM, Pierre Labastie via blfs-dev wrote: On Tue, 2020-09-15 at 19:14 -0400, Joe Locash via blfs-dev wrote: Linux-PAM will create /usr/lib/systemd/system/pam_namespace.service even when building on SystemV. This can cause packages like make-ca (because it checks for the directory) to install files not needed to be installed also. Confirmed. There are two solutions: either sed -i /service_DATA/d modules/pam_namespace/Makefile.am autoreconf # before running configure or rm -r /usr/lib/systemd # as root, after make install Thanks for reporting Pierre I do think that the first approach (sed) is probably the best option in this case. Removing the directory itself just seems unclean. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] VLAN support in BLFS network scripts
On Fri, Sep 4, 2020, 9:27 AM Tim Tassonis via blfs-dev <
blfs-dev@lists.linuxfromscratch.org> wrote:
>
>
> On 9/4/20 8:26 AM, Bruce Dubbs via blfs-dev wrote:
> > On 9/4/20 12:36 AM, Tim Tassonis via blfs-dev wrote:
> >>
> >>
> >> On 9/4/20 2:12 AM, Ken Moffat via blfs-dev wrote:
> >>> On Fri, Sep 04, 2020 at 12:44:31AM +0200, Tim Tassonis via blfs-dev
> >>> wrote:
>
>
> On 9/3/20 10:29 PM, Pierre Labastie via blfs-dev wrote:
> > On Thu, 2020-09-03 at 21:47 +0200, Tim Tassonis via blfs-dev wrote:
> >>
> >> On 9/1/20 7:55 PM, Bruce Dubbs via blfs-dev wrote:
> >>> On 9/1/20 12:24 PM, Tim Tassonis via blfs-dev wrote:
> Hi all
>
> As one of Switzerland largest ISP's requires pppoe with vlan
> tagging
> for fiber connections, I wondered if vlan tagging could get
> supported
> in the network scripts.
>
> As I found out via https://wiki.archlinux.org/index.php/VLAN, one
> can
> create a tagged VLAN using
>
> ip link add link $REAL_IFACE name $VLAN_IFACE type vlan id
> $VLAN_ID
>
> , so I guess this could be implemented by
>
> - checking for $VLAN_IFACE and $VLAN_ID being set
> - checking for $VLAN_ID and $REAL_IFACE (in which case IFACE
> then
> holds the $VLAN_IFACE)
>
> The latter would probably be more consistent with other network
> stuff,
> where iface always holds the resulting interface, and not the
> physical
> one.
>
> I could add this to /lib/services/pppoe, if anyone else cares.
> I'm not
> sure if, apart from pppoe, anyone else is interested in vlan
> stuff.
> I'm not even sure /lib/services/pppoe is still in blfs
>
> If yes, I could also add this to ipv4-static and dhcpcd.
> >>>
> >>> Tim, Can you send me a patch that I can review? I would want to
> >>> make
> >>> sure that changes will not affect users that do not need them.
> >>
> >> The patch against the pppoe service file I got is as follows:
> >>
> >>
> >> --- pppoe-service2018-04-18 19:18:07.739547066 +0200
> >> +++ pppoe-service-vlan2020-09-03 21:37:27.613134901 +0200
> >> @@ -46,11 +46,24 @@
> >>exit 1
> >> fi
> >>
> >> +if [ "x${REAL_IFACE}" != "x" ] && [ "x$x${REAL_IFACE}" != "x" ]
> >
> > I'm not sure what you want to do above: if the first test is true,
> the
> > second is true too, whatever the value of $x. Typo?
>
> Correct, "x$x${REAL_IFACE}" is a typo, it should read:
>
> if [ "x${REAL_IFACE}" != "x" ] && [ "x${REAL_IFACE}" != "x" ]
>
> Like this, it is a very portable way to check if both of those
> variables
> have any defined value. But there may be a bash shortcut, maybe:
>
> >>>
> >>> Maybe I'm missing something (very possible), but you seem to be
> >>> testing the same variable twice:
> >>>
> >>> if [ "x${REAL_IFACE}" != "x" ] && [ "x${REAL_IFACE}" != "x" ]
> >>>
> >>> reformatted to put the two parts on separate lines:
> >>>
> >>> if [ "x${REAL_IFACE}" != "x" ] &&
> >>> [ "x${REAL_IFACE}" != "x" ]
> >>>
> >>>
> >>> Looking at your original posting, I think one of these should maybe
> >>> be ${IFACE} ? It seems that if REAL_IFACE is set then an extra
> >>> module should be modprobed before pppoe is modprobed.
> >>
> >> Oh my god, typical programmer's blindness. Here's the (hopefully)
> >> fixed patch, and attached the fixed script:
> >>
> >> --- pppoe-service2018-04-18 19:18:07.739547066 +0200
> >> +++ pppoe-service-vlan2020-09-04 07:28:50.121311974 +0200
> >> @@ -46,11 +46,24 @@
> >> exit 1
> >> fi
> >>
> >> +if [ "x${REAL_IFACE}" != "x" ] && [ "x${VLAN_ID}" != "x" ]
> >> +then
> >> + VLAN="Y"
> >> + /sbin/modprobe 8021q
> >> +else
> >> + VLAN="N"
> >> +fi
> >> +
> >> case "${2}" in
> >> up)
> >> /sbin/modprobe pppoe
> >> log_info_msg2 "\n"
> >> if is_true ${MANAGE_IFACE}; then
> >> +if [ "${VLAN}" = "Y" ]
> >> +then
> >> + /sbin/ip link set dev ${REAL_IFACE} up
> >> + /sbin/ip link add link ${REAL_IFACE} name ${IFACE} type
> >> vlan id ${VLAN_ID}
> >> +fi
> >> log_info_msg "Bringing up the ${IFACE} interface..."
> >> /sbin/ip link set dev ${IFACE} up
> >> evaluate_retval
> >> @@ -68,6 +81,11 @@
> >> if is_true ${MANAGE_IFACE}; then
> >> log_info_msg "Bringing down the ${IFACE} interface..."
> >> /sbin/ip link set dev ${IFACE} down
> >> +if [ "${VLAN}" = "Y" ]
> >> +then
> >> + /sbin/ip link set dev ${REAL_IFACE} down
> >> + /sbin/ip link del ${IFACE}
> >> +fi
> >> evaluate_retval
> >> fi
> >> ;;
> >
> > That looks more
Re: [blfs-dev] Request to add firefox-78.2.0 to BLFS-10.0
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. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Request for permission to add 'libnsl' as a dependency of procmail
Hello folks, Since Procmail is tagged already, I would like to request permission to add 'libnsl' as an optional dependency in procmail. I spotted this while working on my SysV system: cc -O procmail.o cstdio.o common.o exopen.o goodies.o locking.o mailfold.o foldinfo.o misc.o pipes.o regexp.o robust.o sublib.o acommon.o mcommon.o lastdirsep.o authenticate.o lmtp.o memblk.o variables.o from.o comsat.o -o procmail -s -lm -lnsl -ldl -lc As you can see, it's mentioning 'libnsl' as a library it's attempting to link to. Checking on my systemd system: cc -O procmail.o cstdio.o common.o exopen.o goodies.o locking.o mailfold.o foldinfo.o misc.o pipes.o regexp.o robust.o sublib.o acommon.o mcommon.o lastdirsep.o authenticate.o lmtp.o memblk.o variables.o from.o comsat.o -o procmail -s -lm -ldl -lc Procmail seems to be rather difficult to identify dependencies for. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Inkscape FTBFS
On 8/18/20 5:33 PM, Ken Moffat via blfs-dev wrote: On Tue, Aug 18, 2020 at 10:03:38PM +0100, Ken Moffat via blfs-dev wrote: On Tue, Aug 18, 2020 at 01:47:26PM -0500, Douglas R. Reno via blfs-dev wrote: On 8/18/20 1:24 PM, Ken Moffat via blfs-dev wrote: /usr/include/c++/10.2.0/bits/atomic_base.h:152:12: note: declaration of 'struct std::atomic' 152 | struct atomic; |^~ make[2]: *** [src/CMakeFiles/inkscape_base.dir/build.make:5120: src/CMakeFiles/inkscape_base.dir/ui/tool/node.cpp.o] Error 1 Note the 'Cached relative error' comment. After some random searches without any relevant results, I eventually discovered that boost has a concept of a 'relative error'. But I'm guessing this might be the first time anybody has tried to build inkscape with boost-1.74.0. No idea how to fix it. ĸen Hi Ken, I have a fix in my sandbox right now rendering You'll want to add "#include " either above or below "#include ". I've read conflicting reports about this regarding Boost, glibc, and gcc. I was able to build it with Poppler before freeze, so I know it's not that. I attributed it to glibc in my sandbox. This is the sed I entered: sed -i '/#include /a #include ' src/ui/tool/node.cpp - Doug Thanks! I couldn't find any directly relevant results, I think gcc had not changed since my last build, so from the odd comment in the message I guessed boost. Will give it a try when I'm back at the machine. Works nicely (as in builds and runs, but I'm too inexpert to get it to do what I really would like to use it for ;-). Thanks again. You're welcome! I'm glad it helped :-) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Inkscape FTBFS
On 8/18/20 1:24 PM, Ken Moffat via blfs-dev wrote: I build inkscape on this machine, with the same set of flags that I'm currently using, just under a week ago. But now on 10.0-rc1 it fails: cd /scratch/working/inkscape-1.0_2020-05-01_4035a4fb49/build/src && /usr/bin/c++ -DHAVE_CONFIG_H -DWITH_CSSBLEND -DWITH_CSSCOMPOSITE -DWITH_MESH -DWITH_SVG2 -Dinkscape_base_EXPORTS -I/scratch/working/inkscape-1.0_2020-05-01_4035a4fb49/build/src -I/scratch/working/inkscape-1.0_2020-05-01_4035a4fb49/src -I/scratch/working/inkscape-1.0_2020-05-01_4035a4fb49 -I/scratch/working/inkscape-1.0_2020-05-01_4035a4fb49/build/include -I/scratch/working/inkscape-1.0_2020-05-01_4035a4fb49/src/3rdparty/adaptagrams -isystem /usr/include/pango-1.0 -isystem /usr/include/fribidi -isystem /usr/include/cairo -isystem /usr/include/pixman-1 -isystem /usr/include/uuid -isystem /usr/include/freetype2 -isystem /usr/include/libpng16 -isystem /usr/include/harfbuzz -isystem /usr/include/libsoup-2.4 -isystem /usr/include/libxml2 -isystem /usr/include/libmount -isystem /usr/include/blkid -isystem /usr/include/glib-2.0 -isystem /usr/lib/glib-2.0/include -isystem /usr/include/gc -isystem /usr/include/poppler -isystem /usr/include/gtkmm-3.0 -isystem /usr/lib/gtkmm-3.0/include -isystem /usr/include/atkmm-1.6 -isystem /usr/include/gtk-3.0/unix-print -isystem /usr/include/gdkmm-3.0 -isystem /usr/lib/gdkmm-3.0/include -isystem /usr/include/giomm-2.4 -isystem /usr/lib/giomm-2.4/include -isystem /usr/include/pangomm-1.4 -isystem /usr/lib/pangomm-1.4/include -isystem /usr/include/glibmm-2.4 -isystem /usr/lib/glibmm-2.4/include -isystem /usr/include/cairomm-1.0 -isystem /usr/lib/cairomm-1.0/include -isystem /usr/include/sigc++-2.0 -isystem /usr/lib/sigc++-2.0/include -isystem /usr/include/libgdl-3.0 -isystem /usr/include/gtk-3.0 -isystem /usr/include/at-spi2-atk/2.0 -isystem /usr/include/at-spi-2.0 -isystem /usr/include/dbus-1.0 -isystem /usr/lib/dbus-1.0/include -isystem /usr/include/gio-unix-2.0 -isystem /usr/include/libdrm -isystem /usr/include/atk-1.0 -isystem /usr/include/gdk-pixbuf-2.0 -O3 -march=native -fstack-clash-protection -D_FORTIFY_SOURCE=2 -fstack-protector-strong -D_GLIBCXX_ASSERTIONS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -Werror=format -Werror=format-security -pthread -fopenmp -O3 -DNDEBUG -fPIC -pthread -fPIC -std=gnu++11 -o CMakeFiles/inkscape_base.dir/ui/tool/node.cpp.o -c /scratch/working/inkscape-1.0_2020-05-01_4035a4fb49/src/ui/tool/node.cpp /scratch/working/inkscape-1.0_2020-05-01_4035a4fb49/src/ui/tool/node.cpp:100:25: error: field 'rel_error' has incomplete type 'std::atomic' 100 | std::atomic rel_error; /// Cached relative error | ^ In file included from /usr/include/c++/10.2.0/bits/shared_ptr_atomic.h:33, from /usr/include/c++/10.2.0/memory:85, from /scratch/working/inkscape-1.0_2020-05-01_4035a4fb49/src/preferences.h:21, from /scratch/working/inkscape-1.0_2020-05-01_4035a4fb49/src/desktop.h:33, from /scratch/working/inkscape-1.0_2020-05-01_4035a4fb49/src/ui/tool/node.cpp:19: /usr/include/c++/10.2.0/bits/atomic_base.h:152:12: note: declaration of 'struct std::atomic' 152 | struct atomic; |^~ make[2]: *** [src/CMakeFiles/inkscape_base.dir/build.make:5120: src/CMakeFiles/inkscape_base.dir/ui/tool/node.cpp.o] Error 1 Note the 'Cached relative error' comment. After some random searches without any relevant results, I eventually discovered that boost has a concept of a 'relative error'. But I'm guessing this might be the first time anybody has tried to build inkscape with boost-1.74.0. No idea how to fix it. ĸen Hi Ken, I have a fix in my sandbox right now rendering You'll want to add "#include " either above or below "#include ". I've read conflicting reports about this regarding Boost, glibc, and gcc. I was able to build it with Poppler before freeze, so I know it's not that. I attributed it to glibc in my sandbox. This is the sed I entered: sed -i '/#include /a #include ' src/ui/tool/node.cpp - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Requesting permission to fix Ruby for lchmod problems in glibc
Hi folks, Since Ruby was tagged this morning, I'd like to ask for permission to fix the issue that I just encountered. First, some background information. In glibc-2.32, the glibc developers implemented a wrapper for lchmod() and fchmodat() for POSIX compatibility. Unfortunately, the kernel is incompatible with these syscalls - they modify modes on symbolic links, which the kernel does not support. The relevant entry in the libc-announce email is here: https://sourceware.org/pipermail/libc-announce/2020/29.html (look for [14578] libc: /proc-based emulation for lchmod, fchmodat). The Ruby FileUtils library expects that the operation not return EOPNOTSUPP, which is what the kernel returns if that syscall is attempted. This behavior is similar to what's implemented in musl libc (again for POSIX compatibility). However, lchmod() is unsupported at the kernel level. Ruby is expecting a POSIX compliant system, and in this case, lchmod() isn't supported, so it's failing. This is similar to the libarchive problem that I fixed yesterday, where some functions would output EOPNOTSUPP. This issue is evident in the test suite, where the tests crash after the first portion of the test suite is complete: # Running tests: Leaked file descriptor: DRbTests::TestDRbTCP#test_immediate_close: 9 : # 1) Failure: TestFileUtils#test_cp_r_symlink_preserve [/sources/ruby-2.7.1/ruby-2.7.1/test/fileutils/test_fileutils.rb:439]: Exception raised: <#>. 2) Failure: TestNotImplement#test_respond_to_lchmod [/sources/ruby-2.7.1/ruby-2.7.1/test/ruby/test_notimp.rb:17]: expected but was . 3) Error: TestNotImplement#test_call_lchmod: Errno::ENOTSUP: Operation not supported @ apply2files - /tmp/d20200817-26691-1iz31al/g /sources/ruby-2.7.1/ruby-2.7.1/test/ruby/test_notimp.rb:60:in `lchmod' /sources/ruby-2.7.1/ruby-2.7.1/test/ruby/test_notimp.rb:60:in `block in test_call_lchmod' /sources/ruby-2.7.1/ruby-2.7.1/lib/tmpdir.rb:89:in `mktmpdir' /sources/ruby-2.7.1/ruby-2.7.1/test/ruby/test_notimp.rb:54:in `test_call_lchmod' 4) Error: TestPathname#test_lchmod: Errno::ENOTSUP: Operation not supported @ apply2files - l /sources/ruby-2.7.1/ruby-2.7.1/test/pathname/test_pathname.rb:820:in `lchmod' /sources/ruby-2.7.1/ruby-2.7.1/test/pathname/test_pathname.rb:820:in `lchmod' /sources/ruby-2.7.1/ruby-2.7.1/test/pathname/test_pathname.rb:820:in `block in test_lchmod' /sources/ruby-2.7.1/ruby-2.7.1/test/pathname/test_pathname.rb:340:in `block (2 levels) in with_tmpchdir' /sources/ruby-2.7.1/ruby-2.7.1/test/pathname/test_pathname.rb:339:in `chdir' /sources/ruby-2.7.1/ruby-2.7.1/test/pathname/test_pathname.rb:339:in `block in with_tmpchdir' /sources/ruby-2.7.1/ruby-2.7.1/lib/tmpdir.rb:89:in `mktmpdir' /sources/ruby-2.7.1/ruby-2.7.1/test/pathname/test_pathname.rb:337:in `with_tmpchdir' /sources/ruby-2.7.1/ruby-2.7.1/test/pathname/test_pathname.rb:814:in `test_lchmod' I have a hunch that this might impact either SWIG or Subversion w/ ruby bindings, or potentially both. The reason why I think Subversion's ruby bindings could be affected has to do with the 'svn link' function. There is a fix for it upstream, although it requires modifications because it expects only Musl Libc to be affected, and FreeBSD. The patch needs to be modified to include standard Linux as well. The patch also needs to be modified to modify the spec/ruby/core/file/lchmod_spec.rb file to adjust to expectations from glibc-2.32 (false to true). The patch can be found here: https://git.ruby-lang.org/ruby.git/commit/?id=a19228f878d955eaf2cce086bcf53f46fdf894b9 After applying this, the normal two test failures for clock and getaddrinfo still continue to happen, but no other regressions are experienced: 1) File.utime allows Time instances in the far future to set mtime and atime FAILED Expected 2446 == 559444 to be truthy but was false /sources/ruby-2.7.1/ruby-2.7.1/spec/ruby/core/file/utime_spec.rb:78:in `block (4 levels) in ' /sources/ruby-2.7.1/ruby-2.7.1/spec/ruby/core/file/utime_spec.rb:3:in `' 2) Socket.getnameinfo using IPv6 using a 3 element Array as the first argument using NI_NUMERICHOST as the flag returns an Array containing the numeric hostname and service name ERROR SocketError: getaddrinfo: Name or service not known /sources/ruby-2.7.1/ruby-2.7.1/spec/ruby/library/socket/socket/getnameinfo_spec.rb:111:in `getnameinfo' /sources/ruby-2.7.1/ruby-2.7.1/spec/ruby/library/socket/socket/getnameinfo_spec.rb:111:in `block (6 levels) in ' /sources/ruby-2.7.1/ruby-2.7.1/spec/ruby/library/socket/socket/getnameinfo_spec.rb:65:in `' Finished in 31.352756 seconds 3746 files, 30429 examples, 171113 expectations, 1 failure, 1 error, 0 tagged make: *** [uncommon.mk:822: yes-test-spec] Error 1 I would like permission to integrate this patch into the book. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Re: [blfs-dev] pulseaudio-13.0
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 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] NSS Parallel Build is no longer possible
On 6/27/20 7:24 PM, Ken Moffat via blfs-dev wrote: On Sat, Jun 27, 2020 at 07:58:52PM +0100, Ken Moffat via blfs-dev wrote: On Sat, Jun 27, 2020 at 11:57:04AM -0500, Douglas R. Reno via blfs-dev wrote: Hi folks, While I'm working on updating the book to NSS-3.54, I wanted to let you guys know about the fact that parallel build is no longer possible. Here's some example output from my log before I deleted it and backed down to -j1: |../../coreconf/nsinstall/Linux5.6_x86_64_cc_glibc_PTH_64_OPT.OBJ/nsinstall -R -m 444 nssckfwt.h ../../../dist/public/nss symlink creation race: /sources/nss-3.54/nss-3.54/dist/public/nss/nssckfwt.h nsinstall: symlink was attempted in working directory /sources/nss-3.54/nss-3.54/nss/lib/ckfw from ../../../nss/lib/ckfw/nssckfwt.h to /sources/nss-3.54/nss-3.54/dist/public/nss/nssckfwt.h. : File exists After backing down to -j1, the build is progressing as normal. - Doug || Well, that was a really-short-lived "it's ok to build in parallel" time, wasn't it. Thanks for the heads up. ĸen I've just built 3.54 using -j4 on one of my machiens, it built ok. ĸen I just did a rebuild at -j4, and it worked fine for me as well. Now I'm confused. I am using an HDD because I can't afford to purchase another SSD at the moment. Seems to proceed fine now, but it definitely didn't earlier I'll correct the book - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] NSS Parallel Build is no longer possible
Hi folks, While I'm working on updating the book to NSS-3.54, I wanted to let you guys know about the fact that parallel build is no longer possible. Here's some example output from my log before I deleted it and backed down to -j1: |../../coreconf/nsinstall/Linux5.6_x86_64_cc_glibc_PTH_64_OPT.OBJ/nsinstall -R -m 444 nssckfwt.h ../../../dist/public/nss symlink creation race: /sources/nss-3.54/nss-3.54/dist/public/nss/nssckfwt.h nsinstall: symlink was attempted in working directory /sources/nss-3.54/nss-3.54/nss/lib/ckfw from ../../../nss/lib/ckfw/nssckfwt.h to /sources/nss-3.54/nss-3.54/dist/public/nss/nssckfwt.h. : File exists ../../coreconf/nsinstall/Linux5.6_x86_64_cc_glibc_PTH_64_OPT.OBJ/nsinstall -R -m 444 nssckg.h ../../../dist/public/nss ../../coreconf/nsinstall/Linux5.6_x86_64_cc_glibc_PTH_64_OPT.OBJ/nsinstall -R -m 444 nssckmdt.h ../../../dist/public/nss ../../coreconf/nsinstall/Linux5.6_x86_64_cc_glibc_PTH_64_OPT.OBJ/nsinstall -R -m 444 nssckt.h ../../../dist/public/nss make[4]: Leaving directory '/sources/nss-3.54/nss-3.54/nss/lib/smime' ../../coreconf/nsinstall/Linux5.6_x86_64_cc_glibc_PTH_64_OPT.OBJ/nsinstall -R -m 444 nssckg.h ../../../dist/public/nss make[4]: *** [../../coreconf/rules.mk:387: ../../../dist/public/nss/nssckfwt.h] Aborted (core dumped) make[4]: *** Deleting file '../../../dist/public/nss/nssckfwt.h' make[4]: *** Waiting for unfinished jobs make[5]: *** [../../coreconf/rules.mk:387: ../../../dist/public/nss/nssck.api] Aborted (core dumped) make[5]: *** Deleting file '../../../dist/public/nss/nssck.api' make[5]: Leaving directory '/sources/nss-3.54/nss-3.54/nss/lib/ckfw' make[4]: *** [../../coreconf/rules.mk:44: .] Error 2 make[4]: Leaving directory '/sources/nss-3.54/nss-3.54/nss/lib/ckfw' make[3]: *** [../coreconf/rules.mk:44: ckfw] Error 2 make[3]: Leaving directory '/sources/nss-3.54/nss-3.54/nss/lib' make[2]: *** [coreconf/rules.mk:44: lib] Error 2 make[2]: Leaving directory '/sources/nss-3.54/nss-3.54/nss' make[1]: *** [manifest.mn:25: prepare_build] Error 2 make[1]: Leaving directory '/sources/nss-3.54/nss-3.54/nss' make: *** [Makefile:53: nss_build_all] Error 2 0.8 Elasped Time - nss-3.54 | After backing down to -j1, the build is progressing as normal. - Doug || -- 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
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. Well it certainly would be nice to get polkit to do an update. 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. 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. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] a ttf font is required for cups-filters
On 6/16/20 9:37 AM, Pierre Labastie via blfs-dev wrote: cups-filter-1.27.5 needs a font for its tests. The default one is DejaVuSans.ttf, but this can be changed with the --with-test-font-path switch. Normally this font is only used for tests, so shouldn't be required, but configure fails if DejaVuSans.ttf or the specified font is not installed. There are two possibilities: - make DejaVu fonts recommended - tweak configure so that it does not error out if the font is not there. Pierre I suggest making the DejaVu fonts recommended. If I remember correctly, this isn't the only package that relies off their existence. I could be wrong about that though :) - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] LXDE logout menu items
On 6/14/20 3:08 PM, Pierre Labastie via blfs-dev wrote:
On Sun, 2020-06-14 at 16:03 -0400, Joe Locash via blfs-dev wrote:
polkit doesn't return a result if a user is in the wheel group so
when a user
logs out the options to shutdown, suspend, etc aren't displayed.
Do you mean a regular user gets those option and not a user in the
wheel group?
I propose adding a file in /etc/polkit-1/rules.d in the build of
lxsession
with the following:
polkit.addRule(function(action, subject) {
if (subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
Could be added in the build of polkit maybe? It seems more general than
just for lxde
I do think that would be a great opportunity to describe how to create
polkit rules
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] fix for building ncftp-3.2.6 with gcc-10
On 6/4/20 5:29 PM, Joe Locash wrote: Doug, There is no need to apologize. I'm happy to help out in any way. I didn't quote your reply but I'm curious about llvm playing a role in this. I also build it very early. The book states if LLVM is compiled with clang support then ncftp will use that. Obviously it didn't in my case. Thoughts? -Joe I'm curious as well. If you check the configure output, is yours doing something like this?: Making ncftp-3.2.6-src Thu 04 Jun 2020 09:46:36 AM CDT creating cache ./config.cache checking if you set and exported the environment variable CC... no (configure will try to locate a suitable C compiler) checking for environment variable CFLAGS... no (we will choose a default set for you) checking for environment variable CPPFLAGS... no checking for environment variable LDFLAGS... no checking for environment variable LIBS... no checking for clang C compiler... /usr/bin/clang checking if CC should now be set... /usr/bin/clang checking for gcc... /usr/bin/clang checking whether the C compiler (/usr/bin/clang ) works... yes checking whether the C compiler (/usr/bin/clang ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether /usr/bin/clang accepts -g... yes checking version of C library... glibc2.31 I'm curious as to why it redefines 'gcc' to 'clang'. I think LLVM is package #20 for me. It's easier to get that one done while working on other things :) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] fix for building ncftp-3.2.6 with gcc-10
On 6/2/20 7:06 PM, Joe Locash via blfs-dev wrote: Subject says it all... sed -i 's/^Bookmark/extern Bookmark/' sh_util/gpshare.c Hi Joe, I'd like to personally apologize, I just discovered while rebuilding ncftp on another system that, because I install LLVM many packages before NcFTP, my builds are using Clang instead of GCC. After forcing GCC to be used with CC=gcc before configuring the package, I get the following error: Compiling ncftpget: [ERROR] gcc -D_REENTRANT -O2 -W -Wall -Wno-format-y2k -DLINUX=56013 -DLINUX_GLIBC=231 00 -Dsh_util -DO_S="linux-x86_64-glibc2.31" -DSYSCONFDIR="/etc" -DHAVE_CONFIG _H -DLINUX=56013 -DLINUX_GLIBC=23100 -I/sources/ncftp-3.2.6 -I../libncftp -I. ./Strn -I../sio -I/sources/ncftp-3.2.6 -I/sources/ncftp-3.2.6/libncftp -I/sou rces/ncftp-3.2.6/sio -I/sources/ncftp-3.2.6/Strn gpshare.o bookmark.o preffw. o spoolutil.o util.o gl_getline.o version.o ncftpget.c -o ../bin/ncftpget -L. ./libncftp -L../Strn -L../sio -L/sources/ncftp-3.2.6/libncftp -L/sources/ncft p-3.2.6/sio -L/sources/ncftp-3.2.6/Strn -lncftp -lStrn -lsio /usr/bin/ld: bookmark.o:(.bss+0x20): multiple definition of `gBm'; gpshare.o: (.bss+0x0): first defined here collect2: error: ld returned 1 exit status Thank you for reporting this problem! I've implemented your sed at r23250, and it should be in the next rendering of the book. I also gave credit to you in the changelog entry. Thank you again, - Doug -- 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 ?
On 6/3/20 11:57 AM, Ken Moffat via blfs-dev wrote: On Wed, Jun 03, 2020 at 10:59:59AM -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 :) Yes, thanks, I've caught up with Pierre's posts. 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. For this morning's build of 12.18.0 with its included nghttp2 - configure 0.528s make -j415m58.544s DESTDIR 18.722s make test-only 5m23.080s So yes, I guess that on an older machine 30 minutes is possible. These are on the 'slow' ryzen, with gcc-10 (at the moment its my only gcc-10 system). Yes, I do have a SATA SSD, but for a small-size package like this I've got enough space in /tmp to use that for the build and DESTDIR install. To be fair, it probably doesn't help that I build things at -j1 for the final install. My temps average 80C at -j4 (if I had a better cooler than the stock Intel cooler, I'm sure it would be better). I don't hit the 95C range though, so I don't thermal throttle at least. Looks like 13 minutes for -j4 make, and a little bit longer for tests. At -j1 though, timing is abysmal like it is for most other packages, which is why it takes me so long. I have a list of upgrades for once my medical debt is taken care of, and a better cooler and more RAM is one of them :) -- 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 ?
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. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] fix for building ncftp-3.2.6 with gcc-10
On 6/2/20 7:06 PM, Joe Locash via blfs-dev wrote: Subject says it all... sed -i 's/^Bookmark/extern Bookmark/' sh_util/gpshare.c Hi Joe, Did you try building ncftp with the second method (built in statically), or the first one? When I built it last (a few weeks ago), I built it with the second option and didn't have a problem. However, if it's the first option (building the shared library), we'll definitely have to investigate this. Do you have any error output? Thank you, - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] seamonkey-2.53.2, 2020-05-25 libvpx, rationnal?
On 5/26/20 1:44 PM, Jean-Marc Pigeon wrote: On Tue, 2020-05-26 at 12:50 -0500, Douglas R. Reno via blfs-dev wrote: On 5/26/20 12:35 PM, Jean-Marc Pigeon via blfs-dev wrote: Hello, Trying to compile seamonkey-2.53.2 and beeing not successful. at first I was thinking about a gcc10 problem, but it is not the case. The error is within: mozilla/media/webrtc/trunk/webrtc/modules/video_coding/codecs/vp9/v p9_i mpl.cc seamonkey- 2.53.2/mozilla/media/webrtc/trunk/webrtc/modules/video_coding/codec s/vp 9/vp9_impl.cc:858:17: error: ‘struct vpx_svc_ref_frame_config’ has no member named ‘frame_flags’ 858 | sf_conf.frame_flags[layer_idx] = layer_flags; | ^~~ field frame_flags is not defined within /usr/include/vpx/vp8cx.h, (structure vpx_svc_ref_frame_config) seamonkey-2.49.4 is compiling fine... but routine where the defective code is located, is under/hiden by #ifdef LIBVPX_SVC This ifdef is not present in 2.53.2 code. I noticed, seamonkey 2020-05-25 do not list libvpx in recommended anymore (version 2.49.4 does include libvpx as recommended) Tried to removed libvpx, but 2.53.2 is requesting libvpx > 1.5.0 Obviously, I am missing something. 1) Could the someone in the list confirm he is successful to compile seamonkey within 2020-05-25 (gcc-10, libvpx-1.8.2,rustc-1.42.0, etc.)?? 2) Why libvpx is not in the seamonkey "required". 3) is there a mozconfig parameter involved? 4) wild idea of your own? :-}} Thanks for any help or suggestions, myself out of idea for now.. -- You have seen "Linux from scratch" and looking for ISO files www.osukiss.org Hi Jean-Marc, When I did the update to Seamonkey last, I didn't see any references to configure looking for libvpx in the configure output. In previous versions of Seamonkey, problems were encountered when using system libvpx (if I'm not mistaken, Mozilla / the Seamonkey developers are using an older version within their source code). It looks like libvpx was built as part of the build procedure for seamonkey. I haven't built Seamonkey with a GCC-10 system though. Doing a 'grep libvpx' on my build log from May 3rd shows that it doesn't look for libvpx and builds its own version later on in the process. --with-system-libvpx should be removed from mozconfig if you don't have that already. It looks like the last time I built it was May 3rd, 2020, when I updated the book to Seamonkey-2.53.2. An important thing to remember is that Seamonkey-2.49 was using Firefox-36's codebase, and Seamonkey-2.53 uses Firefox 60's codebase, which now necessitates the usage of rust and potentially an internal snapshot of libvpx Can you post your mozconfig please? I'm curious as to whether you're doing anything different than us. Here's my mozconfig: cat > mozconfig << "EOF" mk_add_options MOZ_MAKE_FLAGS="-j4" ac_add_options --enable-startup-notification ac_add_options --enable-system-sqlite ac_add_options --with-system-libevent ac_add_options --with-system-nspr ac_add_options --with-system-nss ac_add_options --with-system-icu ac_add_options --prefix=/usr ac_add_options --enable-application=suite ac_add_options --disable-crashreporter ac_add_options --disable-updater ac_add_options --disable-tests ac_add_options --enable-optimize="-O2" ac_add_options --enable-strip ac_add_options --enable-install-strip ac_add_options --enable-official-branding ac_add_options --enable-system-ffi ac_add_options --enable-system-cairo ac_add_options --enable-system-pixman ac_add_options --with-pthreads ac_add_options --with-system-bz2 ac_add_options --with-system-jpeg ac_add_options --with-system-png ac_add_options --with-system-zlib EOF I've got the exact same flags as are in the book, with the exception of some things being disabled (I do have GConf, dbus-glib, wireless- tools, and startup-notification installed). Double checked.. about libvpx, if I remove it (via rpm -e --nodeps), seamonkey complain... DEBUG: configure:10348: /usr/bin/gcc -std=gnu99 -c -fno-strict- aliasing -fno-math-errno -pthread conftest.c 1>&5 DEBUG: configure:10468: checking if app-specific confvars.sh exists DEBUG: configure:11601: checking for gtk+-3.0 >= 3.4.0 gtk+-unix-print- 3.0 glib-2.0 gobject-2.0 gio-unix-2.0 DEBUG: configure:11608: checking MOZ_GTK3_CFLAGS DEBUG: configure:11613: checking MOZ_GTK3_LIBS DEBUG: configure:11684: checking for gtk+-2.0 >= 2.18.0 gtk+-unix- print-2.0 glib-2.0 >= 2.22 gobject-2.0 gio-unix-2.0 gdk-x11-2.0 DEBUG: configure:11691: checking MOZ_GTK2_CFLAGS DEBUG: configure:11696: checking MOZ_GTK2_LIBS DEBUG: configure:12848: /usr/bin/gcc -std=gnu99 -c -fno-strict- aliasing -fno-math-errno -pthread conftest.c 1>&5 DEBUG: configure:13030: checking for vpx >= 1.5.0 DEBUG: configure: error: Library requirements (vpx >= 1.5.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstanda
Re: [blfs-dev] seamonkey-2.53.2, 2020-05-25 libvpx, rationnal?
On 5/26/20 12:35 PM, Jean-Marc Pigeon via blfs-dev wrote: Hello, Trying to compile seamonkey-2.53.2 and beeing not successful. at first I was thinking about a gcc10 problem, but it is not the case. The error is within: mozilla/media/webrtc/trunk/webrtc/modules/video_coding/codecs/vp9/vp9_i mpl.cc seamonkey- 2.53.2/mozilla/media/webrtc/trunk/webrtc/modules/video_coding/codecs/vp 9/vp9_impl.cc:858:17: error: ‘struct vpx_svc_ref_frame_config’ has no member named ‘frame_flags’ 858 | sf_conf.frame_flags[layer_idx] = layer_flags; | ^~~ field frame_flags is not defined within /usr/include/vpx/vp8cx.h, (structure vpx_svc_ref_frame_config) seamonkey-2.49.4 is compiling fine... but routine where the defective code is located, is under/hiden by #ifdef LIBVPX_SVC This ifdef is not present in 2.53.2 code. I noticed, seamonkey 2020-05-25 do not list libvpx in recommended anymore (version 2.49.4 does include libvpx as recommended) Tried to removed libvpx, but 2.53.2 is requesting libvpx > 1.5.0 Obviously, I am missing something. 1) Could the someone in the list confirm he is successful to compile seamonkey within 2020-05-25 (gcc-10, libvpx-1.8.2,rustc-1.42.0, etc.)?? 2) Why libvpx is not in the seamonkey "required". 3) is there a mozconfig parameter involved? 4) wild idea of your own? :-}} Thanks for any help or suggestions, myself out of idea for now.. -- You have seen "Linux from scratch" and looking for ISO files www.osukiss.org Hi Jean-Marc, When I did the update to Seamonkey last, I didn't see any references to configure looking for libvpx in the configure output. In previous versions of Seamonkey, problems were encountered when using system libvpx (if I'm not mistaken, Mozilla / the Seamonkey developers are using an older version within their source code). It looks like libvpx was built as part of the build procedure for seamonkey. I haven't built Seamonkey with a GCC-10 system though. Doing a 'grep libvpx' on my build log from May 3rd shows that it doesn't look for libvpx and builds its own version later on in the process. --with-system-libvpx should be removed from mozconfig if you don't have that already. It looks like the last time I built it was May 3rd, 2020, when I updated the book to Seamonkey-2.53.2. An important thing to remember is that Seamonkey-2.49 was using Firefox-36's codebase, and Seamonkey-2.53 uses Firefox 60's codebase, which now necessitates the usage of rust and potentially an internal snapshot of libvpx Can you post your mozconfig please? I'm curious as to whether you're doing anything different than us. Here's my mozconfig: cat > mozconfig << "EOF" mk_add_options MOZ_MAKE_FLAGS="-j4" ac_add_options --enable-startup-notification ac_add_options --enable-system-sqlite ac_add_options --with-system-libevent ac_add_options --with-system-nspr ac_add_options --with-system-nss ac_add_options --with-system-icu ac_add_options --prefix=/usr ac_add_options --enable-application=suite ac_add_options --disable-crashreporter ac_add_options --disable-updater ac_add_options --disable-tests ac_add_options --enable-optimize="-O2" ac_add_options --enable-strip ac_add_options --enable-install-strip ac_add_options --enable-official-branding ac_add_options --enable-system-ffi ac_add_options --enable-system-cairo ac_add_options --enable-system-pixman ac_add_options --with-pthreads ac_add_options --with-system-bz2 ac_add_options --with-system-jpeg ac_add_options --with-system-png ac_add_options --with-system-zlib EOF I've got the exact same flags as are in the book, with the exception of some things being disabled (I do have GConf, dbus-glib, wireless-tools, and startup-notification installed). -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] replacing transcode with handbrake
On 5/20/20 11:28 AM, Pierre Labastie via blfs-dev wrote: Transcode is an old, unmaintained, transcoder for video and audio. I've made a patch to allow building it with GCC 10, but I am not sure how to test it. So maybe time to drop it... At this point, I've discussed with D. Reno, who pointed up that there is a replacement, whose name is handbrake [1]. I've not tried to build it yet, but it has both a cli and a gui, and seems to be able to do all what transcode was able to do (correct me if not). So my proposition is (after some tests maybe) to drop transcode and add handbrake (building does not seem hard [2], no idea of the SBU's). Thoughts? Pierre [1] https://handbrake.fr/ [2] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/handbrake One additional advantage to using Handbrake is that it can rip BluRays in addition to DVDs. When I was in charge of the streaming aspect of the eSports club in college, we used Handbrake (in my case, on Debian) to convert the .flv files that OBS Studio used to give out to something more standard... like MP4 or AVI. -- 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
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? Hey Xi, I haven't encountered this, but it looks simple enough that I can drop it in as a sed. I'll do that first thing this morning. - Doug -- 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
On 4/24/20 6:48 PM, Xi Ruoyao via blfs-dev wrote: 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, 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. Someone suggests that xf86- video-intel is "bad" and should not be used for iGPUs later than year 2006. Maybe it's guilty. By the way, what version of Mesa did you use when adding this, Xi? Since 19.x (used MESA_LOADER_DRIVER_OVERRIDE=iris, in 19.x i965 was the default). With mesa-20.0.0 some applications crash occasionally, but fixed with 20.0.1. On 20.0.1-20.0.5 everything seems fine. So I think we should report the issue to https://gitlab.freedesktop.org/mesa/mesa/-/issues, and revert the change for now. I'll go ahead and revert the change for now. We can re
Re: [blfs-dev] new intel graphic driver
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::QFunctorSlotObject0, 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. 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? By the way, what version of Mesa did you use when adding this, Xi? -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Latest json-c breaks Cryptsetup
On 4/22/20 6:18 AM, Ryan Marsaw via blfs-dev wrote: Hello all. The latest json-c breaks the cryptsetup package with the following: [...] In file included from lib/luks2/luks2_disk_metadata.c:24: lib/luks2/luks2_internal.h:61:10: error: conflicting types for 'json_object_get_uint64' 61 | uint64_t json_object_get_uint64(json_object *jobj); | ^~ In file included from /usr/include/json-c/json.h:27, from lib/luks2/luks2_internal.h:27, from lib/luks2/luks2_disk_metadata.c:24: /usr/include/json-c/json_object.h:725:22: note: previous declaration of 'json_object_get_uint64' was here 725 | JSON_EXPORT uint64_t json_object_get_uint64(const struct json_object *obj); | ^~ make[2]: *** [Makefile:2072: lib/luks2/libcryptsetup_la-luks2_disk_metadata.lo] Error 1 [...] Here's the link to the upstream commit: https://gitlab.com/cryptsetup/cryptsetup/-/commit/604abec333a0efb44fd8bc610aa0b1151dd0f612?view=inline I've create a patch based on the above, in case anyone's interested. Cheers, --Ryan Hi Ryan, This issue has been fixed at r23019 and should be in the next book render. Thank you for reporting it! :) - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] About thunderbird build size
On 4/9/20 6:23 AM, Tim Tassonis via blfs-dev wrote: Hi all I noticed that I do get quite different build sizes for thunderbird than other maintainers, so I thought I will give a few infos about how I build thunderbird. Maybe this helps to find out what's going on here. du -hs /lgl-bld/thunderbird-68.7.0/ reports 4.2G /lgl-bld/thunderbird-68.7.0/ So, as I'm doing this with all other packages and never get a significant difference to what's in the book with other packages, I'm pretty sure that my counting isn't the problem. Hi Tim, I noticed that you're measuring the install via a DESTDIR (otherwise you wouldn't know what the installed files size is - although if you installed it in /opt/thunderbird like I see below, it'd be easy to measure it the same way). I know that cargo puts files in ~/.cargo, but I'm not sure how much of a difference that makes and looking at my script, I normally don't measure that either. See below on your package versions In my mozconfig, I think I'm doing pretty standard stuff, too. These are my active ac_add_options: ac_add_options --enable-startup-notification ac_add_options --disable-pulseaudio ac_add_options --enable-calendar ac_add_options --enable-system-sqlite ac_add_options --with-system-libevent ac_add_options --with-system-nspr ac_add_options --with-system-nss ac_add_options --with-system-icu ac_add_options --prefix=/opt/thunderbird ac_add_options --enable-application=comm/mail ac_add_options --disable-crashreporter ac_add_options --disable-updater ac_add_options --disable-debug ac_add_options --disable-debug-symbols ac_add_options --disable-tests ac_add_options --enable-optimize=-O2 ac_add_options --enable-strip ac_add_options --enable-install-strip ac_add_options --enable-official-branding ac_add_options --enable-system-ffi ac_add_options --enable-system-pixman ac_add_options --with-system-bz2 ac_add_options --with-system-jpeg ac_add_options --with-system-png ac_add_options --with-system-zlib So, what's left maybe is my toolchain, which might be a bit outdated: Name : rustc Version : 1.42.0-1 Name : gcc Version : 7.3.0-1 Name : clang Version : 5.0.1-1 I suppose I'm building with gcc and not clang, might that make such a huge difference in buildsize? Although that might not make a difference in build size, what might is your older package versions. What version of LFS are you building this on? The rest of us use 9.1/SVN, and in our case, that means: rustc-1.42.0 gcc-9.3.0 llvm-10.0.0 Those packages can all contribute to a large difference in build size. Any mismatches in node.js or cbindgen can cause limited problems as well. We've been doing updates with GCC-9.3 and LLVM-10 in case we encounter any compilation or runtime errors caused by newer compilers. We try to keep all of the dependencies for a package on our system up to date before we update a package as well. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] linux kernel 5.6 stable SVN-20200401
On 4/3/20 9:35 AM, Jean-Marc Pigeon via blfs-dev wrote: Hello, According to me, kernel 5.6 is now "mainline" and stable. Is there something wrong with 5.6 such LFS SVN-20200401 is not including the 5.6 family?? My own point of interest with 5.6 is the time_namespace (for containers). Is 5.6.2 too new to be considered for the (B)LFS project? With early 5.6 versions, 5.6/5.6.1, the Intel Wireless driver (IWLWIFI) was broken. I think we're holding to see if any other regressions show up under this release -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Network-manager-applet and libnma split as well as package placement
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". 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). What should we do here? Thank you, - Doug -- 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 1.39 broken with llvm 10?
On 3/27/20 9:24 AM, Pierre Labastie via blfs-dev wrote: Just built cmake 1.17, llvm 10.0? and trying rustc-1.39. Got an error: See attached log (with ~3300 lines cut). Sorry it is a little long, but it really looks like some LLVM header file is missing or API has changed. Has anybody seen this too? Pierre Yes I have! It seems that using system LLVM is broken with rustc-1.39. I had to do the following to get rustc to build using it's builtin version of LLVM for now (I believe it's LLVM9? LLVM-10 has changed a lot of the public API for applications that use bindings such as rustc). - Comment out the [target.x86_64-unknown-linux-gnu] line - Comment out the llvm-config= line If you are on i686 (untested), comment out the i686 portions of that statement. That will unfortunately force rustc to build using it's builtin LLVM though, which is less than desirable - Doug -- 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 config info for bridgeutils
On 3/22/20 6:10 AM, Pierre Labastie via blfs-dev wrote: Hi, Message for systemd devs: There is a "TBA" for bridge-utils configuration in the systemd book. Should I create a ticket? Or just remove that section? Pierre I'd say remove that section for now. I'm not certain on how to configure bridging using networkd at the moment -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] sdl-1.2 triggers gst-plugins-base
On 3/18/20 8:57 AM, Pierre Labastie via blfs-dev wrote: As already mentioned (long ago), on this list[1], Gst-plugins-base doesn't build if sdl-1.2.15 is installed. I've experienced this recently too. The workaround is to pass -Dexamples=disabled, or to patch sdl-1.2.15 (or to not install sdl-1.2, but it is recommended for one package (see below), so if this package is built before gsteamer, it may trigger the failure. SDL-1.2.15 will never have a new release: users are expected to use SDL-2. Arch has a set of 23 patches [2], some fixing security issues. One of those allows to build gst-plugins-base, according to J. Burrell (not tried myself). SDL-1.2.15 is referenced in the following packages: mpg123: optional audacious: optional mlt: optional libdv: optional libtheora: optional (to build examples) gst-plugins-bad: optional gst-plugins-base: optional xine-lib: optional libmpeg2: optional mplayer: optional transcode: optional vlc: optional qemu: optional cogl: optional (cogl can use sdl2...) libwebp: recommended ptlib: optional I wonder how much time has gone since any of those dependencies has been tested (specially to make sure sdl2 cannot be used). In any case, we should do at least one of three things: - pass -Dexamples=disabled to gst-plugins-base (or at least cite it in the command explanations) - patch sdl-1.2 (needed for security issues anyway) I definitely think that we should patch the security issues as well, but -Dexamples=disabled seems to be the best option at the moment. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Archive Seamonkey?
On 3/15/20 5:53 PM, Bruce Dubbs via blfs-dev wrote: We have a problem caused by rust. Seamonkey cannot be built with a version of rust later than 1.37 and librsvg now requires version 1.39 or later. As I see it we have the option of installing multiple versions of rust in /opt or archiving Seamonkey. I'm not sure what SM offers other than a different user interface. It's capabilities are basically the same as firefox and thunderbird. Indeed it uses similar (but earlier) internals as those packages. I know that we've decided to patch Seamonkey already, but I wanted to add my 2cents here now that my email is working properly: Seamonkey also has a WYSWIG editor in it - Composer. For designing web pages in a pinch, it seems to work very well. I forgot that it existed until I finished updating it (and I found a problem with the icon installation that I'm getting ready to commit - I'll make an errata for it too). Nothing else that we have seems to provide a WYSWIG editor. Bluefish comes close though, it does have quick access buttons for adding tables and other elements to HTML documents, as well as something for designing forms IIRC. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Remove sawfish?
On 3/10/20 1:58 PM, Pierre Labastie via blfs-dev wrote: I know it would not bring much (decrease the number of packages by 3), but removing sawfish from the book would allow removing also librep and rep-gtk... Also rep-gtk depends on gtk+-2, and I think we should try to eliminate all the packages that depend on gtk+-2. Comment? Pierre I know that I'm rather late on this, but I would like to suggest keeping sawfish in the book. I was looking upstream and noticed that there have been several commits recently here: https://github.com/SawfishWM/sawfish It seems that they are working on porting to GTK3 as well. I do use Sawfish from time to time, and it is a nice window manager. It does have some odd quirks though. You have to use the middle mouse button to bring up the menu - and I only have one mouse that seems to respond to pressing the middle button. -- 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
On Sat, Mar 14, 2020 at 11:21 AM Douglas R. Reno wrote: > > > On Sat, Mar 14, 2020 at 3:08 AM Pierre Labastie via blfs-dev < > blfs-dev@lists.linuxfromscratch.org> wrote: > >> Le 14/03/2020 à 06:25, Douglas R. Reno via blfs-dev a écrit : >> > 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 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. >> > >> >> Not sure it has anything to do with this, but there is this: >> >> >> https://bugs.archlinux.org/task/65827?string=gst-plugins-good=1_name=%5B0%5D=%5B0%5D=%5B0%5D=%5B0%5D=%5B0%5D=%5B0%5D=%5B0%5D=open%5B0%5D >> >> Pierre >> >> > Thanks for the link! It looks to be a report of the souphttpsrc test suite > failure that we have documented in the book. I never understood why only 1 > out of 15 tests in the souphttpsrc suite failed either > Alright folks, I seem to have figured it out. Now to rebuild packages back to where I had them before experimenting, since I tried a different version of Mesa and glib while going down the rabbit hole... The underlying cause of the problem is the Nouveau graphics driver. Nouveau does not support the NVIDIA GeForce GT1030 that I had in this system. I do not know what other cards are affected by this, but I suspect that anything from the 900-series onwards has a problem with Nouveau. I could have installed the NVIDIA proprietary driver (assuming that I have all of the dependencies - and I think it needs CUDA, so I definitely don't if that's the case). I figured this out after doing a 'dmesg' and then checking glxinfo to find out that the NVIDIA card was using a generic framebuffer and was using software acceleration in X. However, running Cheese and gst-inspect-1.0 ran just fine in Weston (which I built just to experiment). I lost patience and put the GT 630 that I had in my previous workstation into this one. It's a rather nasty decrease in graphics capabilities (two versions of OpenGL), but it will suffice until I can replace this card with an AMD of some kind. It's not worth the hassle of fiddling with proprietary drivers. - Doug -- 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
On Sat, Mar 14, 2020 at 3:08 AM Pierre Labastie via blfs-dev < blfs-dev@lists.linuxfromscratch.org> wrote: > Le 14/03/2020 à 06:25, Douglas R. Reno via blfs-dev a écrit : > > 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 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. > > > > Not sure it has anything to do with this, but there is this: > > > https://bugs.archlinux.org/task/65827?string=gst-plugins-good=1_name=%5B0%5D=%5B0%5D=%5B0%5D=%5B0%5D=%5B0%5D=%5B0%5D=%5B0%5D=open%5B0%5D > > Pierre > > Thanks for the link! It looks to be a report of the souphttpsrc test suite failure that we have documented in the book. I never understood why only 1 out of 15 tests in the souphttpsrc suite failed either -- 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
On Sat, Mar 14, 2020 at 1:31 AM Xi Ruoyao via blfs-dev < blfs-dev@lists.linuxfromscratch.org> wrote: > 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. > > Hello Xi, I use a NVIDIA GeForce GT 1030 with the nouveau driver. I'll note that anything that I use that has 3D Acceleration built in, including Plasma, seems to work properly though. More on this later and what I'm trying next. And can you load the coredump file into GDB? (On systemd) try: > > coredumpctl -1 gdb > (gdb) bt > > to generate a stack backtrace. > > (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7f686287953b in __GI_abort () at abort.c:79 #2 0x0058e78a in OsAbort () at utils.c:1351 #3 0x00593633 in AbortServer () at log.c:879 #4 0x00594401 in FatalError ( f=f@entry=0x5c4990 "Caught signal %d (%s). Server aborting\n") at log.c:1017 #5 0x0058beb5 in OsSigHandler (unused=, sip=0x7ffeb8cb2130, signo=6) at osinit.c:156 #6 OsSigHandler (signo=6, sip=0x7ffeb8cb2130, unused=) at osinit.c:110 #7 #8 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #9 0x7f686287953b in __GI_abort () at abort.c:79 #10 0x7f686287940f in __assert_fail_base ( fmt=0x7f68629e00a8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x59c50a "key->initialized", file=0x5a0a7c "../../../include/privates.h", line=121, function=) at assert.c:92 #11 0x7f6862887fb2 in __GI___assert_fail ( assertion=assertion@entry=0x59c50a "key->initialized", file=file@entry=0x5a0a7c "../../../include/privates.h", line=line@entry=121, 3162> "dixGetPrivateAddr") at assert.c:101 #12 0x00557f43 in dixGetPrivateAddr (key=, key=, privates=0xc13d40) at ../../../include/privates.h:121 #13 0x0055a052 in dixGetPrivateAddr (key=, key=, privates=) at ../../../include/privates.h:122 #14 dixLookupPrivate (key=0x6333c0 , privates=0xc13d40) at ../../../include/privates.h:164 #15 DRI2Authenticate (client=client@entry=0x11ab5d0, pScreen=0xc13cd0, magic=1) at dri2.c:1367 #16 0x0055b087 in ProcDRI2Authenticate (client=0x11ab5d0) at dri2ext.c:152 #17 ProcDRI2Dispatch (client=0x11ab5d0) at dri2ext.c:609 #18 0x0043f2d4 in Dispatch () at dispatch.c:478 #19 0x004431a4 in dix_main (argc=6, argv=0x7ffeb8cb2958, envp=) at main.c:276 #20 0x7f686287accb in __libc_start_main (main=0x42df50 , argc=6, argv=0x7ffeb8cb2958, init=, fini=, rtld_fini=, stack_end=0x7ffeb8cb2948) at ../csu/libc-start.c:308 #21 0x0042df8a in _start () at ../sysdeps/x86_64/start.S:120 And the relevant portion of my Xorg.log: [ 44629.090] (EE) [ 44629.090] (EE) Backtrace: [ 44629.090] (EE) 0: /usr/libexec/Xorg (xorg_backtrace+0x40) [0x5884b0] [ 44629.090] (EE) 1: /usr/libexec/Xorg (0x40+0x18be48) [0x58be48] [ 44629.090] (EE) 2: /lib/libpthread.so.0 (0x7f686312e000+0x13020) [0x7f6863141020] [ 44629.090] (EE) 3: /lib/libc.so.6 (gsignal+0x141) [0x7f686288f661] [ 44629.090] (EE) 4: /lib/libc.so.6 (abort+0x127) [0x7f686287953b] [ 44629.090] (EE) 5: /lib/libc.so.6 (0x7f6862857000+0x2240f) [0x7f686287940f] [ 44629.090] (EE) 6: /lib/libc.so.6 (0x7f6862857000+0x30fb2) [0x7f6862887fb2] [ 44629.090] (EE) 7: /usr/libexec/Xorg (0x40+0x157f43) [0x557f43] [ 44629.090] (EE) 8: /usr/libexec/Xorg (0x40+0x15a052) [0x55a052] [ 44629.090] (EE) 9: /usr/libexec/Xorg (0x40+0x15b087) [0x
[blfs-dev] Gstreamer crashing X
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 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. Thank you, - Doug Sent from my cell phone, my apologies for any grammar or spelling mistakes -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] glibc-2.31 + util-linux-2.35.1 + hwclock (LFS-9.1 RC)
On 3/5/20 3:20 PM, Jean-Marc Pigeon via blfs-dev wrote: Hello, hwclock --htctosys is not working anymore -->> hwclock: settimeofday() failed: Invalid argument I have hint about the fact it could be a glibc-2.31 related problem https://forum.artixlinux.org/index.php/topic,1311.msg9179.html Could someone concur about hwclck malfunction? is there a bypass/patch about this? Thanks for help. Hi Jean-Marc, Check this out: https://marc.info/?l=util-linux-ng=158233347915676=2 This is due to glibc-2.31's y2038 changes, and also due to changes in the kernel's time API. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] strange dependencies: samba -> python3 -> lsb-tools
On 3/3/20 8:42 PM, Xi Ruoyao via blfs-dev wrote: 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. This was instated when upgrading to Python-3.8 IIRC. When installing Python-3.8.0, setuptools would call upon 'lsb-release' if a /etc/lsb-release file is present on the system (to identify the distribution and adapt to some quirks that other distros use). LSB-Tools uses a python module as part of it's implementation of lsb-release, and when upgrading minor versions of python, the modules aren't carried over. Setuptools used to call 'lsb-release' after it would install the new python executable, and as a result, it would crash because there is no '/usr/lib/python3.8/site-packages/lsbtools/lsb_release.py' file installed under the python3.8 directory yet (you have to rebuild lsb-tools for that). I remember putting that in, but I'm not sure if it's valid or not anymore. I think they may have fixed it in the newest version of setuptools (which is included with Python-3.8.2). If there aren't any objections, I have no issues with commenting this out in case it becomes a problem again. * I can build samba with Python 3 built in LFS, before I rebuilt Python 3. That was an oversight on my part, I'll remove it in my next commit. Thank you Xi Should we remove them, or explain why we need these strange dependencies? -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] gimp-2.10.16 : Do not use
On 2/22/20 9:38 AM, Douglas R. Reno via blfs-dev wrote: On 2/21/20 5:29 PM, Ken Moffat via blfs-dev wrote: A few hours ago I put gimp-2.10.16 into the book, after giving it some short tests re photo editing, help, and a brief test of using brushes. Now that I'm checking my mailboxes I found the following on gimp-dev: | On 2/21/20 8:57 PM, Ell via gimp-developer-list wrote: | > Hey, we're doing a ninja 2.10.18 release. There was an ugly data | > corruption bug in 2.10.16 | > (https://gitlab.gnome.org/GNOME/gimp/issues/4643) -- good thing we | > didn't announce it yet, huh? :) We want to do it later today or | > tomorrow (more likely). Just a heads up, if you have some last-minute | > fixes to push. | | Well, this wasn't actually supposed to go to the list, but whatever. If | anyone is already using 2.10.16, you might want to revert to 2.10.14 for | now. There should be a new release soon. That reply (also from Ell) suggests the release might take a little longer. For the moment, I'll wait and see, Meanwhile, I advise people not to use 2.10.16. ĸen Just a heads up for you guys, If you downgrade to GIMP-2.10.14, you're going to need to completely remove all of the files from GIMP-2.10.16. Otherwise you will end up with a version mismatch error for libgimp.so when trying to launch GIMP. Here's what I did: - Attempted to launch GIMP-2.10.14 and got the Version Mismatch error when trying to launch GIMP - Removed the files like so: sudo rm -rfv /usr/lib/libgimp* /usr/bin/gimp* /etc/gimp /usr/include/gimp-2.0 /usr/share/gimp /usr/share/gtk-doc/html/libgimp* /usr/lib/gimp This should remove the GIMP libraries, headers, configuration files in /etc, the binaries, and the items it specifically puts in /usr/share (with the exception of the desktop file because I know that will remain the same). I've since begun rebuilding GIMP-2.10.14. If anyone needs to remove GIMP-2.10.16 from their system ( *and* has it installed in /usr ), I wrote a script: http://anduin.linuxfromscratch.org/~renodr/remove-gimp.sh Another word of caution: It also removes *.la files by running the script that is in "About Libtool Archive (.la) files", and runs 'ldconfig -v' after removing the files that GIMP installs from the system. I originally developed this script for myself, and I almost never remove my *.la files unless forced to, so I figured that it would be an excellent opportunity to slip that command in. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] gimp-2.10.16 : Do not use
On 2/21/20 5:29 PM, Ken Moffat via blfs-dev wrote: A few hours ago I put gimp-2.10.16 into the book, after giving it some short tests re photo editing, help, and a brief test of using brushes. Now that I'm checking my mailboxes I found the following on gimp-dev: | On 2/21/20 8:57 PM, Ell via gimp-developer-list wrote: | > Hey, we're doing a ninja 2.10.18 release. There was an ugly data | > corruption bug in 2.10.16 | > (https://gitlab.gnome.org/GNOME/gimp/issues/4643) -- good thing we | > didn't announce it yet, huh? :) We want to do it later today or | > tomorrow (more likely). Just a heads up, if you have some last-minute | > fixes to push. | | Well, this wasn't actually supposed to go to the list, but whatever. If | anyone is already using 2.10.16, you might want to revert to 2.10.14 for | now. There should be a new release soon. That reply (also from Ell) suggests the release might take a little longer. For the moment, I'll wait and see, Meanwhile, I advise people not to use 2.10.16. ĸen Just a heads up for you guys, If you downgrade to GIMP-2.10.14, you're going to need to completely remove all of the files from GIMP-2.10.16. Otherwise you will end up with a version mismatch error for libgimp.so when trying to launch GIMP. Here's what I did: - Attempted to launch GIMP-2.10.14 and got the Version Mismatch error when trying to launch GIMP - Removed the files like so: sudo rm -rfv /usr/lib/libgimp* /usr/bin/gimp* /etc/gimp /usr/include/gimp-2.0 /usr/share/gimp /usr/share/gtk-doc/html/libgimp* /usr/lib/gimp This should remove the GIMP libraries, headers, configuration files in /etc, the binaries, and the items it specifically puts in /usr/share (with the exception of the desktop file because I know that will remain the same). I've since begun rebuilding GIMP-2.10.14. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Need help testing dovecot and exim for BLFS-9.1
On 2/21/20 12:19 PM, Bruce Dubbs via blfs-dev wrote: I need to get dovecot and exim tested for release. I can build them, but do not want to install them over my existing system. Both build with caveats, so if someone can test in a 9.1 environment, I can update tag them. Caveats. dovecot: The sed sed -e "s;#include ;&\n#include ;" \ -i src/auth/mycrypt.c can be simplified sed -e "/unistd.h/a #include ;" \ -i src/auth/mycrypt.c exim: the sed expression: -e '/# SUPPORT_TLS=yes/s,^#,,' does not match anything in src/EDITME. It's harmless, but should probably be removed. Any help testing will be appreciated. -- Bruce I've got experience in testing Dovecot, but my ability to test Exim would be limited because I already have a MTA installed. I'll do Dovecot -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Note in xf86-video-nouveau
Hi folks, [Note] Note This is a development version of the Nouveau driver which is needed to build properly with the latest xorg-server. I noticed that we have a note like the above in xf86-video-nouveau, but we seem to be using an officially released version. Can this be removed, or is there a reason why it's still there? - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] LSB-Tools: symlink creation no longer needed
On 2/16/20 5:21 AM, Bruce Dubbs via blfs-dev wrote: On 2/16/20 12:01 AM, Douglas R. Reno via blfs-dev wrote: Hi folks, I know that we're in a semi-package freeze right now, so I wanted to ask a question about a package that's already been tagged. root [ /sources/LSB-Tools-0.6 ]# ln -sv /usr/lib/lsb/install_initd /usr/sbin ln: failed to create symbolic link '/usr/sbin/install_initd': File exists This is after running "python3 setup.py install --optimize=1" I don't think that the ln commands to create the symlink are needed anymore: ln -sv /usr/lib/lsb/install_initd /usr/sbin && ln -sv /usr/lib/lsb/remove_initd /usr/sbin Are there any objections to me removing them? I think the links are still needed for a first install. My log shows them being created. we could add -f to the ln command to avoid the error message if reinstalling. -- Bruce This was a first install though, on my new system. I think it might be better to do "sfv" though - do you have that in your script? -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] LSB-Tools: symlink creation no longer needed
Hi folks, I know that we're in a semi-package freeze right now, so I wanted to ask a question about a package that's already been tagged. root [ /sources/LSB-Tools-0.6 ]# ln -sv /usr/lib/lsb/install_initd /usr/sbin ln: failed to create symbolic link '/usr/sbin/install_initd': File exists This is after running "python3 setup.py install --optimize=1" I don't think that the ln commands to create the symlink are needed anymore: ln -sv /usr/lib/lsb/install_initd /usr/sbin && ln -sv /usr/lib/lsb/remove_initd /usr/sbin Are there any objections to me removing them? - Doug -- 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
On 2/15/20 9:51 PM, Bruce Dubbs via blfs-dev wrote: 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? As far as I know, it is used by nm-applet. At one time, I remember gparted being able to use polkit-gnome as well. I think moving it to a more generic place (maybe Chapter 12, System Utilities) would be a smarter option, probably after the release. 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 do not have a problem moving n-d to Chapter 12, System Utilities. I don't have a problem with this either, but I will note that the dependencies for xfce4-notifyd are a lot more complex (it looks like it needs xfce4-panel and libxfce4ui, which with xfce4-panel is a large chunk of XFCE that you'd have to build in order to use it. I think moving notification-daemon to Chapter 12 would be start, but I'd vote for a change like that after release. -- 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
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) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] openjdk-12.0.2 + make-4.3 Version 2020-02-07
On 2020-02-09 11:21, Pierre Labastie via blfs-dev wrote:
Le 09/02/2020 à 18:02, Ken Moffat via blfs-dev a écrit :
On Sun, Feb 09, 2020 at 03:37:08AM -0500, Jean-Marc Pigeon via
blfs-dev wrote:
Hello,
I have strong indication openjdk-12.0.2+10 can NOT be build
while make-4.3 is installed (build possible downgrading to
make-4.2.1)
;---
make[3]: *** No rule to make target '/home/jmp/rpmbuild/BUILD/jdk12u-
jdk-12.0.2+10/build/linux-x86_64-server-release/make-
support/vardeps/make/ReleaseFile.gmk/create-info-file.vardeps',
needed
by '/home/jmp/rpmbuild/BUILD/jdk12u-jdk-12.0.2+10/build/linux-x86_64-
server-release/jdk/release'. Stop
;---
Seems the problem is the same trying to build openjdk-13.0.2+8
Unfortunately "goggling" give no echo about this problem...
Could someone in the list be in position to do this test
and confirm/discard finding??
Many thanks.
I googled for openjdk make-4.3 and that pointed me to
https://bugs.openjdk.java.net/browse/JDK-8237879
and at the bottom of that is a link to the commit:
https://github.com/openjdk/panama-foreign/commit/af5c725b
Being github, you might have to paste from the browser (i.e. copy
make/common/MakeBase.gmk to {,.orig}, edit the .gmk to make the
changes, and then diff).
You can get a raw patch by adding .patch at the end of the commit sha:
https://github.com/openjdk/panama-foreign/commit/af5c725b.patch
I suggest trying that on 12.0, if it applies, because that is what
we are using.
Sorry for not doing more, I do not have a usable LFS machine at the
moment
Pierre
Hi folks,
Do you want me to take care of fixing this and upgrading to JDK-13?
Additional glibc-2.31 fixes would happen as well because my 32-bit
system is now running it (easy to test the seccomp fixes for systemd).
- Doug
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Fixing alsa-tools to work with alsa-lib-1.2.1.2
On 1/10/20 2:20 PM, Douglas R. Reno via blfs-dev wrote: Hi folks, Earlier today, I attempted to build alsa-tools on my 32-bit machine. There's a few utilities in there that are used for patching the firmware for the HD Audio cards, as well as those which have proper Sound Blaster emulation built in (this system has a Creative chipset that communicates through HD Audio. I think this also affects users of newer Creative Sound Blaster cards as well, including those released last year since those most definitely use HD Audio). It seems that in alsa-lib-1.2.1.2, the ALSA developers merged the Linux 5.4 sound API headers, and it has caused a lot of breakage in alsa-tools (and potentially other ALSA users as well). On December 28th, Jean-Marc Pigeon posted to -dev about breakage in alsa-tools. I used the sed that he provided in that email, and the build got a bit farther, but then crashed on ld10k1: In file included from /usr/include/alsa/asoundlib.h:54, from ld10k1_fnc.c:33: /usr/include/alsa/pcm.h:281:3: note: previous declaration of ‘snd_pcm_format_t’ was here 281 | } snd_pcm_format_t; | ^~~~ In file included from /usr/include/alsa/sound/emu10k1.h:27, from ld10k1_fnc.c:35: /usr/include/sound/asound.h:273:23: error: conflicting types for ‘snd_pcm_subformat_t’ 273 | typedef int __bitwise snd_pcm_subformat_t; | ^~~ In file included from /usr/include/alsa/asoundlib.h:54, from ld10k1_fnc.c:33: /usr/include/alsa/pcm.h:288:3: note: previous declaration of ‘snd_pcm_subformat_t’ was here 288 | } snd_pcm_subformat_t; | ^~~ In file included from /usr/include/alsa/sound/emu10k1.h:27, from ld10k1_fnc.c:35: /usr/include/sound/asound.h:304:23: error: conflicting types for ‘snd_pcm_state_t’ 304 | typedef int __bitwise snd_pcm_state_t; | ^~~ In file included from /usr/include/alsa/asoundlib.h:54, from ld10k1_fnc.c:33: /usr/include/alsa/pcm.h:313:3: note: previous declaration of ‘snd_pcm_state_t’ was here 313 | } snd_pcm_state_t; | ^~~ In file included from /usr/include/alsa/sound/emu10k1.h:27, from ld10k1_fnc.c:35: /usr/include/sound/asound.h:837:23: error: conflicting types for ‘snd_ctl_elem_type_t’ 837 | typedef int __bitwise snd_ctl_elem_type_t; | ^~~ In file included from /usr/include/alsa/asoundlib.h:58, from ld10k1_fnc.c:33: /usr/include/alsa/control.h:88:3: note: previous declaration of ‘snd_ctl_elem_type_t’ was here 88 | } snd_ctl_elem_type_t; | ^~~ In file included from /usr/include/alsa/sound/emu10k1.h:27, from ld10k1_fnc.c:35: /usr/include/sound/asound.h:847:23: error: conflicting types for ‘snd_ctl_elem_iface_t’ 847 | typedef int __bitwise snd_ctl_elem_iface_t; | ^~~~ In file included from /usr/include/alsa/asoundlib.h:58, from ld10k1_fnc.c:33: /usr/include/alsa/control.h:107:3: note: previous declaration of ‘snd_ctl_elem_iface_t’ was here 107 | } snd_ctl_elem_iface_t; | ^~~~ make[2]: *** [Makefile:572: ld10k1-ld10k1_fnc.o] Error 1 make[2]: Leaving directory '/sources/alsa-tools-1.1.7/ld10k1/src' make[1]: *** [Makefile:429: all-recursive] Error 1 make[1]: Leaving directory '/sources/alsa-tools-1.1.7/ld10k1' make: *** [Makefile:304: all] Error 2 There seems to be a lot of conflicting type errors here. For reference, here is the sed that he posted as well as a link to the posting: #to fix problem with __user definition within cxx files sed -i \ -e "/#include/i #define __user" \ hdspconf/src/*.cxx \ hdspmixer/src/*.cxx \ hdsploader/hdsploader.c http://lists.linuxfromscratch.org/pipermail/blfs-dev/2019-December/037059.html I've adapted the sed to include the files in ld10k1/src/*.c as well, but that has made no difference on this. Upon looking upstream, I found many changes to alsa-lib since the 1.2.1.2 release, most of them bugfixes. Three of them in particular stand out: https://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=ae564665ec261cf104de499b1cdda3564070fc65 https://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=75584fe660880b332fbf60dd7968e2ed8b49a38b https://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=59792f467b38d6a4c4dffdb30528f7fb03d23d96 The problem with applying these is the amount of changes involved. The first commit listed above, ae564665, is well over 7,000 lines long, and adds some complete new headers to a new folder called "uapi" and installs them. I've attempted to us
[blfs-dev] Fixing alsa-tools to work with alsa-lib-1.2.1.2
Hi folks, Earlier today, I attempted to build alsa-tools on my 32-bit machine. There's a few utilities in there that are used for patching the firmware for the HD Audio cards, as well as those which have proper Sound Blaster emulation built in (this system has a Creative chipset that communicates through HD Audio. I think this also affects users of newer Creative Sound Blaster cards as well, including those released last year since those most definitely use HD Audio). It seems that in alsa-lib-1.2.1.2, the ALSA developers merged the Linux 5.4 sound API headers, and it has caused a lot of breakage in alsa-tools (and potentially other ALSA users as well). On December 28th, Jean-Marc Pigeon posted to -dev about breakage in alsa-tools. I used the sed that he provided in that email, and the build got a bit farther, but then crashed on ld10k1: In file included from /usr/include/alsa/asoundlib.h:54, from ld10k1_fnc.c:33: /usr/include/alsa/pcm.h:281:3: note: previous declaration of ‘snd_pcm_format_t’ was here 281 | } snd_pcm_format_t; | ^~~~ In file included from /usr/include/alsa/sound/emu10k1.h:27, from ld10k1_fnc.c:35: /usr/include/sound/asound.h:273:23: error: conflicting types for ‘snd_pcm_subformat_t’ 273 | typedef int __bitwise snd_pcm_subformat_t; | ^~~ In file included from /usr/include/alsa/asoundlib.h:54, from ld10k1_fnc.c:33: /usr/include/alsa/pcm.h:288:3: note: previous declaration of ‘snd_pcm_subformat_t’ was here 288 | } snd_pcm_subformat_t; | ^~~ In file included from /usr/include/alsa/sound/emu10k1.h:27, from ld10k1_fnc.c:35: /usr/include/sound/asound.h:304:23: error: conflicting types for ‘snd_pcm_state_t’ 304 | typedef int __bitwise snd_pcm_state_t; | ^~~ In file included from /usr/include/alsa/asoundlib.h:54, from ld10k1_fnc.c:33: /usr/include/alsa/pcm.h:313:3: note: previous declaration of ‘snd_pcm_state_t’ was here 313 | } snd_pcm_state_t; | ^~~ In file included from /usr/include/alsa/sound/emu10k1.h:27, from ld10k1_fnc.c:35: /usr/include/sound/asound.h:837:23: error: conflicting types for ‘snd_ctl_elem_type_t’ 837 | typedef int __bitwise snd_ctl_elem_type_t; | ^~~ In file included from /usr/include/alsa/asoundlib.h:58, from ld10k1_fnc.c:33: /usr/include/alsa/control.h:88:3: note: previous declaration of ‘snd_ctl_elem_type_t’ was here 88 | } snd_ctl_elem_type_t; | ^~~ In file included from /usr/include/alsa/sound/emu10k1.h:27, from ld10k1_fnc.c:35: /usr/include/sound/asound.h:847:23: error: conflicting types for ‘snd_ctl_elem_iface_t’ 847 | typedef int __bitwise snd_ctl_elem_iface_t; | ^~~~ In file included from /usr/include/alsa/asoundlib.h:58, from ld10k1_fnc.c:33: /usr/include/alsa/control.h:107:3: note: previous declaration of ‘snd_ctl_elem_iface_t’ was here 107 | } snd_ctl_elem_iface_t; | ^~~~ make[2]: *** [Makefile:572: ld10k1-ld10k1_fnc.o] Error 1 make[2]: Leaving directory '/sources/alsa-tools-1.1.7/ld10k1/src' make[1]: *** [Makefile:429: all-recursive] Error 1 make[1]: Leaving directory '/sources/alsa-tools-1.1.7/ld10k1' make: *** [Makefile:304: all] Error 2 There seems to be a lot of conflicting type errors here. For reference, here is the sed that he posted as well as a link to the posting: #to fix problem with __user definition within cxx files sed -i \ -e "/#include/i #define __user" \ hdspconf/src/*.cxx\ hdspmixer/src/*.cxx \ hdsploader/hdsploader.c http://lists.linuxfromscratch.org/pipermail/blfs-dev/2019-December/037059.html I've adapted the sed to include the files in ld10k1/src/*.c as well, but that has made no difference on this. Upon looking upstream, I found many changes to alsa-lib since the 1.2.1.2 release, most of them bugfixes. Three of them in particular stand out: https://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=ae564665ec261cf104de499b1cdda3564070fc65 https://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=75584fe660880b332fbf60dd7968e2ed8b49a38b https://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=59792f467b38d6a4c4dffdb30528f7fb03d23d96 The problem with applying these is the amount of changes involved. The first commit listed above, ae564665, is well over 7,000 lines long, and adds some complete new headers to a new folder called "uapi" and installs them. I've attempted to use the standard patch method on these into an alsa-lib extract, and get many rejections. I
[blfs-dev] libxcb test suite needs to be adapted to Check-0.13.0 API
Hi folks,
I was building libxcb a little while ago and noticed some errors from
GCC that seemed to be related to API changes in Check. I found a pull
request upstream
(https://gitlab.freedesktop.org/xorg/lib/libxcb/merge_requests/6/diffs?commit_id=a667ec3e0cf5d9cd1d1715e3fff3328e353fae84)
that contained a fix for this. Here are some of the errors - note that
there are lots of repititons of the same line:
check_public.c:216:20: error: passing argument 2 of ‘suite_add_test’
from incompatible pointer type [-Werror=incompatible-pointer-types]
216 | suite_add_test(s, popcount, "xcb_popcount");
| ^~~~
| |
| const TTest * {aka const struct TTest *}
In file included from check_public.c:4:
check_suites.h:3:36: note: expected ‘TFun’ {aka ‘void (*)(int)’} but
argument is of type ‘const TTest *’ {aka ‘const struct TTest *’}
3 | void suite_add_test(Suite *s, TFun tf, const char *name);
| ~^~
cc1: all warnings being treated as errors
make[3]: *** [Makefile:666: check_public.o] Error 1
make[3]: Target 'check_all' not remade because of errors.
make[3]: Leaving directory '/sources/libxcb-1.13.1/tests'
make[2]: *** [Makefile:1014: check-am] Error 2
make[2]: Leaving directory '/sources/libxcb-1.13.1/tests'
make[1]: *** [Makefile:699: check-recursive] Error 1
make[1]: Leaving directory '/sources/libxcb-1.13.1/tests'
make: *** [Makefile:792: check-recursive] Error 1
I've crafted a couple of seds for this, that allowed the tests to pass:
sed -i "s/TFun tf/const TTest *tt/" tests/check_all.c tests/check_suites.h
sed -i "s/tcase_add_test(tc, tf);/tcase_add_test(tc, tt);/"
tests/check_all.c
Are there any objections to me adding these into the book?
Thank you,
- Doug
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] sqlite: Remove `SQLITE_ENABLE_FTS3_TOKENIZER` from configuration
On 1/3/20 8:35 AM, Paul Menzel via blfs-dev wrote: Dear Beyond Linux From Scratch folks, The configuration instructions for SQLite [1] still enable the two-argument version of the fts3_tokenizer() interface. -DSQLITE_ENABLE_FTS3_TOKENIZER=1 The command explanations do not contain that. CFLAGS="-g -O2 -DSQLITE_ENABLE_FTS3=1 -DSQLITE_ENABLE_FTS4=1 -DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_SECURE_DELETE -DSQLITE_ENABLE_UNLOCK_NOTIFY=1 -DSQLITE_ENABLE_DBSTAT_VTAB=1": Applications such as Firefox require secure delete and enable unlock notify to be turned on. Since firefox-41 the dbstat virtual table and FTS3/4 are also required. The only way to do this is to include them in the CFLAGS. By default, these are set to "-g -O2" so we specify that to preserve those settings. You may, of course, wish to omit the '-g' if you do not wish to create debugging information. For further information on what can be specified see http://www.sqlite.org/compile.html. So, I wonder if that is an oversight, as the SQLite upstream say there are security concerns. SQLITE_ENABLE_FTS3_TOKENIZER This option enables the two-argument version of the fts3_tokenizer() interface. The second argument to fts3_tokenizer() is suppose to be a pointer to a function (encoded as a BLOB) that implements an application defined tokenizer. If hostile actors are able to run the two-argument version of fts3_tokenizer() with an arbitrary second argument, they could use crash or take control of the process. Because of security concerns, the two-argument fts3_tokenizer() feature was disabled beginning with Version 3.11.0 (2016-02-15) unless this compile-time option is used. Version 3.12.0 (2016-03-29) added the sqlite3_db_config(db,SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER,1,0) interface that activates the two-argument version of fts3_tokenizer() for a specific database connection at run-time. Kind regards, Paul Hi Paul, This isn't due to an oversight. In 2016, a ticket was filed named "sqlite-3.11.0 causes error in Thunderbird serarch" (Ticket #7991). In order to get search to work again, we had to add -DSQLITE3_ENABLE_FTS3_TOKENISER=1 to the sqlite CFLAGS. That option became required around Thunderbird-52.5.0. I'll update the command explanations to match that though. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] qt patch missing from repository (version 2019-12-24)
On 12/25/19 4:43 PM, Jean-Marc Pigeon via blfs-dev wrote: Hello According to me qt wayland patch http://www.linuxfromscratch.org/patches/blfs/svn/qt-5.14.0-qtwayland_cursor_fix-1.patch Is missing altogether from site: http://www.linuxfromscratch.org/patches/blfs/svn/ possible? Good evening, The patch wasn't in the proper place at the last render. I've since moved the patch to the proper location, but it will not appear there until the next render. For now, you can fetch the patch from this URL: http://linuxfromscratch.org/patches/downloads/qt/qt-5.14.0-qtwayland_cursor_fix-1.patch - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] KDE and Qt-5.14
On 12/25/19 11:59 AM, spiky0011 via blfs-dev wrote: On 25/12/2019 17:55, Douglas R. Reno via blfs-dev wrote: On 12/25/19 11:52 AM, spiky0011 via blfs-dev wrote: On 24/12/2019 08:20, Pierre Labastie via blfs-dev wrote: Hi, As reported on support, some of KDE frameworks are broken by QT-5.14. I've found upstream fixes, so I am now sure that the fixes are needed. They can be done as sed. I think we should also apply the patch reported by "spiky" on -support to Qt-5.14. I have tested that it applies and builds OK, but I have not tested the cursor yet (need to build the desktop first)... I am not sure how much I can do in the next few days, since I go and visit my family for Christmas. Pierre Hi Pierre FYI just rebuilding qt the patch is not availble at link Hi Spiky, I just submitted the patch to the proper location at r4044, but it might not be correct in the book yet. I believe that happens overnight. Here's a direct link: http://linuxfromscratch.org/patches/downloads/qt/qt-5.14.0-qtwayland_cursor_fix-1.patch By the way, to everyone - Merry Christmas / Happy Holidays! Doug is it the same patch I linked the other day? I'm not sure since I was away for a bit, but the header contains this information: +From 36974955d13578071387695adb13a47be33e4d32 Mon Sep 17 00:00:00 2001 +From: David Edmundson +Date: Thu, 28 Nov 2019 02:31:17 +0100 +Subject: Avoid animating single frame cursors + +Currently to determine if a cursor is animated or not we check the +cursor theme delay. + +This doesn't work in practice as by default many cursor themes have a +delay of 50 set even if they don't animate. + +This comes from xcursorgen which specifies a delay of 50ms if there +isn't anything set in the config. +(https://github.com/freedesktop/xcursorgen/blob/master/xcursorgen.c#L92) + +Given many themes will have a delay we should also check the number of +images in a given cursor. + +In order to do that without a double lookup QWaylandCursor needed to +return the native wl_cursor, not wl_cursor_image and move the relevant +logic. + +Change-Id: Ie782ace8054910ae76e61cab33ceca0377194929 +Reviewed-by: Johan Helsing +--- + src/client/qwaylandcursor.cpp | 12 ++-- + src/client/qwaylandcursor_p.h | 3 +-- + src/client/qwaylandinputdevice.cpp | 16 + 3 files changed, 15 insertions(+), 16 deletions(-) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] KDE and Qt-5.14
On 12/25/19 11:52 AM, spiky0011 via blfs-dev wrote: On 24/12/2019 08:20, Pierre Labastie via blfs-dev wrote: Hi, As reported on support, some of KDE frameworks are broken by QT-5.14. I've found upstream fixes, so I am now sure that the fixes are needed. They can be done as sed. I think we should also apply the patch reported by "spiky" on -support to Qt-5.14. I have tested that it applies and builds OK, but I have not tested the cursor yet (need to build the desktop first)... I am not sure how much I can do in the next few days, since I go and visit my family for Christmas. Pierre Hi Pierre FYI just rebuilding qt the patch is not availble at link Hi Spiky, I just submitted the patch to the proper location at r4044, but it might not be correct in the book yet. I believe that happens overnight. Here's a direct link: http://linuxfromscratch.org/patches/downloads/qt/qt-5.14.0-qtwayland_cursor_fix-1.patch By the way, to everyone - Merry Christmas / Happy Holidays! -- 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
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: 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 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Notes on moving an installation of BLFS to another system
Hi folks,
I just upgraded my workstation from an Intel Core 2 Duo to an AMD Phenom
X4, and I figured I'd share some notes in case anyone else does this
down the line (this is primarily commentary on Intel->AMD). It's a
combination of a narrative and some random thoughts on the process.
First of all, I think some context is appropriate here. The rationale
behind my upgrading systems is that rendering the book would take a long
period of time (5 minutes, now down to 2 minutes and 31 seconds), and
after rebooting this afternoon due to a problem with my UPS, I would
either have windows that wouldn't update/render correctly, or the screen
would flicker anytime that I moved my mouse. This system uses components
from SVN-20190728, and was working fine before restarting - pointing to
a likely hardware problem (just in case, I installed another DE this
afternoon, with my choice being XFCE). This flickering was causing my
left eye to twitch (and I'm blind in my right eye, so limited vision in
the left eye is a huge dealbreaker). While searching for a replacement
graphics card (thanks for the suggestion Bruce) I found a system sitting
on my shelf in my storage room that I had repaired for someone who
refused to pay for it a couple of years ago - an AMD Phenom X4-based HP
EliteDesk.
I know that moving from one CPU type/architecture can be really tough,
especially considering that things are often compiled (GMP/libffi are
recent examples) for the exact processor in use unless specified
otherwise. In my case, since I was using an Intel Core 2 Duo, GMP and
libffi had been compiled for the 'core2duo' architecture.
The next step after moving my hard drives and putting a RAM upgrade in
(there was no way I was living with 4GB of RAM) was to make sure that
the system still booted. Currently, I have an NVIDIA GeForce GT 1030 and
an ASUS Wireless + Bluetooth adapter (although I'm using ethernet,
didn't want to mess with too much). After powering my system up and
getting through GRUB, LFS booted - to almost none of my services
starting. This wasn't a problem though - each one of them mentioned
libffi.so.6.0.4 and illegal operation errors in their logs and
coredumps. Suspects primarily included accounts-daemon, NetworkManager,
and colord.
After that, I made sure that a test compile of Chapter 6 in LFS' build
instructions worked, specifically "echo 'int main(){}' > dummy.c" and
"cc dummy.c". I knew that if this didn't work, there was going to be no
compiling a new version of libffi - most likely because of GMP. I lucked
out in this case, as GMP was working properly. I remember reading
reports on lfs-support a long time ago about GMP causing illegal
operation errors when moving across CPU brands/types like I did here. A
simple recompile of libffi from LFS later, and a quick restart, and I'm
off to the races... except, without a network adapter...
When moving systems, one of the things you always should make sure that
you do is update the network configuration so that you have a working
network interface. I use systemd, but have dhcpcd installed to manage my
network interfaces and have systemd-networkd disabled. This simplifies
my network configuration - a "systemctl disable dhcpcd@enp4s0 &&
systemctl enable dhcpcd@enp3s0 && systemctl start dhcpcd@enp3s0" did the
trick. I did reboot after this because I wanted the rest of my services
to come up properly without having to bring them up manually.
I will note that this system isn't without flaws - it has one major
flaw. GDM is extremely slow. I'm on 3.32 though, and I remember reading
that 3.32 had problems with NVIDIA cards after the Pascal series. I
ended up disabling gdm and bringing up Plasma, my preferred DE (working
dark mode and HiDPI scaling), and that worked fine. My performance is
much better and I have some transparency effects that I wasn't aware
existed. Everything is much more responsive too, and my graphics card's
HDMI-based Audio is working great). A long time ago, we discussed
problems with rust-using applications and CPU architectures - I'm
tempted to say that this is no longer a problem because Firefox and
Thunderbird both started up without a problem.
My point at the end of this email is primarily to remind people that if
you move your BLFS installation to another set of hardware, you should
recompile libffi if you encounter problems with programs giving out
illegal operation errors. One program that is extremely important that
refuses to come up unless you do this is pkttyagent. Recompiling libffi
will fix these problems. Another thing that you should be prepared to
deal with is having to change drive assignments around in /etc/fstab
because the kernel might initialize drives in a different order
depending on your hardware (I plugged my boot drive into SATA0 and my
/home drive into SATA1). On that note, always make sure that you have at
least basic storage drivers built in for your
[blfs-dev] HEADSUP: Deprecation of sys/sysctl.h header
Good afternoon folks, This is more of an observation than anything else, nothing needs to be done yet and I haven't noticed any problems. I have a system running with the kernel 5.4 API headers (my i686 machine), and just built OpenSSH. While building OpenSSH, I noticed the following scrolling across my terminal: renodr [ /sources ]$ cat /mnt/lfs/sources/openssh-8.1p1.log | grep sysctl.h checking for sys/sysctl.h... yes /usr/include/sys/sysctl.h:21:2: warning: #warning "The header is deprecated and will be removed." [-Wcpp] 21 | #warning "The header is deprecated and will be removed." This seems to be because the kernel developers plan to remove the sysctl interface: "The Linux 5.5 kernel is set to finally eliminate the code backing the sysctl system call, which has been deprecated for about a decade and should have no impact on modern systems of any architecture. The Linux sysctl system call has long been deprecated and not advised for use with the sysctl interface being exposed via //proc/sys/ being the preferred means of reading/setting kernel system attributes. The change for Linux 5.5 isn't touching the /proc/sys support but is just about finally removing the system call with the binary interface to sysctl on Linux having been unused now for years -- well, the hope is there are no users left but they admit to possibly needing to reverting the patch should any real users come forward of this system call./"/ /https://www.phoronix.com/scan.php?page=news_item=Linux-5.5-Kills-SYSCTL-SYSCALL/ //http://lkml.iu.edu/hypermail/linux/kernel/1911.3/02404.html For some reason, at minimum, OpenSSH uses this header. Hopefully a future release of OpenSSH before Linux-5.5 comes out will handle this. - Doug -- 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
On 12/16/19 2:18 PM, Pierre Labastie via blfs-dev wrote: Sent from my WIKO WIM Le 16 déc. 2019 16:47, Xi Ruoyao via blfs-dev a écrit : 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. If I trust the message, it comes from "gnome-session-binary". I remember once I upgraded gnome-desktop then seen "Oh no" from GDM. Then I fixed that by rebuilding GDM. I've tried that, and even built a fresh system, but nothing worked. Note that I can start gnome from command line, with startx and "exec gnome-session" in .xinitrc. Hi Pierre, I've traced it down to a problem in elogind, and have begun working on a fix. elogind is only setup to read one line from the session data in /run/systemd/sessions. GNOME was using the improper behavior previously, and was fixed as part of gnome-session-3.34.2. elogind has to be adapted to read more than the first line of that file: "# This is private data. Do not parse." Won't result in a valid UID after all :-) -- 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
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. But I begin to be fed up of those repeated attempts from gnome folks to prevent using their desktop without systemd. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
