[blfs-dev] Fwd: BLSF-10.1: polkit / shadow; nspr
Forwarded Message Subject: BLSF-10.1: polkit / shadow; nspr Date: Thu, 22 Apr 2021 12:23:51 +0200 From: Rainer Fiebig To: Bruce Dubbs Hi! polkit / shadow *** The following command doesn't work, the directory /etc/polkit-1 is *not* being created: useradd -c "PolicyKit Daemon Owner" -d /etc/polkit-1 -u 27 \ -g polkitd -s /bin/false polkitd That's obviously due to a change in shadow, as its manpage (-4.8.1) now states that - if missing - the homedir will *not* be created. For version 4.6 it says the opposite. Apart from that I suggest that --enable-libelogind=no be mentioned in the config-options for polkit because otherwise it won't build if elogind is not installed (as in my case). nspr The following line doesn't work, bash-5.1 complains about a missing ']': $([ $(uname -m) = x86_64 ] && echo --enable-64bit) This does work, however: $( if [[ $(uname -m) == x86_64 ]]; then echo "--enable-64bit"; fi ) The first line does work in bash-4.4.18, though. Rainer -- The truth always turns out to be simpler than you thought. Richard Feynman signature.asc Description: PGP signature -- 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-b...@lists.linuxfromscratch.org: [blfs-book] RFC: Adding advisories chapter to the editor's guide.]
On 4/19/21 1:09 PM, Ken Moffat via blfs-dev wrote: On Sun, Apr 18, 2021 at 09:44:19PM -0500, Bruce Dubbs via blfs-dev wrote: On 4/18/21 5:36 PM, Ken Moffat via blfs-dev wrote: - Forwarded message from Ken Moffat via blfs-book - Arghh - I sent this to -book. My first public version of new chapter 7 on how to update security advisories is now rendered at https://rivendell.linuxfromscratch.org/~ken/lfs-editors-guide/ and the cleaned-up patches which created it are at https://rivendell.linuxfromscratch.org/~ken/lfs-editors-guide-patches/ As of this message, the changes are not on rivendell. They are in my area - this is an RFC. Links to the rendered book, and the patches that created it, are above. As I said in my original reply to the requests for this on -book, I expect (at least) differences of opinion about my wording, and it is possible that people may disagree about the content. OK, but there is no mention of the errata pages for releases. Shouldn't those be integrated into the security advisories? -- 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] [blfs-b...@lists.linuxfromscratch.org: [blfs-book] RFC: Adding advisories chapter to the editor's guide.]
On 4/18/21 5:36 PM, Ken Moffat via blfs-dev wrote: - Forwarded message from Ken Moffat via blfs-book - Arghh - I sent this to -book. Date: Sun, 18 Apr 2021 23:03:22 +0100 From: Ken Moffat via blfs-book To: blfs-b...@lists.linuxfromscratch.org Cc: Ken Moffat Subject: [blfs-book] RFC: Adding advisories chapter to the editor's guide. Reply-To: BLFS Book Maintenance List User-Agent: Mutt/2.0.6 (2021-03-06) X-Clacks-Overhead: GNU Terry Pratchett Message-ID: My first public version of new chapter 7 on how to update security advisories is now rendered at https://rivendell.linuxfromscratch.org/~ken/lfs-editors-guide/ and the cleaned-up patches which created it are at https://rivendell.linuxfromscratch.org/~ken/lfs-editors-guide-patches/ (I've also loaded everything I currently had at higgs). I have included comments on making symlinks so that you can check all the links locally before committing - in my own case, the rendered books are in /sources/books/ (versioned as sysv and systemd) but the advisories are in my lfswww repo at ~/ so I have symlinks from /sources/books/: blfs-advisories : to ~/.../lfswww/blfs/advisories lfs-advisories : to ~/.../lfswww/lfs/advsories lfs/view has links to current development and 10.1 LFS books, in my case development now goes to lfs-book-git. blfs to ../blfs-advisories (this fixes the link for consolicated.html when approached from the lfs advisories). view : links for the current and 10.1 BLFS books (in my case svn now goes to blfs-book-sysv). There are two items I regard as outstanding, apart from whatever people pick up when reviewing this: 1. I'd still like some replies to my post about restarting things which use OpenSSL after upgrading it, since I think that not all of our users will appreciate this needs to be done. 2. For the moment, where a vulnerability is late in coming to light and we have already both moved to a newer version, and then made a release, we do not currently mention it (on the grounds that users keeping up to date with addressing the vulnerabilities which concern them will have already read the advisories for the past release). I don't see any easy way of fixing this - if we spam the -dev and -support lists to say 'BTW - new vulnerability in old flac-3.2 has now come to light, see addition to the 10.0 advisories' that will be messy and also we do not report current advisories like that. (Yes, Doug, I thought omitting these was the way to go, but I now think it opens a hole in the process.) See the "In theory ..." paragraph of the Introduction (section 7.1)." As of this message, the changes are not on rivendell. You need to git clone g...@git.linuxfromscratch.org:lfs-editor-guide.git \ lfs-editor-guide.git Be sure to update the date and changelog as usual. Make the changes there and git push. The book should be automatically rebuilt and available are at https://rivendell.linuxfromscratch.org/lfs/LFS-EDITORS-GUIDE.html -- 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] Failure commiting to blfs-book
On 4/14/21 6:24 PM, Tim Tassonis via blfs-dev wrote: Hi all When trying to push my changes to git, I got following error: timtas@dalglish:~/src/blfs-git$ git commit -a [trunk 8355679be] Upgrade to curl-7.76.1. 4 files changed, 15 insertions(+), 4 deletions(-) timtas@dalglish:~/src/blfs-git$ git push fatal: remote error: access denied or repository not exported: /blfs.git I cloned the repo using: git clone git://git.linuxfromscratch.org/blfs.git blfs-git git remote shows: timtas@dalglish:~/src/blfs-git$ git remote -v origin git://git.linuxfromscratch.org/blfs.git (fetch) origin git://git.linuxfromscratch.org/blfs.git (push) Anybody got an idea what I did wrong? Check https://rivendell.linuxfromscratch.org/lfs/LFS-EDITORS-GUIDE.html#ch02-gitssh You need to checkout as g...@git.linuxfromscratch.org:blfs.git blfsbook not git: which is for non-editors. -- 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] 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? No policy, but IMO autotools is a PITA. It adds .la files that we don't need and sometimes get in the way and is difficult to understand. The tools were developed to handle things like solaris, vms, windows, etc in addition to other Unixes. cmake is more modern and cleaner. -- 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] Apache Server Side Includes
On 3/28/21 5:59 PM, Bruce Dubbs wrote: I'm trying to get Apache SSIs to work. I am looking at http://httpd.apache.org/docs/current/howto/ssi.html and http://httpd.apache.org/docs/current/mod/mod_include.html Testing a default apache install, I created a simple html page according to the above in the document root directory: It works! Date: In httpd.conf I added: LoadModule include_module /usr/lib/httpd/modules/mod_include.so and changed the following fragment: #Options Indexes FollowSymLinks Options Indexes FollowSymLinks Includes AllowOverride None Require all granted and restarted apache. But using the browser to load the file does not execute the SSI echo command. What am I missing? Doesn't it always work that way. I figured it out. I needed to add AddType text/html .shtml AddOutputFilter INCLUDES .shtml and rename the test page with a .shtml extention. Now, does anyone know why I shouldn't use AddOutputFilter INCLUDES .html and process all pages with includes? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Apache Server Side Includes
I'm trying to get Apache SSIs to work. I am looking at http://httpd.apache.org/docs/current/howto/ssi.html and http://httpd.apache.org/docs/current/mod/mod_include.html Testing a default apache install, I created a simple html page according to the above in the document root directory: It works! Date: In httpd.conf I added: LoadModule include_module /usr/lib/httpd/modules/mod_include.so and changed the following fragment: #Options Indexes FollowSymLinks Options Indexes FollowSymLinks Includes AllowOverride None Require all granted and restarted apache. But using the browser to load the file does not execute the SSI echo command. What am I missing? -- 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] efibootmgr url ?
On 3/24/21 3:25 PM, Wayne Blaszczyk via blfs-dev wrote: On Wed, 2021-03-24 at 12:50 -0500, Douglas R. Reno via blfs-dev wrote: 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 https://github.com/rhboot/efibootmgr/archive/17/efibootmgr-17.tar.gz works for me. Thanks Wayne. That looks like a better URL. -- 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] BLFS 10.0 systemd-units Broken Link
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 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Couple of X Window System oddities
On 3/8/21 8:03 AM, Pierre Labastie via blfs-dev wrote: On Mon, 2021-03-08 at 19:49 +0800, Kevin Buckley via blfs-dev wrote: 2) Installation of intel-vaapi-driver appears to unpack the intel-vaapi-driver sources into the libva directory. Does it need to be installed from within the libva source directory? I'd have thought one would have cd-d back up out of the libva dir? Well, I'm responsible for this... It does not hurt, and it allows to have only one directory to remove instead of two after building... It's this way for all the pages with two packages on them (see sassc for example)(I hate those pages, they just show our laziness). I do not think it is laziness. Some apps just package their code into two packages and it doesn't really make sense to install one and not the other. Combining those apps into one page is the logical thing to do to make things easier for the user. 3) I also noted that many of the X Window System package instructions (although I think it's a BLFS wide thing) follow this form : Installation of package Install package by running the following commands: ./configure $XORG_CONFIG && make This package does not come with a test suite. Now, as the root user: make install I'd like to suggest that the "Install" sentence there should be replaced by "Build package by running ..." as that's what the combined configure+make commands actually do and that the "Now, as the root user:" becomes "As the root user, install the package as follows:" as that is what the commands to be done as the root user do. Well, I'm not a native English speaker, so I might be wrong, but I understand the first sentence is for all what follows, including the "Now, as the root user" part. that is correct. -- 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] 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. Adding comments to any ticket by anyone is appropriate. We do restrict who can do that due to the potential for spam, but editors are certainly welcome. -- 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] New maintainer for URI (Perl module)
On 3/2/21 5:36 AM, Ryan Marsaw via blfs-dev wrote: Hello. It appears that the URI perl module has a new maintainer. Version 5.08 of the URI module was released a couple of days ago, but is not listed at the site referenced in BLFS. A search at metacpan.org shows that the download location is here: https://cpan.metacpan.org/authors/id/E/ET/ETHER/URI-5.08.tar.gz I believe that the URL for this module should be updated on the BLFS page. Thanks. I created a ticket so we don't forget. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] LFS and BLFS Version 10.1 are released
The Linux From Scratch community is pleased to announce the release of LFS Version 10.1, LFS Version 10.1 (systemd), BLFS Version 10.1, and BLFS Version 10.1 (systemd). This release is a major update to both LFS and BLFS. The LFS release includes updates to glibc-2.33, and binutils-2.36.1. A total of 40 packages have been updated. Changes to text have been made throughout the book. The Linux kernel has also been updated to version 5.10.17. The BLFS version includes approximately 1000 packages beyond the base Linux From Scratch Version 10.0 book. This release has over 850 updates from the previous version in addition to numerous text and formatting changes. Thanks for this release goes to many contributors. Notably: Douglas Reno Pierre Labastie Ken Moffat Thomas Trepl Tim Tassonis Xi Ruoyao DJ Lucas You can read the books online[0]-[3], or download[4]-[7] to read locally. Please direct any comments about this release to the LFS development team at lfs-...@linuxfromscratch.org or blfs-...@linuxfromscratch.org. Registration for the mailing lists is required to avoid junk email. -- Bruce Dubbs LFS [0] http://www.linuxfromscratch.org/lfs/view/10.1/ [1] http://www.linuxfromscratch.org/blfs/view/10.1/ [2] http://www.linuxfromscratch.org/lfs/view/10.1-systemd/ [3] http://www.linuxfromscratch.org/blfs/view/10.1-systemd/ [4] http://www.linuxfromscratch.org/lfs/downloads/10.1/ [5] http://www.linuxfromscratch.org/blfs/downloads/10.1/ [6] http://www.linuxfromscratch.org/lfs/downloads/10.1-systemd/ [7] http://www.linuxfromscratch.org/blfs/downloads/10.1-systemd/ -- 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 couple of Mesa switches need changing
On 2/27/21 4:39 PM, Ryan Marsaw via blfs-dev wrote: Hello. In the Mesa package there are -Dvalgrind=false and -Dlibunwind=false Both of these switches give out a warning that "false" is deprecated in favour of "disabled". It's not a big deal at the moment, but these two switches might give an error in a future build. Thanks for pointing that out. I will make that change. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Final call for changes before LFS/BLFS 10.1 release
We are about ready to release LFS/BLFS 10.1. All tickets have been closed and all packages have been tested using the current instructions in the books. That said, there are probably issues that still need to be addressed. If LFS is printed out on paper, it is about 300 pages. If BLFS is printed out paper, it is over 2000 pages. This is the last call for change proposals before the books are released on Monday, March 1st. All proposals will be considered, but major changes probably will need to be delayed until the next cycle. However, minor changes can be done now. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] LFS-10.1-rc1 is released
The Linux From Scratch community announces the release of LFS Version 10.1-rc1. It is a preliminary release of LFS-10.1. The Linux From Scratch community announces the release of LFS Version 10.1-rc1. It is a preliminary release of LFS-10.1. Major changes include toolchain updates to binutils-2.36.1 and glibc-2.33. In total, 40 packages were updated since the last release. Changes to the text have also been made throughout the book. The Linux kernel has also been updated to version 5.10.17. We encourage all users to read through this release of the book and test the instructions so that we can make the final release as good as possible. You can read the book online [0], or download [1] to read locally. In coordination with this release, a new version of LFS using the systemd package is also being released. This package implements the newer systemd style of system initialization and control and is consistent with LFS in most packages. You can read the systemd version of the book online [2], or download [3] to read locally. -- Bruce [0] http://www.linuxfromscratch.org/lfs/view/10.1-rc1/ [1] http://www.linuxfromscratch.org/lfs/downloads/10.1-rc1/ [2] http://www.linuxfromscratch.org/lfs/view/10.1-systemd-rc1/ [3] http://www.linuxfromscratch.org/lfs/downloads/10.1-systemd-rc1/ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Gparted page seem to have outdated information
On 2/1/21 5:46 PM, Tim Tassonis via blfs-dev wrote: Hi all I just installed gparted for the first time as in the SVN book (version 1.2.0) and it seems that the part about root privileges seems to be outdated. I installed gparted without any helper stuff and it seems that the provided org.gnome.gparted.policy already does the trick: when I call gparted, it asks me about an admin user and after I enter the password, gparted starts just fine. ps shows that it runs under root: timtas@lfsda0:~/src/lgl/src/lgl-2.5/desk/093-gparted$ ps -ef |grep parted timtas 19549 19445 0 00:35 ? 00:00:00 /bin/sh /opt/X11/bin/gparted root 19552 19549 0 00:35 ? 00:00:00 /bin/sh /opt/X11/bin/gparted root 19578 19552 1 00:36 ? 00:00:09 /opt/X11/sbin/gpartedbin gparted also links against dbus/elogind, which is not listed as a dependency in the book. I can't confirm what you found because the very infrequent times I've run gparted I just use sudo from the command line. However, gparted does require gtkmm->gtk3->libepoxy->mesa->xorg libraries->elogind (recommended) Can anybody confirm this? I can update the page, if nobody else wants to. If you get someone else to confirm, go ahead and make the change. -- 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] Security Advisories, v2 - revised prototypes
On 1/31/21 7:57 AM, Ken Moffat via blfs-dev wrote: Current links: 2. The revised details for 10.0 are at http://www.linuxfromscratch.org/blfs/advisories/10.0.html with short summaries of the issue / what to do, and links to fuller details on the consolidated page. I have not been following this closely but I took a look today. I have a question and a suggestion. The entries have numbers associated with them like: OpenSSL (LFS) 10.0-005 A high severity vulnerability was found in OpenSSL. To fix this, update to OpenSSL-1.1.1i or later. 10.0-999 -- What is the significance of the -005 above? I suppose that the 10.0 refers to BLFS-10.0, but that should probably be explicit. Slightly more explanation of the layout will help first time viewers. Also a suggestion: For each entry, preface it with the date the entry was added to the page. For instance: [2021-01-31] A high severity vulnerability... -- 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] 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. I'm OK with this in general, but we are two weeks from package freeze for 10.1. After that is released we are planning on migrating the LFS host to a new location and other major changes to the site. I think this would be a good place to roll in this change with the other changes. -- 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] minor issue on sane page
On 1/22/21 3:59 AM, Tim Tassonis via blfs-dev wrote: Hi all SANE-1.0.29 seems to link against elogind when present and not specifically told to not do so by specifying --with-systemd=no Since I don't know what the consequences of elogind support for sane are, I did set that. Maybe one then needs some polkit/dbus magic and the whole group stuff becomes obsolete? I suppose it makes a difference for how the system is being used. In my case, I'm the only one using sane so the permissions per seat are really not relevant. In a large system with many users, it might be. -- 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] 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. -- 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] Errors accessing wiki.linuxfromscratch.org
On 1/12/21 9:03 AM, Ken Moffat via blfs-dev wrote: On Tue, Jan 12, 2021 at 09:11:47AM +0100, Pierre Labastie via blfs-dev wrote: On Tue, 2021-01-12 at 08:50 +0100, Tim Tassonis via blfs-dev wrote: Hi all Since a couple of days, I'm experiencing connect issues to wiki.linuxfromscratch.org. Is this a known issue, or is the problem on my side? I have the same problems (I guess they are the same): very slow, and I get disconnected before being able to finish writing a comment, if by chance the connection procedure finishes. Other services on higgs seem to run ok now (svn, other parts of the web site, mail, ssh) Pierre It's been the same here for a couple of weeks on the days when I've been using it. But occasionally ok. Yes. That is the impetus for a new server. It's a SW issue associated with the base system, but everything needs to be updated. -- 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] icewm-2.0.0 fails to configure with the book's commands
On 1/6/21 10:56 AM, Tim Tassonis via blfs-dev wrote: On 1/6/21 5:38 PM, Bruce Dubbs via blfs-dev wrote: On 1/6/21 10:27 AM, Tim Tassonis via blfs-dev wrote: On 1/6/21 5:14 PM, Bruce Dubbs via blfs-dev wrote: On 1/6/21 9:58 AM, Tim Tassonis via blfs-dev wrote: Compile works for me with: -DCONFIG_GDK_PIXBUF_XLIB=ON \ -DCONFIG_IMLIB2=OFF \ CONFIG_GDK_PIXBUF_XLIB does not turn off CONFIG_IMLIB2 by itself and will still give an error. Is it ok if I update the page accordingly? I'm on 10.0 up until here, now! Ken has BLFS ticket #14437. Best to let him fix the page. Ooops, I already did it, as icewm built and ran fine with those changes, and I though people might be sleeping. And maybe because I was so proud to finally have made it up until here with my new system. Anyway, one could of course still put in imlib2 as a optional dependency and add some command explanation, I really only fixed the defect with my changes. That's OK. Ken closed the ticket. Well, I did... OK. If Ken thinks it necessary, he can reopen it. -- 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] icewm-2.0.0 fails to configure with the book's commands
On 1/6/21 10:27 AM, Tim Tassonis via blfs-dev wrote: On 1/6/21 5:14 PM, Bruce Dubbs via blfs-dev wrote: On 1/6/21 9:58 AM, Tim Tassonis via blfs-dev wrote: Compile works for me with: -DCONFIG_GDK_PIXBUF_XLIB=ON \ -DCONFIG_IMLIB2=OFF \ CONFIG_GDK_PIXBUF_XLIB does not turn off CONFIG_IMLIB2 by itself and will still give an error. Is it ok if I update the page accordingly? I'm on 10.0 up until here, now! Ken has BLFS ticket #14437. Best to let him fix the page. Ooops, I already did it, as icewm built and ran fine with those changes, and I though people might be sleeping. And maybe because I was so proud to finally have made it up until here with my new system. Anyway, one could of course still put in imlib2 as a optional dependency and add some command explanation, I really only fixed the defect with my changes. That's OK. Ken closed the ticket. -- 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] icewm-2.0.0 fails to configure with the book's commands
On 1/6/21 9:58 AM, Tim Tassonis via blfs-dev wrote: Compile works for me with: -DCONFIG_GDK_PIXBUF_XLIB=ON \ -DCONFIG_IMLIB2=OFF \ CONFIG_GDK_PIXBUF_XLIB does not turn off CONFIG_IMLIB2 by itself and will still give an error. Is it ok if I update the page accordingly? I'm on 10.0 up until here, now! Ken has BLFS ticket #14437. Best to let him fix the page. -- 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] Why do we patch polkit for elogind ?
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: Hi Guys, some of you may have noticed that I have an aversion to gtk-doc (I'm getting over it). This was triggered by occasional uses of autoreconf now needing gtkdocize. That first hit me in polkit with the patch for elogind, but my memory suggested that the patch has in the past been added or rolled forward a little after updates to polkit. From reading the patch that introduced gtkdocize in autoconf [1], it appears that gtkdocize is not called if the -i (--install) flags is not passed. That flag is not needed for polkit. We might want to check whether it is really needed for the other packages that use autoreconf. Pierre Interesting, but I'm not sure I can check that throughout - I've checked plain "does autoreconf work to produce a configure script" on several packages where I lack the dependencies to actually build them. Just checking all packages, the following are present: networking/netprogs/cifsutils.xml: autoreconf -fiv networking/netlibs/libnsl.xml: autoreconf -fi x/lib/clutter.xml: autoreconf -f -i x/lib/cairo.xml: autoreconf -fiv postlfs/filesystems/reiser.xml:autoreconf -fiv postlfs/security/volume_key.xml: autoreconf -fiv postlfs/security/polkit.xml: autoreconf -fi postlfs/security/tripwire.xml: autoreconf -fi multimedia/libdriv/libmad.xml: autoreconf -fi general/graphlib/sassc.xml:autoreconf -fi general/graphlib/libraw.xml: autoreconf -fiv general/genlib/telepathy-glib.xml: autoreconf -fiv general/genlib/libunique.xml: autoreconf -fi general/genlib/libgrss.xml:autoreconf -fiv general/genlib/exempi.xml: autoreconf -fiv general/genlib/libpaper.xml: autoreconf -fi general/genutils/gtk-doc.xml: autoreconf -fiv pst/sgml/sgml-common.xml: autoreconf -f -i xsoft/other/tigervnc.xml: autoreconf -fiv I didn't check the individual pages, but perhaps they all should use -fv. We would need to do a test build at least though make to ensure the instructions still work. -- 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] 2020-09-03" Pango-1.46.0: Cairo is "Recommended" but seems to be Required
On 1/2/21 6:04 PM, Kevin Buckley via blfs-dev wrote: On Sun, 3 Jan 2021 at 03:04, Pierre Labastie via blfs-dev wrote: Looking in more depth, normally, according to meson.build, the dependency on cairo is not required, even for 1.46. So it should be able to compile if cairo is not available. Also, I've grep'ed for "run.*time" in the source directory, and there is no sentence containing cairo and runtime or run-time or "run time"... What is the error message exactly? The tail-end of the meson output is Found pkg-config: /usr/bin/pkg-config (0.29.2) Using 'PKG_CONFIG_PATH' from environment with value: '/opt/Xorg/lib/pkgconfig:/opt/Xorg/share/pkgconfig' Run-time dependency glib-2.0 found: YES 2.64.4 Using 'PKG_CONFIG_PATH' from environment with value: '/opt/Xorg/lib/pkgconfig:/opt/Xorg/share/pkgconfig' Run-time dependency gobject-2.0 found: YES 2.64.4 Using 'PKG_CONFIG_PATH' from environment with value: '/opt/Xorg/lib/pkgconfig:/opt/Xorg/share/pkgconfig' Run-time dependency gio-2.0 found: YES 2.64.4 Using 'PKG_CONFIG_PATH' from environment with value: '/opt/Xorg/lib/pkgconfig:/opt/Xorg/share/pkgconfig' Run-time dependency fribidi found: YES 1.0.9 Found CMake: /usr/bin/cmake (3.18.1) Run-time dependency libthai found: NO (tried pkgconfig and cmake) Using 'PKG_CONFIG_PATH' from environment with value: '/opt/Xorg/lib/pkgconfig:/opt/Xorg/share/pkgconfig' Run-time dependency harfbuzz found: YES 2.7.1 Using 'PKG_CONFIG_PATH' from environment with value: '/opt/Xorg/lib/pkgconfig:/opt/Xorg/share/pkgconfig' Run-time dependency fontconfig found: YES 2.13.1 Message: fontconfig has FcWeightFromOpenTypeDouble: YES Using 'PKG_CONFIG_PATH' from environment with value: '/opt/Xorg/lib/pkgconfig:/opt/Xorg/share/pkgconfig' Run-time dependency freetype2 found: YES 23.2.17 Using 'PKG_CONFIG_PATH' from environment with value: '/opt/Xorg/lib/pkgconfig:/opt/Xorg/share/pkgconfig' Run-time dependency xft found: YES 2.3.3 Using 'PKG_CONFIG_PATH' from environment with value: '/opt/Xorg/lib/pkgconfig:/opt/Xorg/share/pkgconfig' Run-time dependency xrender found: YES 0.9.10 Run-time dependency cairo found: NO (tried pkgconfig and cmake) Run-time dependency cairo found: NO (tried pkgconfig and cmake) Looking for a fallback subproject for the dependency cairo ../meson.build:381:2: ERROR: Subproject directory not found and cairo.wrap file not found and again, reading the Pango docs suggests that it should be happy with building against the Xft rendering as an alternative to building against the Cairo stuff, which makes it even more confusing. And no, i couldn't find a a "Run-time dependency" string by grep-ing either. I think that's from meson. It may be using cmake files, but I'm not sure. When I look at pango-1.46.2/meson.build, I see: glib_req_version = '>= 2.60' fribidi_req_version = '>= 0.19.7' libthai_req_version = '>= 0.1.9' harfbuzz_req_version = '>= 2.0.0' fontconfig_req_version = '>= 2.11.91' xft_req_version = '>= 2.0.0' cairo_req_version = '>= 1.12.10' -- 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] cogl autoreconf
On 12/30/20 4:00 PM, Ken Moffat via blfs-dev wrote: I've got as far as checking cogl in the packages needing autoreconf (might as well do them all whilst on a system where gtkdocize is made unavailable) - not surprisingly, gtkdocize gets needed more in gnome packages. Among these is cogl, but in this case autoreconf is a legacy from when we used to have to patch this re mesa. I propose to comment out the autoreconf in this case, unless anyone objects (it built and did a DESTDIR without it). No objection here, unlike Mitch McConnell. -- 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] Why do we patch polkit for elogind ?
On 12/30/20 3:55 PM, Ken Moffat via blfs-dev wrote:
On Wed, Dec 30, 2020 at 03:46:58PM -0600, Bruce Dubbs via blfs-dev wrote:
On 12/30/20 1:18 PM, Pierre Labastie via blfs-dev wrote:
I think you can start gnome without a dm, by putting "exec gnome-
session" in .xinitrc. Now how to only start gnome-shell, I am not sure.
This is what I use:
$ cat .xinitrc
session=${2:-xfce}
dbus="dbus-launch --exit-with-session"
ck="ck-launch-session dbus-launch --exit-with-session"
case $session in
fluxbox ) exec startfluxbox;;
icewm ) exec icewm-session ;;
openbox ) exec openbox-session ;;
sawfish ) exec sawfish ;;
kde5|plasma ) exec $dbus /opt/kf5/bin/startplasma-x11 ;;
xfce|xfce4 ) exec $dbus startxfce4;;
lxde) exec ck-launch-session startlxde ;;
lxqt) $dbus /opt/lxqt/bin/startlxqt;;
lxqt2 ) exec /opt/lxqt/bin/startlxqt ;;
gnome ) $dbus /usr/bin/gnome-session ;;
twm ) xterm -g 80x40+0+0 &
xclock -g 100x100-0+0 &
twm
;;
# No known session, just say so
*) echo "Cannot run $1" ;;
esac
Some of the entries are obsolete. The default can be changed in line 1.
Thanks. do you think we should mention this for gnome, or is
everyone who goes to the trouble of building it assuemd to want to
use a desktop manager ?
Well, it is listed under Short Descriptions on the gnome-session, but we
could put in a paragraph there about starting from the command line. It
did take me a while to figure it out, but that was some time ago.
-- 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] Why do we patch polkit for elogind ?
On 12/30/20 1:18 PM, Pierre Labastie via blfs-dev wrote:
I think you can start gnome without a dm, by putting "exec gnome-
session" in .xinitrc. Now how to only start gnome-shell, I am not sure.
This is what I use:
$ cat .xinitrc
session=${2:-xfce}
dbus="dbus-launch --exit-with-session"
ck="ck-launch-session dbus-launch --exit-with-session"
case $session in
fluxbox ) exec startfluxbox;;
icewm ) exec icewm-session ;;
openbox ) exec openbox-session ;;
sawfish ) exec sawfish ;;
kde5|plasma ) exec $dbus /opt/kf5/bin/startplasma-x11 ;;
xfce|xfce4 ) exec $dbus startxfce4;;
lxde) exec ck-launch-session startlxde ;;
lxqt) $dbus /opt/lxqt/bin/startlxqt;;
lxqt2 ) exec /opt/lxqt/bin/startlxqt ;;
gnome ) $dbus /usr/bin/gnome-session ;;
twm ) xterm -g 80x40+0+0 &
xclock -g 100x100-0+0 &
twm
;;
# No known session, just say so
*) echo "Cannot run $1" ;;
esac
Some of the entries are obsolete. The default can be changed in line 1.
-- 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] elogind and rootless X
On 12/29/20 6:52 AM, Tim Tassonis via blfs-dev wrote: Hi all I just went through building xorg with elogind/dbus support until xinit, as in the book. I then still had to chmod u+s $XORG_PREFIX/libexec/Xorg in order to get X running. So just to make sure I did not fuck up anywhere: is this still expected behaviour with elogind? No, I assume the rootless thing only works when starting X with some dbus/polkit magic? There are some circular dependencies and it's a bit tricky. pam polkit dbus elogind xorg-libs dbus Of course there are other dependencies for these packages. -- 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] gtkmm3-3.24.3 issues
On 12/28/20 9:04 PM, Ken Moffat via blfs-dev wrote: First, comment on gtkmm3 - the book does not have '..' in the meson command. Seems unusual, Im using e conventional '..'. Second, a question: why are the docs for this package so important ? The book passes -Dbuild-documentation=true and later installs the docs. But that requires doxygen which is not listed as a dependency. ../meson.build:193:0: ERROR: Program 'doxygen' not found Without forcing the docs to be build, it doesn't need doxygen. In the absence of doxygen I can't test if docs are built automatically if it is present, but I think they are only built if forced or if forcing maintainer mode. I suggest that doxygen should be listed as optional, the define should be moved to an example switch, and the command to install them moved to 'if you have built the documentation...' I'm OK with that. I am pretty busy right now, so can you do it? -- 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] polkit-0.118 ftbfs
On 12/26/20 11:30 PM, Ken Moffat via blfs-dev wrote: Using polkit-0.118 and our polkit-0.118-fix_elogind_detection-1.patch, autoreconf fails with current versions of everything. In my script I use autoreconf -fiv instead of just autoreconf -fi, so this maybe shows a little more detail than the book's version: (the first part looks ok) autoreconf: running: intltoolize --copy --force autoreconf: running: gtkdocize --copy Can't exec "gtkdocize": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 293. autoreconf: error: gtkdocize failed with exit status: 2 The only relevant stuff I can find is old (2018) bug reports from debian (e.g. 89911) - | Recent versions of dh-autoreconf automatically run gtkdocize if gtk-doc | is found in configure.ac. This caused gstreamer1.0/1.14.1-1 to FTBFS on | all architectures (except amd64 and all which were built by the uploader, | presumably on a non-minimal system). And from one of the posts on debian 89891 - (dh-autoreconf) - | Version 18 invokes gtkdocize without a way to disable this, although | it does not depend on gtk-doc-tools. | | This breaks e.g. building libtasn1-6 which has gtk-doc-tools only in | Build-Depends-Indep because it uses --disable-gtk-doc on binary-only | builds. | | Please either add a dependency or(and) add a way to disable running | gtkdocize. From that, I guess that the change to autoconf-2.70 has buggered this. From the release notes for 2..70 (pasted from lwn.net) : *** autoreconf will now run gtkdocize and intltoolize when appropriate. From the release notes of autoconf-2.70-2.mga8 at mageia cauldron - * Sun Jul 26 2020 daviddavid 1:2.69.221-d0ac.5.mga8 + Revision: 1609074 - add missing dependency on gtk-doc * autoreconf: running: gtkdocize --copy Can't exec "gtkdocize": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 292, line 6 Which sounds a painfully heavy remedy. As a quick attempt I tried gtkdocize=/bin/true \ autoreconf ... but that doesn't get me much further - autoreconf: running: gtkdocize --copy Can't exec "gtkdocize": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 293. autoreconf: error: gtkdocize failed with exit status: 2 That line is just a generic 'report that a command failed' line, I cannot see where gtkdocize is being invoked. Since I think that installing gtkdoc for this is an unnecessary overhead, I'm halting this build, and everything that depended on it (biber, possibly looking at biber deps, reviewing xfce-4.16 for my own use. Unless someone has an easy solution, the only thing I'll be monitoring is firefox. Perhaps, if there is no solution, I will bring forward itstool and Pygments, and grudgingly install gtk-doc (I already have all of docbook), but this overhead *really* pisses me off and I'm not in any hurry to go back to installing gtk-doc which in my experience makes builds take even longer when it is present. Or perhaps the days of a somewhat minimal LFS are gone, and gtkdocize and its deps needs to be in LFS ? That would certainly be a much bigger LFS. More generally, it does seem that BLFS is more often broken these days. Fortunately, I'm still in chroot on my latest build, so I can continue to use the system and my browsers - this is another example of why I now prefer to build (at least) Xorg and firefox in chroot (on sysv). I was expecting some problems with the new autoconf. It's really complicated, but the upgrade was needed. I really don't understand your objection to gtk-doc. itstool is very quick and you may not need Pygments although it is recommended. gtk-doc is referenced by my count 141 times in blfs so it really doesn't hurt to build it early. -- 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] xfce 4.16.0 status report
On 12/25/20 10:05 AM, Tim Tassonis via blfs-dev wrote:
On 12/25/20 4:04 AM, Ken Moffat via blfs-dev wrote:
On Thu, Dec 24, 2020 at 11:56:59PM +0100, Tim Tassonis via blfs-dev
wrote:
Hi all
As a new release of my favorite DE is out and it's christmas, I
thought I
give it a go.
In short: An upgrade from 4.14 as in blfs svn works seamlessly, in
the exact
order as already in the book.
Apart from many bug-fixes and enhancements. there are just minor
changes to
the build:
- gtk+-2 is dropped completely. That should not bother anybody, I guess.
That is the thing that worries me - on my laptop I use xfce for a
pseudo-minimalist DE (because nm-application needs something more
than icewm) and old plugins (battery, cpugraph, netload). Those
plugins all seem to be on the fringes of xfce and not updated in a
long time. Anyone know if they still build with 4.16 ?
I just tried cpugraph from
https://archive.xfce.org/src/panel-plugins/xfce4-cpugraph-plugin/1.1/xfce4-cpugraph-plugin-1.1.0.tar.bz2
It does not build:
cpu.c:154:10: warning: assignment makes pointer from integer without a
cast [-Wint-conversion]
icon = xfce_panel_pixbuf_from_source ("xfce4-cpugraph-plugin",
NULL, 32);
^
CC libcpugraph_la-os.lo
CC libcpugraph_la-properties.lo
CC libcpugraph_la-settings.lo
CCLD libcpugraph.la
/usr/bin/ld:.libs/libcpugraph.ver:2: syntax error in VERSION script
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:483: libcpugraph.la] Error 1
make[2]: Leaving directory
'/home/timtas/xfce4-cpugraph-plugin-1.1.0/panel-plugin'
make[1]: *** [Makefile:451: all-recursive] Error 1
make[1]: Leaving directory '/home/timtas/xfce4-cpugraph-plugin-1.1.0'
make: *** [Makefile:383: all] Error 2
That package is 18 months old. I do not think it is surprising that it
is not compatible with 4.16. Just guessing, but I suspect it depends on
gtk2 and will need to be updated for 4.16.
-- 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] xfce 4.16.0 status report
On 12/24/20 4:56 PM, Tim Tassonis via blfs-dev wrote: Hi all As a new release of my favorite DE is out and it's christmas, I thought I give it a go. In short: An upgrade from 4.14 as in blfs svn works seamlessly, in the exact order as already in the book. Apart from many bug-fixes and enhancements. there are just minor changes to the build: - gtk+-2 is dropped completely. That should not bother anybody, I guess. - libxfce4ui now can use liggtop, as in the book. It's auto-detected and if present shows the cpu, the gpu and total ram in "About Xfce4" I would update the pages, but as I'm still on an lfs 8.2 base toolchain on my gui development system, I was told to no gui updates (my thunderbird build size varied greatly from others). However, I'd still like to share my details, to maybe make life easier for anybody updating the packages: libxfce4util: SRCURL=https://archive.xfce.org/xfce/4.16/src/libxfce4util-4.16.0.tar.bz2 SRCHASH: 5a2a7b72c0357f410d8e0d4190beeae2 BLDSIZE: 5.5M BINSIZE: 1.06 M xfconf: SRCURL=https://archive.xfce.org/xfce/4.16/src/xfconf-4.16.0.tar.bz2 SRCHASH: ac204fcc17fd4299d59e619aadbc6194 BLDSIZE: 9.3M BINSIZE: 1.81 M xfce4ui SRCURL=https://archive.xfce.org/xfce/4.16/src/libxfce4ui-4.16.0.tar.bz2 SRCHASH: 4a7035374f016efa968b776a110065d9 BLDSIZE: 13M BINSIZE: 2.65 M exo SRCURL=https://archive.xfce.org/xfce/4.16/src/exo-4.16.0.tar.bz2 SRCHASH: 0e2cb9c8bbe1993249358e2b0b9d9c54 BLDSIZE: 14M BINSIZE: 2.96 M garcon SRCURL=https://archive.xfce.org/xfce/4.16/src/garcon-0.8.0.tar.bz2 SRCHASH: a9c2116b0c34a022385f421b639df0f4 BLDSIZE: 8.1M BINSIZE: 1.64 M xfce4-panel SRCURL=https://archive.xfce.org/xfce/4.16/src/xfce4-panel-4.16.0.tar.bz2 SRCHASH: 19e160296e6f79ae27266a38a499ef3b BLDSIZE: 37M BINSIZE: 7.98 M thunar SRCURL=https://archive.xfce.org/xfce/4.16/src/thunar-4.16.0.tar.bz2 SRCHASH: 7b49f71c3748bcbda08d30ae3ff4cf01 BLDSIZE: 53M BINSIZE: 10.89 M thunar-volman SRCURL=https://archive.xfce.org/xfce/4.16/src/thunar-volman-4.16.0.tar.bz2 SRCHASH: 50ccc0e9a4eb7b5a6e9e498823c577f9 BLDSIZE: 6.9M BINSIZE: 950.17 K tumbler SRCURL=https://archive.xfce.org/xfce/4.16/src/tumbler-4.16.0.tar.bz2 SRCHASH: 3ab8fc5ea03e975c6df2ac1c81fbfc68 BLDSIZE: 14M BINSIZE: 2.14 M xfce4-appfinder SRCURL=https://archive.xfce.org/xfce/4.16/src/xfce4-appfinder-4.16.0.tar.bz2 SRCHASH: 7c285e138c3cb495badc2e4dcea5f100 BLDSIZE: 6.8M BINSIZE: 1.02 M xfce4-power-manager SRCURL=https://archive.xfce.org/xfce/4.16/src/xfce4-power-manager-4.16.0.tar.bz2 SRCHASH: 6fbf95dcfe2154be4ff252545c7c887b BLDSIZE: 19M BINSIZE: 5.00 M xfce4-settings SRCURL=https://archive.xfce.org/xfce/4.16/src/xfce4-settings-4.16.0.tar.bz2 SRCHASH: 3aa1f4edb1190f5c164d5760688f247a BLDSIZE: 30M BINSIZE: 6.83 M xfdesktop SRCURL=https://archive.xfce.org/xfce/4.16/src/xfdesktop-4.16.0.tar.bz2 SRCHASH: 20de956693011c429e3ec2928f535b7a BLDSIZE: 19M BINSIZE: 4.58 M xfwm4 SRCURL=https://archive.xfce.org/xfce/4.16/src/xfwm4-4.16.0.tar.bz2 SRCHASH: c464e52540cef79059ef31eb2fa6dc12 BLDSIZE: 32M BINSIZE: 6.53 M xfce4-session SRCURL=https://archive.xfce.org/xfce/4.16/src/xfce4-session-4.16.0.tar.bz2 SRCHASH: 2bb95124f91e9469ea5571c94d6034fe BLDSIZE: 15M BINSIZE: 2.65 M xfce4-dev-tools SRCURL=https://archive.xfce.org/xfce/4.16/src/xfce4-dev-tools-4.16.0.tar.bz2 SRCHASH: 4341c604f3d6198076167c5a2a2d27ea BLDSIZE: 2.5M BINSIZE: 93.34 K Thanks Tin. It would be really nice of you had a development system that you could keep up to date. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] glibmm, cairomm, pangomm, atkmm, and gtkmm4
I've been looking at the c++ interfaces to the glib based libraries today. There are new versions available: glibmm-2.68.0 cairomm-1.16.0 pangomm-2.48.0 atkmm-2.36.0 gtkmm-4.0.0 They need to be built in the above order to satisfy dependencies, but ultimately, gtkmm-4.0.0 requires gtk+-4. Nothing we have yet requires gtk+-4. Each of these libraries can be built and installed along side the current versions of these versions without issue, but they are in hold status for now. They will require new pages in the book when we do need gtk4, probably when the next version of gnome is released. -- 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] 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 think this is a good idea. It is also a good time to do it since we are only a few days past midway through the BLFS release cycle. -- 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] Bad kf5 URL ?
On 12/11/20 2:37 PM, Ken Moffat via blfs-dev wrote: I've also started to build the whole of my normal desktop in chroot so that I can keep using the old desktop until everything has been compiled. Everyone develops their own techniques. Personally I only build enough in chroot to get ssh and nfs working (about 10 packages) and then reboot and move to another full system. I then build up through xorg, xfce, and firefox via ssh. I can then move back to my workstation. Works for me, but I understand others prefer different techniques. -- 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] Bad kf5 URL ?
On 12/11/20 12:39 PM, Bruce Dubbs wrote: On 12/11/20 12:04 PM, Ken Moffat via blfs-dev wrote: On Fri, Dec 11, 2020 at 11:03:05AM -0600, Bruce Dubbs via blfs-dev wrote: On 12/11/20 12:40 AM, Pierre Labastie via blfs-dev wrote: On Fri, 2020-12-11 at 02:43 +, Ken Moffat via blfs-dev wrote: Yes I've been bitten by that when trying to build LXQt. Note that it has nothing to do with jhalfs. Either put Attic instead of stable, or use a later version. Of course with a later version of kf5/plasma all the md5sums are different. -- Bruce For plasma in particular, do not the dependencies (and perhaps even the available tarballs) change over time, so that we ought to stick to the current versions of both for the moment ? More generally, our releases are frozen at a point in time, and subject to errata. If a url becomes unusable, do we not fix that in the development book and add an erratum ? Most of the blfs packages we use are copied to http://ftp.osuosl.org/pub/blfs/ as they are upgraded. An exception to that is kf5/plasma due to the number of packages and their size. The size of the repository there is now 220G and has packages there going back to BLFS-6.1 (2008). I do update osuosl virtually every day. What I think is appropriate is for this case is to add a note similar to the one in ImageMagick, but point it to Attic instead. I did just check plasma, and https://download.kde.org/stable/plasma/ does go back to 5.17.0/ (October 2019), so that should not be a problem unless they reorganize that page. Pierre has explained to me on alfs-discuss about the jhalfs issue with kf5, I'll maybe come back to that next week. I do not use jhalfs for building BLFS. It is useful for showing the order to build dependencies, but I have a long history of having BLFS sources and scripts in /usr/src/. jhalfs does not support that organization and I do not want to re-download sources I already have. In addition, my scripts are instrumented to place logs and statistics in a consistent location tagged by which host built the package. On the other hand, I find jhalfs invaluable for LFS. -- 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] Bad kf5 URL ?
On 12/11/20 12:04 PM, Ken Moffat via blfs-dev wrote: On Fri, Dec 11, 2020 at 11:03:05AM -0600, Bruce Dubbs via blfs-dev wrote: On 12/11/20 12:40 AM, Pierre Labastie via blfs-dev wrote: On Fri, 2020-12-11 at 02:43 +, Ken Moffat via blfs-dev wrote: Yes I've been bitten by that when trying to build LXQt. Note that it has nothing to do with jhalfs. Either put Attic instead of stable, or use a later version. Of course with a later version of kf5/plasma all the md5sums are different. -- Bruce For plasma in particular, do not the dependencies (and perhaps even the available tarballs) change over time, so that we ought to stick to the current versions of both for the moment ? More generally, our releases are frozen at a point in time, and subject to errata. If a url becomes unusable, do we not fix that in the development book and add an erratum ? Most of the blfs packages we use are copied to http://ftp.osuosl.org/pub/blfs/ as they are upgraded. An exception to that is kf5/plasma due to the number of packages and their size. The size of the repository there is now 220G and has packages there going back to BLFS-6.1 (2008). I do update osuosl virtually every day. What I think is appropriate is for this case is to add a note similar to the one in ImageMagick, but point it to Attic instead. Pierre has explained to me on alfs-discuss about the jhalfs issue with kf5, I'll maybe come back to that next week. I do not use jhalfs for building BLFS. It is useful for showing the order to build dependencies, but I have a long history of having BLFS sources and scripts in /usr/src/. jhalfs does not support that organization and I do not want to re-download sources I already have. In addition, my scripts are instrumented to place logs and statistics in a consistent location tagged by which host built the package. On the other hand, I find jhalfs invaluable for LFS. -- 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] Bad kf5 URL ?
On 12/11/20 12:40 AM, Pierre Labastie via blfs-dev wrote: On Fri, 2020-12-11 at 02:43 +, Ken Moffat via blfs-dev wrote: I must have been evil in a previous existence, because I'm not trying to use jhalfs to build kde. In kf5 I stopped the build after a bit over an hour because nothing was happening. The log said: URL transformed to HTTPS due to an HSTS policy --2020-12-11 02:14:37-- https://download.kde.org/stable/frameworks/5.73/ Resolving download.kde.org (download.kde.org)... 168.119.32.158, 2a01:4f8:242:1ed5::3 Connecting to download.kde.org (download.kde.org)|168.119.32.158|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://download.kde.org/Attic/frameworks/5.73/ [following] --2020-12-11 02:14:38-- https://download.kde.org/Attic/frameworks/5.73/ Reusing existing connection to download.kde.org:443. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘index.html.tmp’ 0K .. .. .. .. .. 686K 50K .. .. 24.3M=0.07s Yes I've been bitten by that when trying to build LXQt. Note that it has nothing to do with jhalfs. Either put Attic instead of stable, or use a later version. Of course with a later version of kf5/plasma all the md5sums are different. -- 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] Bad kf5 URL ?
On 12/10/20 8:43 PM, Ken Moffat via blfs-dev wrote: I must have been evil in a previous existence, because I'm not trying to use jhalfs to build kde. In kf5 I stopped the build after a bit over an hour because nothing was happening. The log said: URL transformed to HTTPS due to an HSTS policy --2020-12-11 02:14:37-- https://download.kde.org/stable/frameworks/5.73/ Resolving download.kde.org (download.kde.org)... 168.119.32.158, 2a01:4f8:242:1ed5::3 Connecting to download.kde.org (download.kde.org)|168.119.32.158|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://download.kde.org/Attic/frameworks/5.73/ [following] --2020-12-11 02:14:38-- https://download.kde.org/Attic/frameworks/5.73/ Reusing existing connection to download.kde.org:443. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘index.html.tmp’ 0K .. .. .. .. .. 686K 50K .. .. 24.3M=0.07s 2020-12-11 02:14:38 (1.04 MB/s) - ‘index.html.tmp’ saved [80331] Removing index.html.tmp since it should be rejected. FINISHED --2020-12-11 02:14:38-- Total wall clock time: 0.3s Downloaded: 1 files, 78K in 0.07s (1.04 MB/s) renamed '/opt/kf5' -> '/opt/kf5.old/kf5' install: creating directory '/opt/kf5' install: creating directory '/opt/kf5/etc' install: creating directory '/opt/kf5/share' '/opt/kf5/etc/dbus-1' -> '/etc/dbus-1' '/opt/kf5/share/dbus-1' -> '/usr/share/dbus-1' - - - If I change the url to https://download.kde.org/Attic/frameworks/5.73/ it then downloaded 101 files. But of course, it then failed. The log ended: --2020-12-11 02:16:45-- https://download.kde.org/Attic/frameworks/5.73/portingAids/?C=D;O=D Reusing existing connection to download.kde.org:443. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘index.html?C=D;O=D.tmp’ 0K .. . 21.1M=0.001s 2020-12-11 02:16:45 (21.1 MB/s) - ‘index.html?C=D;O=D.tmp’ saved [16145] Removing index.html?C=D;O=D.tmp since it should be rejected. FINISHED --2020-12-11 02:16:45-- Total wall clock time: 57s Downloaded: 101 files, 266M in 33s (7.96 MB/s) mv: cannot move '/opt/kf5' to '/opt/kf5.old/kf5': Directory not empty '/opt/kf5/etc/dbus-1' -> '/etc/dbus-1' '/opt/kf5/share/dbus-1' -> '/usr/share/dbus-1' I'm inclined to say that the URL needs to be changed, but what do I know ? Anyway, I cleaned out /opt/kf5-5.73.0/kf5 and tried again. No joy: - - - FINISHED --2020-12-11 02:29:31-- Total wall clock time: 57s Downloaded: 101 files, 266M in 35s (7.68 MB/s) renamed '/opt/kf5' -> '/opt/kf5.old' install: creating directory '/opt/kf5' install: creating directory '/opt/kf5/etc' install: creating directory '/opt/kf5/share' '/opt/kf5/etc/dbus-1' -> '/etc/dbus-1' '/opt/kf5/share/dbus-1' -> '/usr/share/dbus-1' - - - Now, a little of that last one might be me misunderstanding what jhalfs is doing, but downloading from Attic definitely works (I've just downloaded all of them again). And I now see that they got downloaded by jhalfs to my work directory rather than to /sources. But I'm **ed if I can persuade it to do anything with the tarballs. I think I'll need to review whether trying to see if the book's instructions work (to catch regressions caused by apparently unrelated updates) is going to do anything useful for me, because at the moment it just looks like a vale of tears. The reason the download failed was because the upstream website changed. They now only have versions 5.74 through 5.76 at https://download.kde.org/stable/frameworks/. I do not know when they made the change, but at one time they had at least 10 versions on that site. I note that they update the version once a month. I was going to update KDE this month and that would bring it back into a valid URL, but I suppose it would also be best to add a note about the availability of the version. I'm not sure how this should be handled by jhalfs. The stable book would be wrong half the time between releases. -- 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] Qt 6 discussion
On 12/8/20 3:34 PM, Marty Jack via blfs-dev wrote: I see some discussion in the ticket on Qt 6.0. This is a case where you will need both Qt 5 and Qt 6 in parallel for potentially years, similar to the situation with GTK 2 and GTK 3 or Qt4 and Qt5. I predict very slow adoption of Qt 6 because they have deferred a lot of modules that are not expected until 6.2 in the fall of 2021 or later and they expect to repackage some classes into other modules. The two that affect me are qtmultimedia and qtwebengine. I had some trouble getting the directory layout the way I wanted it with cmake because it doesn't allow "..". -DCMAKE_INSTALL_PREFIX=/usr -DINSTALL_BINDIR=/usr/lib/qt6/bin -DINSTALL_DATADIR=/usr/share/qt6 -DINSTALL_DOCDIR=/usr/share/doc -DINSTALL_INCLUDEDIR=/usr/include/qt6 -DINSTALL_LIBDIR=/usr/lib -DINSTALL_LIBEXECDIR=/usr/lib/qt6/libexec -DINSTALL_MKSPECSDIR=/usr/lib/qt6/mkspecs -DINSTALL_PLUGINSDIR=/usr/lib/qt6/plugins -DINSTALL_QMLDIR=/usr/lib/qt6/qml -DINSTALL_SYSCONFDIR=/etc/xdg I don't plan to convert any code I work on to it or install any of it until something I build needs it or they ship qtmultimedia and qtwebengine. Yes, it's way too early to add this package. I took a look at Arch and the only thing that depends on any of the modules so far are other qt6 modules. -- 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] Berkeley DB library locations
On 12/4/20 2:11 PM, DJ Lucas via blfs-dev wrote: On December 3, 2020 3:18:39 PM CST, Bruce Dubbs via blfs-dev wrote: In some cases PAM may use Berkeley DB libraries. We should probably change the bdb build to move the libraries to /lib: ... I don't think that is necessary, or at least not by FHS if that's what prompted the suggestion. By the time you reach a login prompt, networking should be up, and if it's not, it'll just fail and move on to the next module in the chain (eventually making it's way to using local files), so it doesn't make any difference for the FHS case. I suppose a local db can be a concern (I've never set one up that way), but you are likely in the same boat in either case if /usr is not available at that time, as you are probably wanting to fix the missing /usr. Good point. -- 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] systemd latest version 247.1
On 12/4/20 11:16 AM, Wayne Blaszczyk via blfs-dev wrote: [snip] 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 Looks like a kernel option: Symbol: PSI [=n] Type : bool Defined at init/Kconfig:596 Prompt: Pressure stall information tracking Location: -> General setup (1) -> CPU/Task time and stats accounting Symbol: PSI_DEFAULT_DISABLED [=n] Type : bool Defined at init/Kconfig:615 Prompt: Require boot parameter to enable pressure stall information tracking Depends on: PSI [=n] Location: -> General setup -> CPU/Task time and stats accounting (2) -> Pressure stall information tracking (PSI [=n] -- 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] Location of Cmake's Vim files
On 12/3/20 6:38 PM, Kevin Buckley via blfs-dev wrote: Noticed this when doing a PkgUser install because of a conflict between Vim and CMake The install of Vim has deployed, amongst other things pkg cmake:cmake-3.18.1> ls -l /usr/share/vim/vim82/ total 384 drwxr-xr-x 4 vim vim 4096 Nov 24 18:57 autoload -rw-r--r-- 1 vim vim 1927 Nov 24 18:57 bugreport.vim drwxr-xr-x 3 vim vim 4096 Nov 24 18:57 colors drwxr-xr-x 2 vim vim 4096 Nov 24 18:57 compiler -rw-r--r-- 1 vim vim 4454 Nov 24 18:57 defaults.vim -rw-r--r-- 1 vim vim 806 Nov 24 18:57 delmenu.vim drwxr-xr-x 2 vim vim 4096 Nov 24 18:57 doc -rw-r--r-- 1 vim vim 2126 Nov 24 18:57 evim.vim -rw-r--r-- 1 vim vim 59967 Nov 24 18:57 filetype.vim -rw-r--r-- 1 vim vim 280 Nov 24 18:57 ftoff.vim drwxr-xr-x 2 vim vim 12288 Nov 24 18:57 ftplugin -rw-r--r-- 1 vim vim 971 Nov 24 18:57 ftplugin.vim -rw-r--r-- 1 vim vim 337 Nov 24 18:57 ftplugof.vim -rw-r--r-- 1 vim vim 1641 Nov 24 18:57 gvimrc_example.vim drwxr-xr-x 2 vim vim 4096 Nov 24 18:57 indent -rw-r--r-- 1 vim vim 767 Nov 24 18:57 indent.vim -rw-r--r-- 1 vim vim 282 Nov 24 18:57 indoff.vim ... ls -l /usr/share/vim/vim82/indent/cmake.vim -rw-r--r-- 1 vim vim 2683 Nov 24 18:57 /usr/share/vim/vim82/indent/cmake.vim The install of Cmake however, looks to place files at -- Installing: /usr/share/vim/vimfiles/indent CMake Error at Auxiliary/cmake_install.cmake:46 (file): file INSTALL cannot make directory "/usr/share/vim/vimfiles/indent": No such file or directory. and would also try to install all of these -- Installing: /usr/share/vim/vimfiles/indent -- Installing: /usr/share/vim/vimfiles/indent/cmake.vim -- Installing: /usr/share/vim/vimfiles/syntax -- Installing: /usr/share/vim/vimfiles/syntax/cmake.vim -- Installing: /usr/share/emacs/site-lisp/cmake-mode.el -- Installing: /usr/share/aclocal/cmake.m4 -- Installing: /usr/share/bash-completion/completions/cmake -- Installing: /usr/share/bash-completion/completions/cpack -- Installing: /usr/share/bash-completion/completions/ctest where you'll note the paths for the Vim-related files doesn't match that of the Vim deployment. FWIW pkg cmake:cmake-3.18.1> diff /usr/share/vim/vimfiles/indent/cmake.vim /usr/share/vim/vim82/indent/cmake.vim 6c6 < " Last Change: 2017 Aug 30 --- > " Last Change: 2017 Sep 24 17,19d16 < let s:keepcpo= < set cpo < 26a24,25 > let s:keepcpo= > set cpo Which of the two Cmake indent files will get precendence, and might there be a case for installing Cmake's, and other package;s Vim-related files, over the top of the ones deployed by Vim. Kevin, On my system the only files in /usr/share/vim/vimfiles/ are installed by cmake. I have three directories: after, indent, and syntax. In each is a single file two named cmake.vim and one named lisp.vim. I'm not sure the lisp.vim is still valid since it was not replaced by the most recent installation of cmake. I'm not sure, but I think these are used when editing cmake files. We might want to investigate installation of the cmake version of the files to put them in the proper directory, but it really makes no practical difference. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Berkeley DB library locations
In some cases PAM may use Berkeley DB libraries. We should probably
change the bdb build to move the libraries to /lib:
...
../dist/configure --prefix=/usr \
--libdir=/lib \ <-- added
--enable-compat185 \
--enable-dbm \
--disable-static \
--enable-cxx &&
...
ln -sv ../../lib/$(readlink /lib/libdb.so) /usr/lib/libdb.so
ln -sv ../../lib/$(readlink /lib/libdb.so) /usr/lib/libdb-5.so
ln -sv ../../lib/$(readlink /lib/libdb_cxx.so) /usr/lib/libdb_cxx.so
ln -sv ../../lib/$(readlink /lib/libdb_cxx.so) /usr/lib/libdb_cxx-5.so
rm -fv /lib/{libdb*.la,libdb{,-5}.so,libdb_cxx{,-5}.so}
This also deletes the .la files which are not needed and would be wrong
anyway.
What do you think?
-- 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] Linux-PAM option --enable-db=no
On 12/1/20 3:02 PM, Tim Tassonis via blfs-dev wrote: On 12/1/20 5:33 PM, Bruce Dubbs via blfs-dev wrote: 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? Not sure. We have bdb listed as optional. We really don't normally list how to disable optional packages. I really don't know what it does for pam. Looking at the man page it says it is a PAM module to authenticate against a db database. Looking at my log, it appears to just build the module pam_userdb.so. It looks like the only downside of building that module if you are not going to use it is using about 72 KB on disk. Well, libdb is a bit bigger: ls -lh /usr/lib/libdb-5.3.so -rwxr-xr-x 1 root root 1.9M Oct 13 08:46 /usr/lib/libdb-5.3.so I fully agree that the book is not here to allow to minimize run-time dependencies, it only covers build AND run dependencies. So, I can live well without the info in the book, I have in now in my build script. My scenario is: I always install PAM on all systems, but bdb only when needed. If pam is linked against bdb, this will require the 2 MB big libdb to be installed as well on all systems. But that is just my scenario, other BLFS users use their systems differently and don't have this problem. If you do not already have bdb installed, then there is no issue. If it is installed, then only the 72 KB module is added. -- 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] 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? Not sure. We have bdb listed as optional. We really don't normally list how to disable optional packages. I really don't know what it does for pam. Looking at the man page it says it is a PAM module to authenticate against a db database. Looking at my log, it appears to just build the module pam_userdb.so. It looks like the only downside of building that module if you are not going to use it is using about 72 KB on disk. -- 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] llvm in /opt
On 11/10/20 6:43 AM, Tim Tassonis via blfs-dev wrote: Hi all I'm just about to build llvm 11 as in current blfs, and wondered if it would be better to install it in /opt/llvm11, instead of /usr. The reason I'm asking is that llvm seems to be updated quite often and I'm not sure about the compatibility of different versions with mesa, rustc and firefox. Any thoughts on this? You can do this, but I have not run into any problems with llvm in /usr in the past. -- 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] python2 as default python?
On 11/2/20 4:35 PM, Ken Moffat via blfs-dev wrote: On Wed, Oct 21, 2020 at 10:48:39PM -0500, Bruce Dubbs 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. I've now completed my build using altinstall. Comments on various packages: python2 itself: The only programs it installed were: 2to3 easy_install-2.7 idle pip2.7 pydoc python2.7 python2.7-config smtpd.py Note that it did NOT overwrite pip, but it did overwrite 2to3 (the versions of that are currntnly similari except for the version of python, but if we're going to do this I suggest that we save the installed 2to3 from LFS and use that to verwrite the py2 version post-install. Note also that the python2 symlink was not installed. Mostly not a problem, but qtwebengine is of course a right pain. If we go for altinstall, I'd be happier if someone else first confirms what python2 installs. From here onwards, I altered my scripts so that python2.7 and python2.7 are not normally available (renamed), but with a function to enable them when needed. In general, using altinstall means that whenever we want to use python2 we have to specify python2.7. I've built the following packages using 2.7: 001. libxml2 python2 module: python2.7 setup.py ... I now see that my build of libxslt does NOT build python, and that I had moved the py2 module to a separate script - and then stopped building that because I no-longer attempt to build the gimp-help files. 002. pycairo2: python2.7 setup.py ... 003. pygobject2: PYTHON=/usr/bin/python2.7 ./configure ... 004. pygtk: PYTHON=/usr/bin/python2.7 ./configure ... 005. gimp-2.10: no action necessary, it finds 2.7 006. seamonkey: no action necessary, it finds 2.7 007. qtwebengine Fedora have a patch to use python2, I did that with a sed: sed -i 's/\$\$python /python2 /' src/webengine/module.pro I tried changing that to python2.7, but whatever parses the pro file seems to treat '.' as a possible field break, resulting in it looking for python2 (only) and not finding it. That doesn't actually break the build, it warns that WebEngine etc will not be built, and exits successfully without doing anything. In the end, I used the sed to get it to use python2, and then created a /usr/bin/python2 symlink for the duration of the build. I also created a /usr/bin/python2-config symlink, unsure if it really needed that. 008. dbus-python: PYTHON=/usr/bin/python2.7 ... I have no idea if anything in the book still needs the python2 module. I suspect that most things have moved on. Links to python2 from the following are already commented out in the book's source: mercurial, swig, usb-utils. The book still builds the following other modules for both, but I see no point in building for python2 nowadays: lxml, MarkupSafe, PyYAML, six. For six we recommend python2 as well as 3, but I've been building only with 3 for three and a half years). If altinstall does not create the /usr/bin/python2 symlink, then we should create it ourselves. I agree that it would be preferable to use the p3 version of 2to3. The only definitive way to check out what is needed is to not built the p2 modules (except those we know are needed for pygtk) and build all of BLFS. Then see what breaks. Maybe I'll try to start that later this week, but right now I'm too damned hung up on the election. -- 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] btrfs-progs needs new location for its pkgconfig file
On 11/1/20 2:52 PM, Ryan Marsaw via blfs-dev wrote: Hello all. The latest btrfs-progs now installs a pkgconfig file (libbtrfsutil.pc). With current build instructions, this file is installed in /lib/pkgconfig. To install this file to its proper location, the configure section must add "--with-pkgconfigdir=/usr/lib/pkgconfig" to the instructions. Thanks. I'll fix that today. -- 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] If P2 modules are built for PyYaml and Markupsafe, then recommend P2
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. 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. Of course the biggest problem appears to be those packages that need pygtk which uses PyGObject-2.28.7 and PyCairo-1.18.2. -- 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] python2 as default python?
On 10/23/20 12:00 PM, Ken Moffat via blfs-dev wrote: On Fri, Oct 23, 2020 at 11:22:06AM -0500, Bruce Dubbs via blfs-dev wrote: Is there an official python recommendation for that, to quote at them, please ? That's a good question, but I would also like to see if there is a survey of the major distros on the subject. I know arch has had python->python3 for a long time, but I don't know what Debian, Gentoo, Fedora, SUSe, Slackware, etc currently do. Does anyone know or have access to systems that can easily check? In the past most had python->python2 because that was baked into the p2 Makefile. Creating a symlink is not in the current p3 Makefile. I think Arch followed fedora in symlinking python3 to python. Gentoo is complicated - python is used for a lot of their build system and they have 'slots' for multiple versions. It looks as if they don't have a python symlink, but I guess there could be such a symlink while (re)building a package. https://wiki.gentoo.org/wiki/Python Ubuntu seems to be removing /usr/bin/python from a comment re 20.04 that somebody's desktop has it from the python-is-python2 package, but that his other systems don't have python2 https://www.gamingonlinux.com/2020/04/distro-news-ubuntu-2004-focal-fossa-ubuntu-mate-and-other-flavours-released/page=5 Certainly, I've seen gimp-help suggestions to use flatpack for python2 scripting in ubuntu because of the absence of python2. I just found out that Mint 20 has python2 and python3, but no python. -- 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] python2 as default python?
On 10/23/20 11:01 AM, Ken Moffat via blfs-dev wrote:
On Fri, Oct 23, 2020 at 10:27:51AM -0500, DJ Lucas via blfs-dev wrote:
On October 23, 2020 10:15:09 AM CDT, Ken Moffat via blfs-dev
wrote:
On Fri, Oct 23, 2020 at 09:04:53AM +0200, Pierre Labastie via blfs-dev
wrote:
Reluctantly, I have to go with a python symlink. Out of the more
than 48000 tests in clang-11.0, one uses /usr/bin/env/python.
When we find something like that, couldn't we use:
grep -rl '#!.*python' | xargs sed -i
'1{s/python$/python3/;s/python[^3]/python3}'
or so?
Of course, P2 only scripts would still fail, but at least, nothing
would depend on a python symlink.
Pierre
I think the problem is more that using env python is hidden deep
within a lot of packages.
This _should_ go away on its own eventually. You are supposed to specify the
major version. If a particular script doesn't, it is broken. Opening bugs for
these errors upstream is entirely appropriate.
--DJ
Is there an official python recommendation for that, to quote at
them, please ?
That's a good question, but I would also like to see if there is a
survey of the major distros on the subject. I know arch has had
python->python3 for a long time, but I don't know what Debian, Gentoo,
Fedora, SUSe, Slackware, etc currently do. Does anyone know or have
access to systems that can easily check?
In the past most had python->python2 because that was baked into the p2
Makefile. Creating a symlink is not in the current p3 Makefile.
-- 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] python2 as default python?
On 10/22/20 12:56 AM, DJ Lucas via blfs-dev wrote: On October 21, 2020 10:48:39 PM CDT, Bruce Dubbs via blfs-dev wrote: On 10/21/20 10:06 PM, DJ Lucas via blfs-dev wrote: In LFS, we can make the symlink to p3. For p2 in BLFS, we will use 'make altinstall'. Everything else would be for non-python packages that either use p2 or create a p2 module. Ok, I'll go back and fix it that way locally then. I'm not too far. I have only like 8 packages that have py2 optional deps listed. So for BLFS, just do it and fix on the fly, or create a tracker bug and let the devs run through it a time or two? I don't think it's going to be all that big of a deal, but might be nice to avoid any interim breakage, do as one big commit or a small series of commits to make it easier on people who are upgrading. My thought is to fix it in LFS and python2 in BLFS and fix everything else as the issues come up. It is a development release right now and we are early in the cycle. -- Bruce -- 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/21/20 10:06 PM, DJ Lucas via blfs-dev wrote:
On 10/21/2020 7:12 PM, Kevin Buckley via blfs-dev wrote:
On Thu, 22 Oct 2020 at 00:26, Bruce Dubbs via blfs-dev
wrote:
Currently we have /usr/bin/python -> python2. Is it time to change that
to python3?
Probably a bit too drastic a view, but should we even be propagating
the need to have a bare python?
Interesting point.
I appreciate it can be a convenience when 2 and 3 co-exist but the
price for that convenience across the version change has been high.
My preference would be to not use the bare "python" anywhere, so
that scripts have to be explicit about which major version they want.
It will make things a lot easy when python4 comes along!
As to the convenience link in /usr/bin, I'd look to remove it and tell
people that they can alias the bare "python" if they really, really need
to, but that they have to make the choice to do so: the system won't
be doing it for them.
I've effectively already done this being that I'm deliberately avoiding
Python2, but IIRC, that means removing the symlink after it's installed
(the Python-2.x installation does it automatically) - or a sed to keep
it from being created I guess. I'm going to proceed with this approach.
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.
As to gimp (mentioned earlier in this thread), is excising python2 a
goal of the 3.0 release? It is about the only *major* consumer left.
There are only 22 bugs remaining that are not labeled "feature"
currently targeted for the 3.0 milestone. Many of those are old as well.
https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all=%E2%9C%93=opened_title=3.0[label_name][]=1.%20Feature
I did a git clone (very slow) and looked.
configure.ac:m4_define([python3_required_version], [3.6.0])
meson.build:is_git_repository = run_command('python3', '-c',
Also in NEWS:
The API is GObject Introspected into 2 modules: Gimp and GimpUi.
This means plug-ins can be written in various non-C languages. So
far the following languages have been tested and work well: Python
3, Lua, Javascript and Vala.
(Note: Python 2 is also still working, but considering that this
language is end-of-life since 2020, we don't really care).
So it does look like it will be p3.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] python2 as default python?
Currently we have /usr/bin/python -> python2. Is it time to change that to python3? -- 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] xorg-applications
On 10/19/20 11:20 PM, DJ Lucas via blfs-dev wrote: On 10/19/2020 11:00 PM, Bruce Dubbs via blfs-dev wrote: On 10/19/20 10:55 PM, DJ Lucas via blfs-dev wrote: mkfontdir is no longer needed (probably hasn't been in a long time). It is a shell script and both it and the manpage are included with makefontscale. OK, I can remove that. Well, I probably could as well, but I was really just looking for second verification on list. :-) I didn't want to just remove it without discussion. I'm (very) slowly working my way through a packaged build, which occasionally brings to light (mostly) inconsequential issues like this that we miss because we overwrite on the fly (of course, it introduces its own ghosts as well). I confirmed it in my log for xorg-apps. It's fixed, and will commit tomorrow. -- 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] xorg-applications
On 10/19/20 11:20 PM, DJ Lucas via blfs-dev wrote: On 10/19/2020 11:00 PM, Bruce Dubbs via blfs-dev wrote: On 10/19/20 10:55 PM, DJ Lucas via blfs-dev wrote: mkfontdir is no longer needed (probably hasn't been in a long time). It is a shell script and both it and the manpage are included with makefontscale. OK, I can remove that. Well, I probably could as well, but I was really just looking for second verification on list. :-) I didn't want to just remove it without discussion. I'm (very) slowly working my way through a packaged build, which occasionally brings to light (mostly) inconsequential issues like this that we miss because we overwrite on the fly (of course, it introduces its own ghosts as well). I've already done it. It will be in my next commit tomorrow. -- 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] xorg-applications
On 10/19/20 10:55 PM, DJ Lucas via blfs-dev wrote: mkfontdir is no longer needed (probably hasn't been in a long time). It is a shell script and both it and the manpage are included with makefontscale. OK, I can remove that. -- 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] llvm-11 and rust
On 10/15/20 5:51 PM, Ken Moffat via blfs-dev wrote: On Thu, Oct 15, 2020 at 05:03:54PM -0500, Bruce Dubbs via blfs-dev wrote: On 10/15/20 4:51 PM, Ken Moffat via blfs-dev wrote: On Wed, Oct 14, 2020 at 03:59:32PM +0100, Ken Moffat via blfs-dev wrote: On Wed, Oct 14, 2020 at 02:14:56PM +0100, Ken Moffat via blfs-dev wrote: On Wed, Oct 14, 2020 at 04:17:50PM +0800, Xi Ruoyao via blfs-dev wrote: On 2020-10-14 02:45 +0100, Ken Moffat via blfs-dev wrote: On Wed, Oct 14, 2020 at 02:21:39AM +0100, Ken Moffat via blfs-dev wrote: On Mon, Oct 12, 2020 at 09:15:30PM +0100, Ken Moffat via blfs-dev wrote: Over the weekend I expect to start updating my other systems to firefox-78.4.0 latest candidate (so far only one, build2) so I suspect that progress on moving the book to llvm-11 with rustc-1.47.0 and patches for 78 versions of firefox and thunderbird will now be a week away (or more if I decide to update all my packages and build a fresh up to date system). Thanks for the update Ken. No big hurry. A week will be fine. It would help if you took the tickets though to reduce the possibility of conflicts. -- Bruce OK, I've taken llvm and a new ticket for rustc-1.47.0. I'll create a ticket for firefox-78.4.0, and close 78.3.0, when the 78.4.0 release appears on Monday. Thanks Ken. -- 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/15/20 4:51 PM, Ken Moffat via blfs-dev wrote: On Wed, Oct 14, 2020 at 03:59:32PM +0100, Ken Moffat via blfs-dev wrote: On Wed, Oct 14, 2020 at 02:14:56PM +0100, Ken Moffat via blfs-dev wrote: On Wed, Oct 14, 2020 at 04:17:50PM +0800, Xi Ruoyao via blfs-dev wrote: On 2020-10-14 02:45 +0100, Ken Moffat via blfs-dev wrote: On Wed, Oct 14, 2020 at 02:21:39AM +0100, Ken Moffat via blfs-dev wrote: On Mon, Oct 12, 2020 at 09:15:30PM +0100, Ken Moffat via blfs-dev wrote: I aim to update my builds for the packages which use rust (cbindgen, librsvg, thunderbird to whatever is currently in the book) and to use firefox-78.3.0, current seamonkey. If these all build, we will be able to update rustc along with llvm. If not, I assume we will need to revert to rustc using its shipped llvm whenever llvm-11 goes into the book. Have I overlooked anything ? ĸen Unfortunately, I _did_ overlook something - I've got several scripts to build rustc (different versions with prefix and sysllvm or shipped) and I accidentally built 1.46.0 on llvm-11.0.0. That did build, and built all of cbindgen, firefox-esr, frefox-82.0 candidate 1, librsvg, seamonkey, thunderbird. Currently building rustc-1.47.0, will attempt to rebuild them all in due course. Second fault in that first attempt - I was using the shipped llvm, so of course it built. I can confirm that rustc-1.47.0 builds OK with system LLVM-11.0.0, and it can build librsvg & js78 with no problem. Thanks. I didn't test firefox 78, though. firefox 78 fails to build, I have not identified the error amongst the warnings. ĸen https://bugzilla.mozilla.org/show_bug.cgi?id=1663715#c7 Three patches (0036-0038) in gentoo's firefox-esr-78-patches-03.tar.xz but a hunk of the second does not apply. I have not looked at the detail of the rejection. Meanwhile, the (first) candidate for 78.4.0 is out. In that the changes in the first two patches, but not the third, have been applied. Will see if 78.4.0 needs that third patch. Seamonkey builds without problems, currently attempting to build thunderbird. Status report (I hesitate to call it progress). And thunderbird has similar issue(s) to firefox-esr (gentoo use their firefox patches for thunderbird). Meanwhile, firefox-82.0 (technically, build candidate 2) is fine. But until thunderbird can be built, there seems little point in even thinking about going back to current firefox. Then I took another look at the gentoo patches. First, their second rust-1.47 patch (0037) was not applying because 0036 changed the same file - I'd overlooked that, and was trying dry runs on each before applying any of them. Applied al three to 78.3.0, diff'd, then realised I had not edited the last, and biggest, patch (their 0038). Gentoo patches create extra files which they then pass to patch, out patches get applied directly. So I'm now working through this one, and boy, is it long (over 3 lines). I'm again hopeful that the three will fix 78.3, and that the third on its own will fix 78.4. But not particularly close to testing that. On one of the updated cargo packages (proc-macro2) in the patch - version updated from 1.0.5 to 1.0.24 - in its caro.toml I see the following: +targets = ["x86_64-unknown-linux-gnu"] (no other targets mentioned near that) A quick gurgle on github shows this is the full latest version of it, so I am _hopeful_ that 32-bit x86 doesn't need this. But I'll mention it now just in case it comes back to bite someone. Over the weekend I expect to start updating my other systems to firefox-78.4.0 latest candidate (so far only one, build2) so I suspect that progress on moving the book to llvm-11 with rustc-1.47.0 and patches for 78 versions of firefox and thunderbird will now be a week away (or more if I decide to update all my packages and build a fresh up to date system). Thanks for the update Ken. No big hurry. A week will be fine. It would help if you took the tickets though to reduce the possibility of conflicts. -- 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] Fwd: Re: mupdf
On 10/14/20 11:43 AM, Ken Moffat via blfs-dev wrote: On Tue, Oct 13, 2020 at 11:11:13AM -0500, Bruce Dubbs via blfs-dev wrote: On 10/12/20 10:15 PM, Ken Moffat via blfs-dev wrote: On Mon, Oct 12, 2020 at 09:41:37PM -0500, Bruce Dubbs via blfs-dev wrote: They seem to be using system JBIG2DEC, JPEGXR, and GUMBO which we do not have. The package certainly doesn't document user.make. I see it now for the first time. The options -DJBIG_NO_MEMENTO -DTOFU -DTOFU_CJK are mysterious but appear to have soemthing to do with noto fonts. I can use that to do some tests, but I don't think it builds a shared library. Maybe we don't need a library though. First, can I offer my thanks to both you and Pierre for your work on this. But I wonder if we really need the shared library. People know that I like shared libs, at least when they are properly versioned, but I'm happy to build static libs which are only used within the same package. For mupdf itself we install multiple variants, and one or two other programs. I guess that those link to the shared lib and therefore the size of each program is reduced. I have a vague recollection that in the past something external might have been able to use mupdf (/me looks ...) : zathura (see Arch - the mupdf dep is optional). As a heretical "run it up a pole and see who salutes it" option, maybe we could build the static lib and only install the useful progs (without headers or libraries) ? That begs the question, of course, "do we need all the variants of mupdf ?". Just a thought. We could do the static libraries, but I think we've got the shared version working now. -- 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] Fwd: Re: mupdf
On 10/13/20 11:11 AM, Bruce Dubbs wrote: On 10/12/20 10:15 PM, Ken Moffat via blfs-dev wrote: On Mon, Oct 12, 2020 at 09:41:37PM -0500, 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 For *lightweight* PDF viewers I use epdfview and mupdf. On a full desktop build I eventually install evince, but I tend not to use that (too awkward, but ISTR it can fill in *some* PDF forms). Looking at fedora, does what is in https://src.fedoraproject.org/rpms/mupdf/blob/master/f/mupdf.spec match what you have been testing ? On a quick look they might be using using artifex's 'thread-safe' replacement for lcms2, not sure. They first patch thirdparty/lcms2 for big-endian builds, which we can happily ignore. But after that they apply 0001-support-PyMuPDF.patch which appears to be a build fix, from (or updated) earlier this month. They seem to be using system JBIG2DEC, JPEGXR, and GUMBO which we do not have. The package certainly doesn't document user.make. I see it now for the first time. The options -DJBIG_NO_MEMENTO -DTOFU -DTOFU_CJK are mysterious but appear to have soemthing to do with noto fonts. I can use that to do some tests, but I don't think it builds a shared library. Maybe we don't need a library though. I'll do some more with this tomorrow, thanks. - I was able to build mupdf with: cat > user.make << EOF USE_SYSTEM_FREETYPE := yes USE_SYSTEM_HARFBUZZ := yes USE_SYSTEM_JBIG2DEC := no USE_SYSTEM_JPEGXR := no # not used without HAVE_JPEGXR USE_SYSTEM_LCMS2 := no # need lcms2-art fork USE_SYSTEM_LIBJPEG := yes USE_SYSTEM_MUJS := no # build needs source anyways USE_SYSTEM_OPENJPEG := yes USE_SYSTEM_ZLIB := yes USE_SYSTEM_GLUT := no # need freeglut2-art fork USE_SYSTEM_CURL := yes USE_SYSTEM_GUMBO := no EOF export XCFLAGS=-fPIC && make $BFLAGS build=release && make prefix=/usr install With the above I get: $ ll -h install/usr/lib total 50M -rw-r--r-- 1 bdubbs bdubbs 48M Oct 13 00:02 libmupdf.a -rw-r--r-- 1 bdubbs bdubbs 2.2M Oct 13 00:02 libmupdf-third.a $ ll -h install/usr/bin total 172M -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-gl -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-x11 -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-x11-curl -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 muraster -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mutool If I add 'shared=yes to the 'make install' line, the build time goes from about 0.1 SBU to 0.7 SBU (at -j22) and the sizes are: $ ll -h install/usr/lib total 46M -rw-r--r-- 1 bdubbs bdubbs 46M Oct 13 10:58 libmupdf.so $ ll -h install/usr/bin total 836K -rwxr-xr-x 1 bdubbs bdubbs 364K Oct 13 10:58 mupdf-gl -rwxr-xr-x 1 bdubbs bdubbs 72K Oct 13 10:58 mupdf-x11 -rwxr-xr-x 1 bdubbs bdubbs 76K Oct 13 10:58 mupdf-x11-curl -rwxr-xr-x 1 bdubbs bdubbs 35K Oct 13 10:58 muraster -rwxr-xr-x 1 bdubbs bdubbs 287K Oct 13 10:58 mutool The extra time is used during the 'nmake install'. Adding 'shared=yes' to both the make and install lines fixes the build time. I think the package is good to go now. Will commit later today. Well it wasn't good. The linking was messed up. It took a while but I've got it solved and the package tested. Will update in a few minutes. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Fwd: Re: mupdf
On 10/12/20 10:15 PM, Ken Moffat via blfs-dev wrote: On Mon, Oct 12, 2020 at 09:41:37PM -0500, 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 For *lightweight* PDF viewers I use epdfview and mupdf. On a full desktop build I eventually install evince, but I tend not to use that (too awkward, but ISTR it can fill in *some* PDF forms). Looking at fedora, does what is in https://src.fedoraproject.org/rpms/mupdf/blob/master/f/mupdf.spec match what you have been testing ? On a quick look they might be using using artifex's 'thread-safe' replacement for lcms2, not sure. They first patch thirdparty/lcms2 for big-endian builds, which we can happily ignore. But after that they apply 0001-support-PyMuPDF.patch which appears to be a build fix, from (or updated) earlier this month. They seem to be using system JBIG2DEC, JPEGXR, and GUMBO which we do not have. The package certainly doesn't document user.make. I see it now for the first time. The options -DJBIG_NO_MEMENTO -DTOFU -DTOFU_CJK are mysterious but appear to have soemthing to do with noto fonts. I can use that to do some tests, but I don't think it builds a shared library. Maybe we don't need a library though. I'll do some more with this tomorrow, thanks. - I was able to build mupdf with: cat > user.make << EOF USE_SYSTEM_FREETYPE := yes USE_SYSTEM_HARFBUZZ := yes USE_SYSTEM_JBIG2DEC := no USE_SYSTEM_JPEGXR := no # not used without HAVE_JPEGXR USE_SYSTEM_LCMS2 := no # need lcms2-art fork USE_SYSTEM_LIBJPEG := yes USE_SYSTEM_MUJS := no # build needs source anyways USE_SYSTEM_OPENJPEG := yes USE_SYSTEM_ZLIB := yes USE_SYSTEM_GLUT := no # need freeglut2-art fork USE_SYSTEM_CURL := yes USE_SYSTEM_GUMBO := no EOF export XCFLAGS=-fPIC && make $BFLAGS build=release && make prefix=/usr install With the above I get: $ ll -h install/usr/lib total 50M -rw-r--r-- 1 bdubbs bdubbs 48M Oct 13 00:02 libmupdf.a -rw-r--r-- 1 bdubbs bdubbs 2.2M Oct 13 00:02 libmupdf-third.a $ ll -h install/usr/bin total 172M -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-gl -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-x11 -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-x11-curl -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 muraster -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mutool If I add 'shared=yes to the 'make install' line, the build time goes from about 0.1 SBU to 0.7 SBU (at -j22) and the sizes are: $ ll -h install/usr/lib total 46M -rw-r--r-- 1 bdubbs bdubbs 46M Oct 13 10:58 libmupdf.so $ ll -h install/usr/bin total 836K -rwxr-xr-x 1 bdubbs bdubbs 364K Oct 13 10:58 mupdf-gl -rwxr-xr-x 1 bdubbs bdubbs 72K Oct 13 10:58 mupdf-x11 -rwxr-xr-x 1 bdubbs bdubbs 76K Oct 13 10:58 mupdf-x11-curl -rwxr-xr-x 1 bdubbs bdubbs 35K Oct 13 10:58 muraster -rwxr-xr-x 1 bdubbs bdubbs 287K Oct 13 10:58 mutool The extra time is used during the 'nmake install'. Adding 'shared=yes' to both the make and install lines fixes the build time. I think the package is good to go now. Will commit later today. -- 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] mupdf
On 10/12/20 10:15 PM, Ken Moffat via blfs-dev wrote: On Mon, Oct 12, 2020 at 09:41:37PM -0500, 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 For *lightweight* PDF viewers I use epdfview and mupdf. On a full desktop build I eventually install evince, but I tend not to use that (too awkward, but ISTR it can fill in *some* PDF forms). Looking at fedora, does what is in https://src.fedoraproject.org/rpms/mupdf/blob/master/f/mupdf.spec match what you have been testing ? On a quick look they might be using using artifex's 'thread-safe' replacement for lcms2, not sure. They first patch thirdparty/lcms2 for big-endian builds, which we can happily ignore. But after that they apply 0001-support-PyMuPDF.patch which appears to be a build fix, from (or updated) earlier this month. They seem to be using system JBIG2DEC, JPEGXR, and GUMBO which we do not have. The package certainly doesn't document user.make. I see it now for the first time. The options -DJBIG_NO_MEMENTO -DTOFU -DTOFU_CJK are mysterious but appear to have soemthing to do with noto fonts. I can use that to do some tests, but I don't think it builds a shared library. Maybe we don't need a library though. I'll do some more with this tomorrow, thanks. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] mupdf
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 -- 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 ? I don't think so. It looks like a good plan to me. -- 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] gobject-introspection should be recommended for harfbuzz
On 10/7/20 10:38 AM, Douglas R. Reno via blfs-dev wrote: 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? 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. I agree. There are very few options for a GUI without pango (twm anyone?) there is really no reason to not build it. In that case g-i should probably be built for the first package that can use it. In that case, it is normally harfbuzz. -- 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] elogind/polkit/dbus circular dependencies
On 10/6/20 9:06 AM, Tim Tassonis via blfs-dev wrote: Hi all I'm in the process of building BLFS 10, which is the first time that I will have to build elogind. I'm currently a bit lost regarding the circular dependencies in this case, is this the correct order: 1. build X libraries 2. build dbus, without elogind 3. build elogind 4. build polkit 5. re-build dbus, with elogind Or is another other recommended? Yes, it is tricky. dbus elogind xorg libraries rebuild dbus polkit You don't need polkit for elogind at build time, just run time. -- 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] gnome-terminal (SysV) book
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 -- 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 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. -- 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] gnome-terminal (SysV) book
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. -- 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] gnome-terminal (SysV) book
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. -- 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] 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. Since this seems to be specific to major version 13, wouldn't it be better to put a warning in the book to recreate the database and catch the problem right away? -- 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] Reinstallation of packages
On 9/27/20 2:32 PM, DJ Lucas via blfs-dev wrote: Do we have a policy about reinstalls? If elogind is installed, both make-ca and Linux-PAM create a /usr/lib/systemd directory (and services). I intend to fix make-ca in a different way, but should instructions be added to prevent this or remove them? It would be better to have a simple way to prevent unneeded files from being installed. Existing configuration files should not be changed without a --force option or equivalent. -- 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] Libsoup-2.70.0 does not build with brotli-1.0.9
On 9/20/20 11:30 AM, Douglas R. Reno via blfs-dev wrote:
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
Seems easy enough:
sed -i 's/-R${libdir}//' scripts/*.in
-- 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] clang as a hard dependency, was Re: firefox (and js) -> rust -> llvm dependency
On 9/8/20 6:19 AM, Ken Moffat via blfs-dev wrote: On Mon, Aug 17, 2020 at 07:00:08PM +0100, Ken Moffat via blfs-dev wrote: On Mon, Aug 17, 2020 at 01:33:49PM +0800, Xi Ruoyao via blfs-dev wrote: I just drafted js78 page. When it was built, the building system utilized some LLVM tools (llvm-objdump and llvm-profdata). Is a rustc built with shipped LLVM providing llvm-objdump and llvm-profdata, which could be used during firefox or js build? If not we should list LLVM as a firefox/js hard dependency. It seems to. On my experimental build last month with llvm-11-rc I had to build rust with its shipped llvm. Clearly I had already installed those two programs, but looking at the log I see [1656/1728] Linking CXX executable bin/llvm-objdump and [1620/1728] Linking CXX executable bin/llvm-profdata In my current build with system llvm neither of those is mentioend in the log. Coming back to this, two points: 1. It might be that we should anyway list clang from llvm as a hard dependency. At some point before we released 10.0 I had hidden clang on this system - I guess that was while exploring thunderbird builds with gcc - and forgotten to reinstate it. Today I was trying to build firefox-81beta (if anyone else wants to build 81, please read the wiki - creating the python virtual environments has been separated out of ./mach build) and eventually got it to run ./mach build, only to fail because it couldn't find clang which is apparently needed for cbindgen to use. I have not yet played with current firefox-esr in the absence of clang, nor current js68, but I see from my firefox-78.2.0esr log: 0:22.46 checking for cbindgen... /usr/bin/cbindgen 0:22.46 checking for rustfmt... /opt/rustc/bin/rustfmt 0:22.46 checking for clang for bindgen... /usr/bin/clang++ 0:22.46 checking for libclang for bindgen... /usr/lib/libclang.so 0:22.46 checking that libclang is new enough... yes In practice, at the moment with rust using system llvm we recommend clang, but when llvm has its next release we'll probably have to drop back to the shipped llvm again, so bigger and slower llvm compiles. 2. In llvm, should we recommend clang instead of listing it as optional ? Yes. At the moment, both clang and compiler-rt are listed as optional. On my less-capable desktop/notebook machines I don't build compiler-rt, but obviously I build clang on all of them. I guess the real question is: Do BLFS users build llvm without clang, and if so, what do they use it for ? I do not know. I always build both clang and compiler-rt, but to be honest, I don't know what we would use compiler-rt for. -- Bruce -- 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.64.5 [solved]
On 9/5/20 4:45 PM, Bruce Dubbs wrote: I'm running into a problem with the glib-2.64.5 tests. Two tests are failing that I don't think failed before: 166/270 glib:gio / tls-certificate 168/270 glib:gio / tls-database They both have: Can't find module 'gnutls-pkcs11' specified in GIO_USE_TLS When I look at glib-networking-2.64.3/NEWS, there is a comment: 2.59.1 - November 11, 2018 This release removes the gnutls-pkcs11 backend, which was disabled in 2.57.2, due to lack of any feedback whatsoever regarding its disablement. If you think it is still useful to you, given that the normal gnutls backend now supports PKCS#11, speak up now. - Indeed we don't list glib-networking as a (circular) dependency of glib. I can disable these tests, try to fix them, or just document the test failures. The problem with fixing the tests is that I can't find where it defines 'gnutls-pkcs11'. It turns out this problem was mine. When building a new system I copy several files from the previous system. In this case I copied the entire directory /etc/profile.d/. In there I had an obsolete file, gio.sh, which set GIO_USE_TLS. Unsetting this environment variable allowed all tests to pass. Of course /etc/profile.d/gio.sh should also be deleted. Posting here just in case someone else runs into this problem. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] glib-2.64.5
I'm running into a problem with the glib-2.64.5 tests. Two tests are failing that I don't think failed before: 166/270 glib:gio / tls-certificate 168/270 glib:gio / tls-database They both have: Can't find module 'gnutls-pkcs11' specified in GIO_USE_TLS When I look at glib-networking-2.64.3/NEWS, there is a comment: 2.59.1 - November 11, 2018 This release removes the gnutls-pkcs11 backend, which was disabled in 2.57.2, due to lack of any feedback whatsoever regarding its disablement. If you think it is still useful to you, given that the normal gnutls backend now supports PKCS#11, speak up now. - Indeed we don't list glib-networking as a (circular) dependency of glib. I can disable these tests, try to fix them, or just document the test failures. The problem with fixing the tests is that I can't find where it defines 'gnutls-pkcs11'. Which is the best way to go? -- 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] VLAN support in BLFS network scripts
On 9/4/20 8:35 AM, Tim Tassonis via blfs-dev wrote: [snip] I assume that ppp gets some kind of revival due to some ISP's requiring it for fiber connections. Therefore I'd vote for de-archiving the package. It now even has systemd suppport! Not that I'd care personally, but probably useful for the systemd version of the book. We would probably need you to maintain that package in the book. Or at least someone who uses the package regularly. -- 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] VLAN support in BLFS network scripts
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-service 2018-04-18 19:18:07.739547066 +0200
+++ pppoe-service-vlan 2020-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-service 2018-04-18 19:18:07.739547066 +0200
+++ pppoe-service-vlan 2020-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 reasonable. Now I'm trying to find a pppoe script or
service file. We have install-service-pppoe in bootscripts/Makefile,
but no blfs/services/pppoe or blfs/ppp/pppoe. I don't have any pppoe
service file either.
-- 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] VLAN support in BLFS network scripts
On 9/3/20 5:44 PM, 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-service 2018-04-18 19:18:07.739547066 +0200
+++ pppoe-service-vlan 2020-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:
if [ -s "${REAL_IFACE}" ] && [ -s "x${REAL_IFACE}" ]
I'm not sure, though, if that would also be correct. The first one will
certainly work with any possible sh-like shell.
Those variables really look the same to me:
if [ "x${REAL_IFACE}" != "x" ] &&
[ "x${REAL_IFACE}" != "x" ]
What am I missing?
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] LFS and BLFS Version 10.0 are released
The Linux From Scratch community is pleased to announce the release of LFS Version 10.0, LFS Version 10.0 (systemd), BLFS Version 10.0, and BLFS Version 10.0 (systemd). This release is a major update to both LFS and BLFS. The LFS release includes updates to glibc-2.31, and binutils-2.34. A total of 35 packages have been updated. A new package, zstd-1.4.4, has also been added. Changes to text have been made throughout the book. The Linux kernel has also been updated to version 5.5.3. The BLFS version includes approximately 1000 packages beyond the base Linux From Scratch Version 9.1 book. This release has over 840 updates from the previous version in addition to numerous text and formatting changes. Thanks for this release goes to many contributors. Notably: Douglas Reno DJ Lucas Ken Moffat Thomas Trepl Pierre Labastie Tim Tassonis Xi Ruoyao You can read the books online[0]-[3], or download[4]-[7] to read locally. Please direct any comments about this release to the LFS development team at lfs-...@linuxfromscratch.org or blfs-...@linuxfromscratch.org. Registration for the mailing lists is required to avoid junk email. -- Bruce Dubbs LFS [0] http://www.linuxfromscratch.org/lfs/view/10.0/ [1] http://www.linuxfromscratch.org/blfs/view/10.0/ [2] http://www.linuxfromscratch.org/lfs/view/10.0-systemd/ [3] http://www.linuxfromscratch.org/blfs/view/10.0-systemd/ [4] http://www.linuxfromscratch.org/lfs/downloads/10.0/ [5] http://www.linuxfromscratch.org/blfs/downloads/10.0/ [6] http://www.linuxfromscratch.org/lfs/downloads/10.0-systemd/ [7] http://www.linuxfromscratch.org/blfs/downloads/10.0-systemd/ -- 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 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. It sounds like we would make an interface file like ifconfig.pppoe with custom defines and then have the other scripts test for them. A separate file such as /etc/lsb/pppoe would also be OK. -- 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] xfce4-pulseaudio-plugin
On 8/31/20 5:07 AM, Ryan Marsaw via blfs-dev wrote: On Mon, 31 Aug 2020, Ken Moffat via blfs-dev wrote: On Mon, Aug 31, 2020 at 03:11:02PM +0800, Xi Ruoyao via blfs-dev wrote: On 2020-08-31 07:49 +0100, Ken Moffat via blfs-dev wrote: > On Mon, Aug 31, 2020 at 01:20:52AM -0500, Bruce Dubbs via blfs-dev > wrote: > > On 8/31/20 1:10 AM, Ken Moffat via blfs-dev wrote: > > > The download link works, but the download is > > > xfce4-pulseaudio-plugin-xfce4-pulseaudio-plugin-0.4.3- > > > 9de2b7865ecb95bdd2cbaae00a17b23ae8455fe5.tar.bz2 > > > > > > I wonder if we should remark on this - in places we remark on > > > directory names which do not match the tarball. This one's > > > direcotry does match the tarball, but hte tarball name is > > > certainly not what I was expecting. > > > > Yes, it's pretty ugly. I did put in a note about it. > > > > -- Bruce > > > Ah, yeah, I see now 'This package extracts to a very non-standard > directory.' but I will argue that the directory, although very ugly, > is standard. That is, it matches the tarball name. It is the > tarball name which does not match what the link claims to download > > (xfce4-pulseaudio-plugin-0.4.3/xfce4-pulseaudio-plugin-0.4.3.tar.bz2) If wget is used to retrieve the file, the tarball name will be correct. But if a browser is used, it will be wrong. Right you are. Thanks. So, the user's options seem to be to use wget, and note that it will unpack to a very long and ugly directory name, or use a browser and get the same name in the tarball. The joys of github. This might seem like an obvious question, or maybe I'm missing something, but why not just use the same directory structure for xfce4-pulseaudio-plugin as the one that's used for the other XFCE packages? For pretty much all of XFCE, download location begins with "http://archive.xfce.org/ ..." For xfce4-pulseaudio-plugin, I use "https://archive.xfce.org/src/panel-plugins/xfce4-pulseaudio-plugin/0.4/xfce4-pulseaudio-plugin-0.4.3.tar.bz2; Also of note is that keybinder-3.0-0.3.2 is an optional download; not required. Secondly, my logs show no mention of xfce4-dev-tools-4.14.0 in the build. I'm not sure why this package is needed at all for XFCE (unless it has something to do with xfce4-pulseaudio-plugin being built with a Github download...) I didn't use that URL because I didn't find it. I'll change to that. Thanks a lot. I'll look at whether xfce4-dev-tools tools is needed or not. At first glance, it looks like the new tarball does no need it. -- 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] xfce4-pulseaudio-plugin
On 8/31/20 1:10 AM, Ken Moffat via blfs-dev wrote: The download link works, but the download is xfce4-pulseaudio-plugin-xfce4-pulseaudio-plugin-0.4.3-9de2b7865ecb95bdd2cbaae00a17b23ae8455fe5.tar.bz2 I wonder if we should remark on this - in places we remark on directory names which do not match the tarball. This one's direcotry does match the tarball, but hte tarball name is certainly not what I was expecting. Yes, it's pretty ugly. I did put in a note about it. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Possible missing dependency for pavucontrol
On 8/30/20 9:03 PM, Ken Moffat via blfs-dev wrote: I have not built libcanberra in recent times. I see now that it is recommended for inkscape, so in future I wil lbe building it for that to get closer to the book, and I see it gets used for plasma, kmix, and various gnome packages. Trying to build pavucontrol, configure failed with: checking for GUILIBS... no configure: error: Package requirements ( gtkmm-3.0 >= 3.0 sigc++-2.0 libcanberra-gtk3 >= 0.16 ) were not met: The required deps for pavucontrol are gtkmm3, libsigc++, and pulseaudio. I have all of those, and I don't think libcanberra is pulled in for any of them, so I think it ought to be added as a required dep for pavucontrol ? Nice of them to say something about it (not). I already had libcanberra installed so there was no problem for me, but there is no INSTALL file that mentions requirements and configure --help does not mention it. The only way to know that is to not have it when attempting to build. I don't know what you are using pavucontrol for, but it was added for xfce (xfce4-pulseaudio-plugin) and libcanberra is recommended for xfce4-settings. I'll add it. -- 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] pavucontrol placement
On 8/30/20 8:33 PM, Ken Moffat via blfs-dev wrote: Now that pavucontrol is i nh book, it is in 'Other X-based Programs' (chapter 41). As it is a volume control, should it not be in 'Audio Utilities' (chapter 43) alongside pnmixer ? Yes, it probably should be. It was in the archives under other x based programs, but audio utilities is probably better. -- 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] 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 ? Yes. It is an 'end' package. Nothing depends on it. -- 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] Permission to upgrade LSB-Tools post tagging
On 8/18/20 1:52 AM, DJ Lucas via blfs-dev wrote: A fix to the issue mentioned on support is included as well as dropping the sed. Also, not as important, but new bootscript releases in both books to get the failsafe for $syslog in place (it's unlikely to ever get triggered, but JIC). I think you can go ahead. Most of the references say (runtime) and several of the others may just not be marked that way but should be. Several that reference it are not tagged yet. It's not like there are libraries in the package. However, please make the change asap. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] LFS-10.0-rc1 is released
The Linux From Scratch community announces the release of LFS Version 10.0-rc1. It is a preliminary release of LFS-10.0. This version of the book has undergone a major reorganization. It uses enhanced cross-compilation techniques and an environment isolated from the host system to build tools for the final system. This reduces both the chance for changing the the host system and the potential of the host system influencing the LFS build process. Major changes include toolchain updates to binutils-2.35, gcc-10.2.0, and glibc-2.32. In total, 37 packages were updated since the last release. Changes to the text have also been made throughout the book. The Linux kernel has also been updated to version 5.8.1. We encourage all users to read through this release of the book and test the instructions so that we can make the final release as good as possible. You can read the book online [0], or download [1] to read locally. In coordination with this release, a new version of LFS using the systemd package is also being released. This package implements the newer systemd style of system initialization and control and is consistent with LFS in most packages. You can read the systemd version of the book online [2], or download [3] to read locally. -- Bruce [0] http://www.linuxfromscratch.org/lfs/view/10.0-rc1/ [1] http://www.linuxfromscratch.org/lfs/downloads/10.0-rc1/ [2] http://www.linuxfromscratch.org/lfs/view/10.0-systemd-rc1/ [3] http://www.linuxfromscratch.org/lfs/downloads/10.0-systemd-rc1/ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] asciidoc-9.0.2 requirements
On 8/12/20 3:00 PM, Ken Moffat via blfs-dev wrote: On Wed, Aug 12, 2020 at 02:54:30PM -0400, Joe Locash via blfs-dev wrote: asciidoc will not build without libxml2 or libxslt installed. To reproduce simply try building it on a fresh LFS install. For the editors, that is hard to test (we build the xml and docbook packages to be able to edit the book). And as a python package, it is hard to know what it does (output from the build and install is meagre). Do you have an example of the error mesage, and which command provokes it ? I've just done a build and DESTDIR install, docs with both those libs and docbook-xsl installed - no obvious references to xml or XML in the output. When things have quietened down I can easily hide those libe for testing, but disabling the docbook stuff now it has been installed fills me with terror (something to try on a system which is going nowhere). So I'd like to know what errors I should look for in this situation, and also if it is libxml2 or libxslt that causes the first error, please ? In a just built LFS, asciidoc returns: Making asciidoc-9.0.2 Wed Aug 12 03:13:37 PM CDT 2020 checking for a sed that does not truncate output... /bin/sed checking whether ln -s works... yes checking for a BSD-compatible install... /usr/bin/install -c configure: creating ./config.status config.status: creating Makefile Fixing CONF_DIR in asciidoc.py Fixing CONF_DIR in a2x.py python3 a2x.py -f manpage doc/testasciidoc.1.txt a2x: ERROR: "xmllint" --nonet --noout --valid "/build/asciidoc/asciidoc-9.0.2/doc/testasciidoc.1.xml" returned non-zero exit status 127 So I guess libxml2 is a required dependency. I'll fix it. -- 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] Perl modules in /usr/share/perl5
On 8/9/20 5:08 PM, Ken Moffat via blfs-dev wrote:
On Sun, Aug 09, 2020 at 04:49:05PM -0500, Bruce Dubbs via blfs-dev wrote:
On 8/9/20 4:20 PM, Ken Moffat via blfs-dev wrote:
On Sun, Aug 09, 2020 at 11:04:09AM -0500, Marty Jack via blfs-dev wrote:
The INSTALL file for git recommends the following incantation to derive the
path (at line 100).
This doesn't need updating when the Perl version changes.
perllibdir=/usr/$(/usr/bin/perl -MConfig -wle 'print substr
$Config{installsitelib}, 1 + length $$Config{siteprefixexp}')
I tested it with make perllibdir=that and make perllibdir=that install and it
worked.
If you should decide to move forward with taking git out of /usr/share.
Nice idea, although it will make a horrendously long line in the
book. But I think there is a typo somewhere.
I tried it in one of my experimental systems in chroot (where
modules are in /usr/lib) and got an error:
root in chroot ~# perllibdir=/usr/$(/usr/bin/perl -MConfig -wle 'print substr
$Config{installsitelib}, 1 + length $$Config{siteprefixexp}')
Use of uninitialized value in addition (+) at -e line 1.
root in chroot ~#
That line is not needed. See the ticket. It can be done with only one
simple variable on the 'make install' line.
Yes, I saw that but I'm not sure if Marty will have seen it. And it
still requires a hardcoded version.
We can live with a hard coded version. In the book's XML, it can be an
entity.
-- 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] Perl modules in /usr/share/perl5
On 8/9/20 4:20 PM, Ken Moffat via blfs-dev wrote:
On Sun, Aug 09, 2020 at 11:04:09AM -0500, Marty Jack via blfs-dev wrote:
The INSTALL file for git recommends the following incantation to derive the
path (at line 100).
This doesn't need updating when the Perl version changes.
perllibdir=/usr/$(/usr/bin/perl -MConfig -wle 'print substr
$Config{installsitelib}, 1 + length $$Config{siteprefixexp}')
I tested it with make perllibdir=that and make perllibdir=that install and it
worked.
If you should decide to move forward with taking git out of /usr/share.
Nice idea, although it will make a horrendously long line in the
book. But I think there is a typo somewhere.
I tried it in one of my experimental systems in chroot (where
modules are in /usr/lib) and got an error:
root in chroot ~# perllibdir=/usr/$(/usr/bin/perl -MConfig -wle 'print substr
$Config{installsitelib}, 1 + length $$Config{siteprefixexp}')
Use of uninitialized value in addition (+) at -e line 1.
root in chroot ~#
That line is not needed. See the ticket. It can be done with only one
simple variable on the 'make install' line.
-- 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] OpenLDAP client instructions
On 8/2/20 9:13 PM, Ken Moffat via blfs-dev wrote: Moving to the new-style LFS has greatly improved test results. I remember the development of 'pure lfs' where the tests were added, and at that time if the tests passed we got much better builds. So I mostly run all the LFS tests when building a new system. I'm keen to see working tests in LFS (although for much of what is in BLFS I'm ambivalent about the usefulness of the testsuites). What I have now in LFS (not yet committed) is: 806-glibc-2.31:FAIL: misc/tst-ttyname 824-gcc-10.2.0:FAIL: 22_locale/time_get/get_time/char/2.cc execution test 824-gcc-10.2.0:FAIL: 22_locale/time_get/get_time/wchar_t/2.cc execution test 824-gcc-10.2.0:FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test 824-gcc-10.2.0:FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution test 824-gcc-10.2.0:FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_env.cc execution test 824-gcc-10.2.0:FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test 833-libtool-2.4.6:123: compiling softlinked libltdl FAILED (standalone.at:35) 833-libtool-2.4.6:124: compiling copied libltdl FAILED (standalone.at:50) 833-libtool-2.4.6:125: installable libltdl FAILED (standalone.at:67) 833-libtool-2.4.6:126: linking libltdl without autotools FAILED (standalone.at:85) 833-libtool-2.4.6:130: linking libltdl without autotools FAILED (subproject.at:115) 865-tar-1.32:223: capabilities: binary store/restore FAILED (capabs_raw01.at:28) 867-vim-8.2.1209:1 FAILED: = That's without running autoconf tests. I have not investigated the tar and vim failures yet. Still waiting for glibc-2.32. I'm a bit disappointed as I didn't see anything in the mailing list and there are no commits since Friday morning. -- 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] OpenLDAP client instructions
On 8/2/20 6:21 PM, Ken Moffat via blfs-dev wrote: Testing re autoconf beta, I ran through the openldap client instructions (in a chroot throwaway build), all completed including the last one: ln -sf ../lib/slapd /usr/sbin/slapd But in the client configure we have: --disable-slapd And looking at what resulted shows me: oot@deluxe /tmp/openldap-2.4.50 #file /usr/sbin/slapd /usr/sbin/slapd: broken symbolic link to ../lib/slapd I think this is broken, but since I've had so much grief with openldap in the past that at one time I resolved never to install it, I thought I might as well ask before just removing the instruction *from the client only*. Better to ask than to be slapd down for missing something ;-) I subscribe to the autoconf mailing list. The stable release is a couple of months away. We will use the current version of autoconf for 10.0 and that works with OpenLDAP so lets leave it alone for now. -- 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] Thunderbird now requires dbus-glib.
On 7/25/20 8:45 PM, Ken Moffat via blfs-dev wrote: Some people may have seen my comments on the thunderbird-78.0.1 ticket, particularly about libxul.so failing to link to dbus-glib right at the end of the build. For those who didn't - I do not normally build t-bird, but I'm considering proposing that we update rustc to 1.45.0 before our next release (not yet certain if everything will be ok, I've built all except t-bird using that but I didn't run the tests for librsvg, and not entirely convinced if it will bring us anything concrete - the last forced update was for librsvg, I guess the next one will be the same). Oh, and I'm using newer rust to be able to build non-ESR firefoxes: 1.79.0 (candidate build 1) works ok with 1.45.0. With past builds of t-bird I've used the mozconfig from the book, even when I knew that I had already installed dbus-glib, without any problems. I wanted to build t-bird-78.0.1, so I tried with what was in the book for 78.0 but it fell over near the end (trying to link libxul.so), with errors about functions from dbus-glib not being found. I started by using gcc and rustc-1.45.0, so I formed the impression "book good, so problem with gcc or newer rust". Wrong! In the end I dropped back to rustc-1.42.0 with clang and got the same failure. I had thought the references to dbus in the includes must be for dbus-glib, but in fact I now realise they were for dbus itself. So I moved all the libs, headers and pkgconfig from dbus-glib out of the way. Retried, no change. Then I looked back at what I'd changed re dbus-glib in firefox: the requirement for dbus-glib was new in firefox-69, and then in October I moved the book to 68-esr (68.2.0) but kept the requirement to avoid later breakage, Sadly, that meant that the requirement for dbus-glib when ff-78 was released was no longer noticeable as a change from 68. With t-bird 78 the option --disable-dbus is still accepted, but it doesn't do anything useful and breaks the build. I've now built and briefly tested thunderbird with clang and rustc-1.42.0, so I propose to make dbus-glib required for thunderbird. I'll raise a ticket later. Meanwhile, I'm back to looking at using gcc for it - first with rustc-1.42.0 (I will again use -fstack-clash-protection in my flags), and then gcc+1.45.0. That's a lot of work. Now let me add that we will be going to gcc-10.2 next week. For LFS I'm waiting until the new glibc is release and then we'll test the new tool chain all at once. -- 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] 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. Agree. I can't duplicate the problem: Jobs Time(sec) SBU Build Size(MB) 22 154.6 1.9 284 12 152.9 1.8 284 8 159.3 1.9 284 4 216.1 2.6 284 1 606.4 7.3 284 Data is without tests or install. I think the -j12 was slightly faster due to caching, but for this package there doesn't seem to be any advantage for using more than 8 threads. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
