Re: [blfs-dev] New maintainer for URI (Perl module)
On Tue, 2 Mar 2021, Bruce Dubbs via blfs-dev wrote: 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 I might have spoken too soon. A new version of URI was released a couple of hours ago at the "old" download location. It's not at the "new" location. Perhaps you should hold off on changing the download location for URI for the time being. Cheers, Ryan-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] New maintainer for URI (Perl module)
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. Cheers, Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] A couple of Mesa switches need changing
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. Cheers, Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] p7zip has been forked (and is actively maintained)
On Fri, 5 Feb 2021, Douglas R. Reno via blfs-dev wrote: On 1/30/21 1:44 PM, Ryan Marsaw via blfs-dev wrote: Hello all. When I noticed that p7zip hadn't had a new release in nearly 5 years I checked to see if perhaps this package was picked up by someone else. Sure enough, I came across a fork of p7zip here: https://github.com/jinfeihan57/p7zip/ The page has this under the "About" section: "A new p7zip fork with additional codecs and improvements (forked from https://sourceforge.net/projects/p7zip/)." The fixes introduced by the BLFS p7zip patch are incorporated in this fork, and as far as I can see the build process is exactly same as the one for the existing p7zip. Cheers, Ryan Hi Ryan, Just following up here - we moved to p7zip-17.03, which is the latest version of the new fork, at r24176. It should be in the next render. Thank you again for bringing this up! - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Just a quick addendum: p7zip 17.03 compresses its man pages before installing. I noticed this when testing the install and inspecting the files afterwards. The behaviour can be avoided by suppressing the compression of the man pages: sed '/^gzip/d' -i install.sh Cheers, Ryan-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] (I know it's the wrong list) Be careful of binutils 2.36
On Mon, 1 Feb 2021, Pierre Labastie via blfs-dev wrote: On Tue, 2021-01-26 at 14:55 +0800, Xi Ruoyao via blfs-dev wrote: On 2021-01-25 19:33 -0500, Marty Jack via blfs-dev wrote: > I found that during the install phase the just installed ld won't > run against > the prior libctf which had not yet been installed. I ended up with > a > nonfunctional ld and had to recover it from another system and > reinstall > 2.35.1. Now holding off to see what others discover. I do not see > anyone > reporting a problem on their mailing list at this point. It's not so fatal. You can set LD_LIBRARY_PATH during make install to workaround. Sorry, I am unable to do that: I've tried: LD_LIBRARY_PATH=/build/dir/binutils-2.36/build/libctf/.libs \ make tooldir=/usr install and that is not enough... What worked for me is: make tooldir=/usr -C libctf install make toolsdir=/usr install Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page This issue looks a lot like the one in this thread: https://lists.gnu.org/archive/html/bug-binutils/2021-01/msg00340.html There's an upstream fix here: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f04ce15e831b691d7610dba284e266919e757b10 I haven't had the pleasure of building binutils-2.36 successfully yet, so I'm not sure if the above patch fixes the issue. Cheers, Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] p7zip has been forked (and is actively maintained)
Hello all. When I noticed that p7zip hadn't had a new release in nearly 5 years I checked to see if perhaps this package was picked up by someone else. Sure enough, I came across a fork of p7zip here: https://github.com/jinfeihan57/p7zip/ The page has this under the "About" section: "A new p7zip fork with additional codecs and improvements (forked from https://sourceforge.net/projects/p7zip/)." The fixes introduced by the BLFS p7zip patch are incorporated in this fork, and as far as I can see the build process is exactly same as the one for the existing p7zip. Cheers, Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] llvm-11.0.0 fails to compile
On Wed, 25 Nov 2020, John Burrell via blfs-dev wrote: I'm using the development version of the book, 2020-11-24 I get these error messages: [2299/4643] Building C object projects/compiler-rt/...les/clang_rt.tsan-x86_64.dir/rtl/tsan_rtl_amd64.S.o FAILED: projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan-x86_64.dir/rtl/tsan_rtl_amd64.S.o ninja: build stopped: subcommand failed. I tried adding a symlink for python to python-3.9 but that makes no difference. jb. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page I believe your build errors are due to CMake. If you're using cmake 3.19.0 then the build will fail. Version 3.19.1 of cmake was released yesterday which fixes the issues. Cheers, --Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] btrfs-progs needs new location for its pkgconfig file
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. Cheers, --Ryan -- 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 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...) Cheers, --Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] iptables-1.8.5 doesn't install "iptables-apply"
Hello all. Iptables doesn't install the iptables-apply program. This results in a dangling symlink "/sbin/ip6tables-apply" Reference: http://git.netfilter.org/iptables/commit/?id=d4ed0c741fc789bb09d977d74d30875fdd50d08b The fix is to edit iptables/Makefile.am: sed '/= iptables-apply/s/sbin_SCRIPT/&S/' -i iptables/Makefile.am (and then run autoreconf -fi) Cheers, --Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Can't install sudo-1.9.0 as a package user
On Mon, 1 Jun 2020, John Burrell via blfs-dev wrote: On Mon, 1 Jun 2020 at 11:35, Xi Ruoyao via blfs-dev wrote: On 2020-06-01 10:58 +0100, John Burrell via blfs-dev wrote: > I use MSB's package user package management system and up til now it > has worked fine but I've come unstuck installing sudo-1.9.0. > > I get: > > make[1]: Entering directory '/usr/src/security/sudo/sudo-1.9.0/lib/util' > /bin/sh ../../scripts/mkinstalldirs /usr/lib/sudo > case "" in \ > *-no-install*) ;; \ > *) if [ X"yes" = X"yes" ]; then \ > INSTALL_BACKUP='' /bin/sh ../../libtool --tag=disable-static --quiet > --mode=install /bin/sh ../../install-sh -c -o 0 -g 0 libsudo_util.la > /usr/lib/sudo; \ > fi;; \ > esac > /sbin/chown: changing ownership of > '/usr/lib/sudo/libsudo_util.so.0.0.0': Operation not permitted > make[1]: *** [Makefile:284: install] Error 1 > > In the dir lib/util the relevant bit of the Makefile.in is: > > install: install-dirs > case "$(LT_LDFLAGS)" in \ > *-no-install*) ;; \ > *) if [ X"$(shlib_enable)" = X"yes" ]; then \ > INSTALL_BACKUP='$(INSTALL_BACKUP)' $(LIBTOOL) > $(LTFLAGS) --quiet --mode=install $(INSTALL) $(INSTALL_OWNER) > libsudo_util.la $(DESTDIR)$(libexecdir)/sudo; \ > fi;; \ > esac > > install-dirs: > $(SHELL) $(scriptdir)/mkinstalldirs $(DESTDIR)$(libexecdir)/sudo > > install-binaries: > > install-includes: > > install-doc: > > install-plugin: > > I assume the chown occurs as part of the install-binaries but I can't > find the code for install-binaries. Could someone give me a clue as to > where I might find this code? I never use this package management approach but it does not make sense to install sudo with a non-root user owning it. sudo only works as a setuid-root executable. -- I set any necessary setuid-root binaries and the required root ownerships after installation. But at the moment I can't install it. I need to edit the Makefile to remove the chown on the library in /usr/lib/sudo but I don't know where that chown command is. Thanks jb. One change that can be made is by editing the Makefile.in: Look for these lines: # User and group ids the installed files should be "owned" by install_uid = 0 install_gid = 0 By replacing the 0s with the uid/gid of the user who's building Sudo, you'll be able to install Sudo in a DESTDIR way without any errors. Of course it'll be up to you to change the ownership of the files afterwards. The file permissions should not need to be modified (at least that's been my experience). Cheers, --Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] cpio breakage with GCC 10
Hi all. The cpio package has breakage with GCC 10. Here's a link to the issue (Gentoo): https://bugs.gentoo.org/705900 The fix is rather easy: sed -i '/The name/,+2 d' src/global.c Cheers, --Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] shared-mime-info's "update-mime-database" will need to be run after install
Hello. One of the changes with the latest shared-mime-info package is that its "update-mime-database" program is no longer called during the install phase. Without the MIME data in the database, gdk-pixbuf (at least -- there could be others) will fail to build. I suggest either having the (as root) user issue "/usr/bin/update-mime-database -V /usr/share/mime/" after install, or add "-Dupdate-mimedb=true" to the meson config options. Cheers, --Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Latest json-c breaks Cryptsetup
Hello all.
The latest json-c breaks the cryptsetup package with the following:
[...]
In file included from lib/luks2/luks2_disk_metadata.c:24:
lib/luks2/luks2_internal.h:61:10: error: conflicting types for
'json_object_get_uint64'
61 | uint64_t json_object_get_uint64(json_object *jobj);
| ^~
In file included from /usr/include/json-c/json.h:27,
from lib/luks2/luks2_internal.h:27,
from lib/luks2/luks2_disk_metadata.c:24:
/usr/include/json-c/json_object.h:725:22: note: previous declaration of
'json_object_get_uint64' was here
725 | JSON_EXPORT uint64_t json_object_get_uint64(const struct json_object
*obj);
| ^~
make[2]: *** [Makefile:2072: lib/luks2/libcryptsetup_la-luks2_disk_metadata.lo]
Error 1
[...]
Here's the link to the upstream commit:
https://gitlab.com/cryptsetup/cryptsetup/-/commit/604abec333a0efb44fd8bc610aa0b1151dd0f612?view=inline
I've create a patch based on the above, in case anyone's interested.
Cheers,
--Ryan--- cryptsetup-2.3.1-orig/lib/luks2/luks2_internal.h2020-03-08
05:53:44.0 -0400
+++ cryptsetup-2.3.1/lib/luks2/luks2_internal.h 2020-04-22 06:45:22.396200853
-0400
@@ -58,9 +58,11 @@
void hexprint_base64(struct crypt_device *cd, json_object *jobj,
const char *sep, const char *line_sep);
+#if !(defined JSON_C_VERSION_NUM && JSON_C_VERSION_NUM >= ((13 << 8) | 99))
uint64_t json_object_get_uint64(json_object *jobj);
-uint32_t json_object_get_uint32(json_object *jobj);
json_object *json_object_new_uint64(uint64_t value);
+#endif
+uint32_t json_object_get_uint32(json_object *jobj);
int json_object_object_add_by_uint(json_object *jobj, unsigned key,
json_object *jobj_val);
void json_object_object_del_by_uint(json_object *jobj, unsigned key);
--- cryptsetup-2.3.1-orig/lib/luks2/luks2_json_metadata.c 2020-03-02
06:59:29.0 -0500
+++ cryptsetup-2.3.1/lib/luks2/luks2_json_metadata.c2020-04-22
06:45:37.193201347 -0400
@@ -234,13 +234,14 @@
tmp = strtoull(json_object_get_string(jobj), &endptr, 10);
if (*endptr || errno) {
*value = 0;
- return FALSE;
+ return 0;
}
*value = tmp;
- return TRUE;
+ return 1;
}
+#if !(defined JSON_C_VERSION_NUM && JSON_C_VERSION_NUM >= ((13 << 8) | 99))
uint64_t json_object_get_uint64(json_object *jobj)
{
uint64_t r;
@@ -262,6 +263,7 @@
jobj = json_object_new_string(num);
return jobj;
}
+#endif
/*
* Validate helpers
@@ -273,9 +275,9 @@
for (i = 0; key[i]; i++)
if (!isdigit(key[i])) {
log_dbg(cd, "%s \"%s\" is not in numbered form.", name,
key);
- return FALSE;
+ return 0;
}
- return TRUE;
+ return 1;
}
json_object *json_contains(struct crypt_device *cd, json_object *jobj, const
char *name,
@@ -300,7 +302,7 @@
errno = 0;
tmp = json_object_get_int64(jobj);
- return (errno || tmp < 0 || tmp > UINT32_MAX) ? FALSE : TRUE;
+ return (errno || tmp < 0 || tmp > UINT32_MAX) ? 0 : 1;
}
static json_bool validate_keyslots_array(struct crypt_device *cd,
@@ -313,17 +315,17 @@
jobj = json_object_array_get_idx(jarr, i);
if (!json_object_is_type(jobj, json_type_string)) {
log_dbg(cd, "Illegal value type in keyslots array at
index %d.", i);
- return FALSE;
+ return 0;
}
if (!json_contains(cd, jobj_keys, "", "Keyslots section",
json_object_get_string(jobj),
json_type_object))
- return FALSE;
+ return 0;
i++;
}
- return TRUE;
+ return 1;
}
static json_bool validate_segments_array(struct crypt_device *cd,
@@ -336,17 +338,17 @@
jobj = json_object_array_get_idx(jarr, i);
if (!json_object_is_type(jobj, json_type_string)) {
log_dbg(cd, "Illegal value type in segments array at
index %d.", i);
- return FALSE;
+ return 0;
}
if (!json_contains(cd, jobj_segments, "", "Segments section",
json_object_get_string(jobj),
json_type_object))
- return FALSE;
+ return 0;
i++;
}
- return TRUE;
+ return 1;
}
static json_bool segment_has_digest(const char *segment_name, json_object
*jobj_digests)
@@ -357,10 +359,10 @@
UNUSED(key);
json_object_object_get_ex(val, "segments", &jobj_segments);
if (LUKS2_array_jobj(jobj_segments, segment_name))
- return TRUE;
+
Re: [blfs-dev] v4l-utils and SDL2 (may require setting flags)
On Mon, 30 Mar 2020, Bruce Dubbs via blfs-dev wrote: On 3/30/20 1:50 PM, Ryan Marsaw via blfs-dev wrote: Hello all. When building v4l-utils per BLFS instructions I get the following at the configure stage: [...] checking for SDL2... no [...] The only way I could get v4l-utils to recognize SDL2 was to set SDL2_LIBS and SDL2_CFLAGS: SDL2_LIBS=/usr/lib SDL2_CFLAGS=/usr/include/SDL2 ./configure ... Can anyone else confirm this? Did you try running ldconfig? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Hi Bruce. It appears the reason SDL2 wasn't being picked up by v4l-utils is that it checks for SDL2 as well as SDL_image, which is a separate package: https://www.libsdl.org/projects/SDL_image/ I installed SDL_image and v4l-utils was then able to detect SDL2 as per BLFS instructions. Perhaps a note on the v4l-utils page should mention that SDL_image is required in order to have SDL2 support. Cheers, --Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] v4l-utils and SDL2 (may require setting flags)
On Mon, 30 Mar 2020, Bruce Dubbs via blfs-dev wrote: On 3/30/20 1:50 PM, Ryan Marsaw via blfs-dev wrote: Hello all. When building v4l-utils per BLFS instructions I get the following at the configure stage: [...] checking for SDL2... no [...] The only way I could get v4l-utils to recognize SDL2 was to set SDL2_LIBS and SDL2_CFLAGS: SDL2_LIBS=/usr/lib SDL2_CFLAGS=/usr/include/SDL2 ./configure ... Can anyone else confirm this? Did you try running ldconfig? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page I ran it just now, and received the same message. --Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] v4l-utils and SDL2 (may require setting flags)
Hello all. When building v4l-utils per BLFS instructions I get the following at the configure stage: [...] checking for SDL2... no [...] The only way I could get v4l-utils to recognize SDL2 was to set SDL2_LIBS and SDL2_CFLAGS: SDL2_LIBS=/usr/lib SDL2_CFLAGS=/usr/include/SDL2 ./configure ... Can anyone else confirm this? Cheers, --Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Cryptsetup is at version 2.3.0 (book has 2.0.6)
On Thu, 27 Feb 2020, Bruce Dubbs via blfs-dev wrote: On 2/27/20 3:51 PM, Ryan Marsaw via blfs-dev wrote: Hello everyone. The "cryptsetup" BLFS package is listed as version 2.0.6. The latest version is 2.3.0 The latest version at https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.0/ is version 2.0.6. Is there someplace else updating that package? The instructions for the build of cryptsetup don't need to be changed, but I did notice that the default cryptograhic backend is now OpenSSL, so the configuration switch "--with-crypto_backend=openssl" doesn't need to be set explicitly (unless one wants a different backend (one of gcrypt/nss/kernel/nettle)) We can look at it after the 9.1 release, butconfigure says the default is 'crypt'. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Hi Bruce. Cryptsetup is now hosted on GitLab (for how long I don't know, but at least as long as I've been using it -- more than 3 years now) https://gitlab.com/cryptsetup/cryptsetup/-/tags Release tarballs: https://www.kernel.org/pub/linux/utils/cryptsetup/v2.3/cryptsetup-2.3.0.tar.xz --Ryan-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Cryptsetup is at version 2.3.0 (book has 2.0.6)
Hello everyone. The "cryptsetup" BLFS package is listed as version 2.0.6. The latest version is 2.3.0 The instructions for the build of cryptsetup don't need to be changed, but I did notice that the default cryptograhic backend is now OpenSSL, so the configuration switch "--with-crypto_backend=openssl" doesn't need to be set explicitly (unless one wants a different backend (one of gcrypt/nss/kernel/nettle)) Cheers! --Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] gcc 9.1 instructions in BLFS
On Fri, 5 Jul 2019, Bruce Dubbs via blfs-dev wrote:
In the current gcc-9.1 instructions after 'make install' we have:
mkdir -pv /usr/share/gdb/auto-load/usr/lib &&
mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib &&
chown -v -R root:root \
/usr/lib/gcc/*linux-gnu/9.1.0/include{,-fixed}
In the first segment, my build script stopped becasue there are no
/usr/lib/*gdb.py files. Indeed, I have no /usr/lib/*.py files at all.
I do have /usr/share/gdb/auto-load/usr/lib, but that was installed bu
gcc in LFS.
In the second segment, I ran the chown command by hand and got
"ownership of '' retained as root:root" in every case.
I recommend removing these statements, but want to ask for other opinions.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Hi Bruce.
For the first segment, GCC chapter 6 reports the following:
[...]
make[2]: Leaving directory '/sources/gcc-9.1.0/build/gcc'
make[1]: Leaving directory '/sources/gcc-9.1.0/build'
'/usr/bin/cc' -> 'gcc'
install: creating directory '/usr/lib/bfd-plugins'
'/usr/lib/bfd-plugins/liblto_plugin.so' ->
'../../libexec/gcc/x86_64-pc-linux-gnu/9.1.0/liblto_plugin.so'
mkdir: created directory '/usr/share/gdb'
mkdir: created directory '/usr/share/gdb/auto-load'
mkdir: created directory '/usr/share/gdb/auto-load/usr'
mkdir: created directory '/usr/share/gdb/auto-load/usr/lib'
renamed '/usr/lib/libstdc++.so.6.0.26-gdb.py' ->
'/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.26-gdb.py'
[...]
So it appears that on my build, there is indeed one *gdb.py file to be
moved.
As for the second segment, I don't see any of that stuff on the GCC
page.
Regards,
-- Ryan
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] LLVM's dependency on libyaml
Hello all. On the LLVM page there's listed an optional dependency on libyaml. According to my logs (from the configuration phase) I get the following: [..] -- Could NOT find Python module yaml [..] I'm wondering if the dependency should be on the PyYAML Python module rather than on just the libyaml libraries? Cheers, -- Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Alternate location for apng patch for libpng
Hello. There's another location for the apng patch: https://sourceforge.net/projects/apng/files/libpng/libpng16/ I find this location better because it updates the patch quicker than the libpng sourceforce site. It needs a "-p0" instead of the traditional "-p1" when applying. Cheers, -- Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Gawk 5.0.0 breaks libgpg-error (patch included)
Hello all.
The new gawk 5.0.0 breaks libgpg-error:
[...]
gawk: fatal: cannot use gawk builtin `namespace' as variable name
make[2]: *** [Makefile:1617: errnos-sym.h] Error 2
[...]
The problem's been fixed upstream, but until a new libgpg-error comes
out I've included a patch that fixes the above issue and allows it to
build with the new gawk.
Note that "autoreconf --verbose --force --install"
will need to be issued after applying the patch.
Cheers,
Ryan--- libgpg-error-1.36-orig/lang/cl/mkerrcodes.awk 2013-03-15
15:24:25.0 -0400
+++ libgpg-error-1.36/lang/cl/mkerrcodes.awk2019-04-16 12:43:50.623999689
-0400
@@ -122,7 +122,7 @@
}
!header {
- sub (/\#.+/, "");
+ sub (/#.+/, "");
sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
if (/^$/)
--- libgpg-error-1.36-orig/src/Makefile.am 2018-12-12 03:14:31.0
-0500
+++ libgpg-error-1.36/src/Makefile.am 2019-04-16 12:50:59.499036057 -0400
@@ -293,7 +293,7 @@
errnos-sym.h: Makefile mkstrtable.awk errnos.in
$(AWK) -f $(srcdir)/mkstrtable.awk -v textidx=2 -v nogettext=1 \
- -v prefix=GPG_ERR_ -v namespace=errnos_ \
+ -v prefix=GPG_ERR_ -v pkg_namespace=errnos_ \
$(srcdir)/errnos.in >$@
--- libgpg-error-1.36-orig/src/mkerrcodes.awk 2013-03-15 15:24:25.0
-0400
+++ libgpg-error-1.36/src/mkerrcodes.awk2019-04-16 12:44:56.404005267
-0400
@@ -85,7 +85,7 @@
}
!header {
- sub (/\#.+/, "");
+ sub (/#.+/, "");
sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
if (/^$/)
--- libgpg-error-1.36-orig/src/mkerrcodes1.awk 2013-03-15 15:24:25.0
-0400
+++ libgpg-error-1.36/src/mkerrcodes1.awk 2019-04-16 12:45:23.126007533
-0400
@@ -81,7 +81,7 @@
}
!header {
- sub (/\#.+/, "");
+ sub (/#.+/, "");
sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
if (/^$/)
--- libgpg-error-1.36-orig/src/mkerrcodes2.awk 2013-03-15 15:24:25.0
-0400
+++ libgpg-error-1.36/src/mkerrcodes2.awk 2019-04-16 12:45:42.925009212
-0400
@@ -91,7 +91,7 @@
}
!header {
- sub (/\#.+/, "");
+ sub (/#.+/, "");
sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
if (/^$/)
--- libgpg-error-1.36-orig/src/mkerrnos.awk 2013-03-15 15:24:25.0
-0400
+++ libgpg-error-1.36/src/mkerrnos.awk 2019-04-16 12:45:58.863010563 -0400
@@ -83,7 +83,7 @@
}
!header {
- sub (/\#.+/, "");
+ sub (/#.+/, "");
sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
if (/^$/)
--- libgpg-error-1.36-orig/src/mkstrtable.awk 2013-03-15 15:24:25.0
-0400
+++ libgpg-error-1.36/src/mkstrtable.awk2019-04-16 12:46:19.520012315
-0400
@@ -77,7 +77,7 @@
#
# The variable prefix can be used to prepend a string to each message.
#
-# The variable namespace can be used to prepend a string to each
+# The variable pkg_namespace can be used to prepend a string to each
# variable and macro name.
BEGIN {
@@ -102,7 +102,7 @@
print "/* The purpose of this complex string table is to produce";
print " optimal code with a minimum of relocations. */";
print "";
- print "static const char " namespace "msgstr[] = ";
+ print "static const char " pkg_namespace "msgstr[] = ";
header = 0;
}
else
@@ -110,7 +110,7 @@
}
!header {
- sub (/\#.+/, "");
+ sub (/#.+/, "");
sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
if (/^$/)
@@ -150,7 +150,7 @@
else
print " gettext_noop (\"" last_msgstr "\");";
print "";
- print "static const int " namespace "msgidx[] =";
+ print "static const int " pkg_namespace "msgidx[] =";
print " {";
for (i = 0; i < coded_msgs; i++)
print "" pos[i] ",";
@@ -158,7 +158,7 @@
print " };";
print "";
print "static GPG_ERR_INLINE int";
- print namespace "msgidxof (int code)";
+ print pkg_namespace "msgidxof (int code)";
print "{";
print " return (0 ? 0";
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] yaml-0.2.2
On Fri, 29 Mar 2019, Bruce Dubbs via blfs-dev wrote: On 3/29/19 6:42 AM, Roger Koehler via blfs-dev wrote: I am using the Sys V version: make[1]: Entering directory '/sources/yaml/libyaml-0.2.2' make[1]: *** No rule to make target 'build'. Stop You are supposed to be IN directory build. mkdir build && cdbuild && cmake ... && make If you are scripting, note that after extracting, you need to cd to libyaml-0.2.2 and not yaml-0.2.2. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page The first line of the installation of YAML 0.2.2 reads: make build && cd build && That should be "mkdir build && cd build &&" I believe that's what's causing Rogers's error. There are other issues with this version of YAML that I wanted to write about: Firstly, the download link saves the file libyam-0.2.2.tar.gz and extracts to the same file name, so the line that reads "This package expands to libyaml-0.2.2, not the expected yaml-0.2.2" does not seem valid for this version. Secondly, the build system for yaml 0.2.2 is CMake, which does not build and install the pkconfig file yaml-0.1.pc (although yaml-0.1.pc.in is in the directory). Instead there are a few *.cmake files (under /usr/cmake). Because of this some packages cannot find libyaml in order to build (one of them is libblockdev). I needed to revert to the autotools build system to get yaml working: ./bootstrap && ./configure .. etc. Cheers, -- Ryan-- 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 8.3 systemd - XTerm fails to build with "-fa" option for FreeType
On Fri, 22 Mar 2019, Mark Wigzell via blfs-dev wrote: The doc talks about installing DejaVu so one can have some fonts for xterm, however xterm builds without support for FreeType. I added "--with-freetype-config=freetype-config" to the configure which supplied the "freetype2" lib, but the "Xft" lib was not used, because of a confusion of configuration around this issue, which was very difficult to understand. I was unable to pass "--with-freetype-libs" with "-lXft" or with "no" or any other value successfully. Finally I edited the "configure" script and forced the "-lXft" value into an appropriate variable. Then xterm finally built with "-fa" option, and I was able to use DejaVu fonts. I believe some kind of modification to the doc to tell people how to actually make an xterm use DejaVu fonts is in order? In what order are you building Freetype and the Xorg Libraries? Here's what I have: Freetype (first pass) --> Fontconfig --> Xorg Libraries... (bunch of others)... --> Harfbuff --> Freetype (second pass) Looking at my logs for Xterm: [...] checking for FreeType config... /usr/bin/pkg-config xft checking for /usr/bin/pkg-config cflags... -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/uuid checking for /usr/bin/pkg-config libs... -lXft checking if we can link with FreeType libraries... yes [...] Freetype with Xft would seem to be required. AFAIK Xft is a Xorg Library. Did you install Freetype before the Xorg Libraries? Also, it might not hurt to build Freetype again (after installing Harfbuzz -- as recommended in BLFS). Cheers, -- Ryan-- 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 8.3 systemd - Firefox/Python2/POSIX semaphores broken ?
On Fri, 22 Mar 2019, Mark Wigzell via blfs-dev wrote: Hey guys, I recently added some BLFS support and got "startx" running, at which point I decided to run "firefox" so I can follow along with further installation of packages. However "firefox" wouldn't build because it turns out "python2" determined (during its configuration), that POSIX semaphores were not supported. This occurred both when booted and also when "chrooted" to LFS partition. Up until success with "startx" I was mostly running with "chroot" since that is easier.The failure occurred when testing the result of generating a code file to use "sem_open()". When I tried that code myself, it built and ran perfectly. So my temp. solution is to force the configure of Python2 so that it believes that the test worked. After that I could build Python2 with sempahores enabled, and thus firefox went without a hitch. I came accross this very problem back in December 2017. At around that point the Firefox build system was tweaked somewhat to check for that "sem_open()" test. I was also running in a chroot environment when I built Python 2 and Firefox. After quite a bit of dissection I discovered that the issue (in my case anyway -- but will probably apply to you as well) is that the permissions on the the /run/shm directory were not set "properly" for the semaphore test to complete successfully. In LFS "6.2. Preparing Virtual Kernel File Systems" there is a line that creates the /run/shm directory using the following: if [ -h $LFS/dev/shm ]; then mkdir -pv $LFS/$(readlink $LFS/dev/shm) fi At that point the permissions on /run/shm are 0755. If a user does not reboot the system before building Python 2, the permissions on /run/shm remain at 0755 (they change to 1777 upon reboot). Without world execute permissions on /run/shm the Python test does not seem to work. How I "fixed" the issue was to set permissions on /run/shm to 1777/drwxrwxrwt in LFS section 6.2, thereby keeping the right permissions on /run/shm throughout the remaining LFS sections, plus BLFS in the chroot environment. However, I read Ken's response to your query and he uses the chroot environment too, so I'm curious if you've done anything differently in your setup, Ken? For what it's worth, I wrote about this issue here: http://lists.linuxfromscratch.org/pipermail/blfs-dev/2017-December/033789.html Cheers, -- Ryan-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Ignoring --enable-threadsafe : Unknown option (JS-52.2.1gnome1)
Hello. I noticed that BLFS has "--enable-threadsafe" as a configuration switch for the "JS-52.2.1gnome1" package. A harmless warning: Ignoring --enable-threadsafe : Unknown option Regards, -- Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] OpenSSH using DESTDIR (ssh-keygen needs to be run after install)
On Wed, 6 Mar 2019, Bruce Dubbs via blfs-dev wrote: On 3/6/19 5:12 PM, Ryan Marsaw via blfs-dev wrote: Hello all. I noticed that when building OpenSSH using the DESTDIR install, the "ssh-keygen" program fails to generate the host keys due to non-root access to the /etc/ssh directory. The install phase of OpenSSH shows this: [...] Could not load host key: /etc/ssh/ssh_host_rsa_key Could not load host key: /etc/ssh/ssh_host_ecdsa_key Could not load host key: /etc/ssh/ssh_host_ed25519_key [...] So if building OpenSSH with the DESTDIR method, the ssh-keygen program needs to be run as root manually after installing the package: ssh-keygen -v -A We don't generally use the DESTDIR method in the books. AFAIK, rustc is the only package in the book that uses it. Should we really need to address this every time? What about users using package management? If you follow the instructions in the book, things work. When deviating, users should be able to figure things out for themselves. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Yeah that's a good point I suppose. In general DESTDIR works fine. It's just those packages that need to generate files outside of the tree that need those special instructions. Aside from librsvg and openssh there are no packages (at least the ones I use) that require those instructions in the DESTDIR builds (well, besides the ones that were already in the BLFS book before today). -- Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] OpenSSH using DESTDIR (ssh-keygen needs to be run after install)
Hello all. I noticed that when building OpenSSH using the DESTDIR install, the "ssh-keygen" program fails to generate the host keys due to non-root access to the /etc/ssh directory. The install phase of OpenSSH shows this: [...] Could not load host key: /etc/ssh/ssh_host_rsa_key Could not load host key: /etc/ssh/ssh_host_ecdsa_key Could not load host key: /etc/ssh/ssh_host_ed25519_key [...] So if building OpenSSH with the DESTDIR method, the ssh-keygen program needs to be run as root manually after installing the package: ssh-keygen -v -A Regards, -- Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] librsvg needs "gdk-pixbuf-query-loaders" command if using DESTDIR
On Wed, 6 Mar 2019, Bruce Dubbs via blfs-dev wrote: On 3/6/19 1:02 PM, Ryan Marsaw via blfs-dev wrote: Hello all. I discovered that if librsvg is installed via the "DESTDIR" method, its svg loadable module info is not updated in the "loaders.cache" file. I discovered this when attempting to build the adwaita-icon-theme package. When trying to build the svg icons, I got flooded with "Can't load file: Unrecognized image file format" Therefore, issuing a "gdk-pixbuf-query-loaders --update-cache" as root user needs to be run after installing librsvg using a "DESTDIR" install. The same message that we have now in gdk-pixbuf? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Correct. To test this out, I uninstalled librsvg, and then updated the "loaders.cache" file (thereby removing the references to the "svg" module) and then proceeded to build adwaita icon theme once again. "Can't load file: Unrecognized image file format" errors once again. Once I issued "gdk-pixbuf-query-loaders --update-cache," the "loaders.cache" file gets updated. I ran a diff on the two versions of loaders.cache (one with librsvg module updated and the one without): "/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so" "svg" 6 "gdk-pixbuf" "Scalable Vector Graphics" "LGPL" "image/svg+xml" "image/svg" "image/svg-xml" "image/vnd.adobe.svg+xml" "text/xml-svg" "image/svg+xml-compressed" "" "svg" "svgz" "svg.gz" "" " By updating the cache there are now entries for "svg." The cache needs updating only when using the DESTDIR install. Just now I looked at my logs for the librsvg package and came across this: make install-data-hook make[4]: Entering directory '/usr/src/librsvg-2.45.5/gdk-pixbuf-loader' *** *** Warning: loaders.cache not built *** *** Generate this file manually on host *** system using gdk-pixbuf-query-loaders *** Yes, I know I'm using a development build of librsvg but other versions surely will have the same issue. I suppose it's because "gdk-pixbuf-query-loaders" cannot be run as a regular user (or at least, the loaders.cache file cannot be accessed by a regular user). Regards, -- Ryan-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] librsvg needs "gdk-pixbuf-query-loaders" command if using DESTDIR
Hello all. I discovered that if librsvg is installed via the "DESTDIR" method, its svg loadable module info is not updated in the "loaders.cache" file. I discovered this when attempting to build the adwaita-icon-theme package. When trying to build the svg icons, I got flooded with "Can't load file: Unrecognized image file format" Therefore, issuing a "gdk-pixbuf-query-loaders --update-cache" as root user needs to be run after installing librsvg using a "DESTDIR" install. Cheers, -- Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Is six really required for libtasn1?
On Tue, 22 Jan 2019, Pierre Labastie via blfs-dev wrote: Hi, On the libtasn1 page, the dependency on "six" has been added at revision 20311 (August 15th, 2018, by bdubbs)). But I do not see any reference to six (except in the word posix) in the libtasn1 build tree, and I do not any reference to python either. I suspect it is an oversight (rev 20311 is a big commit with several lfs83_checked tags and two updates), but before removing this dependency, I'd rather ask first if there is/was a reason to add it. Regards Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page I keep a log of all my BLFS package installations, and I see no reference to "six" for libtasn1 either. Another package that has "six" as a required dep is GTK+ 3. I don't see any reference to "six" in that package either unless it has something to do with wayland/wayland-protocols (which I do not build for my GTK+-3). -- Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] upower-0.99.9 download link
On Mon, 21 Jan 2019, Wayne Blaszczyk via blfs-dev wrote: Hi, The UPower download link does not work for me. Regards, Wayne. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page The new link should point to GitLab: https://gitlab.freedesktop.org/upower/upower/uploads/2282c7c0e53fb31816b824c9d1f547e8/upower-0.99.9.tar.xz -- Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Location changes of certain BLFS packages
Hello everyone. There are some packages in BLFS whose download locations should be updated. Here's a list of what I've come across: 1) URI (perl module) This module seems to be maintained by another developer: https://cpan.metacpan.org/authors/id/O/OA/OALDERS/ The latest version of URI is 1.76 (BLFS book has 1.74) 2) UPower For over a year UPower has been maintained through GitLab. https://gitlab.freedesktop.org/upower/upower/tags Current version is 0.99.9 (BLFS book as 0.99.7) 3) LVM2 Development seems to still be maintained through GitHub, but the release tarballs haven't been listed on the GitHub page in a bit. Here's where I download the tarballs: https://sourceware.org/ftp/lvm2/ Latest version is 2.03.02 (BLFS book has 2.03.01) Cheers! -- Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Poppler 0.73.0 and XPDF Headers
Hello all. Poppler 0.73.0 changed the XPDF headers switch (from the NEWS file:) ... build system: * Rename ENABLE_XPDF_HEADERS to ENABLE_UNSTABLE_API_ABI_HEADERS ... Indeed, when running the BLFS instructions I get the following: "CMake Warning: Manually-specified variables were not used by the project: ENABLE_XPDF_HEADERS" Regards, -- Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libuv-1.24.1
On Sun, 23 Dec 2018, spiky0011 via blfs-dev wrote: On 23/12/2018 14:44, Ryan Marsaw via blfs-dev wrote: On Sun, 23 Dec 2018, spiky0011 via blfs-dev wrote: I think this Package needs looking at. It requires cmake to build, but cmake requires it as a dep? The configure needs to be changed back to sh autogen.sh && ./configure --prefix=/usr --disable-static && make make install Technically, system libuv is not required to build CMake. I don't use libuv for any BLFS packages. Here's my CMake bootstrap line: ./bootstrap --prefix=/usr \ --system-libs \ --mandir=/share/man \ --no-system-jsoncpp \ --no-system-librhash \ --docdir=/share/doc/cmake-3.13.2 \ -- -DCMAKE_USE_SYSTEM_LIBRARY_LIBUV=false That last part (-- -DCMAKE_...) allows the built-in version of libuv to be used, instead of the system one. However, the BLFS philosophy, as I take it, is to build system versions of libraries whenever possible, in order to address issues of security that may not have been addressed in the in-tree versions of packages. I agree though that if system libuv is a *required* dependency then there is a circular dependency which should be addressed... Happy Holidays, -- Ryan Then the configure script for cmake needs to have that added to it, or change the script for "libuv". The other issue is, is the LIBUV with cmake upto date? -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page According to cmake-3.13.2/Utilities/cmlibuv/include/uv-version.h: #define UV_VERSION_MAJOR 1 #define UV_VERSION_MINOR 20 #define UV_VERSION_PATCH 3 #define UV_VERSION_IS_RELEASE 0 #define UV_VERSION_SUFFIX "dev" So it looks like they're using 1.20.3, and by the looks of it, a development version at that. -- Ryan-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libuv-1.24.1
On Sun, 23 Dec 2018, spiky0011 via blfs-dev wrote: I think this Package needs looking at. It requires cmake to build, but cmake requires it as a dep? The configure needs to be changed back to sh autogen.sh && ./configure --prefix=/usr --disable-static && make make install Technically, system libuv is not required to build CMake. I don't use libuv for any BLFS packages. Here's my CMake bootstrap line: ./bootstrap --prefix=/usr\ --system-libs\ --mandir=/share/man \ --no-system-jsoncpp \ --no-system-librhash \ --docdir=/share/doc/cmake-3.13.2 \ -- -DCMAKE_USE_SYSTEM_LIBRARY_LIBUV=false That last part (-- -DCMAKE_...) allows the built-in version of libuv to be used, instead of the system one. However, the BLFS philosophy, as I take it, is to build system versions of libraries whenever possible, in order to address issues of security that may not have been addressed in the in-tree versions of packages. I agree though that if system libuv is a *required* dependency then there is a circular dependency which should be addressed... Happy Holidays, -- Ryan-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] gnutls-3.6.5
On Sat, 15 Dec 2018, Roger Koehler via blfs-dev wrote: On Sat, Dec 15, 2018 at 2:30 PM Roger Koehler wrote: On Sat, Dec 15, 2018 at 2:24 PM Bruce Dubbs via blfs-dev wrote: > > On 12/15/2018 03:06 PM, Roger Koehler via blfs-dev wrote: > > configure can't file libnettle for some reason. > > Try running ldconfig. That's the first thing that I tried. 'whereis libnettle' yields: libnettle: /usr/lib/libnettle.so /usr/lib64/libnettle.so I am running the script generated by jhalfs blfs_root. Log file: checking for NETTLE... no configure: error: *** *** Libnettle 3.4 was not found. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page What version of nettle are you using? When I first attempted to install gnutls 3.6.5 I got a configure error stating that nettle version 3.4.1 was needed. nettle 3.4 was not new enough. -- Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] parted-3.2 build breaks with glibc-2.28
Hello all. In my attempt to build my first desktop environment (xfce) I came across a build failure in parted-3.2: [...] CC table.o AR libver.a CCLD parted /usr/bin/ld: ../libparted/.libs/libparted.so: undefined reference to `major' /usr/bin/ld: ../libparted/.libs/libparted.so: undefined reference to `minor' collect2: error: ld returned 1 exit status [...] The fix is rather simple: sed -i '/assert.h/a#include ' libparted/arch/linux.c Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] v4l-utils fails with glibc-2.28 -- fix attached
Hello all. v4l-utils-1.14.2 build fails with glibc-2.28: [...] CXXLDv4l2-compliance /usr/bin/ld: ../../lib/libv4lconvert/.libs/libv4lconvert.so: undefined reference to `minor' collect2: error: ld returned 1 exit status make[3]: *** [Makefile:558: v4l2-compliance] Error 1 make[3]: Leaving directory '/home/ryan/v4l-utils-1.14.2/utils/v4l2-compliance' make[2]: *** [Makefile:469: all-recursive] Error 1 make[2]: Leaving directory '/home/ryan/v4l-utils-1.14.2/utils' make[1]: *** [Makefile:582: all-recursive] Error 1 make[1]: Leaving directory '/home/ryan/v4l-utils-1.14.2' make: *** [Makefile:509: all] Error 2 [...] I've attached a patch that fixes the issue (taken from Fedora distro). Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com --- v4l-utils-1.14.2/lib/libv4lconvert/control/libv4lcontrol.c.orig 2018-04-29 18:42:05.534170391 +0100 +++ v4l-utils-1.14.2/lib/libv4lconvert/control/libv4lcontrol.c 2018-04-29 18:42:17.765044988 +0100 @@ -20,9 +20,7 @@ */ #include -#if defined(MAJOR_IN_SYSMACROS) #include -#endif #include #include #include --- v4l-utils-1.14.2/utils/v4l2-ctl/v4l2-ctl.cpp.orig 2018-04-29 18:49:34.091977421 +0100 +++ v4l-utils-1.14.2/utils/v4l2-ctl/v4l2-ctl.cpp 2018-04-29 18:50:11.588702105 +0100 @@ -27,6 +27,7 @@ #include #include #include +#include #include #include #include -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] iptables-1.8.0 -- a couple of mistakes
Hello BLFSers. In iptables-1.8.0 there are a couple of small errors: 1) ded -i -e '/libebt_/s/^/#/' \ (should be sed ...) 2) ln -sfv ../../sbin/xtables-multi /usr/bin/iptables-xml && There's no such file as xtables-multi anymore; it's xtables-legacy-multi, so the link sould read: ln -v -sf ../../sbin/xtables-legacy-multi /usr/bin/iptables-xml Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] GTK+3 no longer recognizes "--enable-gtk2-dependency"
Hello all. GTK+-3 no longer recognizes the configuration switch "--enable-gtk2-dependency" Using it will give the following: "configure: WARNING: unrecognized options: --enable-gtk2-dependency" although it doesn't affect the build in any way. However, the Note box under "Installation of GTK+3" is no longer relevant. Cheers, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Btrfs-progs has a new library, libbtrfsutil.so
Hello all.
Starting with Btrfs-progs 4.16 there's a new library that's used for
managing Btrfs file systems. It's called libbtrfsutil.
As is the case with symlinking libbtrfs.so and removing its unneeded
library entries under /lib the same should be done for the new library:
ln -v -sf ../../lib/$(readlink /lib/libbtrfsutil.so) /usr/lib/libbtrfsutil.so
rm -v /lib/libbtrfsutil.{a,so}
Regards,
Ryan
--
Ryan Marsaw
rmar...@personainternet.com
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] HarfBuzz requires Graphite2 when building LibreOffice
Hello all. I believe this has been brought up in the past (albeit not directly - almost as an afterthought) but it deserves to be addressed. When building LibreOffice with system Harfbuzz, the latter needs to be compiled with Graphite2 support. If using system Harfbuzz w/o Graphite2 built in, I get the following config error: [...] checking whether the Boost::System library is available... yes checking which graphite to use... internal checking which harfbuzz to use... external checking for HARFBUZZ... yes checking whether system Harfbuzz is built with Graphite support... checking for hb_graphite2_face_get_gr_face... no configure: error: Harfbuzz needs to be built with Graphite support. Error running configure at ./autogen.sh line 289. [...] Otherwise one would need to use internal Harfbuzz AND internal Graphite2. ( Building LibreOffice with system Graphite2 but without system Harfbuzz yields the following: [...] "configure: error: --without-system-graphite must be used when --without-system-harfbuzz is used" [...] ) On the Harfbuzz page under "Dependencies" there's a note that Graphite2 is "required for building texlive-20170524 with system harfbuzz." I suggest that LibreOffice be added to that list. Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] json-c is required for cryptsetup
On Sat, 7 Apr 2018, Pierre Labastie wrote: Otherwise, configure errors out. Amazingly, nobody seems to have noticed. So am I the only one? Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page You're not the only one :) I'm constantly building pre-release versions of LFS/BLFS packages in order to see what's changed, or what can potentially be build issues down the line. I've been building cryptsetup 2.0 since the first release candidate and first noticed the json-c requirement right off the bat, but I wouldn't have let the mailing list aware of this until the stable version appeared. By the time it did, I'd forgotten about the extra requirement. I think I might start keeping a list of packages for which new dependencies are needed, and if nobody beats me to the punch I'll let the mailing list aware of these new dependencies. Cheers, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Certs not working in current svn ?
On Sun, 1 Apr 2018, Ken Moffat wrote: I did a previous build (on a different machine) last week, using BLFS svn from r19995. That all built, but my choice of a GT710 video card was a bad idea and nouveau frequently locks up Xorg so the completed system has only had limited use - but everything _seemed_ to work. At this point I don't have p11-kit or java. Any clue, please ? ĸen -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Ken, see my post on the mailing list regarding make-ca not working with latest OpenSSL 1.1.0h. If you're using the latest OpenSSL the build breaks the installation of the make-ca certificates. I was unable to download the sources for the newest rustc-1.25.0, which led me to the issue mentioned above. At first I thought it was a rustc problem, but it was the c_rehash program from OpenSSL that was the culprit. Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] OpenSSL 1.1.0h's c_rehash program breaks make-ca-0.7
Hello all. When building make-ca-0.7 with OpensSSL-1.1.0h I get the following build error: [...] Unknown regexp modifier "/W" at /usr/bin/c_rehash line 28, at end of line Unknown regexp modifier "/3" at /usr/bin/c_rehash line 28, at end of line Unknown regexp modifier "/2" at /usr/bin/c_rehash line 28, at end of line No such class installdir at /usr/bin/c_rehash line 63, near "Prefix our installdir" (Might be a runaway multi-line // string starting on line 28) syntax error at /usr/bin/c_rehash line 63, near "Prefix our installdir" Can't redeclare "my" in "my" at /usr/bin/c_rehash line 68, near "my" Execution of /usr/bin/c_rehash aborted due to compilation errors. [...] I diffed the c_rehash programs from OpenSSL-1.1.0g and 1.1.0h and noticed that in the latter, there are missing quotes on lines 15 and 16: my $dir = /etc/ssl; my $prefix = /usr; c_rehash from OpenSSL 1.1.0g has quotes surrounding "/etc/ssl" and "/usr" The missing quotes is the reason for the build error. Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Latest e2fsprogs breaks btrfs-progs
Hello all. LFS has just updated E2fsprogs-1.44.0 and this version breaks btrfs-progs with the following: [...] [CC] btrfs-corrupt-block.o convert/source-ext2.c: In function 'ext2_xattr_check_entry': convert/source-ext2.c:425:13: error: 'struct ext2_ext_attr_entry' has no member named 'e_value_block'; did you mean 'e_value_offs'? if (entry->e_value_block != 0 || value_size > size || ^ e_value_offs make: *** [Makefile:282: convert/source-ext2.o] Error 1 make: *** Waiting for unfinished jobs [...] Here's a link that describes the error: https://patchwork.kernel.org/patch/10281327/ There's a patch at the bottom that fixes the issue. Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Samba 4.8.0 requires libtirpc
On Fri, 23 Mar 2018, Pierre Labastie wrote: On 23/03/2018 20:22, Ryan Marsaw wrote: Hello BLFS editors. Samba 4.8.0 requires libtirpc. Without it, the configuration stage fails with the following: [...] Checking for libtirpc headers : not found Checking for libntirpc headers : not found ERROR: No rpc/rpc.h header found, tirpc or libntirpc missing? [...] This is related to the same issue involving rpcsvc-proto. One of the dependencies of Samba is libnsl, which itself requires rpcsvc-proto and libtirpc. libnsl pulls in libtirpc. However, the former is not a required dependency, while the latter is. Hmm, the question is whether all those libraries are required, or only recommended. That is, is there an option to disable them somehow, or should they be present unconditionally for the configuration to succeed? I'll try digging inside the waf build system... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page From what I can see, there is no option to disable libtirpc from Samba. Those libraries must be on the system, otherwise there's an error at configuration stage. Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Samba 4.8.0 requires libtirpc
Hello BLFS editors. Samba 4.8.0 requires libtirpc. Without it, the configuration stage fails with the following: [...] Checking for libtirpc headers: not found Checking for libntirpc headers : not found ERROR: No rpc/rpc.h header found, tirpc or libntirpc missing? [...] This is related to the same issue involving rpcsvc-proto. One of the dependencies of Samba is libnsl, which itself requires rpcsvc-proto and libtirpc. libnsl pulls in libtirpc. However, the former is not a required dependency, while the latter is. Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Re：Re: gmodule bad settings in glib2
On Thu, 22 Mar 2018, Pierre Labastie wrote:
On 22/03/2018 13:07, Ryan Marsaw wrote:
On Thu, 22 Mar 2018, hykw...@sina.com wrote:
Did you install gdk-pixbuf using the Meson build system by any chance? If
so, did you
issue the following afterwards (as root user)?
gdk-pixbuf-query-loaders --update-cache
I remember a while back when I first built gdk-pixbuf with Meson I
received a build error in one of the packages that followed. I forget
which package it was, but I think it may have had something to do with
what you're experiencing. I _think_.
I also tried to build gdk-pixbuf (2.36.11) with glib (2.56.0) but I got the
same error message "Couldn't recognize the image file format for
file " when I tried to build GTK+2.
If you check the meson_options.txt for the package "gdk-pixbuf", you can
find an option "builtin_loaders" and the default value is "none".
However, even you set it to "all" and all loaders are built sucessfully (You
can use "gdk-pixbuf-query-loaders" command for checking), the error message
still exits.
On the other hand, even the loader is not built, the application
"gdk-pixbuf-csource" will link to the "libpng" directly. (You can use ldd
command to check it). But, it won't help you to fix the error message.
("gdk-pixbuf-csource" still gives nothing when it try to load any png file.)
So, my current solution is: use the old version (2.54.3) of glib for my BLFS
system.
--
I was able to reproduce the GTK2 build error by removing the
"shared-mime-info" package before building GTK2. In my BLFS build I
install shared-mime-info just before installing gdk-pixbuf. I also
install gdk-pixbuf using Meson, which is not the build system used for
that package in BLFS. I don't know if that makes any difference. I'm
assuming you've installed shared-mime-info because it is a required
dependency of gdk-pixbuf.
Yes, I had that... No, really: the problem was with the glib-2.56.0
instructions from March 18th, after removal of the "meson-fixes" patch. I you
have a glib with the patch (provided it applies), I guess it addresses the
problem I was seeing (glib-2.54.3 with the patch had no problem). But now,
back with autotools, looks like everything is fine with glib-2.56.0.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
That's very interesting. I guess one of the differences between your
build and mine is that I never applied the GLib fixes patch in the first
place. I didn't use that patch because it required me to install PCRE
(which I didn't want to do because GLib was the _only_ package for which
I would have needed PCRE. PCRE2 is used in the other packages). Of
course that meant using GLib's internal PCRE, which I didn't mind. So
my current GLib 2.56.0 is built without system PCRE and without any
patches, and my GTK2 builds just fine.
It's probably a moot point now anyway seeing as how autotools is going
to be used instead of Meson for GLib until the Meson stuff gets worked
on.
For what it's worth here's how I currently build my GLib 2.56.0:
mkdir -v build_dir/
LANG=en_CA.UTF-8\
meson --prefix /usr \
-Dselinux=false build_dir/
LANG=en_CA.UTF-8 ninja -C build_dir/
LANG=en_CA.UTF-8 sudo ninja -C build_dir/ install
Regards,
Ryan
--
Ryan Marsaw
rmar...@personainternet.com
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Re：Re: gmodule bad settings in glib2
On Thu, 22 Mar 2018, hykw...@sina.com wrote:
Did you install gdk-pixbuf using the Meson build system by any chance? If so,
did you
issue the following afterwards (as root user)?
gdk-pixbuf-query-loaders --update-cache
I remember a while back when I first built gdk-pixbuf with Meson I
received a build error in one of the packages that followed. I forget
which package it was, but I think it may have had something to do with
what you're experiencing. I _think_.
I also tried to build gdk-pixbuf (2.36.11) with glib (2.56.0) but I got the same
error message "Couldn't recognize the image file format for
file " when I tried to build GTK+2.
If you check the meson_options.txt for the package "gdk-pixbuf", you can find an option
"builtin_loaders" and the default value is "none".
However, even you set it to "all" and all loaders are built sucessfully (You can use
"gdk-pixbuf-query-loaders" command for checking), the error message still exits.
On the other hand, even the loader is not built, the application "gdk-pixbuf-csource" will link to
the "libpng" directly. (You can use ldd command to check it). But, it won't help you to fix the
error message. ("gdk-pixbuf-csource" still gives nothing when it try to load any png file.)
So, my current solution is: use the old version (2.54.3) of glib for my BLFS
system.
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
I was able to reproduce the GTK2 build error by removing the
"shared-mime-info" package before building GTK2. In my BLFS build I
install shared-mime-info just before installing gdk-pixbuf. I also
install gdk-pixbuf using Meson, which is not the build system used for
that package in BLFS. I don't know if that makes any difference. I'm
assuming you've installed shared-mime-info because it is a required
dependency of gdk-pixbuf.
Regards,
Ryan
--
Ryan Marsaw
rmar...@personainternet.com
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] gmodule bad settings in glib2
On Wed, 21 Mar 2018, Pierre Labastie wrote: On 21/03/2018 20:21, Ryan Marsaw wrote: On Wed, 21 Mar 2018, Pierre Labastie wrote: Hi, Using the instructions in the book from March 19 for building glib-2.56.0, I end up with an empty variable "gmodule_supported" in the .pc file: /usr/lib/pkgconfig/gmodule-no-export-2.0.pc. But this variable is read by gdk-pixbuf, which deduces that gmodule are not supported. So that it does not build *any* loader (gdk-pixbuf-query-loaders returns only comments). Then gtk2 does not build, and nothing can work, I think... So glib2 should be fixed. The patch for building with meson has been removed. I guess it is the reason for the failure to set this variable. Note that archlinux switched back to autotools for glib-2.56. Shouldn't we do the same? Or else we need a patch... But from where? Pierre -- Does your error (from Gtk+-2) occur at the "make install" phase by any chance? Something like: [...] /usr/bin/gtk-query-immodules-2.0 > /usr/lib/gtk-2.0/2.10.0/immodules.cache /bin/sh: line 4: /usr/lib/gtk-2.0/2.10.0/immodules.cache: No such file or directory make[4]: *** [Makefile:1409: install-data-hook] Error 1 Unfortunately no. Mine is in the build phase: /usr/bin/gdk-pixbuf-csource --raw --build-list \ apple_red ./apple-red.png \ gnome_foot ./gnome-foot.png \ > test-inline-pixbufs.h \ || (rm -f test-inline-pixbufs.h && false) failed to load "./apple-red.png": Couldn't recognize the image file format for file './apple-red.png' make[3]: *** [Makefile:1018: test-inline-pixbufs.h] Error 1 Gdk-pixbuf-csource is unable to read .png images, because the loader module is disabled. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Did you install gdk-pixbuf using the Meson build system by any chance? If so, did you issue the following afterwards (as root user)? gdk-pixbuf-query-loaders --update-cache I remember a while back when I first built gdk-pixbuf with Meson I received a build error in one of the packages that followed. I forget which package it was, but I think it may have had something to do with what you're experiencing. I _think_. Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Samba 4.8.0 requires rpcsvc-proto
Hello all.
Samba 4.8.0 build fails rather quickly with the following:
[...]
[ 162/3629] Generating samba-passdb_empty_c
[ 163/3629] Generating PKGCONFIG_smbclient.pc
[ 164/3629] Generating vfs_empty_c
[ 165/3629] Generating nfs41acl-xdr-c
/bin/sh: rpcgen: command not found
[ 166/3629] Generating nfs41acl-h
/bin/sh: rpcgen: command not found
Waf: Leaving directory `/home/ryan/samba-4.8.0/bin'
Build failed: -> task failed (err #127):
{task: nfs41acl-h nfs41acl.x -> nfs41acl.h}
make: *** [Makefile:8: all] Error 1
[...]
Samba builds cleanly after installing rpcsvc-proto.
Regards,
Ryan
--
Ryan Marsaw
rmar...@personainternet.com
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] gmodule bad settings in glib2
On Wed, 21 Mar 2018, Pierre Labastie wrote: Hi, Using the instructions in the book from March 19 for building glib-2.56.0, I end up with an empty variable "gmodule_supported" in the .pc file: /usr/lib/pkgconfig/gmodule-no-export-2.0.pc. But this variable is read by gdk-pixbuf, which deduces that gmodule are not supported. So that it does not build *any* loader (gdk-pixbuf-query-loaders returns only comments). Then gtk2 does not build, and nothing can work, I think... So glib2 should be fixed. The patch for building with meson has been removed. I guess it is the reason for the failure to set this variable. Note that archlinux switched back to autotools for glib-2.56. Shouldn't we do the same? Or else we need a patch... But from where? Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Does your error (from Gtk+-2) occur at the "make install" phase by any chance? Something like: [...] /usr/bin/gtk-query-immodules-2.0 > /usr/lib/gtk-2.0/2.10.0/immodules.cache /bin/sh: line 4: /usr/lib/gtk-2.0/2.10.0/immodules.cache: No such file or directory make[4]: *** [Makefile:1409: install-data-hook] Error 1 make[4]: Leaving directory '/home/ryan/gtk+-2.24.32/modules/input' make[3]: *** [Makefile:1274: install-data-am] Error 2 make[3]: Leaving directory '/home/ryan/gtk+-2.24.32/modules/input' make[2]: *** [Makefile:1224: install-am] Error 2 make[2]: Leaving directory '/home/ryan/gtk+-2.24.32/modules/input' make[1]: *** [Makefile:504: install-recursive] Error 1 make[1]: Leaving directory '/home/ryan/gtk+-2.24.32/modules' make: *** [Makefile:733: install-recursive] Error 1 [...] I got this error ever since I started building GLib-2 using Meson. I didn't fix the error from GLib, but rather from Gtk+-2 using a sed statement that creates the appropriate directory structure before Gtk+-2 installs its modules: sed -i.bak '/^install-data-hook/a\ \tinstall -v -dm 0755 $(DESTDIR)$(libdir)/gtk-2.0/$(GTK_BINARY_VERSION)' \ modules/input/Makefile.in This fixes the above error. This is the only error I've had to deal with in regards to GLib/Gtk+-2 using meson build system for GLib. Nothing else appears to be affected in my BLFS build. If your error is not the one I'm referring to above, then I personally wouldn't know how to fix yours. I'm sure the above "fix" for my particular error is probably not the best way to handle it, but at least it gets my Gtk2 installed. Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] cryptsetup can use OpenSSL as a crypto backend
On Sat, 17 Mar 2018, Pierre Labastie wrote: On 17/03/2018 19:12, Ryan Marsaw wrote: Hello BLFS editors. On the cryptsetup page is listed a numer of crypto backends to use with it (libgcrypt-1.8.2, Nettle-3.4, or NSS-3.36). OpenSSL can also be used. From the configure script: --with-crypto_backend=BACKEND crypto backend (gcrypt/openssl/nss/kernel/nettle) I can verify that OpenSSL works as a backend, since I don't use any of the other ones. Cheers, Ryan -- Ryan Marsaw rmar...@personainternet.com Thanks for the report. Since openssl is now in LFS, none of the others is _required_. The question is whether there is some reason to prefer one of the others. If so, it should be in "recommended". Otherwise, all should be in optional. I am not acquainted enough with cryptsetup for knowing that... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Unless the user wants gcrypt as a backend (and libgcrypt is installed), he/she will need to specify the crypto backend explicitly. For example, to use OpenSSL: --with-crypto_backend=openssl This is the case for all other backends as well: nettle, nss, kernel. If the switch itself is not used at all, cryptsetup assumes gcrypt, and if libgcrypt is not installed, configure will fail. Since OpenSSL is installed in LFS, the crypto backends listed on the cryptsetup page may be "demoted" to recommended dependencies. Personally I don't see any real advantage in using one backend over another, with regards to cryptsetup. I'm of the mind that if I don't have to install a package to satisfy another package, I probably will not! Cheers, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] cryptsetup can use OpenSSL as a crypto backend
Hello BLFS editors. On the cryptsetup page is listed a numer of crypto backends to use with it (libgcrypt-1.8.2, Nettle-3.4, or NSS-3.36). OpenSSL can also be used. From the configure script: --with-crypto_backend=BACKEND crypto backend (gcrypt/openssl/nss/kernel/nettle) I can verify that OpenSSL works as a backend, since I don't use any of the other ones. Cheers, Ryan -- Ryan Marsaw rmar...@personainternet.com -- 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 suggestion for librsvg-2.42.2
On Wed, 28 Feb 2018, Tim Tassonis wrote: Hi all I just installed adwaita-icon-themes, resulting in an error due to rsvg being installed, but gdk-pixbuf-query-loaders not being run. As I am doing a DESTDIR install, it might be that this was run at make install of rsvg, but maybe there could be a remark on the rsvg page to run gdk-pixbuf-query-loaders --update-cache as root after make install. This fixed by adwaita-icon-theme error. Bye Tim -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Running "gdk-pixbuf-query-loaders --update-cache" is already mentioned on the gdk-pixbuf page of BLFS. It's pretty much required if using the DESTDIR method of installing. It's also needed if building gdk-pixbuf using the Meson build system, as I discovered when I switched from using the autotools method. Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] x264 recommends NASM, not yasm
Hello all. The x264-20180212 package in BLFS shows yasm as a recommended dependency, but x264 now uses NASM as its assembler. Even with yasm installed there's a "Found no assembler" message while configuring. Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libvpx-1.7.0 builds with NASM
On Mon, 12 Feb 2018, Ryan Marsaw wrote: Hello all. libvpx-1.7.0 builds successfully with NASM. Normally I'd use NASM over yasm for all BLFS packages, but as far I know the only package that needed yasm specifically was libvpx < 1.7.0 because of the broken build with NASM. It would appear that I can now stick with NASM exclusively. Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page I spoke too soon. There are some packages that still require yasm specifically. However, libvpx-1.7.0 now builds with either NASM or yasm (in fact, the developers recommend yasm over NASM). Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] libvpx-1.7.0 builds with NASM
Hello all. libvpx-1.7.0 builds successfully with NASM. Normally I'd use NASM over yasm for all BLFS packages, but as far I know the only package that needed yasm specifically was libvpx < 1.7.0 because of the broken build with NASM. It would appear that I can now stick with NASM exclusively. Regards, Ryan -- Ryan Marsaw rmar...@personainternet.com -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] PulseAudio and Glibc-2.27
On Sun, 4 Feb 2018, Bruce Dubbs wrote:
Ryan Marsaw wrote:
Hello.
While building PulseAudio with the latest Glibc-2.27 I get the following
error:
[...]
In file included from pulsecore/shm.c:48:0:
./pulsecore/memfd-wrappers.h:36:19: error: static declaration of
'memfd_create' follows non-static declaration
static inline int memfd_create(const char *name, unsigned int flags) {
^~~~
In file included from /usr/include/bits/mman-linux.h:115:0,
from /usr/include/bits/mman.h:45,
from /usr/include/sys/mman.h:41,
from pulsecore/shm.c:37:
/usr/include/bits/mman-shared.h:46:5: note: previous declaration of
'memfd_create' was here
int memfd_create (const char *__name, unsigned int __flags) __THROW;
^~~~
make[3]: *** [Makefile:8008: pulsecore/libpulsecommon_11.1_la-shm.lo] Error
1
[...]
I've included a patch that fixes the issue.
Reference: https://patchwork.openembedded.org/patch/147648/
The patch seems like a little overkill for us. I haven't tested it but I
think
sed -i '/int memfd_create/,+2 d' src/pulsecore/memfd-wrappers.h
will work until a new version of pulseaudio is released. Can you check for
us?
-- Bruce
Hi Bruce.
Your sed statement worked just fine. I haven't gone through a thorough
testing, but nothing appears to be any different between the patch and your
workaround.
Thanks, and keep up the great work!
Regards,
Ryan
--
Ryan Marsaw
rmar...@personainternet.com
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] PulseAudio and Glibc-2.27
Hello.
While building PulseAudio with the latest Glibc-2.27 I get the following error:
[...]
In file included from pulsecore/shm.c:48:0:
./pulsecore/memfd-wrappers.h:36:19: error: static declaration of 'memfd_create'
follows non-static declaration
static inline int memfd_create(const char *name, unsigned int flags) {
^~~~
In file included from /usr/include/bits/mman-linux.h:115:0,
from /usr/include/bits/mman.h:45,
from /usr/include/sys/mman.h:41,
from pulsecore/shm.c:37:
/usr/include/bits/mman-shared.h:46:5: note: previous declaration of
'memfd_create' was here
int memfd_create (const char *__name, unsigned int __flags) __THROW;
^~~~
make[3]: *** [Makefile:8008: pulsecore/libpulsecommon_11.1_la-shm.lo] Error 1
[...]
I've included a patch that fixes the issue.
Reference: https://patchwork.openembedded.org/patch/147648/
Regards,
Ryan
--
Ryan Marsaw
rmar...@personainternet.com--- pulseaudio-11.1-orig/configure.ac 2017-09-05 06:46:23.0 -0400
+++ pulseaudio-11.1/configure.ac2018-02-04 14:46:52.647465714 -0500
@@ -603,6 +603,10 @@
AC_CHECK_DECL(SYS_memfd_create, [HAVE_MEMFD=1], [HAVE_MEMFD=0], [#include
]),
[HAVE_MEMFD=0])
+AS_IF([test "x$enable_memfd" != "xno"],
+AC_CHECK_FUNC(memfd_create, [HAVE_MEMFD_CREATE=1], [HAVE_MEMFD_CREATE=0],
[#include ]),
+[HAVE_MEMFD_CREATE=0])
+
AS_IF([test "x$enable_memfd" = "xyes" && test "x$HAVE_MEMFD" = "x0"],
[AC_MSG_ERROR([*** Your Linux kernel does not support memfd shared memory.
*** Use linux v3.17 or higher for such a feature.])])
@@ -610,6 +614,9 @@
AC_SUBST(HAVE_MEMFD)
AM_CONDITIONAL([HAVE_MEMFD], [test "x$HAVE_MEMFD" = x1])
AS_IF([test "x$HAVE_MEMFD" = "x1"], AC_DEFINE([HAVE_MEMFD], 1, [Have memfd
shared memory.]))
+AC_SUBST(HAVE_MEMFD_CREATE)
+AM_CONDITIONAL([HAVE_MEMFD_CREATE], [test "x$HAVE_MEMFD_CREATE" = x1])
+AS_IF([test "x$HAVE_MEMFD_CREATE" = "x1"], AC_DEFINE([HAVE_MEMFD_CREATE], 1,
[Define to 1 if you have the `memfd_create` function.]))
X11 (optional)
--- pulseaudio-11.1-orig/src/pulsecore/memfd-wrappers.h 2016-08-23
08:50:11.0 -0400
+++ pulseaudio-11.1/src/pulsecore/memfd-wrappers.h 2018-02-04
14:46:52.648465714 -0500
@@ -32,11 +32,11 @@
* defined in the kernel header file , that file as
* a whole conflicts with the original glibc header .
*/
-
+#ifndef HAVE_MEMFD_CREATE
static inline int memfd_create(const char *name, unsigned int flags) {
return syscall(SYS_memfd_create, name, flags);
}
-
+#endif
/* memfd_create(2) flags */
#ifndef MFD_CLOEXEC
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] Vala-0.38.5 needs updated sed substitution in configure.ca
Hello. Vala-0.38.5 needs an updated sed statement to reflect the changes in configure.ac: The updated substitution: sed -i '102d; 108,124d; 126,127d' configure.ac Regards, Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Recommendation: replace docbook-xsl with docbook-xsl-nons (No Namespace support)
Hello. I'd like to recommend that BLFS use the no-namespace version of docbook-xsl (known as docbook-xsl-nons). Here's my reasoning: Samba uses xsltproc (from the libxslt package) to generate its man pages from XML documents. Even though the man pages get processed without any errors, I do receive the following tidbit while these man pages get processed: "Note: namesp. add : added namespace before processing smb.conf" This "Note" is displayed for every man page that gets written. The resulting man pages do not appear to be formatted correctly. Many of the hidden formatting elements of the pages (.SS, .IX, etc.) are clearly visible in the files themselves, which throws off the formatting. I discovered through the new homepage of docbook-xsl that there are two versions of docbook-xsl: one that uses DocBook versions 5+ and one for DocBook versions < 5. I'm assuming they're referring to DocBook-XSL when they say 5+ and < 5. BLFS uses DocBook-XSL version 4.5, and according to http://cdn.docbook.org/ the recommended docbook-xsl is the one without namespace support. After installing the alternative docbook-xsl-nons, and re-generating the man pages for Samba, I didn't see any Note about adding namespaces, and the resulting man pages look properly formatted. I've since re-built my BLFS system and have seen (so far anyway) no formatting problems with any man pages using docbook-xsl-nons. Regards, Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Firefox 58 sound issues
On 01/19/18 11:16 PM, Ken Moffat wrote: > > On Thu, Jan 18, 2018 at 12:34:04AM +, Ken Moffat wrote: > > On Wed, Jan 17, 2018 at 10:28:46PM +, Ken Moffat wrote: > > > > > On Tue, Jan 16, 2018 at 01:07:07AM +0100, Tim Tassonis wrote: > > > > > > Hi All > > > > > > > > > > > > On 01/16/2018 12:29 AM, Tim Tassonis wrote: > > > [...] > > > > > > > > > > > > To leave sandboxing active and get alsa sound running, you can also > > > > > > set > > > > > > > > > > > > security.sandbox.content.syscall_whitelist > > > > > > > > > > > > to 16, which is the iotcl syscall needed by alsa. For 32bit > > > > > > architectures, > > > > > > the value is 54. > > > > I've now built b16 with alsa on a second machine: initially no > > sound, but setting security.sandbox.content.syscall_whitelist to 16 > > in about:config, and restarting direfox, fixed it. > > > > Maybe I've left it set like that on the other machine. > > > > Anybody willing to try building it with pulse and style (needs > clang) on a fast multicore machine, test html5 pulse audio, and if > necessary rebuild using alsa instead of pulse ? At the moment I'm > the only person who apparently gets no aound with pulse, so I'm > reluctant to move the book back to alsa if the problem is in my > setup. More data would be welcome. TIA. > Is your no-audio problem consistent, or does it happen intermittently? I _sometimes_ get no sound with Firefox using PulseAudio. What works for me when the sound isn't working is by closing Firefox, and then re-setting my default sink for PulseAudio. For example: running "pactl list short sinks," and then "pacmd set-default-sink " Restarting Firefox then re-enables sound. I cannot determine what exactly causes the sound issue, but the steps listed above always "fixes" the sound problems (in my case!). > > For rustc, the line 'channel = "stable"' needs to be deleted for > recent versions. For firefox, use ./mach build (or ./mach build > --verbose) and (DESTDIR=/some/where ) ./mach install. > > The line doesn't need to be deleted; It needs to be only moved from the header named "[install]" to the newly-added header "[rust]" I noticed this when my first attempt to build Rust 1.23.0 failed at the install phase. After looking at the example config.toml file I saw that "channel=" moved places. Therefore, the new config.toml should look like this: cat < config.toml # see config.toml.example for more possible options [llvm] targets = "X86" [build] # install cargo as well as rust extended = true [install] prefix = "/usr" docdir = "share/doc/rustc-1.23.0" [rust] channel = "stable" EOF > > ĸen > -- > Truth, in front of her huge walk-in wardrobe, selected black leather > boots with stiletto heels for such a barefaced truth. > - Unseen Academicals > -- > http://lists.linuxfromscratch.org/listinfo/blfs-dev > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Samba 4.7.4 fails to build when compiled without Active Directory support
On 01/15/18 10:57 AM, Tim Tassonis wrote:
>
>
>
> On 01/11/2018 10:17 PM, Ryan Marsaw wrote:
> > Hello BLFS editors:
> >
> > Building the latest stable Samba without Active Directory support (ADS) i.e.
> > compiling with the switch "--without-ads" results in the following build
> > error:
>
>
> The book however has
>
> --without-ad-dc
>
> and this still works fine.
>
> Cheers
> Tim
>
> >
> > .
> > .
> > [3385/3612] Linking default/source3/libads-samba4.so
> > default/source3/libads/kerberos_keytab_63.o: In function `ads_keytab_list':
> > kerberos_keytab.c:(.text+0x114): undefined reference to `ads_keytab_open'
> > collect2: error: ld returned 1 exit status Waf: Leaving directory
> > `/usr/src/samba-4.7.4/bin' Build failed: -> task failed (err #1): {task:
> > cc_link
> > ldap_63.o,sasl_63.o,sasl_wrapping_63.o,krb5_setpw_63.o,kerberos_util_63.o,ldap_user_63.o,ads_struct_63.o,kerberos_keytab_63.o,disp_sec_63.o,ldap_utils_63.o,ldap_schema_63.o,util_63.o,ndr_63.o,namequery_dc_104.o,trustdom_cache_104.o,dsgetdcname_104.o
> > -> libads-samba4.so} make: *** [Makefile:8: all] Error 1
> >
> > The error in question is brought up in more detail here:
> >
> > http://samba.2283325.n4.nabble.com/Fix-compilation-of-Samba-4-7-4-with-disabled-ADS-td4728041.html
> >
> > There's a patch (user submitted) that I've included in this mail that allows
> > Samba 4.7.4 to build without complaints regarding ADS.
> >
> > Regards,
> >
> > Ryan
> >
> >
>
Hi Tim,
I was already using the switch "--without-ad-dc"
If I don't add "--without-ads" I get the following config error:
"Active Directory support not available: LDAP support is not available.
/usr/src/scm/samba/source3/wscript:790: error: Active Directory support not
found.
Use --without-ads for building without Active Directory support.
ADS support improves communication with Active Directory domain controllers."
I also add "--without-ldap" to the config script to disable LDAP.
The build error I wrote about originally affects only the latest stable Samba
(4.7.4).
Version 4.7.3 gave me no errors with the very same configuration options.
Regards,
Ryan
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] Samba 4.7.4 fails to build when compiled without Active Directory support
Hello BLFS editors:
Building the latest stable Samba without Active Directory support (ADS) i.e.
compiling with the switch "--without-ads" results in the following build error:
.
.
[3385/3612] Linking default/source3/libads-samba4.so
default/source3/libads/kerberos_keytab_63.o: In function `ads_keytab_list':
kerberos_keytab.c:(.text+0x114): undefined reference to `ads_keytab_open'
collect2: error: ld returned 1 exit status Waf: Leaving directory
`/usr/src/samba-4.7.4/bin' Build failed: -> task failed (err #1): {task:
cc_link
ldap_63.o,sasl_63.o,sasl_wrapping_63.o,krb5_setpw_63.o,kerberos_util_63.o,ldap_user_63.o,ads_struct_63.o,kerberos_keytab_63.o,disp_sec_63.o,ldap_utils_63.o,ldap_schema_63.o,util_63.o,ndr_63.o,namequery_dc_104.o,trustdom_cache_104.o,dsgetdcname_104.o
-> libads-samba4.so} make: *** [Makefile:8: all] Error 1
The error in question is brought up in more detail here:
http://samba.2283325.n4.nabble.com/Fix-compilation-of-Samba-4-7-4-with-disabled-ADS-td4728041.html
There's a patch (user submitted) that I've included in this mail that allows
Samba 4.7.4 to build without complaints regarding ADS.
Regards,
Ryan
samba-4.7.4.patch
Description: Binary data
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] JSON-C-0.13 and parallel build
Hello. It appears that JSON-C-0.13 now builds properly with parallel processing. I no longer get the errors I did with the previous version when running with anything other than -j1. Regards, Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] winbindd boot script -- incorrect location of winbindd.pid
Hello. I noticed that in the boot script for the winbindd daemon there's a line that reads PIDFILE=/var/run/winbindd.pid The actual location of that file is /run/samba/winbindd.pid Regards, Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Samba-4.7.3 build fails if docbook-xsl-1.79.1 is installed
On 12/28/17 10:47 AM, "Armin K." wrote: > > On 28.12.2017. 15:40, Ryan Marsaw wrote: > > > The error is with the docbook-xsl-1.79.1 package, which is described in > > better detail here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1491307 > > > > There is a patch available here: > > https://anonscm.debian.org/cgit/collab-maint/docbook-xsl.git/plain/debian/patches/765567_non-recursive_string_subst.patch > > > > I can confirm that applying this patch to docbook-xsl-1.79.1 prior to > > building > > Samba results in a clean build of Samba. > > > > Regards, > > > > Ryan > > > > > > As a side note, docbook-xsl upstream has changed and there's now 1.79.2 > version available at > > https://github.com/docbook/xslt10-stylesheets/releases > > It fixes the mentioned bug. > Thanks for the information about GitHub. It never occurred to me to check there, as I usually do for packages that tend to stagnate! However, even with the newest docbook-xsl-1.79.2, I'm still getting the same exact error when building Samba. It appears that the upstream fixes didn't cut it, at least not for me. I re-diffed the original patch to take into account the changes from docbook-xsl-1.79.1 and have included it here. Regards, Ryan docbook-xsl-1.79.2-non-recursive_string_subst.patch Description: Binary data -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Samba-4.7.3 build fails if docbook-xsl-1.79.1 is installed
Hello BLFS editors.
When building Samba 4.7.3 (with the docbook-xsl-1.79.1 package installed
beforehand) I get the following error:
.
.
.
[3495/3610] Generating manpages/smb.conf.5
runtime error: file
file:///usr/share/xml/docbook/xsl-stylesheets-1.79.1/lib/lib.xsl line 58
element choose
xsltApplySequenceConstructor: A potential infinite template recursion was
detected.
You can adjust xsltMaxDepth (--maxdepth) in order to raise the maximum number
of nested template calls and variables/params (currently set to 3000).
Templates:
.
.
.
error: file default/docs-xml/manpages/smb.conf.5.xml
xsltRunStylesheet : run failed
Waf: Leaving directory `/usr/src/samba-4.7.3/bin'
Build failed: -> task failed (err #11):
{task: manpages/smb.conf.5 smb.conf.5.xml,parameters.all.xml -> smb.conf.5}
make: *** [Makefile:8: all] Error 1
The error is with the docbook-xsl-1.79.1 package, which is described in better
detail here:
https://bugzilla.redhat.com/show_bug.cgi?id=1491307
There is a patch available here:
https://anonscm.debian.org/cgit/collab-maint/docbook-xsl.git/plain/debian/patches/765567_non-recursive_string_subst.patch
I can confirm that applying this patch to docbook-xsl-1.79.1 prior to building
Samba results in a clean build of Samba.
Regards,
Ryan
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] Firefox-57.0.1 build fails if /run/shm has incorrect permissions when building Python 2
Hello BLFS editors: First, a disclaimer: After I build my LFS system, I chroot into the new build right away to install my BLFS packages. I do not reboot beforehand. This is important when reading the rest of this message. Here's the issue: When attempting to build Firefox-57.0.1 I get the following error shortly after I run "make -f client.mk build:" 0:21.05 Creating config.status 0:21.22 Traceback (most recent call last): 0:21.22 File "/usr/src/scm/gecko-dev/configure.py", line 124, in 0:21.22 sys.exit(main(sys.argv)) 0:21.22 File "/usr/src/scm/gecko-dev/configure.py", line 34, in main 0:21.22 return config_status(config) 0:21.22 File "/usr/src/scm/gecko-dev/configure.py", line 119, in config_status 0:21.22 return config_status(args=[], **encode(sanitized_config, encoding)) 0:21.22 File "/usr/src/scm/gecko-dev/python/mozbuild/mozbuild/config_status.py", line 136, in config_status 0:21.22 reader = BuildReader(env) 0:21.22 File "/usr/src/scm/gecko-dev/python/mozbuild/mozbuild/frontend/reader.py", line 868, in __init__ 0:21.22 self._gyp_worker_pool = ProcessPoolExecutor(max_workers=max_workers) 0:21.22 File "/usr/src/scm/gecko-dev/third_party/python/futures/concurrent/futures/process.py", line 285, in __init__ 0:21.22 EXTRA_QUEUED_CALLS) 0:21.22 File "/usr/lib/python2.7/multiprocessing/__init__.py", line 217, in Queue 0:21.22 from multiprocessing.queues import Queue 0:21.22 File "/usr/src/scm/gecko-dev/build/mach_bootstrap.py", line 351, in __call__ 0:21.22 module = self._original_import(name, globals, locals, fromlist, level) 0:21.22 File "/usr/lib/python2.7/multiprocessing/queues.py", line 48, in 0:21.22 from .synchronize import Lock, BoundedSemaphore, Semaphore, Condition 0:21.22 File "/usr/src/scm/gecko-dev/build/mach_bootstrap.py", line 351, in __call__ 0:21.22 module = self._original_import(name, globals, locals, fromlist, level) 0:21.22 File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 59, in 0:21.22 " function, see issue 3770.") 0:21.22 ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770. 0:21.28 *** Fix above errors and then restart with\ 0:21.28 "/usr/bin/make -f client.mk build" 0:21.28 make: *** [client.mk:388: configure] Error 1 At first I thought this was a problem with Firefox, but after reading through the traceback I realized that it was Firefox attempting to run a Python script (synchronize.py), and it's that script that generates the above error. Some searching into this error led me to conclude that the culprit may be the permissions on /run/shm, combined with the installation of Python 2. Although Python 2 itself builds fine no matter what the permissions of /run/shm are, the effects are not noticeable until one builds Firefox-57.0.1. As I mentioned above, I tend not to reboot my PC after building LFS, but rather, I chroot into the new LFS build and then install all my BLFS packages. Because I haven't rebooted, the permissions on /run/shm are still the same as when they were set in LFS section 6.2. Preparing Virtual Kernel File Systems, which is drwxr-xr-x. It's not until a reboot of the system is made that permissions on /run/shm are changed to drwxrwxrwt. It would appear that Python 2 builds differently depending on the permissions of /run/shm. As a test, I ran Python's configuration (as per BLFS instructions) with the two different permissions on /run/shm. Here's what I found: With /run/shm permissions at drwxr-xr-x: . . checking whether POSIX semaphores are enabled... no checking for broken sem_getvalue... yes . . With /run/shm permissions at drwxrwxrwt: . . checking whether POSIX semaphores are enabled... yes checking for broken sem_getvalue... no . . It's only when Python 2 is built with /run/shm permissions at drwxrwxrwt that Firefox-57.0.1 builds without any issues. I don't know if the LFS editors assume that a user will reboot a machine before building BLFS packages, but this information might come in handy for anyone who (like me) does not reboot until after BLFS is built (or, at least until after Python 2 is built). For what it's worth, in LFS section 6.2. Preparing Virtual Kernel File Systems, I change the permissions on /run/shm as so: if [ -h $LFS/dev/shm ]; then install -v -dm 1777 $LFS$(readlink $LFS/dev/shm) fi Happy Holidays, and keep up the excellent work! Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Qpdf 7.0.0 no longer depends on PCRE
Hello BLFS editors. Qpdf 7.0.0 removed the dependency on PCRE. It's noted in the ChangeLog, and I can confirm that Qpdf builds successfully without PCRE since I no longer build the latter. Regards, Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Cmake-3.10.0 and libuv-1.17.0
Hello BLFS editors. The release of CMake 3.10 made building with libuv more difficult than with previous versions, but not impossible. To build CMake 3.10 without system libuv, one needs only append the following to the last configuration option on the bootstrap line: -- -DCMAKE_USE_SYSTEM_LIBRARY_LIBUV=false Notice the two leading dashes, which are required. Regards, Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] vte-0.48.3
I believe this has something to do with the generation of the signal marshallers. I got the same vte error after building the 2.53 branch of GLib. See this for more info: https://git.gnome.org/browse/vte/commit/?id=fa3bc86008cfe517dbb05deb4dff0059f3749c95 Ryan On 08/27/17 06:08 AM, Christoph Feikes wrote: > > I can't build vte-0.48.3 with all dependencies but GTK-Doc-1.26 and > Glade installed. > > Output is: > > .libs/libvte_2_91_la-vtegtk.o: In function > `vte_terminal_class_init(_VteTerminalClass*)': > /usr/src/pkgusr/vte/vte-0.49.1/src/vtegtk.cc:827: undefined reference to > `_vte_marshal_VOID__STRING_BOXED' > /usr/bin/ld: .libs/libvte_2_91_la-vtegtk.o: relocation R_X86_64_PC32 > against undefined hidden symbol `_vte_marshal_VOID__STRING_BOXED' can > not be used when making a shared object > /usr/bin/ld: final link failed: Bad value > collect2: error: ld returned 1 exit status > > I tried vte-0.49.1 and got the same error. I need a Gtk+-2 version of > vte only (vte-0.28.2; for the geany debugger plugin), so I didn't spend > much time investigating this; it doesn't seem trivial to fix, at least > for me. > > Regards, Christoph > -- > http://lists.linuxfromscratch.org/listinfo/blfs-dev > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] libepoxy-1.4.1 is available
Hi. I noticed that there's a new version of libepoxy on the GitHub page. Version 1.4.1 has been available since March 2nd. Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Cups-2.2.3 does not need sed for cupsd.conf.in
Hello everyone. The release of Cups-2.2.3 fixed the issue with users not having installed MIT Kerberos beforehand. The sed that deletes the Kerberos-specific entries in conf/cupsd.conf.in is no longer required. Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] libdrm-2.4.75 not longer references pthread-stubs
Hello. Starting from libdrm-2.4.75 there are no more references to pthread-stubs. Therefore the sed that disables the dependency on the libpthread-stubs package is no longer required. Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] libusb-1.0.21 and parallel build
Hi. Starting from libusb-1.0.21 (well, since the 1.0.21 release candidates really) a parallel build is now possible. I have an Intel Dual-Core E5300 processor and have not experienced any build errors with this version, which was not the case with libusb-1.0.20. Ryan -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
