Re: [blfs-dev] [blfs-book] r21192 - in trunk/BOOK: general/genutils general/graphlib multimedia/audioutils multimedia/cdwriteutils multimedia/libdriv multimedia/videoutils x/lib
On 2/17/19 10:49 PM, Ken Moffat via blfs-dev wrote: On Mon, Feb 18, 2019 at 12:28:59AM -, bdubbs--- via blfs-book wrote: Author: bdubbs Date: Sun Feb 17 16:28:59 2019 New Revision: 21192 Log: More multimedia tags. Disable incompatible libvpx in vlc. Does current vlc ship with its own version of vpx ? So far, firefox, thunderbird and now vlc dislike the latest version. Are the gst plugins, mplayer, seamonkey, xine ok with the new version, or should we revert to the previous version before the release ? I installed libvpx on my development system at 1253 today. gstreamer* did not complain. mplayer di dnot complain. xine did not complain. I haven't done seamonkey yet. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r21192 - in trunk/BOOK: general/genutils general/graphlib multimedia/audioutils multimedia/cdwriteutils multimedia/libdriv multimedia/videoutils x/lib
On Mon, Feb 18, 2019 at 12:28:59AM -, bdubbs--- via blfs-book wrote: > Author: bdubbs > Date: Sun Feb 17 16:28:59 2019 > New Revision: 21192 > > Log: > More multimedia tags. > Disable incompatible libvpx in vlc. > Does current vlc ship with its own version of vpx ? So far, firefox, thunderbird and now vlc dislike the latest version. Are the gst plugins, mplayer, seamonkey, xine ok with the new version, or should we revert to the previous version before the release ? ĸen -- The beauty of reading a page of de Selby is that it leads one inescapably to the conclusion that one is not, of all nincompoops, the greates.-- du Garbandier -- 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.4 Progress Report
Top posting on purpose... We continue to make great progress. lfs83 tags: 220 lfs84 tags: 619 My plan for tomorrow is to work on the Programming chapter (except java), Networking, and PostLFS, time permitting. -- Bruce On 2/16/19 9:23 PM, Bruce Dubbs wrote: We are doing great. Only two days in and we have over half the book tagged. lfs83 tags: 365 lfs84 tags: 475 There are a couple of drivers I can't easily test. I'd appreciate it if someone can do it. Just an email that the package has been built and tested in the lfs84 environment is sufficient. x/installing/x7driver-ati.xml x/installing/x7driver-vmware.xml x/installing/x7driver-amdgpu.xml x/installing/x7driver-vmmouse.xml -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] ALSA URLs broken
On 2/17/19 6:37 PM, Douglas R. Reno via blfs-dev wrote: Hi guys, I was going to download alsa-lib (the last version I have is 1.1.7), and it seems that they pulled versions 1.1.6-1.1.8 off their site: -rw-r--r-- 14 50 947423 Aug 2 2016 alsa-lib-1.1.2.tar.bz2 -rw-r--r-- 14 50 962001 Dec 20 2016 alsa-lib-1.1.3.tar.bz2 -rw-r--r-- 14 50 974584 Jun 1 2017 alsa-lib-1.1.4.1.tar.bz2 -rw-r--r-- 14 50 973825 May 12 2017 alsa-lib-1.1.4.tar.bz2 -rw-r--r-- 14 50 979225 Nov 14 2017 alsa-lib-1.1.5.tar.bz2 drwxr-xr-x 14 50 Feb 20 2009 old drwxr-xr-x 14 50 Feb 20 2009 stable ncftp /pub/lib > What should we do here? I know I can go pull from OSUOSL, but I wouldn't recommend that to users unless absolutely necessary. I can't see a message on their lists saying that they've pulled it. This seems to affect alsa-plugins, alsa-utils, alsa-tools, and alsa-oss. All of those also seem to have tarballs from 2018/2019 removed. I don't know if there's a data corruption problem upstream, but this is a problem. ALSA-Firmware is OK though, but there hasn't been a release of that in a long time. It must be inadvertent. Arch is at version 1.1.8 and there is still http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8 Just pull from OSUOSL for now. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] ALSA URLs broken
On Sun, Feb 17, 2019 at 06:37:26PM -0600, Douglas R. Reno via blfs-dev wrote: > Hi guys, > > I was going to download alsa-lib (the last version I have is 1.1.7), and it > seems that they pulled versions 1.1.6-1.1.8 off their site: > > > -rw-r--r-- 14 50 947423 Aug 2 2016 alsa-lib-1.1.2.tar.bz2 > -rw-r--r-- 14 50 962001 Dec 20 2016 alsa-lib-1.1.3.tar.bz2 > -rw-r--r-- 14 50 974584 Jun 1 2017 > alsa-lib-1.1.4.1.tar.bz2 > -rw-r--r-- 14 50 973825 May 12 2017 alsa-lib-1.1.4.tar.bz2 > -rw-r--r-- 14 50 979225 Nov 14 2017 alsa-lib-1.1.5.tar.bz2 > drwxr-xr-x 14 50 Feb 20 2009 old > drwxr-xr-x 14 50 Feb 20 2009 stable > ncftp /pub/lib > > > What should we do here? I know I can go pull from OSUOSL, but I wouldn't > recommend that to users unless absolutely necessary. I can't see a message > on their lists saying that they've pulled it. > > This seems to affect alsa-plugins, alsa-utils, alsa-tools, and alsa-oss. All > of those also seem to have tarballs from 2018/2019 removed. I don't know if > there's a data corruption problem upstream, but this is a problem. > ALSA-Firmware is OK though, but there hasn't been a release of that in a > long time. > > Thanks, > > Douglas R. Reno > Worrying - I took -lib and -utils from the book's link 47 hours ago, this looks as if maybe there is a problem in those versions. I suggest that people keep an eye on this for a few days. ĸen -- The beauty of reading a page of de Selby is that it leads one inescapably to the conclusion that one is not, of all nincompoops, the greates.-- du Garbandier -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] ALSA URLs broken
Hi guys, I was going to download alsa-lib (the last version I have is 1.1.7), and it seems that they pulled versions 1.1.6-1.1.8 off their site: -rw-r--r-- 14 50 947423 Aug 2 2016 alsa-lib-1.1.2.tar.bz2 -rw-r--r-- 14 50 962001 Dec 20 2016 alsa-lib-1.1.3.tar.bz2 -rw-r--r-- 14 50 974584 Jun 1 2017 alsa-lib-1.1.4.1.tar.bz2 -rw-r--r-- 14 50 973825 May 12 2017 alsa-lib-1.1.4.tar.bz2 -rw-r--r-- 14 50 979225 Nov 14 2017 alsa-lib-1.1.5.tar.bz2 drwxr-xr-x 14 50 Feb 20 2009 old drwxr-xr-x 14 50 Feb 20 2009 stable ncftp /pub/lib > What should we do here? I know I can go pull from OSUOSL, but I wouldn't recommend that to users unless absolutely necessary. I can't see a message on their lists saying that they've pulled it. This seems to affect alsa-plugins, alsa-utils, alsa-tools, and alsa-oss. All of those also seem to have tarballs from 2018/2019 removed. I don't know if there's a data corruption problem upstream, but this is a problem. ALSA-Firmware is OK though, but there hasn't been a release of that in a long time. Thanks, Douglas R. Reno -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Markup for i686 sed in Xorg intel driver ?
On 2/17/19 3:15 PM, Ken Moffat via blfs-dev wrote: The intel xorg driver has a sed for i686. I assume that people who use jhalfs will apply it even on x86_64. Is that a problem ? If you are building on i686, apply a sed to fix a type mismatch. sed -i "s/#define force_inline inline __attribute__((always_inline))/#define force_inline inline/" src/sna/compiler.h I don't have that in my script so I don't know for sure. I guess we need to make that case $(uname -m) in x86_64) sed '...' src/sna/compiler.h ;; esac But we can shorten up the pattern a lot. -r '/ inline/s/( inline).*$/\1/' -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Markup for i686 sed in Xorg intel driver ?
On 2/17/19 3:15 PM, Ken Moffat via blfs-dev wrote: The intel xorg driver has a sed for i686. I assume that people who use jhalfs will apply it even on x86_64. Is that a problem ? If you are building on i686, apply a sed to fix a type mismatch. sed -i "s/#define force_inline inline __attribute__((always_inline))/#define force_inline inline/" src/sna/compiler.h ĸen I didn't have a problem on x86_64 with this sed, if anything - it improved performance :-) If we do get a report though, I'll wrap it around a case statement. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r21178 - in trunk/BOOK: general/genutils general/graphlib lxde/desktop x/lib
On 2/17/19 9:46 PM, Thanos Baloukas via blfs-dev wrote: On 17/2/19 10:03 μ.μ., Bruce Dubbs via blfs-dev wrote: On 2/17/19 1:38 PM, Pierre Labastie via blfs-dev wrote: Not sure I understand: if a dep is in the recommended chain, what does it bring to put it in optional? Specially in this case, harfbuzz is useless for cairo without freetype and fontconfig... And freetype needs cairo. I think what I have put in the book at rev 21189 allows preventing the issue you had. Of course, it would not the same, for example, if a dep were required, and also in the recommended dependency chain... Then it would have to be mentioned as required. package pango Recommended cairo (but needs harfbuzz first) package cairo Required pixman and libpng only No mention of harfbuzz harfbuzz X Optional cairo If you build the optional cairo before harfbuzz, you can't build pango until cairo is rebuilt. The following sequence freetype fontconfig cairo harfbuzz freetype #Rebuild with Harfbuzz support pango works for me. Pango builds without the need to rebuild cairo after harfbuzz. Actually, according to README in cairo, one font backend is required, and the only one available for linux is fontconfig+freetype2: === Font backends (required to have at least one) - freetype font backend - freetype >= 2.1.9 http://freetype.org fontconfig http://fontconfig.org quartz-font backend --- MacOS X >= 10.4 with Xcode >= 2.4 win32 font backend -- Microsoft Windows 2000 or newer So I think we should *require* fontconfig+freetype for cairo. And that seems to match Thanos build order -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Markup for i686 sed in Xorg intel driver ?
The intel xorg driver has a sed for i686. I assume that people who use jhalfs will apply it even on x86_64. Is that a problem ? If you are building on i686, apply a sed to fix a type mismatch. sed -i "s/#define force_inline inline __attribute__((always_inline))/#define force_inline inline/" src/sna/compiler.h ĸen -- The beauty of reading a page of de Selby is that it leads one inescapably to the conclusion that one is not, of all nincompoops, the greates.-- du Garbandier -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r21178 - in trunk/BOOK: general/genutils general/graphlib lxde/desktop x/lib
On 17/2/19 10:03 μ.μ., Bruce Dubbs via blfs-dev wrote: On 2/17/19 1:38 PM, Pierre Labastie via blfs-dev wrote: On 17/02/2019 19:56, Bruce Dubbs via blfs-dev wrote: On 2/17/19 12:23 PM, Pierre Labastie via blfs-dev wrote: On 17/02/2019 17:06, Bruce Dubbs via blfs-dev wrote: On 2/17/19 7:35 AM, Pierre Labastie via blfs-dev wrote: On 17/02/2019 00:16, bdubbs--- via blfs-book wrote: Author: bdubbs Date: Sat Feb 16 15:16:14 2019 New Revision: 21178 Log: Add harfbuzz as an optional (circular) dependency of cairo. [...] Modified: trunk/BOOK/x/lib/cairo.xml == --- trunk/BOOK/x/lib/cairo.xml Sat Feb 16 14:03:30 2019 (r21177) +++ trunk/BOOK/x/lib/cairo.xml Sat Feb 16 15:16:14 2019 (r21178) @@ -104,6 +104,7 @@ , and , , + , , , , @@ -117,6 +118,10 @@ http://download.qt.io/archive/qt/4.8/;>Qt4. + There is a circular dependency between cairo and harfbuzz. + If cairo is built before harbuzz, it is necessary to rebuild cairo + after harfbuzz in order to build pango. + User Notes: Well, I'm not sure it has to be done this way: actually harfbuz is in the "recommended" dependency chain of cairo: cairo recommends fontconfig, which recommends freetype, which recommends harfbuzz... I do not know whether you use jhalfs. If cairo got built before harfbuzz using jhalfs, this is most probably a bug in jhalfs, so please tell me. I do not use jhalfs for BLFS (but it's critical for me in LFS). As I build for a release I try to get most of the optional dependencies as sell as the required and recommended. That does create some circular dependencies and it bit me when I tried to build pango. But that shouldn't happen, since harfbuzz is recommended (not directly, but it is) for cairo. I'll do the following: - on the harfbuzz page: note that the optional dep on cairo is circular, and that it is recommended to build harfbuzz first - on the cairo page: remove the optional dep on harfbuzz (it is already in the recommended chain), which can only add confusion. I thought we were only omitting deps in the required chain. -- Bruce Not sure I understand: if a dep is in the recommended chain, what does it bring to put it in optional? Specially in this case, harfbuzz is useless for cairo without freetype and fontconfig... And freetype needs cairo. I think what I have put in the book at rev 21189 allows preventing the issue you had. Of course, it would not the same, for example, if a dep were required, and also in the recommended dependency chain... Then it would have to be mentioned as required. package pango Recommended cairo (but needs harfbuzz first) package cairo Required pixman and libpng only No mention of harfbuzz harfbuzz X Optional cairo If you build the optional cairo before harfbuzz, you can't build pango until cairo is rebuilt. The following sequence freetype fontconfig cairo harfbuzz freetype #Rebuild with Harfbuzz support pango works for me. Pango builds without the need to rebuild cairo after harfbuzz. The latest changes you made are fine, but there was not enough explanation before. -- Bruce -- Thanos -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r21178 - in trunk/BOOK: general/genutils general/graphlib lxde/desktop x/lib
On 2/17/19 1:38 PM, Pierre Labastie via blfs-dev wrote: On 17/02/2019 19:56, Bruce Dubbs via blfs-dev wrote: On 2/17/19 12:23 PM, Pierre Labastie via blfs-dev wrote: On 17/02/2019 17:06, Bruce Dubbs via blfs-dev wrote: On 2/17/19 7:35 AM, Pierre Labastie via blfs-dev wrote: On 17/02/2019 00:16, bdubbs--- via blfs-book wrote: Author: bdubbs Date: Sat Feb 16 15:16:14 2019 New Revision: 21178 Log: Add harfbuzz as an optional (circular) dependency of cairo. [...] Modified: trunk/BOOK/x/lib/cairo.xml == --- trunk/BOOK/x/lib/cairo.xml Sat Feb 16 14:03:30 2019 (r21177) +++ trunk/BOOK/x/lib/cairo.xml Sat Feb 16 15:16:14 2019 (r21178) @@ -104,6 +104,7 @@ , and , , + , , , , @@ -117,6 +118,10 @@ http://download.qt.io/archive/qt/4.8/;>Qt4. + There is a circular dependency between cairo and harfbuzz. + If cairo is built before harbuzz, it is necessary to rebuild cairo + after harfbuzz in order to build pango. + User Notes: Well, I'm not sure it has to be done this way: actually harfbuz is in the "recommended" dependency chain of cairo: cairo recommends fontconfig, which recommends freetype, which recommends harfbuzz... I do not know whether you use jhalfs. If cairo got built before harfbuzz using jhalfs, this is most probably a bug in jhalfs, so please tell me. I do not use jhalfs for BLFS (but it's critical for me in LFS). As I build for a release I try to get most of the optional dependencies as sell as the required and recommended. That does create some circular dependencies and it bit me when I tried to build pango. But that shouldn't happen, since harfbuzz is recommended (not directly, but it is) for cairo. I'll do the following: - on the harfbuzz page: note that the optional dep on cairo is circular, and that it is recommended to build harfbuzz first - on the cairo page: remove the optional dep on harfbuzz (it is already in the recommended chain), which can only add confusion. I thought we were only omitting deps in the required chain. -- Bruce Not sure I understand: if a dep is in the recommended chain, what does it bring to put it in optional? Specially in this case, harfbuzz is useless for cairo without freetype and fontconfig... And freetype needs cairo. I think what I have put in the book at rev 21189 allows preventing the issue you had. Of course, it would not the same, for example, if a dep were required, and also in the recommended dependency chain... Then it would have to be mentioned as required. package pango Recommended cairo (but needs harfbuzz first) package cairo Required pixman and libpng only No mention of harfbuzz harfbuzz X Optional cairo If you build the optional cairo before harfbuzz, you can't build pango until cairo is rebuilt. The latest changes you made are fine, but there was not enough explanation before. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r21178 - in trunk/BOOK: general/genutils general/graphlib lxde/desktop x/lib
On 17/02/2019 19:56, Bruce Dubbs via blfs-dev wrote: > On 2/17/19 12:23 PM, Pierre Labastie via blfs-dev wrote: >> On 17/02/2019 17:06, Bruce Dubbs via blfs-dev wrote: >>> On 2/17/19 7:35 AM, Pierre Labastie via blfs-dev wrote: On 17/02/2019 00:16, bdubbs--- via blfs-book wrote: > Author: bdubbs > Date: Sat Feb 16 15:16:14 2019 > New Revision: 21178 > > Log: > Add harfbuzz as an optional (circular) dependency of cairo. > [...] > Modified: trunk/BOOK/x/lib/cairo.xml > == > > --- trunk/BOOK/x/lib/cairo.xml Sat Feb 16 14:03:30 2019 (r21177) > +++ trunk/BOOK/x/lib/cairo.xml Sat Feb 16 15:16:14 2019 (r21178) > @@ -104,6 +104,7 @@ > , > and , > , > + , > , > , > , > @@ -117,6 +118,10 @@ > http://download.qt.io/archive/qt/4.8/;>Qt4. > > + There is a circular dependency between cairo and harfbuzz. > + If cairo is built before harbuzz, it is necessary to rebuild cairo > + after harfbuzz in order to build pango. > + > > User Notes: > Well, I'm not sure it has to be done this way: actually harfbuz is in the "recommended" dependency chain of cairo: cairo recommends fontconfig, which recommends freetype, which recommends harfbuzz... I do not know whether you use jhalfs. If cairo got built before harfbuzz using jhalfs, this is most probably a bug in jhalfs, so please tell me. >>> >>> I do not use jhalfs for BLFS (but it's critical for me in LFS). As I build >>> for a release I try to get most of the optional dependencies as sell as the >>> required and recommended. That does create some circular dependencies and >>> it >>> bit me when I tried to build pango. >>> >> >> But that shouldn't happen, since harfbuzz is recommended (not directly, but >> it >> is) for cairo. I'll do the following: >> - on the harfbuzz page: note that the optional dep on cairo is circular, and >> that it is recommended to build harfbuzz first >> - on the cairo page: remove the optional dep on harfbuzz (it is already in >> the >> recommended chain), which can only add confusion. > > I thought we were only omitting deps in the required chain. > > -- Bruce > > Not sure I understand: if a dep is in the recommended chain, what does it bring to put it in optional? Specially in this case, harfbuzz is useless for cairo without freetype and fontconfig... And freetype needs cairo. I think what I have put in the book at rev 21189 allows preventing the issue you had. Of course, it would not the same, for example, if a dep were required, and also in the recommended dependency chain... Then it would have to be mentioned as required. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r21178 - in trunk/BOOK: general/genutils general/graphlib lxde/desktop x/lib
On 2/17/19 12:23 PM, Pierre Labastie via blfs-dev wrote: On 17/02/2019 17:06, Bruce Dubbs via blfs-dev wrote: On 2/17/19 7:35 AM, Pierre Labastie via blfs-dev wrote: On 17/02/2019 00:16, bdubbs--- via blfs-book wrote: Author: bdubbs Date: Sat Feb 16 15:16:14 2019 New Revision: 21178 Log: Add harfbuzz as an optional (circular) dependency of cairo. [...] Modified: trunk/BOOK/x/lib/cairo.xml == --- trunk/BOOK/x/lib/cairo.xml Sat Feb 16 14:03:30 2019 (r21177) +++ trunk/BOOK/x/lib/cairo.xml Sat Feb 16 15:16:14 2019 (r21178) @@ -104,6 +104,7 @@ , and , , + , , , , @@ -117,6 +118,10 @@ http://download.qt.io/archive/qt/4.8/;>Qt4. + There is a circular dependency between cairo and harfbuzz. + If cairo is built before harbuzz, it is necessary to rebuild cairo + after harfbuzz in order to build pango. + User Notes: Well, I'm not sure it has to be done this way: actually harfbuz is in the "recommended" dependency chain of cairo: cairo recommends fontconfig, which recommends freetype, which recommends harfbuzz... I do not know whether you use jhalfs. If cairo got built before harfbuzz using jhalfs, this is most probably a bug in jhalfs, so please tell me. I do not use jhalfs for BLFS (but it's critical for me in LFS). As I build for a release I try to get most of the optional dependencies as sell as the required and recommended. That does create some circular dependencies and it bit me when I tried to build pango. But that shouldn't happen, since harfbuzz is recommended (not directly, but it is) for cairo. I'll do the following: - on the harfbuzz page: note that the optional dep on cairo is circular, and that it is recommended to build harfbuzz first - on the cairo page: remove the optional dep on harfbuzz (it is already in the recommended chain), which can only add confusion. I thought we were only omitting deps in the required chain. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r21178 - in trunk/BOOK: general/genutils general/graphlib lxde/desktop x/lib
On 17/02/2019 17:06, Bruce Dubbs via blfs-dev wrote: > On 2/17/19 7:35 AM, Pierre Labastie via blfs-dev wrote: >> >> >> >> >> >> On 17/02/2019 00:16, bdubbs--- via blfs-book wrote: >>> Author: bdubbs >>> Date: Sat Feb 16 15:16:14 2019 >>> New Revision: 21178 >>> >>> Log: >>> Add harfbuzz as an optional (circular) dependency of cairo. >>> [...] >>> Modified: trunk/BOOK/x/lib/cairo.xml >>> == >>> --- trunk/BOOK/x/lib/cairo.xml Sat Feb 16 14:03:30 2019 (r21177) >>> +++ trunk/BOOK/x/lib/cairo.xml Sat Feb 16 15:16:14 2019 (r21178) >>> @@ -104,6 +104,7 @@ >>> , >>> and , >>> , >>> + , >>> , >>> , >>> , >>> @@ -117,6 +118,10 @@ >>> http://download.qt.io/archive/qt/4.8/;>Qt4. >>> >>> + There is a circular dependency between cairo and harfbuzz. >>> + If cairo is built before harbuzz, it is necessary to rebuild cairo >>> + after harfbuzz in order to build pango. >>> + >>> >>> User Notes: >>> >> >> Well, I'm not sure it has to be done this way: actually harfbuz is in the >> "recommended" dependency chain of cairo: cairo recommends fontconfig, which >> recommends freetype, which recommends harfbuzz... >> >> I do not know whether you use jhalfs. If cairo got built before harfbuzz >> using >> jhalfs, this is most probably a bug in jhalfs, so please tell me. > > I do not use jhalfs for BLFS (but it's critical for me in LFS). As I build > for a release I try to get most of the optional dependencies as sell as the > required and recommended. That does create some circular dependencies and it > bit me when I tried to build pango. > But that shouldn't happen, since harfbuzz is recommended (not directly, but it is) for cairo. I'll do the following: - on the harfbuzz page: note that the optional dep on cairo is circular, and that it is recommended to build harfbuzz first - on the cairo page: remove the optional dep on harfbuzz (it is already in the recommended chain), which can only add confusion. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] pulseaudio / fftw
On 2/17/19 10:39 AM, Bruce Dubbs wrote: Pulse is looking for ffttw3f... OK, the default for fftw is double... I'll fix the fftw instructions. OK, the instruction changes for fftw are committed at revision 21186. Pulseaudio now finds the proper library. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] pulseaudio / fftw
On 2/17/19 2:08 AM, Armin K. via blfs-dev wrote: On 17.2.2019. 07:04, Thomas Trepl via blfs-dev wrote: Hi, while rebuilding stuff for 8.4 i came across pulseaudio. I have fftw installed and so i expected that pulseaudio will link to it somehow (as it it mentioned as an optional dep). But it didn't. The config.log of pulseaudio shows: ... configure:23251: checking for FFTW configure:23258: $PKG_CONFIG --exists --print-errors " fftw3f " Package fftw3f was not found in the pkg-config search path. Perhaps you should add the directory containing `fftw3f.pc' to the PKG_CONFIG_PATH environment variable No package 'fftw3f' found configure:23261: $? = 1 configure:23275: $PKG_CONFIG --exists --print-errors " fftw3f " Package fftw3f was not found in the pkg-config search path. Perhaps you should add the directory containing `fftw3f.pc' to the PKG_CONFIG_PATH environment variable No package 'fftw3f' found configure:23278: $? = 1 configure:23292: result: no No package 'fftw3f' found ... Indeed, there is no fftw3f.pc, only a /usr/lib/pkgconfig/fftw3.pc Ideas? -- Thomas FFTW has three "modes". This requires compiling it three times. See [1]. You need "single precision" for pulse. https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/fftw That's interesting. We probably should do that now, but don't we install single precision with the current instructions? Checking... Pulse is looking for ffttw3f... fftw is now installing : libfftw3.so.3.5.8 libfftw3.so.3 libfftw3.so OK, the default for fftw is double... I'll fix the fftw instructions. -- bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r21178 - in trunk/BOOK: general/genutils general/graphlib lxde/desktop x/lib
On 2/17/19 7:35 AM, Pierre Labastie via blfs-dev wrote: On 17/02/2019 00:16, bdubbs--- via blfs-book wrote: Author: bdubbs Date: Sat Feb 16 15:16:14 2019 New Revision: 21178 Log: Add harfbuzz as an optional (circular) dependency of cairo. [...] Modified: trunk/BOOK/x/lib/cairo.xml == --- trunk/BOOK/x/lib/cairo.xml Sat Feb 16 14:03:30 2019 (r21177) +++ trunk/BOOK/x/lib/cairo.xml Sat Feb 16 15:16:14 2019 (r21178) @@ -104,6 +104,7 @@ , and , , + , , , , @@ -117,6 +118,10 @@ http://download.qt.io/archive/qt/4.8/;>Qt4. + There is a circular dependency between cairo and harfbuzz. + If cairo is built before harbuzz, it is necessary to rebuild cairo + after harfbuzz in order to build pango. + User Notes: Well, I'm not sure it has to be done this way: actually harfbuz is in the "recommended" dependency chain of cairo: cairo recommends fontconfig, which recommends freetype, which recommends harfbuzz... I do not know whether you use jhalfs. If cairo got built before harfbuzz using jhalfs, this is most probably a bug in jhalfs, so please tell me. I do not use jhalfs for BLFS (but it's critical for me in LFS). As I build for a release I try to get most of the optional dependencies as sell as the required and recommended. That does create some circular dependencies and it bit me when I tried to build pango. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r21178 - in trunk/BOOK: general/genutils general/graphlib lxde/desktop x/lib
On 17/02/2019 00:16, bdubbs--- via blfs-book wrote: > Author: bdubbs > Date: Sat Feb 16 15:16:14 2019 > New Revision: 21178 > > Log: > Add harfbuzz as an optional (circular) dependency of cairo. > [...] > Modified: trunk/BOOK/x/lib/cairo.xml > == > --- trunk/BOOK/x/lib/cairo.xml Sat Feb 16 14:03:30 2019 (r21177) > +++ trunk/BOOK/x/lib/cairo.xml Sat Feb 16 15:16:14 2019 (r21178) > @@ -104,6 +104,7 @@ > , > and , > , > + , > , > , > , > @@ -117,6 +118,10 @@ > http://download.qt.io/archive/qt/4.8/;>Qt4. > > + There is a circular dependency between cairo and harfbuzz. > + If cairo is built before harbuzz, it is necessary to rebuild cairo > + after harfbuzz in order to build pango. > + > > User Notes: > Well, I'm not sure it has to be done this way: actually harfbuz is in the "recommended" dependency chain of cairo: cairo recommends fontconfig, which recommends freetype, which recommends harfbuzz... I do not know whether you use jhalfs. If cairo got built before harfbuzz using jhalfs, this is most probably a bug in jhalfs, so please tell me. Sent to blfs-dev, because some of my last messages to blfs-book have not appeared... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] pulseaudio / fftw
Am Sonntag, den 17.02.2019, 09:08 +0100 schrieb Armin K. via blfs-dev: > On 17.2.2019. 07:04, Thomas Trepl via blfs-dev wrote: > > Hi, > > > > while rebuilding stuff for 8.4 i came across pulseaudio. I have fftw > > installed and so i expected that pulseaudio will link to it somehow > > (as it it mentioned as an optional dep). But it didn't. > > > > The config.log of pulseaudio shows: > > ... > > configure:23251: checking for FFTW > > configure:23258: $PKG_CONFIG --exists --print-errors " fftw3f " > > Package fftw3f was not found in the pkg-config search path. > > Perhaps you should add the directory containing `fftw3f.pc' > > to the PKG_CONFIG_PATH environment variable > > No package 'fftw3f' found > > configure:23261: $? = 1 > > configure:23275: $PKG_CONFIG --exists --print-errors " fftw3f " > > Package fftw3f was not found in the pkg-config search path. > > Perhaps you should add the directory containing `fftw3f.pc' > > to the PKG_CONFIG_PATH environment variable > > No package 'fftw3f' found > > configure:23278: $? = 1 > > configure:23292: result: no > > No package 'fftw3f' found > > ... > > > > Indeed, there is no fftw3f.pc, only a /usr/lib/pkgconfig/fftw3.pc > > > > Ideas? > > > > -- > > Thomas > > > > FFTW has three "modes". This requires compiling it three times. See [1]. > You need "single precision" for pulse. > > https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/fftw Yeah, thats strange :) Thanks! -- Thomas -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r21184 - in branches/bootscripts-elogind: . blfs/init.d
On 17.2.2019. 08:58, dj--- via blfs-book wrote:
Author: dj
Date: Sat Feb 16 23:58:08 2019
New Revision: 21184
Log:
Detect/set XDG_SESSION_TYPE for gdm
Modified:
branches/bootscripts-elogind/ChangeLog
branches/bootscripts-elogind/blfs/init.d/gdm
Modified: branches/bootscripts-elogind/ChangeLog
==
--- branches/bootscripts-elogind/ChangeLog Sat Feb 16 23:22:47 2019
(r21183)
+++ branches/bootscripts-elogind/ChangeLog Sat Feb 16 23:58:08 2019
(r21184)
@@ -1,4 +1,7 @@
2019-02-07 DJ Lucas
+ * Detect/set XDG_SESSION_TYPE for gdm
+
+2019-02-07 DJ Lucas
* Add separate mount for /run/user to mountcgroupfs
* Correct dependency information for elogind
Modified: branches/bootscripts-elogind/blfs/init.d/gdm
==
--- branches/bootscripts-elogind/blfs/init.d/gdmSat Feb 16 23:22:47
2019(r21183)
+++ branches/bootscripts-elogind/blfs/init.d/gdmSat Feb 16 23:58:08
2019(r21184)
@@ -5,6 +5,7 @@
# Description : GDM Boot Script
#
# Authors : Armin K.
+# DJ Lucas
#
# Version : BLFS SVN
#
@@ -14,8 +15,8 @@
# Provides:gdm
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
-# Default-Start: 2 3 4 5
-# Default-Stop:0 1 6
+# Default-Start: 5
+# Default-Stop:0 1 2 3 4 6
# Short-Description: GNOME Display Manager
# X-LFS-Provided-By: BLFS
### END INIT INFO
@@ -26,6 +27,14 @@
case "${1}" in
start)
+ # Determine session type
+ XDG_SESSION_TYPE=wayland
+ if [ -f /etc/gdm/custom.conf ]; then
+grep "^WaylandEnable" | grep "false" 2>&1>/dev/null &&
+XDG_SESSION_TYPE=x11
+ fi
+ export XDG_SESSION_TYPE
+
log_info_msg "Starting GNOME Display Manager GDM"
start_daemon ${GDM_BINARY}
evaluate_retval
This won't always work. Session type is determined at GDM runtime. Even
if wayland is enabled, it can fall back to x11 if wayland cannot be
initialized, for example on nvidia binary drivers.
--
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 / fftw
On 17.2.2019. 07:04, Thomas Trepl via blfs-dev wrote: Hi, while rebuilding stuff for 8.4 i came across pulseaudio. I have fftw installed and so i expected that pulseaudio will link to it somehow (as it it mentioned as an optional dep). But it didn't. The config.log of pulseaudio shows: ... configure:23251: checking for FFTW configure:23258: $PKG_CONFIG --exists --print-errors " fftw3f " Package fftw3f was not found in the pkg-config search path. Perhaps you should add the directory containing `fftw3f.pc' to the PKG_CONFIG_PATH environment variable No package 'fftw3f' found configure:23261: $? = 1 configure:23275: $PKG_CONFIG --exists --print-errors " fftw3f " Package fftw3f was not found in the pkg-config search path. Perhaps you should add the directory containing `fftw3f.pc' to the PKG_CONFIG_PATH environment variable No package 'fftw3f' found configure:23278: $? = 1 configure:23292: result: no No package 'fftw3f' found ... Indeed, there is no fftw3f.pc, only a /usr/lib/pkgconfig/fftw3.pc Ideas? -- Thomas FFTW has three "modes". This requires compiling it three times. See [1]. You need "single precision" for pulse. https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/fftw -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
