[blfs-support] More deprecation of ftp.
The latest versions of firefox (78.10.0esr and 88.0 were released today. I noticed on phoronix that in 88 (but not 78.10) the first steps towards removal of the ability to download from ftp links were taken. Checking this in 88.0 (I normally have that available from testing beta versions, but using it to download from ftp links is not something I normally do) I see that at the moment it will require an application to be chosed to handle this. According to phoronix ftp is expected to be removed completely in firefox-90.0. BLFS will remain on the 78-esr series until the next esr series is available (91.0) - at that point, downloading ftp via firefox will presumable no longer work. ĸen -- My inbox is kind of a modern-day Colossal Cave adventure: "You are in a maze of twisty email threads, all similar but with different hidden details". -- Linus -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] xscreensaver with blank screen
Is anyone else seeing blank screens with current xscreensaver ?
I've updated all my recent systems to the current version, and when
it works it is great (freetype fonts). But often I'm seeing a
blank screen - note that the screen does not turn off, the monitors
are sure there is a display, but everything is black until I move
the mouse or hit a key.
People will know that I rebuild kernels more often than some people,
and at first I thought that a newer kernel, and something backported
to later 5.10 and 5.11 was the problem - but now my impression is
that after a while the saver just goes black.
Current data:
low-end skylake with intel graphics: this only gets used
infrequently (it's too slow), but with 5.10.17 xscreensaver seems to
work and to continue to work (been using it intermittently for a
couple of days).
AMD 3400G (Picasso) - I thought that I saw savers running with
5.11.5, but later things were black. With 5.12.0-rc{4,6} I never
saw a saver running. 5.10.17 worked on a brief test.
Intel haswell (using modesetting) - this is where my expectations
broke down:
first, 5.10.24 - screen just blanked
second, 5.10.17 - worked, then after briefly resuming the system it
again worked ok. I assumed this was 'good', started to build
something - the saver again ran. Used the mouse to see if the
build had finished (it hadn't), left it again. Came back, screen
was black.
At this point I'm just asking if anyone else is seeing similar weird
behaviour ?
ĸen
--
Music teaches you to get past a mistake: If you make one when you play
live, you can't stop. You just have to carry on. -- Richard Thompson
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] xwayland 21.1.0
On Thu, Mar 25, 2021 at 04:19:40PM +0100, Leandro Nini via blfs-support wrote: > Hello, > > a standalone version of Xwayland has been released > (https://lists.x.org/archives/xorg-announce/2021-March/003076.html) > should this be installed over the current version provided by xorg-server? > > > Cheers, > Leandro It's a question for people who are using wayland - I think that of the packages in the book, only gnome uses wayland (certainly when I last looked the kde plasma package was pointed to the xorg version by a sed). I think that Xwayland provides compatability for running Xorg apps under wayland. I don't think we've got anything in the book, apart from gdm/mutter, which invokes wayland. ĸen -- On average, the Panda feeds for 15 hours a day. This is the same as an adult at home under quarantine, which is why we call it a "Pandemic". -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] firefox and the mozilla/plugins symlink
I'm getting ready for next week's release of firefox-78.9.0 by measuring the build using the current candidate. Looking at our instructions, since 'time immemorial' (ok, more exactly for 3 years, but in our terms that is eons ago) we've had: mkdir -pv /usr/lib/mozilla/plugins && ln-sfv ../../mozilla/plugins /usr/lib/firefox/browser/ That was created/updated when I changed firefox to 58 and then 59. I can vaguely recall that in those days there were still available plugins. But looking at my current system I see no sign of any plugins in that directory, so I'm minded to remove this unless anyone jumps up and says that with 78.8.0 they do actually have any extra plugins in /usr/lib/firefox/browser. For myself, the only enabled plugin shown in 'about:addons' is the OpenH264 video codec from Cisco which 'is automatically installed to comply with the WebRTC spec' and that does not show up in /usr/lib/mozilla/plugins. Copying to -support just in case someone there has a different view. ĸen -- On average, the Panda feeds for 15 hours a day. This is the same as an adult at home under quarantine, which is why we call it a "Pandemic". -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] LLVM dependency
On Mon, Mar 08, 2021 at 04:49:31PM -0500, Joe Locash wrote: > On Mon, Mar 8, 2021, 1:24 PM Ken Moffat via blfs-support < > blfs-support@lists.linuxfromscratch.org> wrote: > > > On Mon, Mar 08, 2021 at 11:40:08AM -0500, Pat Barnes via > > blfs-support wrote: > > > > > > On 3/5/21 2:54 PM, Ken Moffat via blfs-support wrote: > > > > On Fri, Mar 05, 2021 at 12:32:05PM -0500, Pat Barnes via > > > > blfs-support wrote: > > > > > While installing LLVM in 10.1, I found that Clang now has a > > > > > dependency on GIT. This should be added to the list of > > > > > dependencies for LLVM, at least when Clang is also installed. > > > > > > > > > > Pat > > > > > [...] > > > > > > Yes, my build failed until I installed GIT and then it installed > > > correctly without any problem. The failure occurred after LLVM > > > proper had compiled and the checks for CLANG dependencies egan. > > > > > > Pat > > > > > Thanks for the report. I've moved git to a required dependency in > > the dev books at r24349 and created errata entries for 10.1 and > > 10.1-systemd. > > > > I'm not so sure this should be a required dep. I build llvm very early > with clang and without git installed and don't get a failure. My build box > doesn't have net access either. I don't run the checks so it could be that > git is needed for that. > Thanks to both you and Pierre for querying this. I've now tested building llvm with clang on a machine where /usr/bin/git has been made unavailable: the build, a DESTDIR install and the tests all completed. I've reverted the change in r24349 and the errata. ĸen -- RIGHT, he said, PESTILENCE, OPEN ANOTHER PACK OF CARDS. I'M GOING TO GET TO THE BOTTOM OF THIS IF IT KILLS ME, FIGURATIVELY SPEAKING OF COURSE. Rincewind grabbed Twoflower and pulled. -- The Light Fantastic -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] LLVM dependency
On Mon, Mar 08, 2021 at 11:40:08AM -0500, Pat Barnes via
blfs-support wrote:
>
> On 3/5/21 2:54 PM, Ken Moffat via blfs-support wrote:
> > On Fri, Mar 05, 2021 at 12:32:05PM -0500, Pat Barnes via
> > blfs-support wrote:
> > > While installing LLVM in 10.1, I found that Clang now has a
> > > dependency on GIT. This should be added to the list of
> > > dependencies for LLVM, at least when Clang is also installed.
> > >
> > > Pat
> > >
> > Looking at one of my own builds, I can see git is mentioned (and
> > I install git very early in my build), but I don't think it has
> > anything to do with clang (although /usr/bin/git-clang-format
> > does get installed (a python script).
> >
> > I can see the following references to GIT in the CMakeLists.txt:
> >
> > ./utils/benchmark/src/CMakeLists.txt:"${version_config}"
> > VERSION ${GIT_VERSION} COMPATIBILITY SameMajorVersion
> > ./utils/benchmark/CMakeLists.txt:# get_git_version(GIT_VERSION)
> > ./utils/benchmark/CMakeLists.txt:set(GIT_VERSION "v0.0.0")
> >
> > The first of those is:
> >
> > include(CMakePackageConfigHelpers)
> > write_basic_package_version_file( "${version_config}" VERSION
> > ${GIT_VERSION} COMPATIBILITY SameMajorVersion)
> >
> > and the second and third are:
> >
> > # Read the git tags to determine the project version # WARNING:
> > This is meaningless for when the benchmark library is being
> > built in-tree, # so disable it and hardcode a null version. #
> > include(GetGitVersion) # get_git_version(GIT_VERSION)
> > set(GIT_VERSION "v0.0.0")
> >
> > That makes me think it is a piece of boilerplate and that
> > although cmake looks for it, it doesn't actually use it.
> >
> > Or did your build fail, or else not install git-clang-format,
> > because git was missing ?
> >
> > ĸen
>
> Yes, my build failed until I installed GIT and then it installed
> correctly without any problem. The failure occurred after LLVM
> proper had compiled and the checks for CLANG dependencies egan.
>
> Pat
>
Thanks for the report. I've moved git to a required dependency in
the dev books at r24349 and created errata entries for 10.1 and
10.1-systemd.
ĸen
--
RIGHT, he said, PESTILENCE, OPEN ANOTHER PACK OF CARDS. I'M GOING TO GET
TO THE BOTTOM OF THIS IF IT KILLS ME, FIGURATIVELY SPEAKING OF COURSE.
Rincewind grabbed Twoflower and pulled. -- The Light Fantastic
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] LLVM dependency
On Fri, Mar 05, 2021 at 12:32:05PM -0500, Pat Barnes via blfs-support wrote:
> While installing LLVM in 10.1, I found that Clang now has a dependency on
> GIT. This should be added to the list of dependencies for LLVM, at least
> when Clang is also installed.
>
> Pat
>
Looking at one of my own builds, I can see git is mentioned (and I
install git very early in my build), but I don't think it has
anything to do with clang (although /usr/bin/git-clang-format does
get installed (a python script).
I can see the following references to GIT in the CMakeLists.txt:
./utils/benchmark/src/CMakeLists.txt:"${version_config}" VERSION
${GIT_VERSION} COMPATIBILITY SameMajorVersion
./utils/benchmark/CMakeLists.txt:# get_git_version(GIT_VERSION)
./utils/benchmark/CMakeLists.txt:set(GIT_VERSION "v0.0.0")
The first of those is:
include(CMakePackageConfigHelpers)
write_basic_package_version_file(
"${version_config}" VERSION ${GIT_VERSION} COMPATIBILITY SameMajorVersion
)
and the second and third are:
# Read the git tags to determine the project version
# WARNING: This is meaningless for when the benchmark library is being built
in-tree,
# so disable it and hardcode a null version.
# include(GetGitVersion)
# get_git_version(GIT_VERSION)
set(GIT_VERSION "v0.0.0")
That makes me think it is a piece of boilerplate and that although
cmake looks for it, it doesn't actually use it.
Or did your build fail, or else not install git-clang-format,
because git was missing ?
ĸen
--
RIGHT, he said, PESTILENCE, OPEN ANOTHER PACK OF CARDS. I'M GOING TO GET
TO THE BOTTOM OF THIS IF IT KILLS ME, FIGURATIVELY SPEAKING OF COURSE.
Rincewind grabbed Twoflower and pulled. -- The Light Fantastic
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] Missing directory patch directory for systemd 10.1
On Wed, Mar 03, 2021 at 05:21:28PM -0500, Pat Barnes via blfs-support wrote: > While trying to install libxml2-2.9.10, I tried to download the patch: > > http://www.linuxfromscratch.org/patches/blfs/10.1/libxml2-2.9.10-security_fixes-1.patch > > It seems that http://www.linuxfromscratch.org/patches/blfs/10.1/ doesn't > exist. I was able to get the patch from the 10.0 security advisors, but I > suspect this will not be the last missing patch that I need. > Thanks for the report. Meanwhile, all patches are at http://www.linuxfromscratch.org/patches/downloads/ ĸen -- RIGHT, he said, PESTILENCE, OPEN ANOTHER PACK OF CARDS. I'M GOING TO GET TO THE BOTTOM OF THIS IF IT KILLS ME, FIGURATIVELY SPEAKING OF COURSE. Rincewind grabbed Twoflower and pulled. -- The Light Fantastic -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] /run/user/1000 vs /run/user/$username ?
I've been looking at one or two things which seem a bit odd in my currnet build. First, running the tests on falkon tried to create run/user/ken but failed with -EPERM - I have /run/user/1000, symlinking ken to 1000 caused the error message to change - it expected a directory buit found a symlink. Now I've decided to try to get sound in firefox working again (it's been broken for a while, but I don't usually have time to care). So I killed firefox and ran the first of the "how to fix it" steps: ken@origin ~ $pactl list short sinks Failed to create secure directory (/run/user/ken/pulse): No such file or directory Connection failure: Connection refused pa_context_connect() failed: Connection refused Has anyone else using sysv got /run/user/$name or is everyone on /run/user/number ? It looks as if the reason for no sound is that pulseaudio needs to access /run/user/ken - after trying to kill it (failed, but not running) : ken@origin ~ $pulseaudio --kill E: [pulseaudio] core-util.c: Failed to create secure directory (/run/user/ken/pulse): No such file or directory E: [pulseaudio] main.c: Failed to kill daemon: No such file or directory ken@origin ~ $killall -KILL pulseaudio pulseaudio: no process found ken@origin ~ $ps aux | grep pulse ken 4423 0.0 0.0 221364 2232 pts/3S+ 03:09 0:00 grep pulse I then tried to start it: ken@origin ~ $pulseaudio --verbose I: [pulseaudio] main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted I: [pulseaudio] main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted I: [pulseaudio] core-util.c: Failed to acquire high-priority scheduling: No such file or directory I: [pulseaudio] main.c: This is PulseAudio 14.2 I: [pulseaudio] main.c: Page size is 4096 bytes I: [pulseaudio] main.c: Machine ID is b541c1c5d946b7c8ef70d0cb6026903f. I: [pulseaudio] main.c: Session ID is c1. E: [pulseaudio] core-util.c: Failed to create secure directory (/run/user/ken/pulse): No such file or directory ken@origin ~ $ps aux | grep pulse ken 4435 0.0 0.0 221364 2064 pts/3S+ 03:10 0:00 grep pulse At this point I think I'll utter the usual obscenities. Thanks for any suggestions. ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] QtWebengine and glibc-2.33, was Re: Blank text on some sites with fresh build of falkon
On Sun, Feb 14, 2021 at 02:07:57AM +, Ken Moffat via blfs-support wrote: [ originally to -support, now copying -dev, looks like glibc-2.33 with qtwebengine is the problem ] > This has got me flummoxed. > > I use falkon as my secondary browser for (amongst other things) > lwn.net and gmail. I last built it using package versions from > 2020-12-25 BLFS, now I'm using 2021-02-10. > > On some pages (gmail, theregister) everything is normal, but on > others all images are present but no text (except for any text which > is within an image). > > Among the sites without text are: > > https://lwn.net > www.lspace.org/ (and all the pages, starting at main.html) > www.hyperion-records.co.uk > > https://googleprojectzero.blogspot.com/2021/01/introducing-in-wild-series.html > I'll also mention that github is similarly affected. Arch are using a qt5-webengine-glibc-2.33.patch to fix this, from fedora, reported at https://bugzilla.redhat.com/show_bug.cgi?id=1904652 Something in glibc-2.33 breaks the chromium sandbox code: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/OK3ZF3554P4D5NUGW3BJMR2R7WONIFUY/#OK3ZF3554P4D5NUGW3BJMR2R7WONIFUY Interesting comments in that thread explaining what changed in glibc-2.33. It will be some hours before I can prove that the patch does fix it, but it looks hopeful. Makes me wonder what other surprises are hiding in glibc-2.33. ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Blank text on some sites with fresh build of falkon
This has got me flummoxed. I use falkon as my secondary browser for (amongst other things) lwn.net and gmail. I last built it using package versions from 2020-12-25 BLFS, now I'm using 2021-02-10. On some pages (gmail, theregister) everything is normal, but on others all images are present but no text (except for any text which is within an image). Among the sites without text are: https://lwn.net www.lspace.org/ (and all the pages, starting at main.html) www.hyperion-records.co.uk https://googleprojectzero.blogspot.com/2021/01/introducing-in-wild-series.html I can't see anything obvious in what has changed, in particular the versions of Qt, QtWebEngine, Falkon are unchanged. Both Cmake and extra-cmake-modules are newer in this build, but I don't think those seem likely candidates. I'm guessing this might be stylesheets being mis-processed, but no idea what would cause that. I wondered if newer harfbuzz might be the problem, so I installed harfbuzz-2.7.2, fixed up the .so symlinks to point to that older version, and recompiled freetype - but no change. My only other qt packages are vlc and gimp's qmic-qt plugin, both appear to be working without problems. Any ideas, please ? ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Security Advisories now live
On Sat, Feb 06, 2021 at 09:57:58PM -0500, Don Cross via blfs-support wrote: > On Sat, Feb 6, 2021 at 9:46 PM Ken Moffat via blfs-support < > blfs-support@lists.linuxfromscratch.org> wrote: > > > The new pages for Security Advisories are now live. > > > > To see the LFS advisories, go to > > http://www.linuxfromscratch.org/lfs/read.html and follow the links > > in the Current Stable paragraphs (svn, systemd). > > > > To see the BLFS advisories, go to > > http://www.linuxfromscratch.org/blfs/read.html and follow the links > > in the Current Stable paragraphs (svn, systemd). > > > > ĸen > > > > That's great that you are helping us stay on the cutting edge of security > issues. I find it fascinating and educational. > > I did see a small typo on > http://www.linuxfromscratch.org/lfs/advisories/ > "... keep on top of htat ..." > > Don Thanks. I seem to accidentally type th as ht a lot of the time. I'm sure there are other typos and infelicities, but I'm trying to take a break from it for the moment. ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Security Advisories now live
The new pages for Security Advisories are now live. To see the LFS advisories, go to http://www.linuxfromscratch.org/lfs/read.html and follow the links in the Current Stable paragraphs (svn, systemd). To see the BLFS advisories, go to http://www.linuxfromscratch.org/blfs/read.html and follow the links in the Current Stable paragraphs (svn, systemd). ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Firefox
Yesterday mozilla released firefox-78.7.1 with a security fix described as Critical. It has now been clarified that this only applied to Windows systems. Therefore, if you have not already updated beyond 78.7.0 there is no reason to do so. ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Security Advisories
I'm posting this to both lfs-support and blfs-support. When I started here, things were a lot simpler - far fewer packages, a much more limited desktop, and not many security vulnerabilities were getting disclosed. In those days we had the lfs-security list for mentioning new vulnerabilities, but that has become defunct. More recently, in BLFS we have mostly noticed updates which had security fixes, marked then in the Changelog as 'security update' or similar, and added them to the Security Vulnerabilities in the Errata. So, at the moment we have current vulnerabilities listed in http://www.linuxfromscratch.org/blfs/errata/stable-systemd/ and http://www.linuxfromscratch.org/blfs/errata/stable/ and we seem to have been doing this since BLFS-8.4. However, these reports tended to add new reports at the end, but update previously reported issues where they were so that the order was a bit random. In addition, details were usually sketchy (often the ticket had CVE numbers). On LFS, AFAICS we've stopped mentioning security issues except in the tickets for new versions. I've been hacking away on html for some changes to how we record these. The details are not yet all present (I've still got about the last 6 weeks to do), but there is enough to see where this is going. What I'm proposing is that we do this for both LFS and BLFS (at the moment, the only way to find LFS vulnerabilities after the event is to look at the links to the tickets from the Changelog). We will have pages for LFS and BLFS with lists of vulnerabilities between the release and the next release, and a consolidated list of all vulnerabilities. The pages for between releases are in alphabetical order by package, with newest vulnerability first if more than one, and the consolidated list is newest first. For the moment, the way in to this is: LFS - http://www.linuxfromscratch.org/lfs/advisories/ BLFS - http://www.linuxfromscratch.org/blfs/advisories/ Both of these point to 10.0 and consolidated. Once you find an advisory which is relevant to you, click on the link at the end (e.g. 10-024 for FreeType in BLFS) and you should get to the item in the consolidated list with (usually) one or more external links and links to the current pages in the sysv and Systemd development books. What I'm also proposing is to: (i) Add new 10.1 pages for the period from when 10.1 has been released up until we release 10.2, and add a label "Items between the releases of the 10.1 and 10.2 books" to the consolidated page above the existing items. (ii) After that, Muggins here will change the consolidated links (10.0 to 10.1 period) to point to the 10.1 books. This is because over time the books change. People who are still building 10.0 in the next few months should look at both the 10.0 page and also the 10.1 page (e.g. firefox-esr now gets a point release every four weeks, but instructions and dependencies which were present in February (10.1 release) might be very different by July and similarly some other packages may have been archived or forked and renamed. (iii) Eventually, the consolidated page will become rather large. At some point we can move older items to a different historical page. (iv) Critically, when this gets sorted (I need to look at indexing, and I'm aware the menu on the consolidated page is only relevant to BLFS) I'll comment out the existing advisories in the current BLFS Errata pages and add a message or link to the new advisories. One further thought: I've been catching up with details to provide links. For many of the items where upstream did not specify a severity level I've now found ratings at NVD. I'm sure that most of these ratings were not available when the packages were updated. So in general ratings will be assumed to be High in the absence of any other data. Obviously, glibc may be an exception for that (the only supported way to upgrade to a new version is to build a new LFS, although individuals with good *usable* backups might be able to update in place followed by an unclean shutdown, but no guarantees!). At the moment several items have 'Updated:' in their heading rather than 'Date:' to indicate that changes have occurred. The new pages include things which we ought to have noted, although sometimes we either missed them or failed to provide a vulnerability notification. Comments are welcome. ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] perl.com stolen
A few days ago I read in a link somewhere that perl.com had been stolen and appeared to be parked for sale, as squatters do. This sounded merely annoying, and I can't find the original link. Today I looked at the latest URI release and saw that it changed perl.com to example.com in tests and examples. I mentioned that in the ticket, Doug asked if there were security issues. I was about to say no, but one of the links google found was https://www.bleepingcomputer.com/news/security/perlcom-domain-stolen-now-using-ip-address-tied-to-malware/ That says that the current address is associated with malware campaigns, and further down it says: Until the domain hijacking is resolved, perl.org is recommending that users do not use perl.com as a CPAN mirror and to update it using the following command: | # perl -MCPAN -eshell | cpan shell -- CPAN exploration and modules installation (v2.20) | Enter 'h' for help. | | cpan[1]> o conf urllist http://www.cpan.org/ | Please use 'o conf commit' to make the config permanent! | cpan[2]> o conf commit | commit: wrote '/root/.cpan/CPAN/MyConfig.pm' So anyone using CPAN needs to make sure they do not use perl.com as a mirror, and if you have done so since 27th January (when it was pointed to the Google Cloud IP address (35.186.238[.]101.) you will wish to review what is on your system(s). ĸen -- The right of the people to keep and arm Bears, shall not be infringed. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Problems downloading patches using jhalfs
On Mon, Dec 21, 2020 at 06:31:08PM -0600, Bruce Dubbs via blfs-support wrote: > On 12/21/20 4:06 PM, Bruce Dubbs wrote: > > > > I think patches are not on osuosl (or if they are, not in blfs/svn). > > > Usually there is no problem downloading them from higgs, except when > > > they have just been committed (they are not yet in blfs/svn). But higgs > > > seems unresponsive at times these days. > > > > The patches should be at osuosl, but they can be missed, especially if a > > patch is added but the base package has not been updated. > > I've updated osuosl with the patches. If there are others missing, let me > know. > Unfortunately, I've now abandonned that exercise so no more reports if any are missing. > I did run into a problem with wget hanging. I don't know why. If wget > hangs, a ^C followed by an immediate retry works virtually instantaneously. > > Perhaps I should reboot higgs, but I'm hesitant to do that since it's been > up 425 days. I did try restarting apache yesterday. > > -- Bruce > Trac still seems very erratic - working through changesets to update my scripts, from time to time it hangs for long enough to encourage me to step away, just as it was hanging when I was updating on the 15th and 16th. ĸen -- (The Balancing Monks) use small brass weights, none of them bigger than a fist. They work. Well, obviously they work. The world has not tipped up yet. -- The Thief Of Time -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Problems downloading patches using jhalfs
On Mon, Dec 21, 2020 at 04:06:36PM -0600, Bruce Dubbs via blfs-support wrote: > On 12/21/20 3:17 PM, Pierre Labastie via blfs-support wrote: > > On Mon, 2020-12-21 at 19:19 +0000, Ken Moffat via blfs-support wrote: > > > Connecting to > > > www.linuxfromscratch.org > > > (www.linuxfromscratch.org)|2600:3c01::f03c:91ff:fe70:25e8|:80 > > > ... failed: Network is unreachable. > > > --2020-12-21 17:28:20-- > > > http://ftp.osuosl.org/pub/blfs/svn/p/procmail-3.22-consolidated_fixes-1.patch > > > Resolving ftp.osuosl.org (ftp.osuosl.org)... 64.50.236.52, > > > 140.211.166.134, 2600:3402:200:227::2, ... > > > Connecting to ftp.osuosl.org (ftp.osuosl.org)|64.50.236.52|:80... > > > connected. > > > HTTP request sent, awaiting response... 404 Not Found > > > 2020-12-21 17:28:20 ERROR 404: Not Found. > > > > I think patches are not on osuosl (or if they are, not in blfs/svn). > > Usually there is no problem downloading them from higgs, except when > > they have just been committed (they are not yet in blfs/svn). But higgs > > seems unresponsive at times these days. > > The patches should be at osuosl, but they can be missed, especially if a > patch is added but the base package has not been updated. > Certainly, higgs seems very unresponsive these days. But I think that every patch where the download has failed has not been a recent one. Certainly for procmail the page was last updated on 26th August (probably tagging it for 10.0). Others in this run were openjade, procmail, lua-5.4.1, net-tools. I can accept that lua-5.4.1 maybe dropped out because the book has moved on to 5.4.2 (I'm still using the version of the book that was current when I started), but I'm wondering if something needs to be done for (some) patches which were in 10.0 to make them visible in osuosl svn ? ĸen -- (The Balancing Monks) use small brass weights, none of them bigger than a fist. They work. Well, obviously they work. The world has not tipped up yet. -- The Thief Of Time -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Problems downloading patches using jhalfs
I've hit this several times during my current attempt to use jhalfs to build the parts of blfs which I have not yet built : trying to download a patch from linuxfromscratch times out, then osuosl 404s. Not sure where the problem lies, so I'll ask here. Latest one is procmail: --2020-12-21 17:27:48-- http://ftp.osuosl.org/pub/blfs/conglomeration/procmail/procmail-3.22.tar.gz Resolving ftp.osuosl.org (ftp.osuosl.org)... 140.211.166.134, 64.50.236.52, 2600:3402:200:227::2, ... Connecting to ftp.osuosl.org (ftp.osuosl.org)|140.211.166.134|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 226817 (222K) [application/x-gzip] Saving to: ‘procmail-3.22.tar.gz’ 0K .. .. .. .. .. 22% 151K 1s 50K .. .. .. .. .. 45% 316K 1s 100K .. .. .. .. .. 67% 21.4M 0s 150K .. .. .. .. .. 90% 315K 0s 200K .. .. . 100% 43.1M=0.7s 2020-12-21 17:27:49 (341 KB/s) - ‘procmail-3.22.tar.gz’ saved [226817/226817] procmail-3.22.tar.gz: OK --2020-12-21 17:27:49-- http://www.linuxfromscratch.org/patches/blfs/svn/procmail-3.22-consolidated_fixes-1.patch Resolving www.linuxfromscratch.org (www.linuxfromscratch.org)... 192.155.86.174, 2600:3c01::f03c:91ff:fe70:25e8 Connecting to www.linuxfromscratch.org (www.linuxfromscratch.org)|192.155.86.174|:80... failed: Connection timed out. Connecting to www.linuxfromscratch.org (www.linuxfromscratch.org)|2600:3c01::f03c:91ff:fe70:25e8|:80... failed: Network is unreachable. --2020-12-21 17:28:20-- http://ftp.osuosl.org/pub/blfs/svn/p/procmail-3.22-consolidated_fixes-1.patch Resolving ftp.osuosl.org (ftp.osuosl.org)... 64.50.236.52, 140.211.166.134, 2600:3402:200:227::2, ... Connecting to ftp.osuosl.org (ftp.osuosl.org)|64.50.236.52|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2020-12-21 17:28:20 ERROR 404: Not Found. ĸen -- (The Balancing Monks) use small brass weights, none of them bigger than a fist. They work. Well, obviously they work. The world has not tipped up yet. -- The Thief Of Time -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Parole now playing mp4 and mkv on haswell integrated, with modesetting
Back in early August I reported that parole had become broken on my haswell integrated gpu (video window broken into horizontal stripes rather like a venetian blind, with a mix of colours not apparently related to the video). At that time I documented what had changed between the last good versions of various packages and the current state, but I got nowhere by trying to revert any of them. We were heading for a release, so I put it aside. Since then I've tended to use vlc on that machine. Today (hmm, yesterday now) an article on phoronix noted that the intel driver has been updated for something (forcing tear free, I think) and reminded me that most distros use modesetting on intel. So, since I'd had to reboot to check something in my jhalfs system, when I came back to the main system I looked at this. According to gentoo, creating 20-modesetting.conf (for me, that goes in /usr/share/X11/xorg.conf.d along with quirks, libinput and in my case keyboard conf files, I did not have any conf file for the video driver. Gentoo note that if both that and 20-intel.conf are present they will be loaded in alphanumeric order, which would stop modesetting being used). So, added it with Section "Device" Identifier "Intel Graphics" Driver "modesetting" Option "AccelMethod""glamor" Option "DRI""3" EndSection and restarted Xorg. Joy! I cannot recall if absolutely everything in parole was broken with the intel driver, but I'm fairly sure that mp4 and mkv were. Certainly, both of those formats, and everything else I have to hand, are now working. Result! I guess I'll stop using the intel driver. ĸen -- (The Balancing Monks) use small brass weights, none of them bigger than a fist. They work. Well, obviously they work. The world has not tipped up yet. -- The Thief Of Time -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Has something happened with the LFS/BLFS repos?
On Wed, Dec 16, 2020 at 08:25:34AM +1100, Wayne Blaszczyk via blfs-support wrote: > I cannot seem to pull anything down this morning, either LFS or BLFS. > Is there some maintenance going on? > > wblaszcz [ ~/LFS-Patches ]$ svn up > Updating '.': > svnserve: E210005: No repository found in > 'svn+ssh://svn.linuxfromscratch.org/patches/trunk' > svn: E170013: Unable to connect to a repository at URL > 'svn+ssh://svn.linuxfromscratch.org/patches/trunk' > svn: E210005: No repository found in > 'svn+ssh://svn.linuxfromscratch.org/patches/trunk' > > Wayne. > Trac is mostly timing out too. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] gpm mouse server
On Tue, Dec 15, 2020 at 12:07:42AM +, James Read via blfs-support wrote: > On Mon, Dec 14, 2020 at 11:48 PM Douglas R. Reno via blfs-support < > blfs-support@lists.linuxfromscratch.org> wrote: > > > > > On 12/14/20 5:36 PM, James Read via blfs-support wrote: > > > I installed the gpm mouse server and ran /etc/rc.d/rc3.d/S70gpm start > > > and got the output > > > > > >* Starting GPM console mouse service > > > > > > However, no mouse pointer appears in my terminals and the mouse > > > doesn't seem to be working. Any ideas? > > > > > > James Read > > > > > Hi James, > > > > What are the contents of your "/etc/sysconfig/mouse" file? > > > > At first I used the example values in the book: > > That didn't work > > > > > > You can try running mouse-test to find out what mouse type your mouse is > > presenting itself as, as well as what the device node is. > > > > > I tried running mouse-test and it suggested /dev/autofs That sounds bizarre (although I admit I have not run that program for many years). > I updated /etc/sysconfig/mouse accordingly and still no joy. > > I know my usb mouse is connected because I installed and ran lsusb.py and > it shows my mouse there but no /dev/? file. > > Any other way I can figure out what device my mouse is on? > For mice, (CONFIG_) MOUSE, MOUSEDEV and perhaps MOUSEDEV_PSAUX usually do the job. Since you know it is a usb mouse I would have suggested that maybe one of the usb driver modules was disabled (or alternatively set to 'M' but for some reason not automatically loaded. But if that lsusb script shows it then presumably the driver is loaded. But I'm slightly dubious about lsusb.py: on the laptop where I'm writing this, the trackpad is busted and I've got a usb trackpad plugged in - that shows as a keyboard in lsusb.py. Lemme point to the kernel docs (for 5.8, since I think that is what you said you are running): https://www.kernel.org/doc/html/v5.8/input/input.html and pasting from there - For the most usual configuration, with one USB mouse and one USB keyboard, you’ll have to load the following modules (or have them built in to the kernel): input mousedev usbcore uhci_hcd or ohci_hcd or ehci_hcd usbhid hid_generic After this, the USB keyboard will work straight away, and the USB mouse will be available as a character device on major 13, minor 63: crw-r--r-- 1 root root 13, 63 Mar 28 22:45 mice [...] After that you have to point GPM (the textmode mouse cut tool) and XFree to this device to use it - GPM should be called like: gpm -t ps2 -m /dev/input/mice For sysv lfs, those options belong in /etc/sysconfig/mouse: MDEVICE="/dev/input/mice" PROTOCOL="imps2" GPMOPTS="" And in X: Section "Pointer" Protocol"ImPS/2" Device "/dev/input/mice" ZAxisMapping 4 5 EndSection I'm not sure that last part is true - on this laptop the only matches for Pointer in xorg are: en@terror ~ $grep Pointer /usr/share/X11/xorg.conf.d/* /usr/share/X11/xorg.conf.d/10-quirks.conf:Identifier "Xen Virtual Pointer axis blacklist" /usr/share/X11/xorg.conf.d/10-quirks.conf:MatchProduct "Xen Virtual Pointer" /usr/share/X11/xorg.conf.d/40-libinput.conf:MatchIsPointer "on" and I think that the file installed by libinput handles it all. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] blocaled-0.3 install fails
On Thu, Dec 10, 2020 at 07:10:12PM +, Ken Moffat via blfs-support wrote: > > In the end, since my primary goal is to actually build all of these > packages, and running them (in the booted system, obviously) is only > a hope, I've touched the stamp file for this package and resumed the > build. That built, but is terminally broken as a result (non-UTF-8 locale, so gnome-terminal will not start, and also broken because although the static IP address on eth0 is still apparently used, it cannot connect even to my local network). I blame most of that on NetworkManager which has no place on my wired-only machines :) AFAICS, both gnumeric and abiword are working. I then went back to my backup from before building gnome, with firefox, seamonkey and xfce, and built epiphany which did not take long (most of the deps had already been pulled in). With that, 'Web Browser' works, although like much of gnome I find it not to my taste. For the future, I'll maybe look at trying to tune NetworkManager, and if so, building blocaled (only, ideally) while the system is booted - everything else so far in sysv seems to build adequately in chroot, although perhaps systemd might be different. I'll try to put any future posts on alfs-discuss. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] blocaled-0.3 install fails
On Thu, Dec 10, 2020 at 09:01:58AM +0530, Palash Tekam via blfs-support wrote: > Try removing the `la files` and then install again. > > On Thu, Dec 10, 2020, 05:53 Ken Moffat via blfs-support < > blfs-support@lists.linuxfromscratch.org> wrote: > > > I'm trying to build all of gnome (sysv). > > > > In blocaled, the build apparently completed, but the install fails: > > Thanks for trying to help, but I omitted some context (using jhalfs in chroot, the la files are removed by jhalfs) because I thought it might be a general problem and I assumed that Pierre (who knew I was doing that) would reply when convenient to him. However, can I again say "Please do not top post". ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] blocaled-0.3 install fails
On Thu, Dec 10, 2020 at 02:33:25PM +, Ken Moffat via blfs-support wrote: > On Thu, Dec 10, 2020 at 08:14:43AM +0100, Pierre Labastie via blfs-support > wrote: > > On Thu, 2020-12-10 at 00:19 +, Ken Moffat via blfs-support wrote: > > > I'm trying to build all of gnome (sysv). > > > > > > In blocaled, the build apparently completed, but the install fails: > > > > > > Error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The > > > name org.freedesktop.locale1 was not provided by any .service files > > [...] > > Yes, that need to access dbus occurred to me after some sleep. I'd > assumed dbus was only ever a runtime requirement. > > > > > > > Experimentation shows that if I run the tests, all 22 pass. Trying > > > again with make -j1 makes no difference. > > > > > > Google only finds generic references to various org.freedesktop > > > services, and references to localed from systemd. > > > > Well, I have never had an external report about that package (you are > > the first one), so I guess blocaled is unknown by google... > > > > Pierre > > > > I'll try to take a look later. > The basic problem is that dbus is on the host and knows nothing about services installed in chroot. It is claimed that the arch-chroot script *might* allow this (it apparently uses namespaces), but trying to understand what it does is outside my pay grade. Equally, I'm not really sure where the install breaks: I can DESTDIR to /tmp, but when I then try to cp -av from there to '/' it again errors, and adding '|| true' to the install does not help, it still stops. In the end, since my primary goal is to actually build all of these packages, and running them (in the booted system, obviously) is only a hope, I've touched the stamp file for this package and resumed the build. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] blocaled-0.3 install fails
On Thu, Dec 10, 2020 at 08:14:43AM +0100, Pierre Labastie via blfs-support wrote: > On Thu, 2020-12-10 at 00:19 +0000, Ken Moffat via blfs-support wrote: > > I'm trying to build all of gnome (sysv). > > > > In blocaled, the build apparently completed, but the install fails: > > > > Error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The > > name org.freedesktop.locale1 was not provided by any .service files > > I have to recheck, but as far as I can tell, "make install" itself does > not run gdbus. In the book instructions, it is only run after > installation, as part of the configuration. I suspect it cannot be run > in chroot, since it needs to access a system daemon... > Yes, that need to access dbus occurred to me after some sleep. I'd assumed dbus was only ever a runtime requirement. > > > > Experimentation shows that if I run the tests, all 22 pass. Trying > > again with make -j1 makes no difference. > > > > Google only finds generic references to various org.freedesktop > > services, and references to localed from systemd. > > Well, I have never had an external report about that package (you are > the first one), so I guess blocaled is unknown by google... > > Pierre > I'll try to take a look later. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] blocaled-0.3 install fails
I'm trying to build all of gnome (sysv). In blocaled, the build apparently completed, but the install fails: Error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.locale1 was not provided by any .service files Experimentation shows that if I run the tests, all 22 pass. Trying again with make -j1 makes no difference. Google only finds generic references to various org.freedesktop services, and references to localed from systemd. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] How to make an iso of BLFS
On Wed, Dec 09, 2020 at 01:32:25AM +0530, Palash Tekam via blfs-support wrote: > > I had made the BLFS on the host machine itself ( due to hardware > limitations ) i.e. I have only one operating system which is the BLFS 8.4 . > So mounting and ssh won't work . Can I still tar /mnt/lfs and will it tar > up the packages of BLFS also? > If it is the only system, then /mnt/lfs is empty and not mounted. I don't think I understand your situation. Does your machine still have the host OS on which you built LFS and then BLFS ? If you tar up a whole system, it will include all the installed files whether they are from LFS or BLFS and whether they are in /usr or /opt. But if you used more than one partition for the system, things get more interesting and you probably need to tar those up separately. If you do not still have the host OS, tarring up a running system is much harder (you want to avoid /dev /proc /sys as previously mentioned) - not something I've done after my first build many years ago, I quickly learned that backing up, and restoring, a compelted system is mch easier when done from another system on the same machine. Can probably be done after thoroughly reading the man/info pages for tar. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] How to make an iso of BLFS
On Tue, Dec 08, 2020 at 07:48:48PM +, Ken Moffat via blfs-support wrote: > > And then make those changes (e.g. edit /etc/hostname and > /etc/sysconfig files), ensuring you are in the new system. > Forgot to add: In the same way that you (I imagine) used lspci to see what hardware was on the machine where you built LFS, and then searched for those drivers in the kernel (or perhaps started with the config from the running distro kernel) you will need to do that on the second machine. If you are doing that as a learning exercise (as I said, I can't recommend running BLFS-8.4 without a lot of package updates) then I'll wish you luck and patience : my recent experience with getting a usable kernel on my current laptop, particularly for wifi, and then in trying to slim it down to remove things I won't be using, was slow, painful, and had a lot of failures. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] How to make an iso of BLFS
On Wed, Dec 09, 2020 at 12:34:13AM +0530, Palash Tekam via blfs-support wrote: > How to tar up the whole LFS system. I mean what all directories ( all the > directories have same name as given in the book ). > Would simply tarring and untarring do the job? ( except some minor changes > that you mentioned ) > Please don't top-post when replying on this list. You need to be in a separate system on the machine (e.g. the host system which you used to build LFS) so that the LFS system is not mounted. (Trying to tar up /dev /proc /sys is not a good idea). If everything from LFS is in one partition, mount the LFS system at /mnt/lfs on the host, then as root cd to /mnt/lfs and tar up '.' to a file (if you use -v with tar it will show it writing names beginning './'). Transfer the file to an existing linux system on the other machine, make a filesystem on the partition where you want LFS, and then as root mount that filesystem (creating /mnt/lfs and mounting there is conventional), cd to it and untar. > > Other minor things are to change the host name, ip address, fstab, > > grub.cfg, and maybe unprivileged user(s). Also any kernel modules and > > (potentially) firmware for the target system must be available. > > > >-- Bruce And then make those changes (e.g. edit /etc/hostname and /etc/sysconfig files), ensuring you are in the new system. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] How to make an iso of BLFS
On Tue, Dec 08, 2020 at 06:14:58PM +0530, Palash Tekam via blfs-support wrote: > Dear all, > I have successfully installed BLFS 8.4 and now I want to make its iso file > so that I can transfer it to my other laptop like any other Linux > distribution such as Ubuntu, Mint, Manjaro, etc. Please also mention all > the changes that I have to make in kernel to make it run on different > laptops. I don't want to pour water on your parade, but BLFS-8.4 is now so old (in LFS/BLFS terms) that many security vulnerabilities have come to light and installing it now cannot be recommended. Even with 10.0 there are a continuous stream of security fixes which need packages to be updated. But the real problems are in configuring the system for different hardware. In particular, different disk controllers but also different wifi or ethernet drivers. That is why commercial distros use modules for as much of the kernel as possible, and therefore provide an initrd from which the modules can be loaded. For modern laptops you probably need firmware for the wifi (I'm assuming that the hardware _is_ supported by the upstream kernel, distros may carry their own patches) and perhaps firmware for video, bluetooth, maybe other things. Distros also use various approaches for identifying the root filesystem (typically UUID) and updating (in their installers) the fstab. Alternatively, "Live" isos (typically, on sticks) need to have an area where data can be updated when the system is running. That is way beyond LFS (initrds are covered in BLFS) and most of the people here know nothing about that. > I had read somewhere that MacOS X was based on LFS 6.1. Not true. It is based on Darwin, which is based on "real" unix. The core parts are probably nearest to FreeBSD. > This should be possible, else how do they make operating systems and > distribute it! > By spending lots of time and money, and destroying a certain amount of hardware in the process :-( ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] libsoup will not build with sysprof
On Mon, Nov 30, 2020 at 11:30:53PM +, Ken Moffat via blfs-support wrote: > On Fri, Nov 27, 2020 at 09:14:40PM +0000, Ken Moffat via blfs-support wrote: > > On Fri, Nov 27, 2020 at 09:46:39PM +0100, Pierre Labastie via blfs-support > > wrote: > > > > > > Just to be sure: it is not enough to just patch meson and recompile > > > libsoup. Sysprof has to be recompiled to after the change to meson: the > > > problem is in the .pc file for sysprof (-pthread not present in the > > > "public" part of the .pc file). > > > > > > > Ah, I missed that (rebuilt meson, retried libsoup). > > I'll upload the patch to patches, but I really don't think we need > to recommend sysprof for libsoup. > I finally go round to building sysprof and libsoup with patched meson "by the book" in jhalfs, the patch works fine. Added to LFS in r12067. I suppose that might prompt meson to release 0.56.1 :) ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] elogind: added user cannot startx
On Sun, Dec 06, 2020 at 03:55:12AM +, Ken Moffat via blfs-support wrote: > > I added a normal user, with things similar to what I added for the > jhalfs user (but with a slightly more complex .xinitrc to allow me > to specify which windowmanager to use). > And the problem was in the .xinitrc. Although it apparently attempted to startfluxbox (as expected), something in the file was wrong and it didn't, so therefore the server shutdown because there was nothing for it to do. I've now removed everything and then copied in the one line from the already-working .xinitrc of the jhalfs user, and my normal user can startx. And reading a diff of the output from strace was as hard as I expected - differing delays eventually cause the lines which are apparently unchanged (white in 'view' with my black background) to match the wrong places. Oh well, sorted now. Onward. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] elogind: added user cannot startx
Further questions from "Trying to use jhalfs to build BLFS in chroot." Background : I built a base system using my own LFS scripts (package versions and scripts known to work ok on another machine), but with changes to not make my normal systems mounted in fstab. I then built a few things needed before I could use jhalfs to build blfs (wget, docbook, subversion). I also removed my normal users, and added a jhalfs user with full sudo privileges (unsafe), and a normal user with minimal privileges so that from time to time I could try running the results. System booted, so I set about starting to find my way around jhalfs for build testing (going back to chroot). Minimal console progs worked (e.g. lynx). Eventually built Xorg and fluxbox. My jhalfs user can 'startx' (with fluxbox), but I don't want to use that user when I do boot the system for testing. I added a normal user, with things similar to what I added for the jhalfs user (but with a slightly more complex .xinitrc to allow me to specify which windowmanager to use). The normal user can login ok, the syslog shows the seat details, loginctl user-status looks ok. But when that user tries to startx the screen blanks, then X ends. Looking at .local/share//xorg/Xorg.0.log everything looks ok and I don't see any obvious differences between the working log from the jhalfs user and the non-working log from the normal user. Does any of this ring any bells, please ? I don't see elogind reporting any errors errors, the output in syslog seems fine, so I'm wondering if PAM might be involved. I can see that PAM's elogind-user has a LOT more in the jhalfs build than in my own build, but my gut feelign is that if the user can login on a tty then PAM is not the problem ? I'm wondering about adding strace to the build, but my recollections from just over a year ago suggest that might not give any meaningful pointers to the problem. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] GCC fails to find headers that are present on the system
On Sun, Aug 30, 2020 at 10:04:59PM +0200, Pierre Labastie via blfs-support wrote: > On Sat, 2020-08-29 at 20:20 -0400, Chris Gorman via blfs-support wrote: > > Hello Again, > > > > I believe I have found the culprit for my 'broken' search path for > > gcc > > and g++. In 'Introduction to Xorg-7' we are told to run the > > following > > if we are using a directory other than /usr as our $XORG_PREFIX. ... > > > > cat >> /etc/profile.d/xorg.sh << "EOF" > > > > pathappend $XORG_PREFIX/bin PATH > > pathappend $XORG_PREFIX/lib/pkgconfig PKG_CONFIG_PATH > > pathappend $XORG_PREFIX/share/pkgconfig PKG_CONFIG_PATH > > > > pathappend $XORG_PREFIX/lib LIBRARY_PATH > > pathappend $XORG_PREFIX/include C_INCLUDE_PATH > > pathappend $XORG_PREFIX/include CPLUS_INCLUDE_PATH > > > > ACLOCAL="aclocal -I $XORG_PREFIX/share/aclocal" > > > > export PATH PKG_CONFIG_PATH ACLOCAL LIBRARY_PATH C_INCLUDE_PATH > > CPLUS_INCLUDE_PATH > > EOF > > > > The setting of C_INCLUDE_PATH and CPLUS_INCLUDE_PATH here cause a gcc > > and g++ to change their search order, to put /usr/include at the > > beginning of their search path. This breaks some builds like mesa. > > To be clear, this was my fault as the note before this states to skip > > these instructions if I am using /usr as my $XORG_PREFIX, which I am. > > > > Hope this helps someone else. > > Thanks a lot for the investigation and the finding. You are not the > first to run instructions for $XORG_PREFIX != /usr while setting > XORG_PREFIX=/usr... This generates several hard to debug failures. I > think we should explicitly have an if...fi pair around those > instructions (that would help jhalfs too :). > > Pierre > Belated follow-up on this, after I too jsut got bitten by it. I see that Bruce preferred to put a big Warning in setting up the environment, but it definitely adds to the overhead of things to fix. I suppose that next time I'll remember this (assuming, for the moment, that there _is_ a next time - I'm not yet certain if using jhalfs in chroot is going to work for what I want to do). And a big Thank You to Chris for finding out what was causing this. When I saw the cmath error I thought 'seen that somewhere' ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] nss-3.50 & nss-3.55
On Wed, Dec 02, 2020 at 10:59:24PM +1100, Fosca via blfs-support wrote: > (Late reply, on the details of how things change) > > I have just been working on BLFS and came across a slight hitch regarding > nss-3.50 & nss-3.55 in 9.1 and 10.0 respectively. > > So in 9.1 - http://www.linuxfromscratch.org/blfs/view/9.1/postlfs/nss.html - > we find "The unit tests were run during the build." > I _think_ I originally added that line. Over time, things change and to look at how the change happened might mean looking at changes to that file in svn. For example, in 9.0 the text was very different. The nss tarballs have had some changes in how they are organized/constructed since that time. > Whereas in 10.0 - > http://www.linuxfromscratch.org/blfs/view/10.0/postlfs/nss.html - we find : > > To run the tests, execute the following commands: > > cd tests && > HOST=localhost DOMSUF=localdomain ./all.sh && > cd ../ > Yes. What is in 9.1 may or may not be correct for that old version of nss (my gut feeling is that I was probably mistaken when I added it). Since then, someone (Xi, I think) looked deeper and found out how to run the tests. > The previous "make BUILD_OPT=1 . . . command sequence reads the same for > both 9.1 and 10.0. > The details of building the package did not change. > Hence why the test in 10.0 ? > But our understanding of what was going on did change - call it continuous improvement. > The point is that I had that test fail on me. I'm hopeful that Doug's reply set you on the right course. But I'll mention that I only run the nss tests if I'm updating nss in the book. Like many packages, the tests are more for the package developers than for users. Maybe I should also mention that nss is one of those packages where updating to a new release is almost always a good idea. I see that in our Errata we currently mention updating to 3.58 or later (current in the svn book is 3.59). On my current/old-but-maintained systems I update nss (and nspr, if new release), and ca-certificates when I update to a newer firefox (approx every 6 weeks). ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] libsoup will not build with sysprof
On Tue, Dec 01, 2020 at 09:18:04PM +0100, Christopher Gregory via blfs-support wrote: > > Hello Ken, > > If sysprof is not installed, and is not disabled, it creates a blank git > "tree" and downloads sysprof and compiles it. I did not investigate if it > actually installs sysprof, or if it keeps it private to itself. > What it wants is a static library, so links the part it wants. I can't find the reference at the moment, but it was to do with profiling. > I notice that other packages are also now including sysprof as run-time > requirements, unless of course it is disabled. It was the not knowing what > may happen with a running system that has sysprof disabled in libsoup that > had me concerned. > I had not noticed that, but I see that gentoo mention it for glib2. > I did apply the patch mentioned and recompiled sysprof and libsoup > successfully, so libsoup now has sysprof support. > > Regards, > > Christopher. Thanks. I might revisit my decision to drop it, and therefore to also drop libdazzle, in my own (non-gnome) builds. But for the moment I'm trying to get my head around other things. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] libsoup will not build with sysprof
On Tue, Dec 01, 2020 at 02:07:38PM -0600, Douglas R. Reno via blfs-support wrote: > > On 12/1/20 1:08 PM, Ken Moffat via blfs-support wrote: > > On Tue, Dec 01, 2020 at 09:27:32AM -0600, Douglas R. Reno via blfs-support > > wrote: > > > > > Ah, I missed that (rebuilt meson, retried libsoup). > > > > I'll upload the patch to patches, but I really don't think we need > > > > to recommend sysprof for libsoup. > > > > > > > > ĸen > > > Xi and I were the ones who found the issue. If you don't have sysprof > > > installed, on our systems, libsoup downloaded a git copy of > > > libsysprof-capture-4. Turning sysprof off is an option of course, but it > > > does remove some functionality and it remains to be seen (I guess I'll see > > > here in a day or two since I'm doing a full rebuild for systemd-247) what > > > having that functionality removed actually does... > > > > > I'm vaguely interested in what showed up during the download (if > > details are available). > > > > In theory the choice for sysprof (in libsoup) is auto, so I would > > expect it to be disabled if sysprof is not found, but obviously my > > expectations and what actually happens may differ. > > > > However, if it does download a git copy and you therefore want to > > use system sysprof then meson will need to be patched until the next > > meson release comes out. > > Hi Ken, > > I just moved /usr/lib/libsysprof-capture-4.a and > /usr/lib/pkgconfig/sysprof-capture-4.pc out of the way so I can test this. > Here's the output: > > renodr [ /sources ]$ sh SCRIPTS/libsoup-2.72.0-update.sh > Making libsoup-2.72.0 > Tue Dec 1 02:06:48 PM CST 2020 > patching file tests/ssl-test.c > Initialized empty Git repository in > /sources/libsoup-2.72.0/libsoup-2.72.0/subprojects/sysprof/.git/ > From https://gitlab.gnome.org/GNOME/sysprof > * branch 1bb0eb7798f6a88667681229dde415ed663b1053 -> FETCH_HEAD > Note: switching to '1bb0eb7798f6a88667681229dde415ed663b1053'. > > You are in 'detached HEAD' state. You can look around, make experimental > changes and commit them, and you can discard any commits you make in this > state without impacting any branches by switching back to a branch. > > If you want to create a new branch to retain commits you create, you may > do so (now or later) by using -c with the switch command. Example: > > git switch -c > > Or undo this operation with: > > git switch - > > Turn off this advice by setting config variable advice.detachedHead to false > > HEAD is now at 1bb0eb7 Merge branch 'collector-libraries' into 'master' > > [...] > > Run-time dependency sysprof-capture-4 found: NO (tried pkgconfig and cmake) > Looking for a fallback subproject for the dependency sysprof-capture-4 > > |Executing subproject sysprof method meson > | > |Using 'PKG_CONFIG_PATH' from environment with value: > '/opt/kf5/lib/pkgconfig:/opt/qt5/lib/pkgconfig' > |Using 'PKG_CONFIG_PATH' from environment with value: > '/opt/kf5/lib/pkgconfig:/opt/qt5/lib/pkgconfig' > |Project name: sysprof > |Project version: 3.37.1 > |C compiler for the host machine: cc (gcc 10.2.0 "cc (GCC) 10.2.0") > |C linker for the host machine: cc ld.bfd 2.35 > |Compiler for C supports arguments -fvisibility=hidden: YES > |Has header "execinfo.h" : YES > |Checking for function "strlcpy" : NO > |Run-time dependency libunwind-generic found: NO (tried pkgconfig and cmake) > |Checking whether type "struct perf_event_attr" has member "use_clockid" : > YES > |Checking whether type "struct perf_event_attr" has member "clockid" : YES > |Compiler for C supports arguments -Wcast-align: YES > |Compiler for C supports arguments -Wdeclaration-after-statement: YES > (cached) > |Compiler for C supports arguments -Wformat-nonliteral: YES > |Compiler for C supports arguments -Wformat-security: YES > |Compiler for C supports arguments -Wmissing-include-dirs: YES (cached) > |Compiler for C supports arguments -Wnested-externs: YES > |Compiler for C supports arguments -Wno-missing-field-initializers > -Wmissing-field-initializers: YES > |Compiler for C supports arguments -Wno-sign-compare -Wsign-compare: YES > |Compiler for C supports arguments -Wno-unused-parameter -Wunused-parameter: > YES > |Compiler for C supports arguments -Wno-cast-function-type > -Wcast-function-type: YES > |Compiler for C supports arguments -Wpointer-arith: YES (cached) > |Compiler for C supports arguments -Wredundant-decls: YES > |Compiler for C supports arguments -Wswitch-default: YES > |Compiler for C s
Re: [blfs-support] Kernel configuration observations/questions - BLFS 10.0/development
On Fri, Nov 27, 2020 at 08:34:02PM +, Ken Moffat via blfs-support wrote: > On Thu, Nov 26, 2020 at 04:58:17PM -0600, rhubarbpieguy--- via blfs-support > wrote: > > > > -- > > > > > > Xorg AMDGPU Driver > > > > Device Drivers ---> > > Graphics support ---> > > <*> Direct Rendering Manager (XFree86 ... support) ---> [CONFIG_DRM] > > <*/M> AMD GPU [CONFIG_DRM_AMDGPU] > > [ /*] Enable amdgpu support for SI parts [CONFIG_DRM_AMDGPU_SI] > > [ /*] Enable amdgpu support for CIK parts [CONFIG_DRM_AMDGPU_CIK] > > > > Should the [ /*]'s above be [*]? > > > > Yes, these are either on or off (so if amdgpu is a module, either it > supports SI or it doesn't, and similarly either it supports CIK or > it doesn't.) Actually, no, they should be < /*> : '[]' for not-optional, '<>' for make a choice. And as the wording says, the expected choice is to leave them blank and use a different driver. Apart from that, I've done the others I said I'd do. The qemu Virtualization part is now a bit wide, but such is life. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] libsoup will not build with sysprof
On Tue, Dec 01, 2020 at 09:27:32AM -0600, Douglas R. Reno via blfs-support wrote: > > > > > > > > Ah, I missed that (rebuilt meson, retried libsoup). > > I'll upload the patch to patches, but I really don't think we need > > to recommend sysprof for libsoup. > > > > ĸen > > Xi and I were the ones who found the issue. If you don't have sysprof > installed, on our systems, libsoup downloaded a git copy of > libsysprof-capture-4. Turning sysprof off is an option of course, but it > does remove some functionality and it remains to be seen (I guess I'll see > here in a day or two since I'm doing a full rebuild for systemd-247) what > having that functionality removed actually does... > I'm vaguely interested in what showed up during the download (if details are available). In theory the choice for sysprof (in libsoup) is auto, so I would expect it to be disabled if sysprof is not found, but obviously my expectations and what actually happens may differ. However, if it does download a git copy and you therefore want to use system sysprof then meson will need to be patched until the next meson release comes out. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] libsoup will not build with sysprof
On Fri, Nov 27, 2020 at 09:14:40PM +, Ken Moffat via blfs-support wrote: > On Fri, Nov 27, 2020 at 09:46:39PM +0100, Pierre Labastie via blfs-support > wrote: > > On Fri, 2020-11-27 at 17:50 +, Ken Moffat via blfs-support wrote: > > > On Tue, Nov 10, 2020 at 06:34:21PM +0100, Christopher Gregory via > > > blfs-support wrote: > > > > I notice that arch have dropped the need to make sysprof a > > > > requirement. I have not found any patch to date to actually get it > > > > to work. I am using the svn version of systemd blf from 2020-11- > > > > 01. There has been no update to sysprof so I could not see if a > > > > later version worked. > > > > > > > Starting a fresh sub-thread to reply to this, because we were > > > floundering. I've just hit this, and apart from Christopher's post > > > google found > > > https://github.com/mesonbuild/meson/issues/7929 > > > > > > Seems to be a problem with meson-0.56.0, apparently will be fixed > > > with 0.56.1 by > > > https://github.com/mesonbuild/meson/commit/2b923f532c3e16687910fecb09cedb80a76597cf.diff > > > but that didn't make any difference for me. > > > > Just to be sure: it is not enough to just patch meson and recompile > > libsoup. Sysprof has to be recompiled to after the change to meson: the > > problem is in the .pc file for sysprof (-pthread not present in the > > "public" part of the .pc file). > > > > Ah, I missed that (rebuilt meson, retried libsoup). I'll upload the patch to patches, but I really don't think we need to recommend sysprof for libsoup. ĸen -- To say that it (his hair) was black and bound up in a ponytail is to miss the opportunity of using the term 'elephantine'. It was hair with personality. -- The Thief Of Time (about the monk, Sato). -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] libsoup will not build with sysprof
On Fri, Nov 27, 2020 at 09:46:39PM +0100, Pierre Labastie via blfs-support wrote: > On Fri, 2020-11-27 at 17:50 +0000, Ken Moffat via blfs-support wrote: > > On Tue, Nov 10, 2020 at 06:34:21PM +0100, Christopher Gregory via > > blfs-support wrote: > > > Hello, > > > > > > I am working through another installation, and have found that > > > libsoup will not compile against sysprof. The following error > > > occurs: > > > > > > /usr/bin/ld: /usr/lib/libsysprof-capture-4.a(sysprof- > > > collector.c.o): in function `use_single_trace': > > > /sources/sysprof-3.38.1/build/../src/libsysprof-capture/sysprof- > > > collector.c:119: undefined reference to `pthread_getspecific' > > > > > > The only way that I could get libsoup to compile and install was by > > > going into the meson_options.txt and setting the option to use > > > sysprof to disabled. > > > > > > Has anyone actually tested and got this combination to work? > > > > > > I notice that arch have dropped the need to make sysprof a > > > requirement. I have not found any patch to date to actually get it > > > to work. I am using the svn version of systemd blf from 2020-11- > > > 01. There has been no update to sysprof so I could not see if a > > > later version worked. > > > > > > Re-installing sysprof made no difference to the above error. I > > > have only used the commands listed in the book and not added > > > anything extra to the build commands, ie nothing optional. > > > > > > Regards, > > > > > > Christopher. > > > > Starting a fresh sub-thread to reply to this, because we were > > floundering. I've just hit this, and apart from Christopher's post > > google found > > https://github.com/mesonbuild/meson/issues/7929 > > > > Seems to be a problem with meson-0.56.0, apparently will be fixed > > with 0.56.1 by > > https://github.com/mesonbuild/meson/commit/2b923f532c3e16687910fecb09cedb80a76597cf.diff > > but that didn't make any difference for me. > > Just to be sure: it is not enough to just patch meson and recompile > libsoup. Sysprof has to be recompiled to after the change to meson: the > problem is in the .pc file for sysprof (-pthread not present in the > "public" part of the .pc file). > Ah, I missed that (rebuilt meson, retried libsoup). But ... > I guess those of us who had built sysprof with a previous version of > meson could not see the problem, even if they were building libsoup > with meson 0.56... > > > > > I then tried Christopher's change to -Dsysprof=disabled and libsoup > > built. I agree with him that it shows no signs of downloading > > anything for sysprof. > > > > Meson reported: > > Dependency sysprof-capture-4 skipped: feature sysprof disabled > > and the verbose output from ninja did not mention sysprof. > > > > Pierre > With sysprof disabled (instead of auto, because I had a version of sysprof available, albeit a version with a defective .pc file) I see no indication from a verbose build of libsoup that anything to do with sysprof gets downloaded - ISTR there was mention of it installing a git version. ĸen -- Internal error in fortune program: fnum=2987 n=45 flag=1 goose_level=-232323 Please write down these values and notify fortune program admin. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Kernel configuration observations/questions - BLFS 10.0/development
On Thu, Nov 26, 2020 at 04:58:17PM -0600, rhubarbpieguy--- via blfs-support wrote: Dear Mr Pie Guy (since I have no other way to call you), I'm afread such a long detailed post gets a long detailed reply. for some of the minor points I now think I agree with you, but for much of it I think the situation is more complex that what you are initially seeing (and that thought has developed during this reply, so what I say later is built upon, and developed from, my initial reply on autofs. Please read the whole reply before replying to any of it, otherwise I will have wasted 2½ hours. > > autofs > > File systems ---> > <*/M> Kernel automounter version 4 support (also supports v3) > [CONFIG_AUTOFS4_FS] > > I believe Kernel automounter support has no options. Should the above > lines be deleted? > As of 5.9.8 (I forget when it changed) CONFIG_AUTOFS_FS is the new option. In my case, on a fresh tarball it is selected by the old AUTOFS4_FS and it appears that it cannot be disabled or modularized. In the .config I'm using for this machine (updated for 5.9.1) # CONFIG_AUTOFS4_FS is not set CONFIG_AUTOFS_FS=y Looking back at the config for this machine, I have not always saved a new config for a new kernel version in my git tree. In this case, somewhere between 4.20.1 and 5.3.4 CONFIG_AUTOFS got enabled (unsure now if that was automatic or by my choice). Looking at my other machines, AUTOFS is enabled on all of them except for my desktop haswell (again, updated for 5.9.1) which has CONFIG_AUTOFS4_FS=m CONFIG_AUTOFS_FS=m So it looks as if AUTOFS (whether that or AUTOFS4 is the correct item to sepcify, I'm unsure - the 4 variant was supposed to be transitory, or for help in converting old configs - I think) can be a module. Not sure if it can be turned off nowadays (that would be nice, there is so much enabled in modern kernels which I don't need). > File systems ---> > [*] Network File Systems ---> [CONFIG_NETWORK_FILESYSTEMS] > <*/M> NFS client support > [CONFIG_NFS_FS] > <*/M> CIFS support (advanced network filesystem, SMBFS successor) > [CONFIG_CIFS] > > Should CIFS support (advanced network filesystem, SMBFS successor) be > SMB3 and CIFS support (advanced network filesystem)? I guess so. > -- > > > BlueZ > > [*] Networking support ---> [CONFIG_NET] > Bluetooth subsystem support ---> [CONFIG_BT] > > Is correct? Should it be ? <*/M>? > No idea. ISTR you have mentioned using bluetooth for input devices ? If so, can you build it in, and if so does it work better as built-in (e.g. easier pairing) or as a module (e.g. sometime need to rmmod and reload if it loses the connection) ? > <*/M> RF switch subsystem support ---> [CONFIG_RFKILL] > > Should RF switch subsystem support ---> be RF switch subsystem support > ? I don't understand, the words after 'Should' and 'be' look identical to me, maybe you didn't type what you intended ? > > [*] Networking support ---> [CONFIG_NET] > -*- Cryptographic API ---> [CONFIG_CRYPTO] > User-space interface for hash algorithms > [CONFIG_CRYPTO_USER_API_HASH] > User-space interface for symmetric key cipher algorithms > [CONFIG_CRYPTO_USER_API_SKCIPHER] > > I believe Cryptographic API has no options. Could [CONFIG_CRYPTO] be > deleted as in cryptsetup? > On 5.9.8 Cryptographic API has loads of options. Near the bottom are < > User-space interface for hash algorithms (NEW) < > User-space interface for symmetric key cipher algorithms (NEW) > As with the above, should the hash algorithms and key cipher lines be > ? <*/M>? > -- > > > lm-sensors > > [*] Enable loadable module support ---> [CONFIG_MODULES] > > Bus options (PCI etc.) ---> > [*] PCI support [CONFIG_PCI] > > Should Enable loadable module support and Bus options be reversed to > follow the order displayed with menuconfig? No idea. Where is MODULES found now ? I assume it is somewhere in General setup, but I can't see it and it seems to be enabled by default. According to the help (which might be out of date), PCI is somewhere under Device Drivers. > > Device Drivers ---> > I2C support ---> > <*/M> I2C device interface [CONFIG_I2C_CHARDEV] > I2C Hardware Bus support ---> > (configure all of them as modules) > <*/M> Hardware Monitoring support ---> [CONFIG_HWMON] > > I believe Hardware Monitoring support has no options. Should it be -*- > Hardware Monitoring Support? If so, could [CONFIG_HWMON] be deleted? Depends on your hardware for whether or not it gets selected: (From the help on a fresh 5.9.8 tree) Symbol: HWMON [=y] │ Type : tristate │ Defined at
Re: [blfs-support] libsoup will not build with sysprof
On Tue, Nov 10, 2020 at 06:34:21PM +0100, Christopher Gregory via blfs-support wrote: > Hello, > > I am working through another installation, and have found that libsoup will > not compile against sysprof. The following error occurs: > > /usr/bin/ld: /usr/lib/libsysprof-capture-4.a(sysprof-collector.c.o): in > function `use_single_trace': > /sources/sysprof-3.38.1/build/../src/libsysprof-capture/sysprof-collector.c:119: > undefined reference to `pthread_getspecific' > > The only way that I could get libsoup to compile and install was by going > into the meson_options.txt and setting the option to use sysprof to disabled. > > Has anyone actually tested and got this combination to work? > > I notice that arch have dropped the need to make sysprof a requirement. I > have not found any patch to date to actually get it to work. I am using the > svn version of systemd blf from 2020-11-01. There has been no update to > sysprof so I could not see if a later version worked. > > Re-installing sysprof made no difference to the above error. I have only > used the commands listed in the book and not added anything extra to the > build commands, ie nothing optional. > > Regards, > > Christopher. Starting a fresh sub-thread to reply to this, because we were floundering. I've just hit this, and apart from Christopher's post google found https://github.com/mesonbuild/meson/issues/7929 Seems to be a problem with meson-0.56.0, apparently will be fixed with 0.56.1 by https://github.com/mesonbuild/meson/commit/2b923f532c3e16687910fecb09cedb80a76597cf.diff but that didn't make any difference for me. I then tried Christopher's change to -Dsysprof=disabled and libsoup built. I agree with him that it shows no signs of downloading anything for sysprof. Meson reported: Dependency sysprof-capture-4 skipped: feature sysprof disabled and the verbose output from ninja did not mention sysprof. ĸen -- Internal error in fortune program: fnum=2987 n=45 flag=1 goose_level=-232323 Please write down these values and notify fortune program admin. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Qemu 5.1.0
On Mon, Nov 23, 2020 at 11:44:10PM +0100, Christopher Gregory via blfs-support wrote: > Hello, > > Late last year, it was reported that quemu failed to build due to missing > gnu/stubs-32.h, and it seems that the original poster never managed to get it > solved. I have now encountered the exact same error when building quemu > 5.1.0. > > I have managed to solve this issue, by editing: > > /usr/include/gnu/stubs.h and commenting out the below block. > > > /*#if !defined __x86_64__ > # include > #endif */ > > Please note that like the original poster, I have not, and never have enabled > 32 bit on my lfs builds. I have no idea why we are randomly coming up with > this error. After commenting out the above, qemu successfully compiles, > without the need of going through and attempting multiple re-installations of > various packages. > > I am going to leave that commented out so that I do not get any more > unpleasant surprises down the track. > > Regards, > > Christopher. > Hi Christopher, obviously something strange is happening from time to time with qemu builds. the original report can be found at https://www.mail-archive.com/blfs-support@lists.linuxfromscratch.org/msg06247.html and the actual reported failure was: CC pc-bios/optionrom/linuxboot_dma.oIn file included from /usr/include/features.h:474, from /usr/include/bits/libc-header-start.h:33, from /usr/include/stdint.h:26, from /usr/src/blfs/vm/qemu-4.1.0/pc-bios/optionrom/linuxboot_dma.c:65:/usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or directory7 | # include | ^~~~compilation terminated.make[1]: *** [/usr/src/blfs/vm/qemu-4.1.0/rules.mak:69: linuxboot_dma.o] Error 1make: *** [Makefile:519: pc-bios/optionrom/all] Error 2* I've just tried pasting what is in the book, with the x86_64-softmmu QEMU_ARCH (which the OP was using) and make -j1 on an LFS-10 sustem succeeded without error and I definitely have the following linuxboot files: ./pc-bios/optionrom/linuxboot_dma.bin ./pc-bios/optionrom/linuxboot_dma.raw ./pc-bios/optionrom/linuxboot_dma.img ./pc-bios/optionrom/linuxboot_dma.o ./pc-bios/optionrom/linuxboot_dma.d ./pc-bios/optionrom/linuxboot.bin ./pc-bios/optionrom/linuxboot.raw ./pc-bios/optionrom/linuxboot.img ./pc-bios/optionrom/linuxboot.d ./pc-bios/optionrom/linuxboot.o ./docs/system/linuxboot.html Same with -j5, so hopefully not a broken Makefile dependency (although this has cropped up over many years, mostly on multiarch distros where 32 libs are available but might need to be separately installed). Looking at my verbose log, this part _is_ building 32-bit code to suit a 486 (below, reformatted re line length) but I've no real idea why mine builds and yours doesn't. make[1]: Entering directory '/tmp/qemu-5.1.0/build/pc-bios/optionrom' cc -E -iquote /tmp/qemu-5.1.0/tcg/i386 -isystem /tmp/qemu-5.1.0/linux-headers -isystem /tmp/qemu-5.1.0/build/linux-headers -iquote . -iquote /tmp/qemu-5.1.0 -iquote /tmp/qemu-5.1.0/accel/tcg -iquote /tmp/qemu-5.1.0/include -iquote /tmp/qemu-5.1.0/disas/libvixl -I/tmp/qemu-5.1.0 -MMD -MP -MT multiboot.o -MF ./multiboot.d -c -o - /tmp/qemu-5.1.0/pc-bios/optionrom/multiboot.S | as -32 -o multiboot.o cc -E -iquote /tmp/qemu-5.1.0/tcg/i386 -isystem /tmp/qemu-5.1.0/linux-headers -isystem /tmp/qemu-5.1.0/build/linux-headers -iquote . -iquote /tmp/qemu-5.1.0 -iquote /tmp/qemu-5.1.0/accel/tcg -iquote /tmp/qemu-5.1.0/include -iquote /tmp/qemu-5.1.0/disas/libvixl -I/tmp/qemu-5.1.0 -MMD -MP -MT linuxboot.o -MF ./linuxboot.d -c -o - /tmp/qemu-5.1.0/pc-bios/optionrom/linuxboot.S | as -32 -o linuxboot.o cc -iquote /tmp/qemu-5.1.0/build/. -iquote . -iquote /tmp/qemu-5.1.0/tcg/i386 -isystem /tmp/qemu-5.1.0/linux-headers -isystem /tmp/qemu-5.1.0/build/linux-headers -iquote . -iquote /tmp/qemu-5.1.0 -iquote /tmp/qemu-5.1.0/accel/tcg -iquote /tmp/qemu-5.1.0/include -iquote /tmp/qemu-5.1.0/disas/libvixl -I/tmp/qemu-5.1.0 -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fno-pie -ffreestanding -fno-stack-protector -m16 -Wa,-32 -MMD -MP -MT linuxboot_dma.o -MF ./linuxboot_dma.d -O2 -g -march=i486 -c -o linuxboot_dma.o /tmp/qemu-5.1.0/pc-bios/optionrom/linuxboot_dma.c The only logical explanation is that my build has __x86_64__ defined and yours doesn't. But I cannot see any reason how that might happen. In configure's output I had host CPU x86_64 target list x86_64-softmmu But looking again, the 3 lines that you commented out are followed by alternatives for systems where __x86_64__ IS defined (normal, i.e. LP64 using stubs-64.h, or x32 for that past attempt to gain the extra
Re: [blfs-support] nspr and nss
On Mon, Nov 23, 2020 at 09:45:07PM +0100, Pol Vangheluwe via blfs-support wrote: > A while ago, I finished the build of LFS-10.0 on a PowerMac-G5 and I am now > playing with jhalfs in the BLFS book. > > For LFS, I know meanwhile what scripts I must adapt for PowerPC > (creatingminlayout, addinguser, gcc-pass1, glibc, gcc-pass2, changingowner, > tcl, glibc, gcc and kernel). > > Some of the adaptations could have been avoided if the construction: > [ “$(uname -m)" = x86_64 ] > would be changed into: > [ “$(uname -m)" = *64 ] > because it would then match with as well “x86_64” as with “ppc64” > And that’s also the case for a number of BLFS scripts, like the packages nspr > and nss. > > But that’s not the reason for this mail… > > I had to add a sed to the script for nss that is not in the BLFS book to make > the compilation successful: > > sed -i ’s/.abiversion\t2/.abiversion\t1/‘ lib/freebl/sha512-p8.s > > I am wondering if this sed is only needed for the PowerPc architecture. I > have no idea what it does, Google just showed me the way. > Anyone that knows more about this? > > pvg > https://bugzilla.mozilla.org/show_bug.cgi?id=1642174 Modern power is little-endian, it appears that the old big-endian power and powerpc used the elf v1 abi. That patch slipped off their radar (big-endian ppc is barely encountered these days, unfortunately) and only got committed 4 days ago so I guess that nss-3.60 should be ok when it appears in about 5 weeks time. ĸen -- Internal error in fortune program: fnum=2987 n=45 flag=1 goose_level=-232323 Please write down these values and notify fortune program admin. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] libsoup will not build with sysprof
On Tue, Nov 10, 2020 at 08:19:26PM +0100, Christopher Gregory via blfs-support
wrote:
>
>
> > Sent: Wednesday, November 11, 2020 at 7:30 AM
> > From: "Ken Moffat via blfs-support"
> >
> > To: "BLFS Support List"
> > Cc: "Ken Moffat"
> > Subject: Re: [blfs-support] libsoup will not build with sysprof
> >
> > On Tue, Nov 10, 2020 at 06:34:21PM +0100, Christopher Gregory via
> > blfs-support wrote:
> > > Hello,
> > >
> > > I am working through another installation, and have found that libsoup
> > > will not compile against sysprof. The following error occurs:
> > >
> > > /usr/bin/ld: /usr/lib/libsysprof-capture-4.a(sysprof-collector.c.o): in
> > > function `use_single_trace':
> > > /sources/sysprof-3.38.1/build/../src/libsysprof-capture/sysprof-collector.c:119:
> > > undefined reference to `pthread_getspecific'
> > >
> > > The only way that I could get libsoup to compile and install was by going
> > > into the meson_options.txt and setting the option to use sysprof to
> > > disabled.
> > >
> > > Has anyone actually tested and got this combination to work?
> > >
> > > I notice that arch have dropped the need to make sysprof a requirement.
> > > I have not found any patch to date to actually get it to work. I am
> > > using the svn version of systemd blf from 2020-11-01. There has been no
> > > update to sysprof so I could not see if a later version worked.
> > >
> >
> > Hi, Christopher.
> >
> > I asked on -dev last month *why* sysprof was recommended. The
> > answer was that if sysprof is not present, libsoup's build will now
> > download and install it as a sub-module.
> >
> > In my case I'd had problems because of static modules (I hide them
> > so that I know what needs to be rebuilt if a package has a
> > vulnerability - the old, old zlib problem from years ago).
> >
> > For me, sysprof builds ok. It looks as if in your build it is not
> > finding libpthread. I can't see any references to pthread i nthe
> > meson files I looked at, but in verbose builds (ninja -v) it
> > magically appears for me, in the case of sysprof I see it in
> > -fPIC -pthread -DSYSPROF_CAPTURE_COMPILATION
I've just noticed (after looking at libsoup output) that this is
NOT -lpthread, which I had assumed, but -pthread. That is actually
one of the CXXFLAGS which it uses. From a reply on stackoverflow
that causes '%{pthread:' items from 'gcc -dumpspecs' to be used on
linux gcc systems, which turns on -D_REENTRANT (errno calls become
a function returning a thread-local location) and adds -lpthread.
So this is more portable.
[https://stackoverflow.com/questions/2127797/significance-of-pthread-flag-when-compiling]
> > for the first target
> > (src/libsysprof-capture/libsysprof-capture-4.a.p/sysprof-address.c.o).
> >
> > Quoting https://mesonbuild.com/howtox.html
> >
> > | Enable threads | | Lots of people seem to do this manually with
> > | find_library('pthread') or something similar. Do not do that. It
> > | is not portable. Instead do this.
> > |
> > | thread_dep = dependency('threads')
> > | executable(..., dependencies : thread_dep)
> >
> > From that, the configuration information re 'threads' is what
> > matters. Im my case (just before glib-2.0) -
> >
> > Program gdbus-codegen found: YES
> > Found pkg-config: /usr/bin/pkg-config (0.29.2)
> > Program gdbus-codegen found: YES
> > Program gdbus-codegen found: YES
> > Configuring sysprof-version.h using configuration
> > Run-time dependency threads found: YES
> > Run-time dependency glib-2.0 found: YES 2.66.2
> >
> > Did meson find it on your system ?
> >
> > I'm guessing that perhaps meson only looks for the header file.
> >
> > The library comes from glibc. In LFS we have a symlink from
> > /usr/lib/libpthread.so to /lib. There is also a static lib (which I
> > hide).
> >
> > > Re-installing sysprof made no difference to the above error. I have only
> > > used the commands listed in the book and not added anything extra to the
> > > build commands, ie nothing optional.
> > >
> > > Regards,
> > >
> > > Christopher.
> >
> > I'm sorry, I'm not well up on all the details of how meson works.
> > But this seems an uncommon problem and makes me wonder if something
> > has trashed either the /usr/lib/libpthread.so symlink or
> > /lib/libpthread.so ? I would epect the static libpthre
Re: [blfs-support] libsoup will not build with sysprof
On Tue, Nov 10, 2020 at 06:34:21PM +0100, Christopher Gregory via blfs-support
wrote:
> Hello,
>
> I am working through another installation, and have found that libsoup will
> not compile against sysprof. The following error occurs:
>
> /usr/bin/ld: /usr/lib/libsysprof-capture-4.a(sysprof-collector.c.o): in
> function `use_single_trace':
> /sources/sysprof-3.38.1/build/../src/libsysprof-capture/sysprof-collector.c:119:
> undefined reference to `pthread_getspecific'
>
> The only way that I could get libsoup to compile and install was by going
> into the meson_options.txt and setting the option to use sysprof to disabled.
>
> Has anyone actually tested and got this combination to work?
>
> I notice that arch have dropped the need to make sysprof a requirement. I
> have not found any patch to date to actually get it to work. I am using the
> svn version of systemd blf from 2020-11-01. There has been no update to
> sysprof so I could not see if a later version worked.
>
Hi, Christopher.
I asked on -dev last month *why* sysprof was recommended. The
answer was that if sysprof is not present, libsoup's build will now
download and install it as a sub-module.
In my case I'd had problems because of static modules (I hide them
so that I know what needs to be rebuilt if a package has a
vulnerability - the old, old zlib problem from years ago).
For me, sysprof builds ok. It looks as if in your build it is not
finding libpthread. I can't see any references to pthread i nthe
meson files I looked at, but in verbose builds (ninja -v) it
magically appears for me, in the case of sysprof I see it in
-fPIC -pthread -DSYSPROF_CAPTURE_COMPILATION
for the first target
(src/libsysprof-capture/libsysprof-capture-4.a.p/sysprof-address.c.o).
Quoting https://mesonbuild.com/howtox.html
| Enable threads | | Lots of people seem to do this manually with
| find_library('pthread') or something similar. Do not do that. It
| is not portable. Instead do this.
|
| thread_dep = dependency('threads')
| executable(..., dependencies : thread_dep)
From that, the configuration information re 'threads' is what
matters. Im my case (just before glib-2.0) -
Program gdbus-codegen found: YES
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Program gdbus-codegen found: YES
Program gdbus-codegen found: YES
Configuring sysprof-version.h using configuration
Run-time dependency threads found: YES
Run-time dependency glib-2.0 found: YES 2.66.2
Did meson find it on your system ?
I'm guessing that perhaps meson only looks for the header file.
The library comes from glibc. In LFS we have a symlink from
/usr/lib/libpthread.so to /lib. There is also a static lib (which I
hide).
> Re-installing sysprof made no difference to the above error. I have only
> used the commands listed in the book and not added anything extra to the
> build commands, ie nothing optional.
>
> Regards,
>
> Christopher.
I'm sorry, I'm not well up on all the details of how meson works.
But this seems an uncommon problem and makes me wonder if something
has trashed either the /usr/lib/libpthread.so symlink or
/lib/libpthread.so ? I would epect the static libpthread.a to get
used, but this is all turning into guesses and hypotheses on my
part.
ĸen
--
Brave Sir Nigel ran away! When reality reared its ugly head, Sir
Nigel turned his tail and fled. Brave brave brave Sir Nigel.
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] Rebuilding gst-plugins-base after installing Qt
On Thu, Oct 29, 2020 at 02:11:29AM +0100, Christopher Gregory via blfs-support
wrote:
>
> > Sent: Thursday, October 29, 2020 at 10:11 AM
> > From: "Ken Moffat via blfs-support"
> >
> > To: "BLFS Support List"
> > Cc: "Ken Moffat"
> > Subject: Re: [blfs-support] Rebuilding gst-plugins-base after installing Qt
> >
> > > >
> > > > On one of my 9.1 systems I had installed OpenEXR in February (a
> > > > dependency of blender). On that system gst-plugins-bad-0.16.3 gave
> > > > some warnings about a missing include direcotry for OpenEXR
> > > > (include/OpenEXR) - presumably the pkgconfig file (for 2.4.1) was
> > > > incorrect and not pointing to the prefix (/usr), then it failed to
> > > > find a specific header which indeed was not installed by that
> > > > version.
> > > >
> > > > The workaround is to hide the pc file during the build, although a
> > > > better workaround is probably not to build these packages in the
> > > > first place.
> > > >
> > > > ĸen
>
> Hello Ken,
>
> OpenSuse have a number of patches for gstreamer-plugins-bad:
>
> https://build.opensuse.org/package/view_file/openSUSE:Factory/gstreamer-plugins-bad/gstreamer-plugins-bad.changes?expand=0
>
> I am not sure which, if any of them would be a solution for this. I always
> install openexr and at times have to hunt for patches to get things to work
> correctly. I never do a partial rebuild of an existing system, as I do not
> like the eventual headache of stubborn packages not wanting to play nice.
>
> Regards,
>
> Christopher.
Hi Christopher,
thanks for the link. I have only built OpenEXR when building
blender ('these packages' really refers to the unpleasant mess of
cmake and python packages pulled in for blender). I had built it on
three machines in February, only one hit this problem. I then built
it on two or three machines in September, that was extremely
aggravating (not for OpenEXR) and at the end of the day I don't
think that using a home 3D printer is going to be practical for me
for what I was thinking about.
And rendering the files - even on my machine which now has more than
30GB available for 8 CPUs - is still horrendously slow.
But along the way I tried one 'movie' demo which created exr files -
I thought I could look at them in 'iv' from one of the blender
dependencies, but they seemed to not look at all like what I was
expecting.
ĸen
--
The people next door oppress me all night long. I tell them: I work
all day, a man's got to have some time to learn to play the tuba.
That's oppression, that is.[ Guards! Guards! ]
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] Rebuilding gst-plugins-base after installing Qt
On Wed, Oct 28, 2020 at 09:52:02AM -0500, Douglas R. Reno via blfs-support wrote: > > On 10/27/20 8:48 PM, Ken Moffat via blfs-support wrote: > > On Tue, Oct 27, 2020 at 10:00:15PM +, Ken Moffat via blfs-support wrote: > > > (Cc: to support if I remember, in case anyone else hits this) > > > > > > Starting to upgrade my systems for whatever has caused today's > > > gstreamer releases. Most are still running 9.1 with 1.16.2. > > > Normally I build gstreamer well before qt, but trying to upgrade has > > > changed that. > > > > > > In gst-plugins-base it finds all the Qt items it tests for, but then > > > fails: > > > > > (etc) > > > > On one of my 9.1 systems I had installed OpenEXR in February (a > > dependency of blender). On that system gst-plugins-bad-0.16.3 gave > > some warnings about a missing include direcotry for OpenEXR > > (include/OpenEXR) - presumably the pkgconfig file (for 2.4.1) was > > incorrect and not pointing to the prefix (/usr), then it failed to > > find a specific header which indeed was not installed by that > > version. > > > > The workaround is to hide the pc file during the build, although a > > better workaround is probably not to build these packages in the > > first place. > > > > ĸen > > Hi Ken, > > I know you've probably already tried this, but can you try doing an > 'ldconfig' and logging in and out? I experienced this issue a few weeks ago, > and that's what I did to solve it. I have no idea why it happened though or > if that was even the true solution unfortunately. > > - Doug > Hi Doug, I hadn't tried it because it's a header not found, rather than a library. Tried it now on a different system for -base after that failed as before, it made no difference (and there is no OpenEXR on this system, so -bad was ok). Thanks anyway. ĸen -- The people next door oppress me all night long. I tell them: I work all day, a man's got to have some time to learn to play the tuba. That's oppression, that is.[ Guards! Guards! ] -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Rebuilding gst-plugins-base after installing Qt
On Tue, Oct 27, 2020 at 10:00:15PM +, Ken Moffat via blfs-support wrote: > (Cc: to support if I remember, in case anyone else hits this) > > Starting to upgrade my systems for whatever has caused today's > gstreamer releases. Most are still running 9.1 with 1.16.2. > Normally I build gstreamer well before qt, but trying to upgrade has > changed that. > > In gst-plugins-base it finds all the Qt items it tests for, but then > fails: > (etc) On one of my 9.1 systems I had installed OpenEXR in February (a dependency of blender). On that system gst-plugins-bad-0.16.3 gave some warnings about a missing include direcotry for OpenEXR (include/OpenEXR) - presumably the pkgconfig file (for 2.4.1) was incorrect and not pointing to the prefix (/usr), then it failed to find a specific header which indeed was not installed by that version. The workaround is to hide the pc file during the build, although a better workaround is probably not to build these packages in the first place. ĸen -- The people next door oppress me all night long. I tell them: I work all day, a man's got to have some time to learn to play the tuba. That's oppression, that is.[ Guards! Guards! ] -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Rebuilding gst-plugins-base after installing Qt
(Cc: to support if I remember, in case anyone else hits this) Starting to upgrade my systems for whatever has caused today's gstreamer releases. Most are still running 9.1 with 1.16.2. Normally I build gstreamer well before qt, but trying to upgrade has changed that. In gst-plugins-base it finds all the Qt items it tests for, but then fails: FAILED: tests/examples/overlay/qtgv-videooverlay.p/qtgv-videooverlay.cpp.o c++ -Itests/examples/overlay/qtgv-videooverlay.p -Itests/examples/overlay -I../tests/examples/overlay -I. -I.. -Igst-libs -I../gst-libs -Igst-libs/gst/video -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gstreamer-1.0 -I/opt/qt5/include -I/opt/qt5/include/QtGui -I/opt/qt5/include/QtWidgets -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -O3 -Waggregate-return -Wmissing-declarations -Wredundant-decls -Wundef -Wwrite-strings -Wformat -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress -Wno-multichar -Wvla -Wpointer-arith -march=native -fstack-clash-protection -D_FORTIFY_SOURCE=2 -fstack-protector-strong -D_GLIBCXX_ASSERTIONS -DQT_GUI_LIB -DQT_WIDGETS_LIB -fPIC -pthread -DHAVE_CONFIG_H -MD -MQ tests/examples/overlay/qtgv-videooverlay.p/qtgv-videooverlay.cpp.o -MF tests/examples/overlay/qtgv-videooverlay.p/qtgv-videooverlay.cpp.o.d -o tests/examples/overlay/qtgv-videooverlay.p/qtgv-videooverlay.cpp.o -c ../tests/examples/overlay/qtgv-videooverlay.cpp ../tests/examples/overlay/qtgv-videooverlay.cpp:29:10: fatal error: QTimer: No such file or directory 29 | #include | ^~~~ Adding -Dexamples=disabled worked around it. I got a similar failure in 1.18.1. Looking at Qt files on the current system, I see several #include In current 1.18.1 I can see references in ./tests/examples/overlay/qtgv-videooverlay.cpp:#include ./tests/examples/overlay/qt-videooverlay.cpp:#include ./tests/examples/gl/qt/videooverlay/videooverlay.cpp:#include ./gst-libs/gst/video/videooverlay.c: * #include ; That last one is a comment on how to use the file. I guess that perhaps these should all be changed to #include ? But looking back they have lived there since at least 5.11.1. Perhaps something in Qt changed, or maybe nobody else is affected ? For me the workaround is adequate. ĸen -- The people next door oppress me all night long. I tell them: I work all day, a man's got to have some time to learn to play the tuba. That's oppression, that is.[ Guards! Guards! ] -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Newer rustc
I've just updated the development book to llvm-11.0.0 and rustc-1.47.0. The only reason to update rust is because llvm changed some internal details and earlier versions cannot build with system llvm-11. In general, as with most other compiler updates, builds using llvm and rustc are now a little slower, and bigger, but the installed files are marginally smaller. For the moment, the only reason to update rustc is if you are also updating llvm. All packages in the book should build fine with rustc-1.42.0, so your system, upgrade or not as you please. Please note that both firefox-esr and thunderbird now need a patch to build with 1.47.0 - it's the same patch, but symlinked for thunderbird. ĸen -- The people next door oppress me all night long. I tell them: I work all day, a man's got to have some time to learn to play the tuba. That's oppression, that is.[ Guards! Guards! ] -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] QtWebEngine - make: *** [Makefile 49: sub-src-make_first] Error 2 - BLFS 10.0
On Sat, Oct 24, 2020 at 04:38:25PM -0400, Scott Andrews via blfs-support wrote: > On Thu, 22 Oct 2020 18:17:16 +0100 > Ken Moffat via blfs-support > wrote: > > > On Mon, Oct 19, 2020 at 07:58:23AM -0400, Scott Andrews via > > blfs-support wrote: > > > On Mon, 19 Oct 2020 02:32:39 +0100 > > > Ken Moffat via blfs-support > > > wrote: > > > On normal builds which use 'make' I always pass -O in my own > > MAKEFLAGS (with -j). I don't recall if I ever passed that to > > qtwebengine, but recently I had not been doing that (the build > > system is very unusual, perhaps based on chrome). But I'm now > > building qtwebengine. > > > > Using 'make -O' (and letting ninja use its default number of jobs) > > the output from the first part (building gn) arrives > > target-by-target, but after that nothing has been written to stdout > > or stderr for the past 10 minutes while all 8 cores are churning > > away. So no, for this using -O does not help. > > > > ĸen > > Works on my system RPI4 *GB > All 4 cores are building away > Your system broke? > > top - 16:35:13 up 8:09, 2 users, load average: 7.73, 8.15, 5.88 > Tasks: 199 total, 8 running, 191 sleeping, 0 stopped, 0 zombie > %Cpu(s): 66.2 us, 33.6 sy, 0.0 ni, 0.1 id, 0.0 wa, 0.0 hi, 0.2 > si, 0.0 st > MiB Mem : 7874.9 total, 5245.8 free,666.8 used, 1962.3 > buff/cache > MiB Swap:100.0 total, 95.5 free, 4.5used. 6777.1 avail > Mem That was not the issue. All cores were running, but using tail -f on the output (I was logging stdout and stderr to a file) I saw no output between the start of the main build and when it finished. I had line-by line output until gn was linked (target 185 of Makefile.gn), then a few lines of make output before it entered build/src/core. Then nothing until the build completed, at which point the output from all 18259 njatargets appeared. ĸen -- The people next door oppress me all night long. I tell them: I work all day, a man's got to have some time to learn to play the tuba. That's oppression, that is.[ Guards! Guards! ] -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] QtWebEngine - make: *** [Makefile 49: sub-src-make_first] Error 2 - BLFS 10.0
On Mon, Oct 19, 2020 at 07:58:23AM -0400, Scott Andrews via blfs-support wrote: > On Mon, 19 Oct 2020 02:32:39 +0100 > Ken Moffat via blfs-support > wrote: > > > > > > I can recall that at times building qtwebengine with NINJA_JOBS > > > > > has been a right PITA, and my notes suggest that passing > > > > > VERBOSE=1 to make definitely stopped it using NINJA_JOBS. > > > > > > > > > > I think that on one occasion I was able to find the error by > > > > > rerunning make in the broken build (and writing to a file, but I > > > > > also recall that there is no output until the build ends). > > > > > [...] > > 5.4.1 Output During Parallel Execution > When running several recipes in parallel the output from each recipe > appears as soon as it is generated, with the result that messages from > different recipes may be interspersed, sometimes even appearing on the > same line. This can make reading the output very difficult. > > To avoid this you can use the ‘--output-sync’ (‘-O’) option. This > option instructs make to save the output from the commands it invokes > and print it all once the commands are completed. Additionally, if > there are multiple recursive make invocations running in parallel, they > will communicate so that only one of them is generating output at a > time. On normal builds which use 'make' I always pass -O in my own MAKEFLAGS (with -j). I don't recall if I ever passed that to qtwebengine, but recently I had not been doing that (the build system is very unusual, perhaps based on chrome). But I'm now building qtwebengine. Using 'make -O' (and letting ninja use its default number of jobs) the output from the first part (building gn) arrives target-by-target, but after that nothing has been written to stdout or stderr for the past 10 minutes while all 8 cores are churning away. So no, for this using -O does not help. ĸen -- The people next door oppress me all night long. I tell them: I work all day, a man's got to have some time to learn to play the tuba. That's oppression, that is.[ Guards! Guards! ] -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] QtWebEngine - make: *** [Makefile 49: sub-src-make_first] Error 2 - BLFS 10.0
On Sun, Oct 18, 2020 at 05:55:39PM -0500, Bruce Dubbs via blfs-support wrote: > On 10/18/20 5:16 PM, rhubarbpieguy--- via blfs-support wrote: > > On 10/17/20 9:14 PM, Ken Moffat via blfs-support wrote: > > > On Sat, Oct 17, 2020 at 04:11:07PM -0500, rhubarbpieguy--- via > > > blfs-support wrote: > > > > Compiling QtWebEngine fails with the following end output: > > > > > > > > make[3]: *** No rule to make target > > > > '/sources/qtwebengine-everywhere-src-5.15.0/build/src/core/release/QtWebEngineCore.stamp', > > > > > > > > needed by '../../lib/libQt5WebEngineCore.so.5.15.0'. Stop. > > > > make[3]: Leaving directory > > > > '/sources/qtwebengine-everywhere-src-5.15.0/build/src/core' > > > > make[2]: *** [Makefile:132: > > > > sub-core_module-pro-install_subtargets] Error > > > > 2 > > > > make[2]: Leaving directory > > > > '/sources/qtwebengine-everywhere-src-5.15.0/build/src/core' > > > > make[1]: *** [Makefile:92: sub-core-install_subtargets] Error 2 > > > > make[1]: Leaving directory > > > > '/sources/qtwebengine-everywhere-src-5.15.0/build/src' > > > > make: *** [Makefile:61: sub-src-install_subtargets] Error 2 > > > > > > > > However, the problem appears to start with 'make: *** [Makefile:49: > > > > sub-src-make_first] Error 2.' > > > > > > > > Qt5 appears to have compiled without error and I believe I'm > > > > following the > > > > documentation. I tried 'NINJA_JOBS=4 make' without success? > > > > > > > I can recall that at times building qtwebengine with NINJA_JOBS has > > > been a right PITA, and my notes suggest that passing VERBOSE=1 to > > > make definitely stopped it using NINJA_JOBS. > > > > > > I think that on one occasion I was able to find the error by > > > rerunning make in the broken build (and writing to a file, but I > > > also recall that there is no output until the build ends). > > > > > > If you need to restrict the number of cores (e.g. insufficient > > > DRAM), taking cores offline (not core 0!) by echoing 0 to > > > /sys/devices/system/cpu/cpu/online etc for the cores you wish to > > > disable (on intel, probably the highest numbered if SMT, on zen the > > > "slow" cores might vary). But that's just a workaround. > > > > > > However, looking at your output I'm puzzled (unless the error was > > > during the install) - Output from 'make' (e.g. at start of line, > > > there are a lot of filenames which include make in them) doesn't > > > really appear in my log from the main build except in > > > > > > make[3]: Nothing to be done for 'first'. > > > [1/185] CXX base/files/file_path_constants.o > > > > > > (running make Makefile.gn to put things together, the part that > > > needs a static lib, which ends at > > > > > > [185/185] LINK gn > > > make[3]: Nothing to be done for 'first'. > > > > > > and then a little later > > > > > > make[3]: Entering directory > > > '/scratch/working/qtwebengine-everywhere-src-5.15.0/build/src/core' > > > ninja -v -C > > > /scratch/working/qtwebengine-everywhere-src-5.15.0/build/src/core/release > > > QtWebEngineCore > > > ninja: Entering directory > > > `/scratch/working/qtwebengine-everywhere-src-5.15.0/build/src/core/release' > > > > > > [1/18172] touch obj/base/allocator/allocator.stamp > > > > > > and nothing more until > > > > > > [18172/18172] touch QtWebEngineCore.stamp > > > make[3]: Leaving directory > > > '/scratch/working/qtwebengine-everywhere-src-5.15.0/build/src/core' > > > > > > and then after that I see 'make' bouncing around directories, > > > removing files, (re) creating .so libs - I assumed that was part of > > > the install, but perhaps it is the end of 'make' itself. If so, did > > > all the ninja targets complete ? > > > > > > ĸen > > > > Sorry, I was sloppy providing output. The problem occurs with 'make' > > and I included the tail end of 'make install.' The error with 'make' > > is: > > > > ninja: build stopped: subcommand failed. > > make[3]: *** [Makefile.gn_run:552: run_ninja] Error 1 > > make[3]: Leaving directory > > '/sources/qtwebengine-everywhere-src-5.15.0/build/src/core' > > make
Re: [blfs-support] QtWebEngine - make: *** [Makefile 49: sub-src-make_first] Error 2 - BLFS 10.0
On Sat, Oct 17, 2020 at 04:11:07PM -0500, rhubarbpieguy--- via blfs-support wrote: > > Compiling QtWebEngine fails with the following end output: > > make[3]: *** No rule to make target > '/sources/qtwebengine-everywhere-src-5.15.0/build/src/core/release/QtWebEngineCore.stamp', > needed by '../../lib/libQt5WebEngineCore.so.5.15.0'. Stop. > make[3]: Leaving directory > '/sources/qtwebengine-everywhere-src-5.15.0/build/src/core' > make[2]: *** [Makefile:132: sub-core_module-pro-install_subtargets] Error > 2 > make[2]: Leaving directory > '/sources/qtwebengine-everywhere-src-5.15.0/build/src/core' > make[1]: *** [Makefile:92: sub-core-install_subtargets] Error 2 > make[1]: Leaving directory > '/sources/qtwebengine-everywhere-src-5.15.0/build/src' > make: *** [Makefile:61: sub-src-install_subtargets] Error 2 > > However, the problem appears to start with 'make: *** [Makefile:49: > sub-src-make_first] Error 2.' > > Qt5 appears to have compiled without error and I believe I'm following the > documentation. I tried 'NINJA_JOBS=4 make' without success? > I can recall that at times building qtwebengine with NINJA_JOBS has been a right PITA, and my notes suggest that passing VERBOSE=1 to make definitely stopped it using NINJA_JOBS. I think that on one occasion I was able to find the error by rerunning make in the broken build (and writing to a file, but I also recall that there is no output until the build ends). If you need to restrict the number of cores (e.g. insufficient DRAM), taking cores offline (not core 0!) by echoing 0 to /sys/devices/system/cpu/cpu/online etc for the cores you wish to disable (on intel, probably the highest numbered if SMT, on zen the "slow" cores might vary). But that's just a workaround. However, looking at your output I'm puzzled (unless the error was during the install) - Output from 'make' (e.g. at start of line, there are a lot of filenames which include make in them) doesn't really appear in my log from the main build except in make[3]: Nothing to be done for 'first'. [1/185] CXX base/files/file_path_constants.o (running make Makefile.gn to put things together, the part that needs a static lib, which ends at [185/185] LINK gn make[3]: Nothing to be done for 'first'. and then a little later make[3]: Entering directory '/scratch/working/qtwebengine-everywhere-src-5.15.0/build/src/core' ninja -v -C /scratch/working/qtwebengine-everywhere-src-5.15.0/build/src/core/release QtWebEngineCore ninja: Entering directory `/scratch/working/qtwebengine-everywhere-src-5.15.0/build/src/core/release' [1/18172] touch obj/base/allocator/allocator.stamp and nothing more until [18172/18172] touch QtWebEngineCore.stamp make[3]: Leaving directory '/scratch/working/qtwebengine-everywhere-src-5.15.0/build/src/core' and then after that I see 'make' bouncing around directories, removing files, (re) creating .so libs - I assumed that was part of the install, but perhaps it is the end of 'make' itself. If so, did all the ninja targets complete ? ĸen -- The people next door oppress me all night long. I tell them: I work all day, a man's got to have some time to learn to play the tuba. That's oppression, that is.[ Guards! Guards! ] -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Berkeley DB
On Sat, Sep 26, 2020 at 06:18:14PM -0400, Scott Andrews via blfs-support wrote: > > On 9/26/20 5:44 PM, Bruce Dubbs via blfs-support wrote: > > On 9/26/20 4:26 PM, Scott Andrews via blfs-support wrote: > > > Beyond Linux® From Scratch - Version 7.5 > > > Chapter 22. Databases > > > > > > Berkeley DB-6.0.20 > > > > > > > > > Beyond Linux® From Scratch (System V Edition) - Version 9.0 > > > Chapter 22. Databases > > > > > > Berkeley DB-5.3.28 > > > > > > > > > Why was Berkeley DB-6.0.20 reverted to Berkeley DB-5.3.28? > > > > > > These both are way behind, Berkeley DB 18.1 (18.1.40) > > > > > > https://www.oracle.com/database/technologies/related/berkeleydb-downloads.html > > > > > > This is not a true open source version. Oracle is not friendly to open > > source. In your link below you have to "sign in" to get the source > > code. > > > > Note that Arch and Debian also use version 5.3.28. > > > > -- Bruce > > > Berkley DB was at DB-6.0.20 in BLFS Version 7.5, WHY REVERT? > > I remember being involved in the revert, but it was a long while ago and I do not recall the details, but probably that the DB-6 version was not being used by anyone else, and therefore it seemed like a bad idea. Please find the last version where we used DB-6, then look at the changelog in the next version, and then look at the list archives around that date (primarily for -dev, but I suspect someone also asked on -support after the change). Or, you can compile whatever software/versions you wish on your own system. But if you are distributing binaries, remember to check that the licenses are compatible. More generally, when we decide to revert versions that often gets discussed on -dev and will therefore be in the archives (sometimes the problem is pointed out on -support before we revert, other times it's all on -dev). ĸen -- A really good hydrophobe has to be trained on dehydrated water from birth. I mean, that costs a fortune in magic alone. But they make great weather magicians. Rain clouds just give up and go away. -- The Colour of Magic -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Problem with evolution-data-server-3.36.5
On Thu, Sep 24, 2020 at 08:45:51AM +0200, filbar--- via blfs-support wrote: > Hello, > my output is: > > nm /usr/lib/libsoftokn3.so | grep sqlite > U sqlite3_bind_blob@@SQLITE_3 > U sqlite3_bind_int@@SQLITE_3 > U sqlite3_bind_text@@SQLITE_3 > U sqlite3_busy_timeout@@SQLITE_3 > U sqlite3_close@@SQLITE_3 > U sqlite3_column_blob@@SQLITE_3 > U sqlite3_column_bytes@@SQLITE_3 > U sqlite3_column_int@@SQLITE_3 > U sqlite3_column_text@@SQLITE_3 > U sqlite3_exec@@SQLITE_3 > U sqlite3_file_control@@SQLITE_3 > U sqlite3_finalize@@SQLITE_3 > U sqlite3_free@@SQLITE_3 > U sqlite3_mprintf@@SQLITE_3 > U sqlite3_open_v2@@SQLITE_3 > U sqlite3_prepare_v2@@SQLITE_3 > U sqlite3_reset@@SQLITE_3 > U sqlite3_step@@SQLITE_3 > U sqlite3_temp_directory@@SQLITE_3 > > Thanks, > Filip Bartmann > *please* don't top post. To summarise, your items are all @SQLITE3, for the rest of us that version specification is missing. From http://lists.linuxfromscratch.org/pipermail/blfs-support/2015-June/076782.html Armin's suggestion to a similar problem was that nss had been built with its bundled sqlite instead of the system version. Looking at my own log for nss-3.56, the only references to sqlite are a lot of ' -lsqlite3 '. If you logged your build, I assume it showed sqlite code from (nss/)libsqlite/sqlite3.c getting compiled. If that is right, the question then becomes: why do the book's commands, particularly the last line, not work on your system ? Pierre already suggested that you force that setting, but in the meantime, what do you get if you run [ -f /usr/include/sqlite3.h ] && echo NSS_USE_SYSTEM_SQLITE=1 ? It ought to echo that setting of the envvar. Perhaps for some reason sqlite did not actually get installed ? Alternatively, perhaps a backslash on an earlier line in nss was missed ? ĸen -- A really good hydrophobe has to be trained on dehydrated water from birth. I mean, that costs a fortune in magic alone. But they make great weather magicians. Rain clouds just give up and go away. -- The Colour of Magic -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] xinit-1.4.1
On Thu, Sep 17, 2020 at 12:31:28PM -0500, Bruce Dubbs via blfs-support wrote: > On 9/17/20 10:58 AM, Hans Meier via blfs-support wrote: > > Hello, > > > > Is sed -e correct in xinit-1.4.1 on the last command? Should it > > not be sed -i ? > > > > > > sed -e '/$serverargs $vtarg/ s/serverargs/: #&/' > > $XORG_PREFIX/bin/startx sed -i '/$serverargs $vtarg/ > > s/serverargs/: #&/' $XORG_PREFIX/bin/startx > > > > > > I use blfs 10.0. > > Yes, you are right, it should be -i. We will need to note this in > the errata. > > Thanks for the report. > > -- Bruce > I see it has been like that for a year. Making xorg suid is generally considered a bad idea now that we have the ability to run X in user mode. I have to assume very few people have tried it, which is why nobody mentioend it until now. For capturing messages (apart from what is in the X log) I use commands like: $startx 2>&1 | tee myxmessages ĸen -- A really good hydrophobe has to be trained on dehydrated water from birth. I mean, that costs a fortune in magic alone. But they make great weather magicians. Rain clouds just give up and go away. -- The Colour of Magic -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Gwenview is unable to launch
On Mon, Sep 14, 2020 at 09:08:47AM -0400, Linux Lover via blfs-support wrote: > Upon researching it seems cfisio is apart of that which is installed at 3.19 > > I'm at a loss lol > P;lease don't top post, it makes it very hard to follow the thread. I'm unable to parse that sentence. What is 'cfisio', and what is '3.19' ? > On Mon, Sep 14, 2020, 8:18 AM Elias Rudberg wrote: > > > On Mon, 2020-09-14 at 07:09 -0400, Linux Lover via blfs-support wrote: > > > Followed instructions > > > http://www.linuxfromscratch.org/blfs/view/svn/kde/gwenview5.html > > > > > > Compiled just fine, however upon launching I get an error > > > > > > gwenview: symbol lookup error: > > > gwenview: undefined symbol: > > > _ZNK10FitsPlugin12capabilitiesEP9QIODeviceRK10QByteArray > > > > > > Any ideas? Everything is up to date on my system. I filed a bug with > > > kde t they told me to post here. Unfortunately, with LFS/BLFS 'Everything is up to date on my system' doesn't tell us a lot about what you have installed or updated. I guess you are running what started out as an older system, and have been upgrading packages ? > > > > I don't know how to solve it but one step along the way could be to > > demangle that cryptic name using c++filt: > > > > $ echo _ZNK10FitsPlugin12capabilitiesEP9QIODeviceRK10QByteArray | > > c++filt > > FitsPlugin::capabilities(QIODevice*, QByteArray const&) const > > > > So somewhere there is a C++ class called "FitsPlugin" -- the question > > is, which library is supposed to provide an implementation for that? > > Perhaps KDE folks could at least help with answering that? > > > > / Elias > > Google doesn't find much for FitsPlugin related to gwenview (it found some results for photoshop, I think it might be related to astronomy (i.e. photos of starts). The plugins seem to come from KF5Kipi. That makes me wonder if you have updated qt and qwenview from an old version (at a guess, before 5.15 ahnd 20.08) where KF5Kipi was installed, but have not updated/reinstalled that. Other than that, I have no ideas - unfortunately the qwenview releases don't have any information on what changed, and I could not find any Release Notes. ĸen -- I could not live without Champagne. In victory I deserve it, in defeat I need it. -- Churchill -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] md5sum for IPC::System::Simple-1.30 has changed
On Wed, Sep 02, 2020 at 08:05:22PM -0400, Chris Gorman via blfs-support wrote: > Hello, > > Just noticed that the md5sum for Perl Module Dependencies, > IPC::System::Simple-1.30 is no longer > 4fc72ad2c1454b78b82d329a958def18. It is now > e68341fd958fd013b3521d909904f675. > > Chris I wish you'd pointed that out earlier ;-) Correct, and I obviously forgot to change it when I updated that last month. Will add to the Errata: at the moment it looks like I'm going to own the errata. ĸen -- I could not live without Champagne. In victory I deserve it, in defeat I need it. -- Churchill -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-9.0, BLFS-9.1, BLFS-SVN: xorgproto
On Fri, Aug 28, 2020 at 08:00:39AM -0400, Scott Andrews via blfs-support wrote: > On Fri, 28 Aug 2020 02:06:34 +0100 > Ken Moffat via blfs-support > wrote: > > > On Thu, Aug 27, 2020 at 08:01:18PM -0400, Scott Andrews via > > blfs-support wrote: > > > > If you never need to build multilib (e.g. 32-bit and 64-bit) then > > moving them should not cause you any trouble. > > > > Looking at Arch for xorgproto, the only pc file that I see mentioned > > at > > https://github.com/archlinux/svntogit-packages/blob/packages/xorgproto/trunk/PKGBUILD > > is applewmproto.pc which they remove as part of cleaning up the > > apple stuff. I don't see any mention of the other pc files being > > moved. > > > > Similarly, fedora, mandriva cooker are using /usr/share. > > > > ĸen > > They are in /usr/share/pkgconfig > Indeed, and yet your original post implied that Arch were installing them in /usr/lib/pkgconfig: | *.pc files in wrong directory | | install -m755 -d /usr/lib | mv /usr/share/pkgconfig /usr/lib/ > Name: xorgproto > Version : 2019.1 > Release : 1 > Architecture: armv7hnl > Install Date: (not installed) > Group : Xorg > Size: 4060717 > License : Other > Signature : (none) > Source RPM : xorgproto-2019.1-1.src.rpm > Build Date : Fri Aug 28 11:53:31 2020 > Build Host : rpi.example.org > Relocations : (not relocatable) > Vendor : Octothorpe > URL : https://xorg.freedesktop.org/ > Summary : Combined X.Org X11 Protocol headers > Description : > Combined X.Org X11 Protocol headers > > [ putolin ] > An interesting word for snipping, somebody by another name used that. I have no problem with whatever language people wish to use, merely mentioning it. > /usr/share/licenses/xorgproto/COPYING-kbproto Licenses can reasonably go into /usr/share/licenses (in BLFS we do not explicitly install them if the package does not automatically do that - but for anyone who provides a binary package that is a good idea). > /usr/share/pkgconfig/bigreqsproto.pc > /usr/share/pkgconfig/compositeproto.pc > /usr/share/pkgconfig/damageproto.pc > /usr/share/pkgconfig/dmxproto.pc > /usr/share/pkgconfig/dri2proto.pc > /usr/share/pkgconfig/dri3proto.pc > /usr/share/pkgconfig/fixesproto.pc > /usr/share/pkgconfig/fontsproto.pc > /usr/share/pkgconfig/glproto.pc > /usr/share/pkgconfig/inputproto.pc > /usr/share/pkgconfig/kbproto.pc > /usr/share/pkgconfig/presentproto.pc > /usr/share/pkgconfig/randrproto.pc > /usr/share/pkgconfig/recordproto.pc > /usr/share/pkgconfig/renderproto.pc > /usr/share/pkgconfig/resourceproto.pc > /usr/share/pkgconfig/scrnsaverproto.pc > /usr/share/pkgconfig/videoproto.pc > /usr/share/pkgconfig/windowswmproto.pc > /usr/share/pkgconfig/xcmiscproto.pc > /usr/share/pkgconfig/xextproto.pc > /usr/share/pkgconfig/xf86bigfontproto.pc > /usr/share/pkgconfig/xf86dgaproto.pc But you started by saying that /usr/share/pkgconfig is the wrong directory. Those all match the canonical Arch install at https://www.archlinux.org/packages/extra/any/xorgproto/ I repeat: you can do what you want for pkgconfig files on a non-multilib build. But saying that Arch are installing them in /usr/lib is at best misleading. ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-9.0, BLFS-9.1, BLFS-SVN: xorgproto
On Thu, Aug 27, 2020 at 08:01:18PM -0400, Scott Andrews via blfs-support wrote: > On Thu, 27 Aug 2020 22:46:52 +0100 > Ken Moffat via blfs-support > wrote: > > > On Thu, Aug 27, 2020 at 05:32:37PM -0400, Scott Andrews via > > blfs-support wrote: > > > > > > *.pc files in wrong directory > > > > > > install -m755 -d /usr/lib > > > mv /usr/share/pkgconfig /usr/lib/ > > > > No. /usr/share/pkgconfig was introduced many years ago, for > > pkgconfig files which are not architecture-specific. My oldest > > remaining logs are from LFS-7.1, and at that time iso-codes, udev, > > shared-mime-info, dbus, xbitmaps, util-macros were among the > > packages using it. > > > > ĸen > > Most distros are moving them, check archlinux for one If you never need to build multilib (e.g. 32-bit and 64-bit) then moving them should not cause you any trouble. Looking at Arch for xorgproto, the only pc file that I see mentioned at https://github.com/archlinux/svntogit-packages/blob/packages/xorgproto/trunk/PKGBUILD is applewmproto.pc which they remove as part of cleaning up the apple stuff. I don't see any mention of the other pc files being moved. Similarly, fedora, mandriva cooker are using /usr/share. ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] BLFS-9.0, BLFS-9.1, BLFS-SVN: xorgproto
On Thu, Aug 27, 2020 at 05:32:37PM -0400, Scott Andrews via blfs-support wrote: > > *.pc files in wrong directory > > install -m755 -d /usr/lib > mv /usr/share/pkgconfig /usr/lib/ No. /usr/share/pkgconfig was introduced many years ago, for pkgconfig files which are not architecture-specific. My oldest remaining logs are from LFS-7.1, and at that time iso-codes, udev, shared-mime-info, dbus, xbitmaps, util-macros were among the packages using it. ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Problems with xine-lib on intel and amdgpu
On Sat, Aug 22, 2020 at 12:14:52AM +0100, Ken Moffat via blfs-support wrote: > On Sat, Aug 15, 2020 at 01:27:49AM +0800, Xi Ruoyao via blfs-support wrote: > > On 2020-08-14 17:00 +0100, Ken Moffat via blfs-support wrote: > > > On Fri, Aug 14, 2020 at 10:19:18AM -0500, Douglas R. Reno via blfs-support > > > wrote: > > > > On 8/9/20 6:57 PM, Ken Moffat via blfs-support wrote: > > > > > My second set of problems with video players ;) > > > > > > > > > > I know that xine has always been rather fragile, partly related to > > > > > CFLAGS I use in oe of the dependencies - but a year ago those > > > > > detined flags made it mostly work. With mov files and some of my > > > > > own mkv and (old: fmpeg-0.7!) mp4 conversions it has tended to > > > > > stutter (the picture jumps backwards). On downloads they usually > > > > > play ok. > > > > > > > > > > With my current (late July build) on my haswell, almost everything > > > > > that I try to play in xine crashes at startup. On my machine using > > > > > radeon r600, my own mov files crash but everything else plays fine. > > > > > On my machien with amdgpu, the mov files from my camera similarly > > > > > crash, but everything else plays *until I use the xine control > > > > > slider to move forward through the video* (I don't wish to spend > > > > > hours looking at the files I'm using for testing). As soon as I > > > > > touch the slider, xine crashes. [...] > > > > > > > > I wanted to let you know that I was able to get Xine to play > > > > big_buck_bunny.mp4 properly on my Intel Skylake system (i5-6600k). I > > > > don't > > > > have any .mov files or any .wmv files sitting around here that I can use > > > > though, and I'm not sure converting would be much help here either. I > > > > did > > > > also scrub through the video using the slider, and watched it to > > > > completion. > > > > > > > > I am using Mesa-20.1.5, with the Intel Iris driver that's built into > > > > Mesa > > > > (newer Intel systems won't be able to use i965 properly, especially > > > > once the > > > > Xe series of graphics cards comes out). FFMPEG-4.3.1 is in use too. The > > > > current driver loaded on my system is "iris". I did see an error > > > > regarding > > > > libvdpau_nvidia.so when starting though, but I don't think that's > > > > related. > > > > As far as I can tell, I do have the latest version of the related > > > > packages > > > > installed on this machine. > > > > > > > > Here is my console output: > > > > > > > > renodr [ /sources ]$ xine big_buck_bunny.mp4 > > > > This is xine (X11 gui) - a free video player > > > > v0.99.12. | > > > > (c) 2000-2019 The xine Team. > > > > Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared > > > > object > > > > file: No such file or direct > > > > ory > > > > libva info: VA-API version 1.8.0 > > > > libva error: vaGetDriverNameByIndex() failed with unknown libva error, > > > > driver_name = (null) > > > > > > > > > > > > Is it possible that it could be permissions? My intel system here is a > > > > systemd box. I am working on my elogind system at the moment to check > > > > on a > > > > couple things, and it has a Radeon in it. I'll let you know how that > > > > works, > > > > it's on my list to try next. > > > > I know libva-intel-driver won't work with new Intel hardware. But I'm not > > sure > > if it would work with mesa Iris driver. Have you > > tried `MESA_LOADER_DRIVER_OVERRIDE=i965`? > > I assumed that question was for Douglas, because I was using my > haswell. > > I've now been trying xine on my i3 skylake (not sure how to tell if > that is using Iris ?) and some files play in xine without problems > (no sound on this machine, but the video is ok) but others crash > immediately. > > Looking at term output for one of those: > > This is xine (X11 gui) - a free video player v0.99.12. > (c) 2000-2019 The xine Team. > Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared object > file: No such file or directory > X Error of
Re: [blfs-support] Problems with xine-lib on intel and amdgpu
On Sat, Aug 15, 2020 at 01:27:49AM +0800, Xi Ruoyao via blfs-support wrote: > On 2020-08-14 17:00 +0100, Ken Moffat via blfs-support wrote: > > On Fri, Aug 14, 2020 at 10:19:18AM -0500, Douglas R. Reno via blfs-support > > wrote: > > > On 8/9/20 6:57 PM, Ken Moffat via blfs-support wrote: > > > > My second set of problems with video players ;) > > > > > > > > I know that xine has always been rather fragile, partly related to > > > > CFLAGS I use in oe of the dependencies - but a year ago those > > > > detined flags made it mostly work. With mov files and some of my > > > > own mkv and (old: fmpeg-0.7!) mp4 conversions it has tended to > > > > stutter (the picture jumps backwards). On downloads they usually > > > > play ok. > > > > > > > > With my current (late July build) on my haswell, almost everything > > > > that I try to play in xine crashes at startup. On my machine using > > > > radeon r600, my own mov files crash but everything else plays fine. > > > > On my machien with amdgpu, the mov files from my camera similarly > > > > crash, but everything else plays *until I use the xine control > > > > slider to move forward through the video* (I don't wish to spend > > > > hours looking at the files I'm using for testing). As soon as I > > > > touch the slider, xine crashes. > > > > > > > > Looking back at older systems, that behaviour with amdgpu was > > > > present in BLFS-9.1. > > > > > > > > I've now reverted the string of packages I mentioned in my post > > > > about parole (but again that has made no difference. > > > > > > > > Summary: For me xine (technically xine-ui) crashes on intel igpu, > > > > mostly works on radeon, works on amdgpu if I don't use the controls > > > > and let it play through. > > > > > > > > Again, I would be interested to hear of other people's successes. > > > > Note that one or two files (one commercial mov, two commercial wmv) > > > > do work with or without the reverts, other commercial wmv files > > > > crash. > > > > > > > > ĸen > > > > > > Hi Ken, > > > > > > > > > I wanted to let you know that I was able to get Xine to play > > > big_buck_bunny.mp4 properly on my Intel Skylake system (i5-6600k). I don't > > > have any .mov files or any .wmv files sitting around here that I can use > > > though, and I'm not sure converting would be much help here either. I did > > > also scrub through the video using the slider, and watched it to > > > completion. > > > > > > I am using Mesa-20.1.5, with the Intel Iris driver that's built into Mesa > > > (newer Intel systems won't be able to use i965 properly, especially once > > > the > > > Xe series of graphics cards comes out). FFMPEG-4.3.1 is in use too. The > > > current driver loaded on my system is "iris". I did see an error regarding > > > libvdpau_nvidia.so when starting though, but I don't think that's related. > > > As far as I can tell, I do have the latest version of the related packages > > > installed on this machine. > > > > > > Here is my console output: > > > > > > renodr [ /sources ]$ xine big_buck_bunny.mp4 > > > This is xine (X11 gui) - a free video player > > > v0.99.12. | > > > (c) 2000-2019 The xine Team. > > > Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object > > > file: No such file or direct > > > ory > > > libva info: VA-API version 1.8.0 > > > libva error: vaGetDriverNameByIndex() failed with unknown libva error, > > > driver_name = (null) > > > > > > > > > Is it possible that it could be permissions? My intel system here is a > > > systemd box. I am working on my elogind system at the moment to check on a > > > couple things, and it has a Radeon in it. I'll let you know how that > > > works, > > > it's on my list to try next. > > I know libva-intel-driver won't work with new Intel hardware. But I'm not > sure > if it would work with mesa Iris driver. Have you > tried `MESA_LOADER_DRIVER_OVERRIDE=i965`? I assumed that question was for Douglas, because I was using my haswell. I've now been trying xine on my i3 skylake (not sure how to tell if that is using Iris ?) and some files play in xine without problem
Re: [blfs-support] GCC fails to find headers that are present on the system
On Fri, Aug 21, 2020 at 04:14:28PM -0400, Chris Gorman via blfs-support wrote: > On Fri, Aug 21, 2020 at 3:47 PM Pierre Labastie via blfs-support > wrote: > > > > On Fri, 2020-08-21 at 13:44 -0400, Chris Gorman via blfs-support wrote: > > > Hello All, > > > > > > I am trying to build a sysv BLFS system off of LFS-10.0-rc1 and am > > > getting an odd error with header files. The compiler is failing > > > complaining about missing headers that are present on the system. I > > > have experienced this with two packages, gcc and mesa. > > > > > > Attempting to build gcc I get ... > > > > > > g++ -std=gnu++98 -c -g -DIN_GCC -fno-exceptions -fno-rtti > > > -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings > > > -Wcast-qual -Wno-error=format-diag -Wno-format > > > -Wmissing-format-attribute -Woverloaded-virtual -pedantic > > > -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings > > > -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild > > > -I../../gcc -I../../gcc/build -I../../gcc/../include > > > -I../../gcc/../libcpp/include \ > > > -o build/genhooks.o ../../gcc/genhooks.c > > > In file included from ../../gcc/system.h:266, > > > from ../../gcc/gengenrtl.c:22: > > > /usr/include/c++/10.2.0/cstdlib:75:15: fatal error: stdlib.h: No such > > > file or directory > > >75 | #include_next > > > | ^~ > > > compilation terminated. > > > make[3]: *** [Makefile:2723: build/gengenrtl.o] Error 1 > > > make[3]: *** Waiting for unfinished jobs > > > In file included from ../../gcc/system.h:266, > > > from ../../gcc/sort.cc:38: > > > /usr/include/c++/10.2.0/cstdlib:75:15: fatal error: stdlib.h: No such > > > file or directory > > >75 | #include_next > > > | ^~ > > > compilation terminated. > > > make[3]: *** [Makefile:2723: build/sort.o] Error 1 > > > In file included from ../../gcc/system.h:266, > > > from ../../gcc/genhooks.c:21: > > > /usr/include/c++/10.2.0/cstdlib:75:15: fatal error: stdlib.h: No such > > > file or directory > > >75 | #include_next > > > | ^~ > > > compilation terminated. > > > make[3]: *** [Makefile:2723: build/genhooks.o] Error 1 > > > /bin/sh ../../gcc/../move-if-change tmp-mlib.h multilib.h > > > echo timestamp > s-mlib > > > /bin/sh ../../gcc/../move-if-change tmp-optionlist optionlist > > > echo timestamp > s-options > > > make[3]: Leaving directory '/sources/gcc/gcc-10.2.0/build/gcc' > > > make[2]: *** [Makefile:4744: all-stage1-gcc] Error 2 > > > make[2]: Leaving directory '/sources/gcc/gcc-10.2.0/build' > > > make[1]: *** [Makefile:25317: stage1-bubble] Error 2 > > > make[1]: Leaving directory '/sources/gcc/gcc-10.2.0/build' > > > make: *** [Makefile:1000: all] Error 2 > > > > > > And when trying to build mesa I get ... > > > > > > [68/2168] Compiling C++ object > > > src/compiler/libcompiler.a.p/glsl_types.cpp.o > > > FAILED: src/compiler/libcompiler.a.p/glsl_types.cpp.o > > > c++ -Isrc/compiler/libcompiler.a.p -Isrc/compiler -I../src/compiler > > > -Isrc/mapi -I../src/mapi -Isrc/mesa -I../src/mesa -Iinclude > > > -I../include -Isrc -I../src -I../src/gallium/include > > > -Isrc/gallium/auxiliary -I../src/gallium/auxiliary > > > -fdiagnostics-color=always -DNDEBUG -pipe -D_FILE_OFFSET_BITS=64 > > > -Wall > > > -Winvalid-pch -Wnon-virtual-dtor -std=c++14 -O3 > > > -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS > > > '-DPACKAGE_VERSION="20.1.5"' > > > '-DPACKAGE_BUGREPORT=" > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues;' > > > -DUSE_ELF_TLS -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0 > > > -DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM > > > -DGLX_INDIRECT_RENDERING > > > -DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM > > > -DHAVE_SURFACELESS_PLATFORM -DENABLE_SHADER_CACHE > > > -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 > > > -DHAVE___BUILTIN_CLZ > > > -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT > > > -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT > > > -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE > > > -DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN > > > -DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE > > > -DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT > > > -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT > > > -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL > > > -DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_FUNC_ATTRIBUTE_ALIAS > > > -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_UINT128 -D_GNU_SOURCE > > > -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM > > > -DMAJOR_IN_SYSMACROS -DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H > > > -DHAVE_DLFCN_H -DHAVE_EXECINFO_H -DHAVE_SYS_SHM_H -DHAVE_CET_H > > > -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE > > > -DHAVE_RANDOM_R -DHAVE_FLOCK -DHAVE_STRTOK_R > > >
Re: [blfs-support] Parole breakage on intel gpu.
On Sat, Aug 15, 2020 at 01:21:45AM +0800, Xi Ruoyao via blfs-support wrote: > On 2020-08-14 16:53 +0100, Ken Moffat via blfs-support wrote: > > On Fri, Aug 14, 2020 at 10:39:44AM -0500, Douglas R. Reno via blfs-support > > wrote: > > > On 8/9/20 6:35 PM, Ken Moffat via blfs-support wrote: > > > > Two or three weeks ago I noticed a problem with parole on my latest > > > > build on my haswell (LFS from 25th July, BLFS from the next day). > > > > Whatever I try to view, the screen broken into horizontal stripes, > > > > rather like venetian blinds but with a mix of colours not apparently > > > > related to the video which should be visible. > > > > > > > > On a machine using radeon (R600-series) video, parole works fine. > > > > > > > > On my haswell, the following all work fine: ffplay, gst-play-1.0, > > > > vlc. > > > > > > > > Other things have, of course, got in the way, but I'm now ready to > > > > document what has changed between working and broken versions, and > > > > to ask for suggestions. > > > > > > > > Looking back at previous builds on this machine, a build in May was > > > > fine, the intermediate build in June showed the same problem. > > > > > > > > The following packages, and versions, are common to both the good > > > > and bad builds: running kernel 5.7.2, gcc-10.1.0, gstreamer-1.16.2, > > > > fdk-aac-2.0.1, freetype-2.10.2, lame-3.100, libtheora-1.1.1, > > > > libvorbis-1.3.7 (I upgraded older systems to that version), > > > > libvpx-1.8.2, opus-1.3.1, x264-20200218, yasm-1.3.0, libvdpau-1.4, > > > > libvdpau-va-gl-0.4.0, SDL2-2.0.12. > > > > > > > > Looking at what had changed: > > > > > > > > ffmpeg 4.2.2 on previous good systems, 4.3 and 4.3.1 on current. > > > > > > > > libva-2.7.1 on last working system and on June non-working, 2.8.0 on > > > > latest. > > > > > > > > x265 3.3 on working, 3.4 on latest (now reverted to 3.3, symlink > > > > fixed, gst-plugins-bad rebuilt) > > > > > > > > intel-vaapi-driver 2.4.0 on good, 2.4.1 on latest, now reverted to > > > > 2.4.0. > > > > > > > > xf86-video-intel 20200218 on good, 20200518 on latest, now reverted > > > > to 20200218. > > > > > > > > Before Bruce asks: I've used the same CFLAGS, CXXFLAGS throughout > > > > these builds. > > > > > > > > At this stage, this is just a request for suggestions, and a > > > > question whether parole is working on anyone's current intel > > > > machiens with integrated graphics ? > > > > > > > > TIA > > > > > > > > ĸen > > > > > > I would say that I was able to get Parole working, but unfortunately I'm > > > not > > > able to: > > > > > > [Current thread is 1 (Thread 0x7fb5315b2a00 (LWP 6876))] > > > (gdb) bt > > > #0 0x7fb5325379c2 in _XInternAtom > > > (dpy=dpy@entry=0x7fb524003ee0, name=name@entry=0x438f75 > > > "_NET_WM_WINDOW_OPACITY_LOCKED", onlyIfExis > > > ts=onlyIfExists@entry=1, psig=psig@entry=0x7ffedf8e53b8, > > > pidx=pidx@entry=0x7ffedf8e53b0, pn=pn@entry=0x > > > 7ffedf8e53b4) at IntAtom.c:76 > > > #1 0x7fb532537cfb in XInternAtom > > > (dpy=dpy@entry=0x7fb524003ee0, name=name@entry=0x438f75 > > > "_NET_WM_WINDOW_OPACITY_LOCKED", onlyIfExis > > > ts=onlyIfExists@entry=1) at IntAtom.c:175 > > > #2 0x0041f4f6 in parole_player_set_wm_opacity_hint > > > (widget=0x1a28510 [GtkWindow]) > > > at parole-player.c:3071 > > > #3 parole_player_init (player=0x1e98480 [ParolePlayer]) at > > > parole-player.c:3734 > > > #4 0x7fb5327d1571 in g_type_create_instance (type=) at > > > ../gobject/gtype.c:1867 > > > #5 0x7fb5327b8125 in g_object_new_internal > > > (class=class@entry=0x1a77ed0, params=params@entry=0x7ffedf8e56a0, > > > n_params=n_params@entry=1) > > > at ../gobject/gobject.c:1937 > > > #6 0x7fb5327b9bb4 in g_object_new_valist > > > (object_type=, > > > first_property_name=first_property_name@entry=0x438348 "client-id", v > > > ar_args=var_args@entry=0x7ffedf8e57e8) at ../gobject/gobject.c:2262 > > > #7 0x7fb5327b9f0c in g_object_new > > > (object_
Re: [blfs-support] Error in building OpenJDK with glibc-2.32 build
On Fri, Aug 21, 2020 at 01:23:19AM -0400, Bud Rozwood via blfs-support wrote: > Hi, > > I'm getting an error saying: > > fatal error: sys/sysctl.h: No such file or directory > > when trying to build OpenJDK 14.01+7 using glibc 2.32 version. I've > looked it up on archlinux.org/packages for glibc version 2.32 and it > seems that this version of glibc doesn't ship with the header file > "sysctl.h". I've searched other places and they also said the same > thing, like for example, Debian's babeld: > https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1759087.html > > The LFS version is 9.1, System V. The only reason why I'm using this > version of OpenJDK is for compatibility with the latest FireFox. Also, > I'm using the latest FireFox and glibc for security updates. I rarely build OpenJDK, and never before firefox, so I've no idea what it offers to firefox users. In BLFS we do not generally talk about older versions of dependant packages (I have been known to do so occasionally, and in the wiki for firefox I mention the versions for required dependencies), so I would not be surprised to learn that any maintained version of OpenJDK could be used - if it built. But http://openjdk.5641.n7.nabble.com/8u-RFR-XS-8244461-JDK-8u-Build-fails-with-glibc-2-32-td410342.htm with a link to https://bugs.openjdk.java.net/browse/JDK-8244461 said (before 2.32 was released) that this would only be a problem in OpenJDK 8u and 7u because in later versions the headers had been cleaned up. In any case, in the development book (preparing to be LFS-10.0) somebody has already tagged 14.0.1+7 as working. That makes me think something in your build is wrong. > > Can anyone else confirm this? Would a patch replacing "sys/sysctl.h" to > "linux/sysctl.h" be sufficient? > And unfortunately, that seems unlikely to work. iThe glibc-2.32 Release annonucement at https://sourceware.org/pipermail/libc-announce/2020/29.html said: | The deprecated header and the sysctl function have been | removed. To support old binaries, the sysctl function continues to | exist as a compatibility symbol (on those architectures which had it), | but always fails with ENOSYS. This reflects the removal of the system | call from all architectures, starting with Linux 5.5. ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] 9.1-systemd: NSS-3.55 build fails
On Mon, Aug 17, 2020 at 04:37:49PM -0400, Scott Andrews via blfs-support wrote: > On Mon, 17 Aug 2020 21:05:31 +0100 > Ken Moffat via blfs-support > wrote: > > > > > ĸen > > > > > > Chromium and firefox-esr. > > > > If you built chromium then your skills are much higher than mine. > > It is the "open source" debian version of chromium built for the ARM > platform. Maybe you should look into it. It should build on the > Wintel platform with minimal changes Thanks for that information, but the moment I don't have the time. ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] 9.1-systemd: NSS-3.55 build fails
On Sun, Aug 16, 2020 at 08:59:09PM -0400, Scott Andrews via blfs-support wrote:
> On Mon, 17 Aug 2020 01:13:19 +0100
> Ken Moffat via blfs-support
> wrote:
>
> > On Sun, Aug 16, 2020 at 05:28:42PM -0400, Scott Andrews via
> > blfs-support wrote:
> > > On Sun, 16 Aug 2020 22:10:37 +0100 Ken Moffat via blfs-support
> > > wrote:
> > >
> > > > >
> > > > For a desktop machine, 2GB is woefully inadequate nowadays :-(
> > > > (And if it is a server, nss might be an uncommon choice).
> > > >
> > > > ĸen
> > >
> > > Maybe from your point a view. I am using raspbery pi 3 and 4 as
> > > desktop machines and servers. They work well.
> > >
> > Great, for whatever packages you are compiling on your desktop. But
> > the OP was using x86_64 and on that 2GB is woefully inadequate for
> > comiling a modern desktop - unless someone is using a single core
> > machine, and I do not recall when those were last produced in
> > x86_64. To be honest I could not contemplate building and
> > maintaining an x86_64 BLFS machine with less than 4 cores and 2GB
> > RAM per core (for things like rust and qtwebengine). Oh, my laptop
> > has 8 cores but a pitiful amount of RAM (6.7GB according to top,
> > some is used for the video) and on that I have to shut down almost
> > everything and force rust and qtwebengine to use fewer cores when I
> > rebuild those or firefox, and it is painful.
> >
> > For i686 I have no idea how much RAM is needed to build and maintain
> > a BLFS *desktop* system.
> >
> > I assume you are using 32-bit for at least pi3. Out of interest,
> > Which graphical browser do you build for your desktop ?
> >
> > ĸen
>
> Chromium and firefox-esr.
If you built chromium then your skills are much higher than mine.
> The build machine is a raspberry pi 2
>
> A 900MHz quad-core ARM Cortex-A7 CPU
> 1GB RAM
> 100 Base Ethernet
> 4 USB ports
> 40 GPIO pins
> Full HDMI port
> Combined 3.5mm audio jack and composite video
> Camera interface (CSI)
> Display interface (DSI)
> Micro SD card slot
> VideoCore IV 3D graphics core
>
> FLAGS are as follows
> # ARM settings, RPI2
> MARCH="armv7-a+neon-vfpv4"
> MTUNE="cortex-a7"
> MFLOAT="hard"
> MFPU="neon-vfpv4"
>
> %_optflags -O2 -pipe -march=${MARCH} -mtune=${MTUNE}
> -mfloat-abi=${MFLOAT} -mfpu=${MFPU} -fPIC -fomit-frame-pointer
> -ftree-vectorize
> %_system_type --with-arch=${MARCH} --with-fpu=${MFPU}
> --with-float=${MFLOAT} --with-arch-directory=arm
>
> I can build LFS-9.0 complete with kernel, dovecot, exim, dns and rpm
> in less than 24 hours.
>
> I don't have the time for Chromium and firefox-esr, as I didn't keep
> the logs for the old build system. I am currently updating my build
> scripts to make the simpler.
>
> --
> http://lists.linuxfromscratch.org/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
--
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
-- Unseen Academicals
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] 9.1-systemd: NSS-3.55 build fails
On Sun, Aug 16, 2020 at 05:28:42PM -0400, Scott Andrews via blfs-support wrote: > On Sun, 16 Aug 2020 22:10:37 +0100 Ken Moffat via blfs-support > wrote: > > > > > > For a desktop machine, 2GB is woefully inadequate nowadays :-( > > (And if it is a server, nss might be an uncommon choice). > > > > ĸen > > Maybe from your point a view. I am using raspbery pi 3 and 4 as > desktop machines and servers. They work well. > Great, for whatever packages you are compiling on your desktop. But the OP was using x86_64 and on that 2GB is woefully inadequate for comiling a modern desktop - unless someone is using a single core machine, and I do not recall when those were last produced in x86_64. To be honest I could not contemplate building and maintaining an x86_64 BLFS machine with less than 4 cores and 2GB RAM per core (for things like rust and qtwebengine). Oh, my laptop has 8 cores but a pitiful amount of RAM (6.7GB according to top, some is used for the video) and on that I have to shut down almost everything and force rust and qtwebengine to use fewer cores when I rebuild those or firefox, and it is painful. For i686 I have no idea how much RAM is needed to build and maintain a BLFS *desktop* system. I assume you are using 32-bit for at least pi3. Out of interest, Which graphical browser do you build for your desktop ? ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] 9.1-systemd: NSS-3.55 build fails
On Sun, Aug 16, 2020 at 11:25:54AM -0500, Douglas R. Reno via blfs-support wrote: > > On 8/16/20 10:58 AM, Hans Malissa via blfs-support wrote: > > On August 16, 2020 at 6:27 AM, Xi Ruoyao via blfs-support > > wrote: > > > On 2020-08-16 02:27 +0100, Ken Moffat via blfs-support: > > > > Playing with CFLAGS does not always do what you expect (it depends > > > > on the individual packages as to whether you need to take special > > > > action to force your own CFLAGS, and trying to detune released > > > > packages seems like a bad idea. For the little it is worth, I did > > > > some experiments just over a year ago with the aim of forcing my own > > > > CFLAGS, CXXFLAGS and exploring some of the options. The results > > > > (basically one run of each variation, but with some upgrades along > > > > the way) were mostly inconclusive but somewhere in there are details > > > > of what I had to do to the packages I build to get them to obey my > > > > CFLAGS (or in some cases, to not use my optimization of -O2 or -O3) > > > > because some default to -O3 but will detune to -O2 if you pass that, > > > > and one some of my less-powerful machines I do generally use -O2. > > > > > > > > But the problem was in nss. I do not regard that as a large > > > > package, although it is a slow one when built using -j1. > > > > AFAICS building nss-3.55 less than 300 MB which should be trivial. > > > > > > Current version of NSS can be built with -jN. But I can tell that > > > the test > > > suite just fails with -O3. > > > > I followed the build with free from another terminal; the machine does > > indeed run out of memory (2GB on this system) during make. > > I temporarily added some swap space (on an external hard drive), and the > > build succeeded - building NSS needs ~1GB of swap on top of my 2GB. > > I'm planning to install NSS and remove the swap space again. Does the > > memory usage during the build have anything to do with memory usage > > during run-time? Will I be able to use NSS without the swap space? > > By the way, the test suite (following the instructions on > > http://linuxfromscratch.org/blfs/view/systemd/postlfs/nss.html ) > > reports: > > > > Tests summary: > > -- > > Passed: 54674 > > Failed: 2442 > > Failed with core: 0 > > ASan failures: 0 > > Unknown status: 8 > > TinderboxPrint:Unknown: 8 > > > > Is it safe to proceed with 2442 failed tests? > > Greetings, > > > > Hans > > > You should be safe to proceed. The NSS test suite is quite buggy, and it's > dependent on the contents of /etc/hosts as well as you passing > "HOST=localhost DOMSUF=localdomain". On that note, make sure that you have > the following line in /etc/hosts next time you run the tests: > > 127.0.0.1 localhost.localdomain localhost > > I think that was changed after the 9.1 release cycle. That allows the NSS > test suite to function properly. > > You should be OK, NSS should work perfectly without swap space. I think you > hit the memory ceiling when linking. You might want to invest in more RAM > though in the future, if at all possible. > > > - Doug > For a desktop machine, 2GB is woefully inadequate nowadays :-( (And if it is a server, nss might be an uncommon choice). ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] 9.1-systemd: NSS-3.55 build fails
On Sat, Aug 15, 2020 at 11:37:23PM +0200, Elias Rudberg via blfs-support wrote: > Hi Hans, > > > How can I verify whether I ran out of memory or not? > > That's something I would like to know also. I don't know how to do that. > > Some things you could try: > > - monitor the memory usage using "top" or similar, while the compilation is > going on > With modern versions of top, you may need to spend some time configuring it to your preferences, but you should be able to get it to show memory and swap at the bottom of the upper part of its display, below the CPU activity if that is being shown. Mine is configured to show the active processes (not the default 'tree' style), so when it is running with processes which use a lot of memory (graphical browsers, C++ compiles, rust compiles) I can see how much memory they are using. You can also use 'free' to get the memory/swap usage. On sysv I would look at dmesg to see if it mentioned an OOM (out of memory). If you are running systemd then 'journalctl -k' might show you the dmesg output (based on a quick google for systemd dmesg, not from experience, so could well be wrong). > - try to free up some memory and then try again, for example if you were > using a window manager you could try without that (boot to runlevel 3 or > something) > > - try to reduce the amount of memory it is using when compiling, for example > turn off parallel make (if that was used) and/or change compiler > optimization flags to use less optimizations, e.g. -O1 instead of -O2. > Playing with CFLAGS does not always do what you expect (it depends on the individual packages as to whether you need to take special action to force your own CFLAGS, and trying to detune released packages seems like a bad idea. For the little it is worth, I did some experiments just over a year ago with the aim of forcing my own CFLAGS, CXXFLAGS and exploring some of the options. The results (basically one run of each variation, but with some upgrades along the way) were mostly inconclusive but somewhere in there are details of what I had to do to the packages I build to get them to obey my CFLAGS (or in some cases, to not use my optimization of -O2 or -O3) because some default to -O3 but will detune to -O2 if you pass that, and one some of my less-powerful machines I do generally use -O2. But the problem was in nss. I do not regard that as a large package, although it is a slow one when built using -j1. AFAICS building nss-3.55 less than 300 MB which should be trivial. > - try in another computer that has more memory to see if it works there > > Hope this helps > > / Elias Another thought is that there might have been a RAM problem which caused g++ to be killed. Again, dmesg or equivalent might show what happened. If you got a segmentation fault on an LFS system, then either something was miscompiled using opcodes which are not available (has been known with e.g. gmp using its default configure scripts on low-end intel machines where some op-codes for the higher end versions of that generation were assumed by the gmp developers to be present in all models), or else there might be a memory fault. For the opcode issue, it seems unlikely that you would manage to complete LFS and then on the same machine hit this when trying to build NSS. But if you built LFS on one machine and then tried to run it on a different machine it could happen (e.g. I took a binary from an old LFS optimised for a Kaveri and eventually managed to get it working-enough to build LFS on a Ryzen+, but getting there was 'fun' with no guarantee of success). For memory problems, on a past x86_64 AMD machine (I think it was some sort of old phenom with 4 cores) I had a low-end motherboard and from time to time it would segfault if using -j4, or very occasionally it would segfault even on -j1 and need to be turned off for a while. I suspect that insufficient voltage in the RAM was the problem (someone else had similar results), but power supply issues, or cooling, can also do this. Beyond thant, memtest86 (or old unmaintained memtest86+ with the reservation that using all cores usually locks up). If RAM has gone bad (or is being run with too-optimistic settings) it usually shows up within a couple of passes. ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Problems with xine-lib on intel and amdgpu
On Fri, Aug 14, 2020 at 10:19:18AM -0500, Douglas R. Reno via blfs-support wrote: > > On 8/9/20 6:57 PM, Ken Moffat via blfs-support wrote: > > My second set of problems with video players ;) > > > > I know that xine has always been rather fragile, partly related to > > CFLAGS I use in oe of the dependencies - but a year ago those > > detined flags made it mostly work. With mov files and some of my > > own mkv and (old: fmpeg-0.7!) mp4 conversions it has tended to > > stutter (the picture jumps backwards). On downloads they usually > > play ok. > > > > With my current (late July build) on my haswell, almost everything > > that I try to play in xine crashes at startup. On my machine using > > radeon r600, my own mov files crash but everything else plays fine. > > On my machien with amdgpu, the mov files from my camera similarly > > crash, but everything else plays *until I use the xine control > > slider to move forward through the video* (I don't wish to spend > > hours looking at the files I'm using for testing). As soon as I > > touch the slider, xine crashes. > > > > Looking back at older systems, that behaviour with amdgpu was > > present in BLFS-9.1. > > > > I've now reverted the string of packages I mentioned in my post > > about parole (but again that has made no difference. > > > > Summary: For me xine (technically xine-ui) crashes on intel igpu, > > mostly works on radeon, works on amdgpu if I don't use the controls > > and let it play through. > > > > Again, I would be interested to hear of other people's successes. > > Note that one or two files (one commercial mov, two commercial wmv) > > do work with or without the reverts, other commercial wmv files > > crash. > > > > ĸen > > Hi Ken, > > > I wanted to let you know that I was able to get Xine to play > big_buck_bunny.mp4 properly on my Intel Skylake system (i5-6600k). I don't > have any .mov files or any .wmv files sitting around here that I can use > though, and I'm not sure converting would be much help here either. I did > also scrub through the video using the slider, and watched it to completion. > > I am using Mesa-20.1.5, with the Intel Iris driver that's built into Mesa > (newer Intel systems won't be able to use i965 properly, especially once the > Xe series of graphics cards comes out). FFMPEG-4.3.1 is in use too. The > current driver loaded on my system is "iris". I did see an error regarding > libvdpau_nvidia.so when starting though, but I don't think that's related. > As far as I can tell, I do have the latest version of the related packages > installed on this machine. > > Here is my console output: > > renodr [ /sources ]$ xine big_buck_bunny.mp4 > This is xine (X11 gui) - a free video player > v0.99.12. | > (c) 2000-2019 The xine Team. > Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object > file: No such file or direct > ory > libva info: VA-API version 1.8.0 > libva error: vaGetDriverNameByIndex() failed with unknown libva error, > driver_name = (null) > > > Is it possible that it could be permissions? My intel system here is a > systemd box. I am working on my elogind system at the moment to check on a > couple things, and it has a Radeon in it. I'll let you know how that works, > it's on my list to try next. > > > - Doug > Hi Doug. First, thanks for looking at this. I will be very surprised if permissions are involved, because I'm using the same scripts (different xorg video drivers, and the intel-specific va only on intel) on haswell (broken), radeon (ok), amdgpu (ok until I use the slider to scroll forward or back). ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Parole breakage on intel gpu.
On Fri, Aug 14, 2020 at 10:39:44AM -0500, Douglas R. Reno via blfs-support wrote: > > On 8/9/20 6:35 PM, Ken Moffat via blfs-support wrote: > > Two or three weeks ago I noticed a problem with parole on my latest > > build on my haswell (LFS from 25th July, BLFS from the next day). > > Whatever I try to view, the screen broken into horizontal stripes, > > rather like venetian blinds but with a mix of colours not apparently > > related to the video which should be visible. > > > > On a machine using radeon (R600-series) video, parole works fine. > > > > On my haswell, the following all work fine: ffplay, gst-play-1.0, > > vlc. > > > > Other things have, of course, got in the way, but I'm now ready to > > document what has changed between working and broken versions, and > > to ask for suggestions. > > > > Looking back at previous builds on this machine, a build in May was > > fine, the intermediate build in June showed the same problem. > > > > The following packages, and versions, are common to both the good > > and bad builds: running kernel 5.7.2, gcc-10.1.0, gstreamer-1.16.2, > > fdk-aac-2.0.1, freetype-2.10.2, lame-3.100, libtheora-1.1.1, > > libvorbis-1.3.7 (I upgraded older systems to that version), > > libvpx-1.8.2, opus-1.3.1, x264-20200218, yasm-1.3.0, libvdpau-1.4, > > libvdpau-va-gl-0.4.0, SDL2-2.0.12. > > > > Looking at what had changed: > > > > ffmpeg 4.2.2 on previous good systems, 4.3 and 4.3.1 on current. > > > > libva-2.7.1 on last working system and on June non-working, 2.8.0 on > > latest. > > > > x265 3.3 on working, 3.4 on latest (now reverted to 3.3, symlink > > fixed, gst-plugins-bad rebuilt) > > > > intel-vaapi-driver 2.4.0 on good, 2.4.1 on latest, now reverted to > > 2.4.0. > > > > xf86-video-intel 20200218 on good, 20200518 on latest, now reverted > > to 20200218. > > > > Before Bruce asks: I've used the same CFLAGS, CXXFLAGS throughout > > these builds. > > > > At this stage, this is just a request for suggestions, and a > > question whether parole is working on anyone's current intel > > machiens with integrated graphics ? > > > > TIA > > > > ĸen > > > I would say that I was able to get Parole working, but unfortunately I'm not > able to: > > [Current thread is 1 (Thread 0x7fb5315b2a00 (LWP 6876))] > (gdb) bt > #0 0x7fb5325379c2 in _XInternAtom > (dpy=dpy@entry=0x7fb524003ee0, name=name@entry=0x438f75 > "_NET_WM_WINDOW_OPACITY_LOCKED", onlyIfExis > ts=onlyIfExists@entry=1, psig=psig@entry=0x7ffedf8e53b8, > pidx=pidx@entry=0x7ffedf8e53b0, pn=pn@entry=0x > 7ffedf8e53b4) at IntAtom.c:76 > #1 0x7fb532537cfb in XInternAtom > (dpy=dpy@entry=0x7fb524003ee0, name=name@entry=0x438f75 > "_NET_WM_WINDOW_OPACITY_LOCKED", onlyIfExis > ts=onlyIfExists@entry=1) at IntAtom.c:175 > #2 0x0041f4f6 in parole_player_set_wm_opacity_hint > (widget=0x1a28510 [GtkWindow]) > at parole-player.c:3071 > #3 parole_player_init (player=0x1e98480 [ParolePlayer]) at > parole-player.c:3734 > #4 0x7fb5327d1571 in g_type_create_instance (type=) at > ../gobject/gtype.c:1867 > #5 0x7fb5327b8125 in g_object_new_internal > (class=class@entry=0x1a77ed0, params=params@entry=0x7ffedf8e56a0, > n_params=n_params@entry=1) > at ../gobject/gobject.c:1937 > #6 0x7fb5327b9bb4 in g_object_new_valist > (object_type=, > first_property_name=first_property_name@entry=0x438348 "client-id", v > ar_args=var_args@entry=0x7ffedf8e57e8) at ../gobject/gobject.c:2262 > #7 0x7fb5327b9f0c in g_object_new > (object_type=, > first_property_name=first_property_name@entry=0x438348 "client-id") > at ../gobject/gobject.c:1780 > #8 0x0042127e in parole_player_new (client_id=0x0) at > parole-player.c:3739 > #9 0x004182af in main (argc=, argv=) > at main.c:340 > (gdb) > > When I launch Parole, it crashes with a segmentation fault. This is on my > Intel system, with Mesa-20.1.5, gst-*-1.16.2 of course, and > libxfce4ui-4.14.1 with the rest of the stack. > > > I'm not sure what's causing this. > > Ken, you are able to get it to start at least without a segfault, right? > Yes. On elogind and i965. > I'll be building this on my elogind system later, will verify that it works > there. Maybe it's something with the Iris driver. I'll research how to back > down to i965 to see if I can fix it that way, but it's acting like its > elsewhere. > > > - Doug > Fun. ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Problems with xine-lib on intel and amdgpu
My second set of problems with video players ;) I know that xine has always been rather fragile, partly related to CFLAGS I use in oe of the dependencies - but a year ago those detined flags made it mostly work. With mov files and some of my own mkv and (old: fmpeg-0.7!) mp4 conversions it has tended to stutter (the picture jumps backwards). On downloads they usually play ok. With my current (late July build) on my haswell, almost everything that I try to play in xine crashes at startup. On my machine using radeon r600, my own mov files crash but everything else plays fine. On my machien with amdgpu, the mov files from my camera similarly crash, but everything else plays *until I use the xine control slider to move forward through the video* (I don't wish to spend hours looking at the files I'm using for testing). As soon as I touch the slider, xine crashes. Looking back at older systems, that behaviour with amdgpu was present in BLFS-9.1. I've now reverted the string of packages I mentioned in my post about parole (but again that has made no difference. Summary: For me xine (technically xine-ui) crashes on intel igpu, mostly works on radeon, works on amdgpu if I don't use the controls and let it play through. Again, I would be interested to hear of other people's successes. Note that one or two files (one commercial mov, two commercial wmv) do work with or without the reverts, other commercial wmv files crash. ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Parole breakage on intel gpu.
Two or three weeks ago I noticed a problem with parole on my latest build on my haswell (LFS from 25th July, BLFS from the next day). Whatever I try to view, the screen broken into horizontal stripes, rather like venetian blinds but with a mix of colours not apparently related to the video which should be visible. On a machine using radeon (R600-series) video, parole works fine. On my haswell, the following all work fine: ffplay, gst-play-1.0, vlc. Other things have, of course, got in the way, but I'm now ready to document what has changed between working and broken versions, and to ask for suggestions. Looking back at previous builds on this machine, a build in May was fine, the intermediate build in June showed the same problem. The following packages, and versions, are common to both the good and bad builds: running kernel 5.7.2, gcc-10.1.0, gstreamer-1.16.2, fdk-aac-2.0.1, freetype-2.10.2, lame-3.100, libtheora-1.1.1, libvorbis-1.3.7 (I upgraded older systems to that version), libvpx-1.8.2, opus-1.3.1, x264-20200218, yasm-1.3.0, libvdpau-1.4, libvdpau-va-gl-0.4.0, SDL2-2.0.12. Looking at what had changed: ffmpeg 4.2.2 on previous good systems, 4.3 and 4.3.1 on current. libva-2.7.1 on last working system and on June non-working, 2.8.0 on latest. x265 3.3 on working, 3.4 on latest (now reverted to 3.3, symlink fixed, gst-plugins-bad rebuilt) intel-vaapi-driver 2.4.0 on good, 2.4.1 on latest, now reverted to 2.4.0. xf86-video-intel 20200218 on good, 20200518 on latest, now reverted to 20200218. Before Bruce asks: I've used the same CFLAGS, CXXFLAGS throughout these builds. At this stage, this is just a request for suggestions, and a question whether parole is working on anyone's current intel machiens with integrated graphics ? TIA ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Odd test results from haveged
Putting together a fresh build, one of the things I install on this machines is haveged, because two years ago problems with entropy after using a SSD in a couple of machines led me to add it. Until now I've been building haveged on a couple of desktop machines which have integrated graphics and SSDs. On other lower-end machines with SSDs (Skylake i3, Ryzen3 with R600 video card) I did not have trouble (i.e. slow boots for e.g. unbound) so I don't build haveged on those. And I've been running its tests to get a warn feeling. In this build I've moved from haveged-1.9.11 to 1.9.13. For the first time ever, the tests failed (and therefore stopped my build). Test Results Sample: 16777216 bytes Entropy: 7.86 bits Chi-Square: 314.967041(0.619551%) Mean:127.527005 PI: 3.140198(-0.044392%) Correlation: -0.000550 Check Fail: chisqr:0.619551% not in 1.00-99.00 make[2]: *** [Makefile:573: check-local] Error 255 Apart from the Chi-Square result (over 300, tiny percentage) the results seemed on a par with previous results. Since I can't see any obvious reason for this failure, I thought I might let it go by using make -k check and adding '|| true' in my script. Ran and installed, the results were now ok ! Test Results Sample: 16777216 bytes Entropy: 7.88 bits Chi-Square: 287.206482(8.084906%) Mean:127.481261 PI: 3.142029(0.013892%) Correlation: 0.98 Sample looks good! Weird, and perhaps I'll stop running tests for haveged in future builds. Or perhaps I'll just stop building it, to see if still needed. Just thought I'd mention this as another example of "should I believe a testsuite ?" ;-) ĸen -- +++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++ - Hogfather -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] g++ (when including c++ standard headers) is not able to find c standard headers
On Sun, Jul 19, 2020 at 05:02:38PM +0100, Ken Moffat via blfs-support wrote: > On Sun, Jul 19, 2020 at 01:18:50PM +0200, Rielynd Mira wrote: > >That's interesting... > >What do you mean with "to add the missing headers"? As far as I can tell, > >all headers are there... > > Please do not top post. > > With C++ packages (and occasionally too with C) is that what used to s/is that/the problem is that/ > work may now break when the language changes. It might help if I mention that I saw this sort of problem a year or so ago when I tried to build libreoffice. That ships many packages we do not use in naything else , and one of them was broken by a change to the standard used by poppler. The actual error message in that case was deep in the build (even using -j1), but somebody had hit it in gentoo and the problem was ultimately caused by a newer version of poppler. Unfortunately, in that case the only practical workaround was to build an updated version of the package causing the problem (XMLSec1, I think) - until then we had not needed to build that separately. A later release of libreoffice pulled in the fixed version so that it no longer needed to be built separately. But after that, ISTR that another package I build later had a somewhat similar error message and I applied a similar include of one of more C++ headers (*not* C headers!) to whatever was the eventual upstream fix for XMLSec1. ĸen -- +++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++ - Hogfather -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] g++ (when including c++ standard headers) is not able to find c standard headers
On Sun, Jul 19, 2020 at 01:18:50PM +0200, Rielynd Mira wrote: >That's interesting... >What do you mean with "to add the missing headers"? As far as I can tell, >all headers are there... Please do not top post. With C++ packages (and occasionally too with C) is that what used to work may now break when the language changes. >And yep, the exact same source folder failed to compile a day later. >I literally just did a 'make clean' and 'make'. That worked out somehow. >And yeah, I'm quite baffled about that as well.. I have no idea what the >reason for that could be. >I literally just got the idea of recompiling glibc because the only thing >I found regarding that problem I have is that "something with your gcc >might be completely wrong" or "glibc may be at fault". If I rephrase that as "the *standard* implied by you gcc or g++ version is no-longer adequate", perhaps you will understand the problem better. You have not specified which package(s) are affected, nor the errors which resulted. If something used to compile in the past, but now does not, changes in the language standard are often the cause. >No idea... >Funny enough, recompiling and reinstalling glibc worked out without any >kind of crash or hang You were lucky ;-) >10:03 PM, July 16, 2020, "Ken Moffat via blfs-support" >: > > On Thu, Jul 16, 2020 at 09:00:19AM +0200, Rielynd Mira via blfs-support > wrote: > >Hi there, found something extremely weird yesterday. > >When trying to build C++ programs/files, I sometimes get errors >like that: > >/usr/include/c++/10.1.0/cstdlib:75:15: fatal error: stdlib.h: No >such file >or directory >75 | #include_next > >That just appears to happen when including something like >; if I >include the C headers directly, it works fine. > > > I think I've seen similar failures when using a newer version of gcc > (or clang), and maybe also when using a newer version of glibc. > > In each case, the fix has been to add the missing header(s). That's > one of the reasons I hate it when packages or tools change their > default c++ standard, and I have to hope that someone else has > already fixed the packages, and that google can find the fix. > >The main thing that's weird about it: >Yesterday, after I tried out recompiling gcc, everything worked >just fine. >Program built and ran. Though, literally right after I woke up >today, it >didn't work anymore. > > You appear to be saying that the *same* source which compiled > yeaterday no longer compiles today on the same system ? > > A more normal situation would be: yesterday I built several > programs, and of those I had to fix 'foo'. Today I'm getting a > similar problem in 'bar'. That is normal. > >I also tried it with recompiling glibc, which resulted in exactly >the same >thing, and I tried using the '-I' and '-isystem' switches, which >do >absolutely nothing... > >gcc's include search path, glibc's version and 'ldconfig -v' >output from >my system is here: >https://pastebin.com/3qKtNkC8 > >LFS Version I used: Version 20200707-systemd >BLFS Version I used: Version 2020-07-14 - systemd > >I hope that someone is able to help me here to at least understand >what I >did wrong... if anything. > >Thank you. > > Recompiling glibc in case it fixes the problem seems like a > dangerous idea unless you have reason to believe that something > specific in your glibc build was wrong - you will generally need to > reboot after recompiling glibc, and the shutdown can be very unclean > (i.e. the system can hang). > > ĸen > > -- > +++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++ > - Hogfather > -- > http://lists.linuxfromscratch.org/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > >-- >Sent from Yandex.Mail for mobile -- +++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++ - Hogfather -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] g++ (when including c++ standard headers) is not able to find c standard headers
On Thu, Jul 16, 2020 at 09:00:19AM +0200, Rielynd Mira via blfs-support wrote: >Hi there, found something extremely weird yesterday. > >When trying to build C++ programs/files, I sometimes get errors like that: > >/usr/include/c++/10.1.0/cstdlib:75:15: fatal error: stdlib.h: No such file >or directory >75 | #include_next > >That just appears to happen when including something like ; if I >include the C headers directly, it works fine. > I think I've seen similar failures when using a newer version of gcc (or clang), and maybe also when using a newer version of glibc. In each case, the fix has been to add the missing header(s). That's one of the reasons I hate it when packages or tools change their default c++ standard, and I have to hope that someone else has already fixed the packages, and that google can find the fix. >The main thing that's weird about it: >Yesterday, after I tried out recompiling gcc, everything worked just fine. >Program built and ran. Though, literally right after I woke up today, it >didn't work anymore. You appear to be saying that the *same* source which compiled yeaterday no longer compiles today on the same system ? A more normal situation would be: yesterday I built several programs, and of those I had to fix 'foo'. Today I'm getting a similar problem in 'bar'. That is normal. >I also tried it with recompiling glibc, which resulted in exactly the same >thing, and I tried using the '-I' and '-isystem' switches, which do >absolutely nothing... > >gcc's include search path, glibc's version and 'ldconfig -v' output from >my system is here: >https://pastebin.com/3qKtNkC8 > >LFS Version I used: Version 20200707-systemd >BLFS Version I used: Version 2020-07-14 - systemd > >I hope that someone is able to help me here to at least understand what I >did wrong... if anything. > >Thank you. Recompiling glibc in case it fixes the problem seems like a dangerous idea unless you have reason to believe that something specific in your glibc build was wrong - you will generally need to reboot after recompiling glibc, and the shutdown can be very unclean (i.e. the system can hang). ĸen -- +++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++ - Hogfather -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Trying to tame rustc compiles
On Tue, Jun 30, 2020 at 12:04:25AM +0100, Ken Moffat via blfs-support wrote: > For a long time I've been annoyed when building rustc because it > thinks it owns the machine and will schedule one job per CPU. On a > reasonably-well specified machine that is only being used for > compiling rust that is not too much of a problem. > > But on lesser machines (such as the laptop where I'm writing this > while building rusts - 8 cores, 6.7GB RAM according to 'top' because > some is used for the graphics), or where you are trying to use a > graphical browser or do other things, at best the desktop can become > unresponsive from time to time, at worst it might swap badly and > become very unresponsive. > > Until now, the only solution for minimising swap that I have found > was to take cores offline. But it turns out that rust, or rather > cargo, has now been adapted to use -j or --jobs like 'make'. > The bast that I can find for that is that it only works for packages > which use cargo to build them (e.g. cbindgen, perhaps librsvg). > > Unfortunately, for building rustc itself that approach does not > work. Putting --jobs in the RUSTFLAGS is not recognized. > Exporting it in CARGOFLAGS is recognized, but after a few minutes > rust fails with: > > running: > "/scratch/working/rustc-1.42.0-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" > "build" "-Zconfig-profile" "--target" "x86_64-unknown-linux-gnu" "--jobs" > "4" "-Zbinary-dep-depinfo" "-j" "8" "-v" "--release" "--features" > "panic-unwind backtrace compiler-builtins-c" "--manifest-path" > "/scratch/working/rustc-1.42.0-src/src/libtest/Cargo.toml" "--message-format" > "json-render-diagnostics" > error: The argument '--jobs ' was provided more than once, but cannot be > used multiple times > > USAGE: > cargo build --features ... --jobs --manifest-path > --message-format ... --release --target -Z ... --verbose > > However, there seemed to be a partial solution. Googling for this > sort of rust problem is doubly hard - mismatches for a rust game and > for corrosion on iron and steel, but the worse problem is they > expect people to use rustup for the binary, therefore almost all > compile questions are about persuading it to use *more* CPU. But I > eventually I found a page showing the available options for ./x.py > and there it mentioned --jobs . > > With that, I've got all cores of this laptop online using --jobs 4 > and although at times more than 4 C++ jobs seemed to be active in > 'top', the loadavg was around 4 to 5 (with 'top' and other terms > also active. The box was very quickly into swap, and reached 0.7GB > swap usage. > > Unfortunately, now the main rust compilations have started, up to 8 > jobs are running at a time and the system is marginally unresponsive > although not using any more swap. /me swears, I thought I'd cracked > this. Perhaps the envvar CARGO_BUILD_JOBS=4 might help (I tried > that and then discarded it when I saw 8 C++ jobs running). > > Hmm, swap is now up to 2.0GB - not yet sorted, but perhaps a step > on the way. And no, I'm not going to stop this compile to see if > the envvar is accepted - I'll wait until I've got tiem to try that > on a faster machine :) > That was, as stated, on an underspecified machine and also the output was logged rather than dumped on the screen - so I had to rely on what top showed me. Today I've been manually building on an 8-core desktop with an adequate amount of memory, and watching both the output and top. I mention that because almost everything seemed to be rust, C++ jobs hardly showed up. But anyway: With a combination of '--jobs 4' on each invocation of x.py AND exporting CARGO_BUILD_JOBS=4 the build was mostly limited to 4 cores. The exception was running the tests - some of these obeyed the restriction, others still used all cores. For most purposes, and particularly for compiling rustc on a machine without enough RAM, or for running other CPU-intensive jobs while compiling rustc, this approach seems to be good enough. I've updated the developmetn book. ĸen -- He died at the console, of hunger and thirst. Next day he was buried, face-down, nine-edge first. - the perfect programmer -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Trying to tame rustc compiles
For a long time I've been annoyed when building rustc because it thinks it owns the machine and will schedule one job per CPU. On a reasonably-well specified machine that is only being used for compiling rust that is not too much of a problem. But on lesser machines (such as the laptop where I'm writing this while building rusts - 8 cores, 6.7GB RAM according to 'top' because some is used for the graphics), or where you are trying to use a graphical browser or do other things, at best the desktop can become unresponsive from time to time, at worst it might swap badly and become very unresponsive. Until now, the only solution for minimising swap that I have found was to take cores offline. But it turns out that rust, or rather cargo, has now been adapted to use -j or --jobs like 'make'. The bast that I can find for that is that it only works for packages which use cargo to build them (e.g. cbindgen, perhaps librsvg). Unfortunately, for building rustc itself that approach does not work. Putting --jobs in the RUSTFLAGS is not recognized. Exporting it in CARGOFLAGS is recognized, but after a few minutes rust fails with: running: "/scratch/working/rustc-1.42.0-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "-Zconfig-profile" "--target" "x86_64-unknown-linux-gnu" "--jobs" "4" "-Zbinary-dep-depinfo" "-j" "8" "-v" "--release" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/scratch/working/rustc-1.42.0-src/src/libtest/Cargo.toml" "--message-format" "json-render-diagnostics" error: The argument '--jobs ' was provided more than once, but cannot be used multiple times USAGE: cargo build --features ... --jobs --manifest-path --message-format ... --release --target -Z ... --verbose However, there seemed to be a partial solution. Googling for this sort of rust problem is doubly hard - mismatches for a rust game and for corrosion on iron and steel, but the worse problem is they expect people to use rustup for the binary, therefore almost all compile questions are about persuading it to use *more* CPU. But I eventually I found a page showing the available options for ./x.py and there it mentioned --jobs . With that, I've got all cores of this laptop online using --jobs 4 and although at times more than 4 C++ jobs seemed to be active in 'top', the loadavg was around 4 to 5 (with 'top' and other terms also active. The box was very quickly into swap, and reached 0.7GB swap usage. Unfortunately, now the main rust compilations have started, up to 8 jobs are running at a time and the system is marginally unresponsive although not using any more swap. /me swears, I thought I'd cracked this. Perhaps the envvar CARGO_BUILD_JOBS=4 might help (I tried that and then discarded it when I saw 8 C++ jobs running). Hmm, swap is now up to 2.0GB - not yet sorted, but perhaps a step on the way. And no, I'm not going to stop this compile to see if the envvar is accepted - I'll wait until I've got tiem to try that on a faster machine :) ĸen -- He died at the console, of hunger and thirst. Next day he was buried, face-down, nine-edge first. - the perfect programmer -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Updating firefox
This is just a heads up for anyone using firefox. The firefox-78.0esr release should be available on Monday, meanwhile I've been building what I hope is the last release candidate on my systems. The obvious big gotcha for 78.0 is the need to update to rustc-1.42.0. If you are not using currnet llvm, that means building rustc-1.42.0 with its shipped llvm - I think I've covered that adequately in the wiki entry for rustc (using system llvm with old llvm used to build, but failed its tests catastrophically). However, the real problem is node-js. For 78.0 the minimum required version is 10.19.0. In BLFS-9.0 and earlier we had older versions, and those worked with the firefox-68esr series. For BLFS-9.0 and BLFS-8.4 I have now managed to build node-v10.21.0 using CC=clang CXX=clang++ with CFLAGS="$CFLAGS -std=c11" and CXXFLAGS="$CXXFLAGS -std=c++14". On 9.0, firefox-78.0esr has built, on 8.4 firefox is still building. However, on BLFS-8.3 I have not managed to compile a suitable version of node-js. My intention was to stop updating 8.3 from July (2 years after the release, plus time for users to actually build the release), so arguably my 8.3 system has expired slightly earlier than planned. With 8.3, clang failed with undefined variable erorrs. I then tried gcc, that told me that deduced return type need c++14 or gnu++14. So I tried gcc with c++14, but rthat failed with c++ scope errors (which was the original problem with node-v12.). I think that firefox-68esr will be updated to .10, and then to .11 and 12 after another 4 weeks and 8 weeks. if anyone is using firefox on a system with such an old toolchain, I suggest that you stick with 68esr and prepare to upgrade the whole system to something newer. ĸen -- He died at the console, of hunger and thirst. Next day he was buried, face-down, nine-edge first. - the perfect programmer -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Microcode on skylake - request for success/failure reports
Intel released fresh microcode on 20200609 to provide mitigation for the SRBDS vulnerability, and this week's kernel releases list Mitigation: Microcode for srbds on affected machines with that microcode. But on Monday Pierre made me aware that there were issues on some Skylake machines (06-4e-03) - issue 31 at https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues so I put a Caution on the firmware page. Meanwhile, my own 06-5e-03 skylake was fine with that release. But yesterday Intel released a 20200616 version which reverts both sets of Skylake microcode to the old (0xd6) version. For the moment, my gut feeling is that, at least on 06-5e-03, the 20200609 microcode is good. But I have exactly one machine like that (running sysvinit) and no 06-4e-03 machines. Looking at issue 31, it seems likely that the reporters were all running systemd. I cannot think of any logical reason why systemd should cause early-boot hangs with the updated microcode, but to try to get towards the bottom of this I'd like to hear from anyone with a Skylake who has updated to the 20200609 firmware: Which variant (triplet), was early-loading successful, are you using sysvinit or systemd ? Thanks ĸen -- So it's not 'I think, therefore I am', it's 'The computer thinks, therefore I think I am'. I've never actually thought about that before. -- Rimmer (a hologram), Red Dwarf, 'The Promised Land' -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] polkit update in BLFS Dev
On Fri, Jun 12, 2020 at 09:44:34AM -0500, Bruce Dubbs via blfs-support wrote: > On 6/12/20 3:34 AM, Ivan Wagner via blfs-support wrote: > > Hello, > > > > I'm using BLFS Dev and the Change Log says polkit was updated to allow > > the use of js68 and calls the new version polkit-32450615. Where did > > this new version come from? Because I don't see this version on the > > polkit gitlab page and there was no BLFS ticket for this update. > > It is in merge request 25. 32450615 is the commit ID. > > -- Bruce > merge request 148, I think https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/48 and no, it does not appear to have been merged yet. But it seems to work fine, although moving to JS68 doesn't seem to allow us to get rid of python2 for this. ĸen -- +++ OUT OF CHEESE ERROR. REDO FROM START +++ -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] OpenSSH
On Sat, Jun 06, 2020 at 01:25:31AM +0300, Greekforce1821 via blfs-support wrote: > Good evening gentlemen, I created an ssh server in my BLFS system (still > using terminal without having a GUI). When I boot my system the SSH server > starts but, when I use the PuTTY to connect an error message (Connection > Refused) pops up. I double-checked my credentials (IP addresses, gateway, > broadcast etc.) but still I haven't figured it out any solution. Can you > help? Two thoughts: 1. The book's configuration for openssh prevents connecting as root, you need to login as a regular user when using openssh. 2. Maybe your firewalling (iptables, etc) - if that is the case, you should see output in the logs, and you will then need to change the settings to permit the access - a fun job, with risks of adding too much access. ĸen -- +++ OUT OF CHEESE ERROR. REDO FROM START +++ -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Firefox-68 crashes
On Thu, Jun 04, 2020 at 03:26:12PM -0400, Richard via blfs-support wrote: > On 6/2/20 4:06 PM, Ken Moffat via blfs-support wrote: > > On Tue, Jun 02, 2020 at 02:57:22PM -0400, Richard via blfs-support wrote: > > First to respond to some of the suggestions: > > I have tried running firefox without any add-ons or extensions > and still have the above-reported errors. > ok > I am not running kde, I am using twm in X. > Apart from me saying "rather you than me" that shouldn't be a problem. > Here are outputs from df and free while I am running firefox: > > rkm:~$ free > total used free shared buff/cache > available > Mem: 889512 137036 516740 8028 235736 726792 > Swap: 1959892 0 1959892 > rkm:~$ df -h > Filesystem Size Used Avail Use% Mounted on > /dev/root 32G 7.6G 23G 26% / > tmpfs 435M 1.4M 433M 1% /run > devtmpfs 435M 0 435M 0% /dev > /dev/sdb8 42M 9.7M 30M 25% /boot > tmpfs 435M 0 435M 0% /sys/fs/cgroup I note you don't have /run/user/ where is your user number. In that directory on a system where firefox is running I I have directories for dbus-1 and pulse. I know that pulse is the default in firefox, but perhaps only started when firefox manages to find someting to play. But I'm surpried by the lack of the dbus-1 directory, since dbus is needed for elogind (and has always been needed for systemd). > > Here is also output from ps -aux related to firefox: > > rkm 653 11.1 24.6 614620 219564 pts/0 Sl 14:52 0:28 firefox > rkm 737 0.2 0.0 0 0 pts/0 Zl 14:52 0:00 [Web > Content] > rkm 764 0.2 0.0 0 0 pts/0 Zl 14:52 0:00 > [WebExtensions] > rkm 801 0.2 0.0 0 0 pts/0 Zl 14:52 0:00 [Web > Content] > > (I don't recall seeing the last 3 entries in earlier blfs versions where > firefox was working). > On my machines the Web Content entries have been present for a long time. Apparently this was part of what they called 'electrolysis' (or e10s) - if you are able to use a browser, details at https://support.mozilla.org/en-US/kb/performance-settings and has apparently been around since the later firefox-5N versions : https://wiki.mozilla.org/Electrolysis. But I suppose it only shows up if you regularly use top: I do that often while I'm running builds. > I am not running firefox as root. The installed binary is owned > by root, but the files have read and execute privileges for all > users. I don't understand why the above output referred to > /root/.mozilla/firefox/Crash. > > I also found something interesting. The last blfs version that I built > was blfs-8.4, and in that version I installed the pre-compiled > firefox-67.0.4. I've used blfs-8.4 and firefox-67.0.4 for > several months without any problems. Today I tried to install the > same binary, firefox-67.0.4, in my blfs-9.1 build, which is where > the firefox-68 binary versions are crashing. I found that I have > the same problems with firefox-67.0.4 in blfs-9.1. Therefore it > seems that there is something about my blfs-9.1 installation that > has precipitated these crashes, and not something introduced in > firefox-68. > 8.4 was released on March 1st last year, there has been a vast amount of change since then. In any case, if you are using the system while conencted to the web then you really should look at the errata online (yes, I understand that doing that from your 9.1 system may be impractical, but f you have another system - or later, when this system is working - you should check from time to time. If you were still using 8.4, you would need to look at errata for 8.4, 9.0 and 9.1 because we only update them for the current release. The problem for people who only build LFS/BLFS irregularly is that a great many things change over the years, and I suppose it is possible that you missed something - see my comments below re strace (and if you install that, use the current version - at times over the past couple of years the release has not built with current linux headers). > I have several crash reports that were generated by firefox. Is > there a way to read them? I tried about:crashes but that only > allows you to submit crash reports, which I can't do because > firefox crashes so much. According to mozilla docs (which might be out of date), the popup window should also allow you to click on 'Details' to open the 'Report Contents' window. It also says: | If you can't use the above method because Firefox crashes when it | starts, you can also view the reports in files on your computer with | the following steps: | | Crash reports are stored in ~/.mozilla/firefox/Crash Reports/ | | T
Re: [blfs-support] Firefox-68 crashes
On Tue, Jun 02, 2020 at 09:06:54PM +0100, Ken Moffat via blfs-support wrote: > On Tue, Jun 02, 2020 at 02:57:22PM -0400, Richard via blfs-support wrote: > > > > A lot in google (not all necessarily for firefox), on a quick glance > the main suspects seem to be X11 forwarding and add-ons or extensions. > > > 2020-05-31 14:32:50: minidump.cc:1571: ERROR: MinidumpThread has a memory > > region problem, 0xbf712e60+0x0, RVA 0x0x338 > > And for that, no obvious common features except that restarting > without add-ons and extensions is again suggested. Oh, and some > instances where people were running kde as their desktop. > [...] > > Hmm, you're trying to run it as root ? If the X session is owned by > your regular user, you can't do that. And running X as root, except > (perhaps) for initial testing on a new build, is a bad idea. > A couple of further thoughts - I've assumed you have installed at lease _some_ TTF or OTF fonts, but I just took a look at how Arch are building 77.0 (to see if there is anything I might want to look at in their options when I try to build 78). I noticed that they depend on some TTF font package or metapackage. Since from time to time we get people who only install the antique legacy fonts, I thought I'd better mention this. More likely, try starting firefox from the command-line with 'firefox -P' and create a new profile for testing. After that, when it works you can use the same option to start it and select which profile to use. On one of my machines I have both old-ESR and newer profiles, and two versions of firefox - on that machine, firefox itself asks which profile to use, and defaults to the appropriate one. ĸen -- +++ OUT OF CHEESE ERROR. REDO FROM START +++ -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Firefox-68 crashes
On Tue, Jun 02, 2020 at 02:57:22PM -0400, Richard via blfs-support wrote: > > I have tried both firefox-68.5.0 and firefox-68.8.0 > in blfs-9.1, and both of them are unusable because > they crash at startup. Unfortunately I have to use > the pre-compiled versions because my system is > no longer capable of building firefox, but I have > done this in past versions without any problems. Yeah, been there in the past - but at least you don't spend hours compiling it (although I'm not exactly sure that a non-working binary actually counts as an improvement). > Since I am not building firefox I guess I can't > really expect much help, but I thought I would > just list the typical output I get at startup -- I am > hoping someone has maybe seen similar output > and can suggest what might be the problem. > Also, any suggestions how I might troubleshoot > the problem would be helpful. > I get many lines like the following at startup: > > [Parent 757, Gecko_IOThread] WARNING: pipe error (68): Connection reset by > peer: file > /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, > line 358 > [Parent 757, Gecko_IOThread] WARNING: pipe error (79): Connection reset by > peer: file > /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, > line 358 > A lot in google (not all necessarily for firefox), on a quick glance the main suspects seem to be X11 forwarding and add-ons or extensions. > 2020-05-31 14:32:50: minidump.cc:1571: ERROR: MinidumpThread has a memory > region problem, 0xbf712e60+0x0, RVA 0x0x338 And for that, no obvious common features except that restarting without add-ons and extensions is again suggested. Oh, and some instances where people were running kde as their desktop. But for both, many of the reports are quite old (I think the newest I looked at was for firefox-71 which is at least 6 months ago). Of course, if you don't have any other systems or graphical browsers then searching in google or duckduckgo is quite problematic. > 2020-05-31 14:32:50: minidump_processor.cc:255: ERROR: No memory region for > /root/.mozilla/firefox/Crash Hmm, you're trying to run it as root ? If the X session is owned by your regular user, you can't do that. And running X as root, except (perhaps) for initial testing on a new build, is a bad idea. > Reports/pending/67ce34e7-0dcd-9d48-1162-302034561b57.dmp:0/13 id 0x31c > 2020-05-31 14:32:50: stackwalker_x86.cc:631: ERROR: Can't get caller frame > without memory or stack > I expect that last error is because everything has already fallen over. Like compilation failures: the first error matters, later errors may be irrelevant and/or misleading. More generally, if you have to use the binary then once you get it working I suggest you use the latest 'stable' release (e.g. as of today that would be 77.0). When I used to use the binary on my old 32-bit netbook ISTR that it would download a new version within a few days of a release. The only reason we're using ESR in BLFS is to keep the same version of rustc for all packages that use rust (cbindgen, firefox, librsvg, seamonkey, thunderbird). Good luck. ĸen -- +++ OUT OF CHEESE ERROR. REDO FROM START +++ -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Odd build failure with Jinja2
On Fri, May 29, 2020 at 01:41:36AM +0100, Ken Moffat via blfs-support wrote: > > I think the problem is that for some reason easy_install decides > that MarkupSafe is needed (it never used to be, for python2) and > picks a current version which does not support python3. > While I was creating the ticket, I looked a bit further - my memory was incorrect, in BLFS-9.1 MarkupSafe-1.1.1 did get installed by Jinja-2.11.1. So, theoretically it is needed, but qtwebengine manages to build without it. Perhaps python-2.7.18 broke something. I've created #13590, for the moment the text, and indeed the addition of '|| true', are up for discussion so I have not yet taken ownership. ĸen -- Do you not know that, what you belittle by the name tree is but the mere four-dimensional analogue of a whole multidimensional universe which - no, I can see you do not. -- Druellae (a Dryad) -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Odd build failure with Jinja2
On Sat, May 09, 2020 at 11:56:05PM +0100, Ken Moffat via blfs-support wrote: > On Sat, May 09, 2020 at 10:56:46AM +, Tom Willhite via blfs-support wrote: > > > > From: blfs-support on > > behalf of Ken Moffat via blfs-support > > > > Sent: Thursday, May 7, 2020 9:29 PM > > To: blfs-support@lists.linuxfromscratch.org > > > > Cc: Ken Moffat > > Subject: [blfs-support] Odd build failure with Jinja2 (now ok):wq > > > > > I _thought_ I had deleted the files installed from the failed > > Python2 build, but apparently I didn't. I then built Jinja2 for > > Python3, and let my script continue, expecting qtwebengine to fail - > > but that succeeded and falkon has now been built and is working. > > So, it seems that the previous 2.7 install was ok (even though it > > failed). > > > > - - - > > > > I've now tried a manual build, and installed to a DESTDIR equivalent > > using > > python2 setup.py install --root /tmp/JINJA2 > > and that completed ok. > > > I can confirm Jinja in blfs-sysd book is broke for the python2 version. V3 > > builds/installs. Same invalid syntax error as you posted Ken. > > I'll chk back since I'd like it for qtwebengine but I think that builds ok > > regardless of this error. > > > > Archetech > > Hi Tom, > > that is very interesting. I assumed the alpha version of MarkupSafe > was the problem (probably never tested on a system with python2) and > that it happened to have been removed, which was why my later manual > build worked. But maybe there is again a newer version. > > Because I had NOT removed the 2.7 egg which did get installed, I > think that was used by qtwebengine. > > That implies that for future builds Python2 Jinja is still needed, > but might crap out in the later stages of the install - if so, not a > problem. In other words, maybe add ' || true' to the Python2 > install and mark it down as collateral damage from the > discontinuation of that version. > > But I don't know how pip works (maybe it uses mirrors, and if so thy > might lag behind by a day or two). > > I'll bear this in mind, but I don't expect to be building > qtwebengine on a fresh system for several weeks (and if 5.15 is > released and I upgrade my existing systems I won't bother updating > Jinja2). > I'm now running a new build (trying the cross-chap5 LFS branch) and got as far as Jinja about 24 hours ago. The exact same failures in the python2 install, which ended in error. Unfortunately, I overwrote that log by allowing the py2 install to fail - but it was definitely trying to install MarkupSafe in the 2.7 python site-packages. I'd forgotten about this, semes like much more than 3 weeks ago. So, at the moment all I know is that it *sometimes* fails when trying to install MarkupSafe in the 2.7 site-packages. This is the last version of Jinja2 to support Python2, so trying to debug it seems a waste of time. I think the problem is that for some reason easy_install decides that MarkupSafe is needed (it never used to be, for python2) and picks a current version which does not support python3. In my own scripts (designed to error if a non-zero status is unexpectedly encountered) I have added ' || true' to the pythin2 install command. For the book, to support automation such as jhalfs I think we need the same, with a Note above it that "Sometimes the python2 install tries to install the incompatible and unnecessary current version of MarkupSafe, and fails. As long as the files in /usr/lib/python2.7/site-packages/Jinja2-2.11.2-py2.7.egg/jinja2 have been installed, the install will be adequate for QtWebengine." I'll create a ticket. ĸen -- Do you not know that, what you belittle by the name tree is but the mere four-dimensional analogue of a whole multidimensional universe which - no, I can see you do not. -- Druellae (a Dryad) -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Problem building glib-2.62.4
On Wed, May 13, 2020 at 11:09:08PM +0100, Ken Moffat via blfs-support wrote:
>
> In this case, your build *needs* the library from dbus.
>
> I have no idea whether that is nowadays always true, in which case
> we need to correct the book, or whether it is a result of e.g. which
> dependencies are present. What I can tell you is nowadays almost
> everyone will install dbus before glib.
>
I repeat that almost everyone who builds glib will want to build
dbus before building glib, and hopefully the build order I posted
earleir might be useful. But I grepped for dbus in the current
glib source and among many irrelevant results were the following:
./gio/tests/meson.build:# Check for libdbus1 - Optional - is only used in the
GDBus test cases
./gio/tests/meson.build:# 1.2.14 required for dbus_message_set_serial
./gio/tests/meson.build:dbus1_dep = dependency('dbus-1', required : false,
version : '>= 1.2.14')
./gio/tests/meson.build:if not dbus1_dep.found()
./gio/tests/meson.build: dbus1_dep = cc.find_library('dbus-1d', required :
false)
./gio/tests/meson.build: dbus1_dep = cc.find_library('dbus-1', required :
false)
So it appears that dbus is still optional as far as glib is
concerned, so the book is correct in marking it as optional.
ĸen
--
See You Later, Holy Poppadom!
-- Red Dwarf, The Promised Land
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] Problem building glib-2.62.4
On Wed, May 13, 2020 at 01:40:58PM -0400, Richard via blfs-support wrote: > I am stuck at the first phase of building glib-2.62.4 > in blfs-9.1 (i.e. the first compilation before installing > desktop-file-utils-0.24 and shared-mime-info-1.15 > in order to do the tests). I applied both patches and > followed the instructions in the blfs-9.1 book. Here > is the output I get after issuing the "ninja" command: > > rkm:/sources/glib-2.62.4/build$ ninja > [775/1157] Linking target gio/tests/gdbus-serialization. > FAILED: gio/tests/gdbus-serialization > cc -o gio/tests/gdbus-serialization > 'gio/tests/bcb7ac7@@gdbus-serialization@exe/gdbus-serialization.c.o' > 'gio/tests/bcb7ac7@@gdbus-serialization@exe/gdbus-tests.c.o' -Wl,--as-needed > -Wl,--no-undefined -Wl,--start-group glib/libglib-2.0.so.0.6200.4 > gmodule/libgmodule-2.0.so.0.6200.4 gobject/libgobject-2.0.so.0.6200.4 > gio/libgio-2.0.so.0.6200.4 -pthread -ldbus-1 -Wl,--end-group > '-Wl,-rpath,$ORIGIN/../../glib:$ORIGIN/../../gmodule:$ORIGIN/../../gobject:$ORIGIN/..' > -Wl,-rpath-link,/sources/glib-2.62.4/build/glib > -Wl,-rpath-link,/sources/glib-2.62.4/build/gmodule > -Wl,-rpath-link,/sources/glib-2.62.4/build/gobject > -Wl,-rpath-link,/sources/glib-2.62.4/build/gio > /usr/bin/ld: cannot find -ldbus-1 ^^ > collect2: error: ld returned 1 exit status > [776/1157] Compiling C object 'gio/tests/bcb7ac7@@file@exe/file.c.o'. > ninja: build stopped: subcommand failed. > Whenever you get a failed build while trying to build a package, you should assume that you will not be able to install it (there may occasionally be exceptions). In this case, your build *needs* the library from dbus. I have no idea whether that is nowadays always true, in which case we need to correct the book, or whether it is a result of e.g. which dependencies are present. What I can tell you is nowadays almost everyone will install dbus before glib. Before the sysv book moved to using elogind to enable rootless Xorg, I can remember that I used to build glib after I'd got Xorg working, but even then I built dbus a couple of packages before I built glib. For current sysv I build glib on the way to building Xorg. Some of the order in which I build things. freetype fontconfig XML-Simple xorgproto libXau, libXdmcp, xcb-proto, libxcb dbus and its bootscript elogind and the PAM files (I've already built PAM before this) xtrans ... libxshmfence dbus, second time xcb-util* pixman libdrm [ some Python stuff for Sphinx ] llvm libvdpau wayland Mako wayland-protocols libva Mesa libva second build (might not be necessary) glu xbitmaps iceauth some of the Xorg applications xcursor-themes sometimes, enough of the legacy fonts: font-util, font-alias, bdftopcf, font-adobe-100dpi If you use xterm, I guess you will want these. xkeyboard-config libepoxy And now: glib. Since I've started listing my build, I'll contine - gobject-introspection autoconf-1.23 zip nspr JS60 polkit xorg-server mtdev libevdev libinput xf86-input-libinput Then the video driver (for me, amdgpu or ati or intel) If intel, libva-intel-driver xcalc xclock xinit Here, I build rxvt-unicode, if you follow the book you'll want xterm and its dep. (Now I do the createfiles part and configure my keyboard to my own desires) After this, some useful fonts. At a minimum: dejavu freefont liberation-fonts Now, my initial WM (I cannot get on with twm!) fluxbox I also rebuild links so it will work in X (I built it long before this, along with most of the graphics libs). And after that, I reboot to find out whether elogind is working (if it isn't, no mouse or keyboard in Xorg, need to power cycle). ĸen -- See You Later, Holy Poppadom! -- Red Dwarf, The Promised Land -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Odd build failure with Jinja2 (now ok):wq
On Sat, May 09, 2020 at 10:56:46AM +, Tom Willhite via blfs-support wrote: > > From: blfs-support on > behalf of Ken Moffat via blfs-support > > Sent: Thursday, May 7, 2020 9:29 PM > To: blfs-support@lists.linuxfromscratch.org > > Cc: Ken Moffat > Subject: [blfs-support] Odd build failure with Jinja2 (now ok):wq > > I _thought_ I had deleted the files installed from the failed > Python2 build, but apparently I didn't. I then built Jinja2 for > Python3, and let my script continue, expecting qtwebengine to fail - > but that succeeded and falkon has now been built and is working. > So, it seems that the previous 2.7 install was ok (even though it > failed). > > - - - > > I've now tried a manual build, and installed to a DESTDIR equivalent > using > python2 setup.py install --root /tmp/JINJA2 > and that completed ok. > I can confirm Jinja in blfs-sysd book is broke for the python2 version. V3 > builds/installs. Same invalid syntax error as you posted Ken. > I'll chk back since I'd like it for qtwebengine but I think that builds ok > regardless of this error. > > Archetech Hi Tom, that is very interesting. I assumed the alpha version of MarkupSafe was the problem (probably never tested on a system with python2) and that it happened to have been removed, which was why my later manual build worked. But maybe there is again a newer version. Because I had NOT removed the 2.7 egg which did get installed, I think that was used by qtwebengine. That implies that for future builds Python2 Jinja is still needed, but might crap out in the later stages of the install - if so, not a problem. In other words, maybe add ' || true' to the Python2 install and mark it down as collateral damage from the discontinuation of that version. But I don't know how pip works (maybe it uses mirrors, and if so thy might lag behind by a day or two). I'll bear this in mind, but I don't expect to be building qtwebengine on a fresh system for several weeks (and if 5.15 is released and I upgrade my existing systems I won't bother updating Jinja2). Thanks. ken (for some reasons, I'm getting errors trying to write the glyph I normally use instead of k) -- See You Later, Holy Poppadom! -- Red Dwarf, The Promised Land -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-support] Odd build failure with Jinja2 (now ok):wq
If I was an animist, I would say that Python knows I hate it, and
reciprocates.
I've just spent some hours trying to work out (expletives deleted)
went wrong with my Jinja2 build. It seems to have resolved itself
(which is why I'm blaming Pip), but I'm writing this partly to calm
down, and partly to warn people that Pip will break your builds at
awkward times.
I have MarkupSafe-1.1.1 installed for Python3, apparently a few
hours ago the best match for that package was 2.0.0a1 which sounds
like an alpha version. And I've never seen MarkupSafe getting
referenced by the Python2 install of Jinja2 until this happened.
- - -
In the problematic build I had several messages like:
byte-compiling build/bdist.linux-x86_64/egg/jinja2/asyncsupport.py to
asyncsupport.pyc
File "build/bdist.linux-x86_64/egg/jinja2/asyncsupport.py", line 18
async def concat_async(async_gen):
^
SyntaxError: invalid syntax
I wasn't sure if that was 2.7 or 3.8, but later it was definitely
doing 2.7 and got another syntax error -
removing 'build/bdist.linux-x86_64/egg' (and everything under it)
Processing Jinja2-2.11.2-py2.7.egg
creating /usr/lib/python2.7/site-packages/Jinja2-2.11.2-py2.7.egg
Extracting Jinja2-2.11.2-py2.7.egg to /usr/lib/python2.7/site-packages
File
"/usr/lib/python2.7/site-packages/Jinja2-2.11.2-py2.7.egg/jinja2/asyncfilters.py",
line 8
async def auto_to_seq(value):
^
SyntaxError: invalid syntax
File
"/usr/lib/python2.7/site-packages/Jinja2-2.11.2-py2.7.egg/jinja2/asyncsupport.py",
line 18
async def concat_async(async_gen):
^
SyntaxError: invalid syntax
File
"/usr/lib/python2.7/site-packages/Jinja2-2.11.2-py2.7.egg/jinja2/asyncfilters.py",
line 8
async def auto_to_seq(value):
^
SyntaxError: invalid syntax
File
"/usr/lib/python2.7/site-packages/Jinja2-2.11.2-py2.7.egg/jinja2/asyncsupport.py",
line 18
async def concat_async(async_gen):
^
SyntaxError: invalid syntax
Adding Jinja2 2.11.2 to easy-install.pth file
Installed /usr/lib/python2.7/site-packages/Jinja2-2.11.2-py2.7.egg
Processing dependencies for Jinja2==2.11.2
Searching for MarkupSafe>=0.23
Reading https://pypi.org/simple/MarkupSafe/
Best match: MarkupSafe 2.0.0a1
Processing MarkupSafe-2.0.0a1.tar.gz
Writing /tmp/easy_install-d_D5Lj/MarkupSafe-2.0.0a1/setup.cfg
Running MarkupSafe-2.0.0a1/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-d_D5Lj/MarkupSafe-2.0.0a1/egg-dist-tmp-_ozZwk
Traceback (most recent call last):
File "setup.py", line 55, in
entry_points={"babel.extractors": ["jinja2 =
jinja2.ext:babel_extract[i18n]"]},
File "/usr/lib/python2.7/site-packages/setuptools/__init__.py", line 145, in
setup
return distutils.core.setup(**attrs)
File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
dist.run_commands()
[snipped here, it's there was a lot, all 2.7]
And eventually the 2.7 install failed at
File "/usr/lib/python2.7/site-packages/setuptools/config.py", line 349, in
_parse_attr
value = getattr(module, attr_name)
AttributeError: 'module' object has no attribute '__version__'
- - -
In past builds, MarkupSafe gets mentioned at the end of the Python3
install, and I got the same thing in my last 3-only build:
Adding Jinja2 2.11.2 to easy-install.pth file
Installed /usr/lib/python3.8/site-packages/Jinja2-2.11.2-py3.8.egg
Processing dependencies for Jinja2==2.11.2
Searching for MarkupSafe==1.1.1
Best match: MarkupSafe 1.1.1
Processing MarkupSafe-1.1.1-py3.8-linux-x86_64.egg
MarkupSafe 1.1.1 is already the active version in easy-install.pth
Using /usr/lib/python3.8/site-packages/MarkupSafe-1.1.1-py3.8-linux-x86_64.egg
Finished processing dependencies for Jinja2==2.11.2
- - -
I _thought_ I had deleted the files installed from the failed
Python2 build, but apparently I didn't. I then built Jinja2 for
Python3, and let my script continue, expecting qtwebengine to fail -
but that succeeded and falkon has now been built and is working.
So, it seems that the previous 2.7 install was ok (even though it
failed).
- - -
I've now tried a manual build, and installed to a DESTDIR equivalent
using
python2 setup.py install --root /tmp/JINJA2
and that completed ok.
I can recall that in the past Pip has offered me too-new or alpha
versions, but I thought I'd always got round that by finding the
version I wanted (i.e. what worked before) and doing a manual
install. So I don't understand how it managed to get so screwed up
that it thought it needed MarkupSafe for a 2.7 install.
Hopefully, it is now sorted.
I suppose that my feelings towards Python are summed up by this
quote from Sir Pterry's 'Pyramids' -
'I wanted to be buried at sea,’ said Teppicymon. 'I hate pyramids.’
‘You do not,’ said Ashk-ur-men-tep.
‘Excuse me, but I do,’ said the king, politely.
'But you do not. What you feel nowe is mild dislike. When you have
lain in one for a thousand yeares,’ said the ancient one, 'THEN you
will begin to know the
Re: [blfs-support] xterm-353.tgz md5 sum doesn't match
On Sat, Apr 25, 2020 at 10:41:11AM +1000, Wayne Blaszczyk via blfs-support wrote: > > For me, this particular url, when using the above method in firefox, > will download the file directly into gedit. Where as for ntfs-3g, which is > also a tgz file, it downloads normally. > I don't use this method to download files, but I though I would > just mention it. > > Regards, > Wayne. > I think it's something in the gnome area (i.e. one of the packages which I've only installed when I've been testing parts of gnome). When I've done that in the past, firefox sometimes offered to open in gedit, or gimp, or (I think) gnome-ar. I guess something(s) has/have "stolen" some of the mime associations, but as you say - other files ostensibly of the same type work as normal. ĸen -- He could send for Ptraci, his favourite handmaiden. She was special. Her singing always cheered him up. Life seemed so much brighter when she stopped. -- Pyramids -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] texdoc error: No texlive.tlpdb nor shipped tlpdb data found
On Fri, Apr 24, 2020 at 01:13:53PM +0100, Ken Moffat via blfs-support wrote: > On Fri, Apr 24, 2020 at 12:54:38PM +0200, Stephen Berman via blfs-support > wrote: > > I built the full texlive-20200406 using jhalfs and it installed without > > error and using LaTeX works so far, but when I try to use texdoc, it > > fails with the error in the Subject line. My last full build of texlive > > was the 2018 source, and it contained > > /opt/texlive/2018/texmf-dist/scripts/texdoc/Data.tlpdb.lua. Searching > > the web I found this from Karl Berry on Apr 19, 2018 > > (https://github.com/TeX-Live/texdoc/issues/2): > > > > I think it would be better to get rid of the Data.tlpdb.lua file. It > > is perpetually stale. And if it's only a backup. if texlive.tlpdb > > can't be found, IMHO it is better for texdoc to simply fail. > > > > IIUC texlive.tlpdb is installed when using the binary installer but not > > when installing from source. The file is also available from CTAN under > > systems/texlive/tlnet/tlpkg/, but since it's apparently regularly > > (perhaps nightly) regenerated, could it be incompatible with the > > texlive-20200406 installation? Alternatively, the texdoc repository at > > Github shows how to generate Data.tlpdb.lua using rake, but AFAICT this > > is not available in the source installation. > > > > So what's the best way to get texdoc to work with texlive from source in > > BLFS? > > > > Steve Berman > Hmm, on the machine where I'm writing this texlive is still 2019 and > the problem also shows there. > > I conclude that nobody uses texdoc, and perhaps nobody uses TeX, so > we could just archive it. ^_^ > > I agree that installing a random newer version might give erroneous > results, or alternatively it might fix previous bugs. > > The instructions seem to be at > https://github.com/TeX-Live/texdoc/wiki/Packaging-Texdoc > and whilst I have 'rake' (from ruby) it still means finding a > suitable version of texlive.tlpdb. Will think about this. I've got > texlive svn on my server, last updated for pretest, with > Master/tlpkg/texlive.tlpdb - need to work out how to find the > appropriate revision for the release. > In fact there is a tlpdb-full tarball in historic/ - dropping that into /opt/texlive//tlpkg allows texdoc to run (on the first run, it creates the cache). Tested on 2019 with the corresponding version, I'll create a ticket and confirm 2020 works when I'm back on the machine where that is installed. ĸen -- He could send for Ptraci, his favourite handmaiden. She was special. Her singing always cheered him up. Life seemed so much brighter when she stopped. -- Pyramids -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
