[blfs-dev] evolution-data-server-3.40.0 FTBFS with cmake-3.20.1
When running cmake following the book, I get: -- CMake Error at cmake/modules/PrintableOptions.cmake:38 (message): variable name cannot be empty Call Stack (most recent call first): CMakeLists.txt:152 (add_printable_variable) -- Looks like it is known upstream, and fixed by https://gitlab.gnome.org/GNOME/evolution-data-server/-/commit/c95a70bfeae25ba11fbe50fe759a6cdb29388e44 Will make a patch Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Failure starting X/lxdm with glib 2.68.0
On Mon, 2021-04-12 at 09:46 +0200, Tim Tassonis via blfs-dev wrote: > Hi all > > I just tried to upgrade my qemu virtual machine to glib 2.68.0, which > lead to lxdm/X not starting anymore. /var/log/lxdm.log reports: > > MESA-LOADER: failed to open bochs-drm: > /opt/X11/lib/dri/bochs-drm_dri.so: cannot open shared object file: No > such file or directory (search paths /opt/X11/lib/dri) > failed to load driver: bochs-drm > > > The file /opt/X11/lib/dri/bochs-drm_dri.so really does not exist, but > with older glib (2.66.8) this is no problem. > > A downgrade to glib 2.66.8 does actually fix the problem, so glib 2.68.0 > really seems to be the problem here. I will try to investigate further, > but for the moment, I would advise people to stay away from glib 2.68.0, > at least on qemu vm's running X. Just to be sure: the VM has been updated, but the host has not been touched (no upgrade of glib2/qemu/whatever on host). Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] doxygen doc error
On Mon, 2021-04-05 at 12:11 -0500, Douglas R. Reno via blfs-dev wrote: > > On 4/3/21 12:02 PM, Pierre Labastie via blfs-dev wrote: > > Trying to build doxygen docs by the book, I get: > > --- > > [ 81%] Generating language.doc > > Traceback (most recent call last): > > File "/sources/doxygen/doxygen-1.9.1/build/doc/translator.py", line 2018, > > in > > > > trMan.generateTranslatorReport() > > File "/sources/doxygen/doxygen-1.9.1/build/doc/translator.py", line 1688, > > in > > generateTranslatorReport > > dic = self.__checkForNotUsedTrMethods() > > File "/sources/doxygen/doxygen-1.9.1/build/doc/translator.py", line 1491, > > in > > __checkForNotUsedTrMethods > > self.__removeUsedInFiles(fname, trdic) > > File "/sources/doxygen/doxygen-1.9.1/build/doc/translator.py", line 1458, > > in > > __removeUsedInFiles > > cont = f.read() > > File "/usr/lib/python3.9/codecs.py", line 322, in decode > > (result, consumed) = self._buffer_decode(data, self.errors, final) > > File "/usr/lib/python3.9/encodings/utf_8_sig.py", line 69, in > > _buffer_decode > > return codecs.utf_8_decode(input, errors, final) > > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb0 in position 45: > > invalid > > start byte > > make[3]: *** [doc/CMakeFiles/run_doxygen.dir/build.make:436: > > doc/language.doc] > > Error 1 > > make[3]: *** Deleting file 'doc/language.doc' > > make[2]: *** [CMakeFiles/Makefile2:703: doc/CMakeFiles/run_doxygen.dir/all] > > Error 2 > > make[1]: *** [CMakeFiles/Makefile2:657: doc/CMakeFiles/docs.dir/rule] Error > > 2 > > make: *** [Makefile:369: docs] Error 2 > > - > > I've found a patch in gentoo [1], but amazingly, there is nothing in arch. > > > > Actually, there is an "AppleDouble encoded Macintosh file" (according to > > "file") > > named src/._xmlgen.cpp, which is a binary. Removing it does not prevent > > building > > doxygen, and allows building the doc... > > Actually, according to [2], this file has been added in version 1.9.1, so it > > looks like an oversight! > > > > I propose to add a command to remove that file in the book. Gentoo patch is > > too > > complicated... > > > > Pierre > > > > [1] > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b89f80cd9c20607ada13ec091a32cef4b44d29f3 > > [2] https://fossies.org/diffs/doxygen/1.9.0_vs_1.9.1/index.html > > Adding a command to the book to remove that file sounds good to me. It > seems like that file is only compiled on Apple Mac systems. Looks like the person doing the packaging did it from an Apple computer, and that since it is a hidden file, nobody has seen it. Will add the remove (sounds a little weird, I must admit). Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] doxygen doc error
Trying to build doxygen docs by the book, I get: --- [ 81%] Generating language.doc Traceback (most recent call last): File "/sources/doxygen/doxygen-1.9.1/build/doc/translator.py", line 2018, in trMan.generateTranslatorReport() File "/sources/doxygen/doxygen-1.9.1/build/doc/translator.py", line 1688, in generateTranslatorReport dic = self.__checkForNotUsedTrMethods() File "/sources/doxygen/doxygen-1.9.1/build/doc/translator.py", line 1491, in __checkForNotUsedTrMethods self.__removeUsedInFiles(fname, trdic) File "/sources/doxygen/doxygen-1.9.1/build/doc/translator.py", line 1458, in __removeUsedInFiles cont = f.read() File "/usr/lib/python3.9/codecs.py", line 322, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) File "/usr/lib/python3.9/encodings/utf_8_sig.py", line 69, in _buffer_decode return codecs.utf_8_decode(input, errors, final) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb0 in position 45: invalid start byte make[3]: *** [doc/CMakeFiles/run_doxygen.dir/build.make:436: doc/language.doc] Error 1 make[3]: *** Deleting file 'doc/language.doc' make[2]: *** [CMakeFiles/Makefile2:703: doc/CMakeFiles/run_doxygen.dir/all] Error 2 make[1]: *** [CMakeFiles/Makefile2:657: doc/CMakeFiles/docs.dir/rule] Error 2 make: *** [Makefile:369: docs] Error 2 - I've found a patch in gentoo [1], but amazingly, there is nothing in arch. Actually, there is an "AppleDouble encoded Macintosh file" (according to "file") named src/._xmlgen.cpp, which is a binary. Removing it does not prevent building doxygen, and allows building the doc... Actually, according to [2], this file has been added in version 1.9.1, so it looks like an oversight! I propose to add a command to remove that file in the book. Gentoo patch is too complicated... Pierre [1] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b89f80cd9c20607ada13ec091a32cef4b44d29f3 [2] https://fossies.org/diffs/doxygen/1.9.0_vs_1.9.1/index.html -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] icewm FTBFS
On Sun, 2021-03-28 at 18:42 +0100, Ken Moffat via blfs-dev wrote: > On Sun, Mar 28, 2021 at 04:16:33PM +0100, Ken Moffat via blfs-dev wrote: > > > In theory plugins should have been working for years, and nothing in > > that area has changed, but exceot for icewm I don't use lto because > > packages that should benefit from the longer build (mozilla > > packages) get rebuilt monthly and the extra build time seems a > > waste. > > Looks as if my script broke at some point in the past: > liblto_plugin.so points to > /usr/libexec/gcc/x86_64-pc-linux-gnu//liblto_plugin.so > which of course does not exist. > > So I get to keep both the pieces ;-) Thanks for the diagnostics, > they do not alter my views about unnecessarily using cmake, but I > guess I'm in a minority on that. While doing research about that problem, I found one of the issues where the reporter was having a problem during build, and was using autotools. The maintainer advised him to use cmake, so it seems to be upstream choice. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] icewm FTBFS
On Sun, 2021-03-28 at 00:31 +, Ken Moffat via blfs-dev wrote: > On Sun, Mar 28, 2021 at 12:16:18AM +, Ken Moffat wrote: > > Trying to bring up a new system (packages current as of a day > > ago), I got as far as icewm. > > > > My previous build used icewm-2.1.2, this attempt was using 2.2.1. > > I also note that cmake is now 3.20.0, and that I was initially > > adding more options: > > > > -DCONFIG_LIBRSVG=on \ -DCONFIG_LIBPNG=on > > \ -DCONFIG_JPEG=on \ > > > > With those options on a -j8 build the iniital failure was > > > > [ 80%] Linking CXX executable ../icewmhint cd > > /scratch/working/icewm-2.2.1/build/src && /usr/bin/cmake -E > > cmake_link_script CMakeFiles/icewmhint.dir/link.txt --verbose=1 > > /usr/bin/c++ -O3 -march=native -fstack-clash-protection > > -D_FORTIFY_SOURCE=2 -fstack-protector-strong -D_GLIBCXX_ASSERTIONS > > -O3 -DNDEBUG -Wl,--as-needed > > CMakeFiles/icewmhint.dir/icewmhint.cc.o -o ../icewmhint > > ../libice.a -lXext -lX11 -flto /usr/bin/ld: > > /tmp/icewmhint.F5TdfP.ltrans0.ltrans.o: in function `main': > > :(.text.startup+0x34): undefined reference to > > `YLocale::YLocale(char const*)' /usr/bin/ld: > > :(.text.startup+0x9a): undefined reference to > > `GetArgument(char*&, char const*, char const*, char**&, char**)' > > /usr/bin/ld: :(.text.startup+0xbc): undefined > > reference to `check_help_version(char const*, char const*, char > > const*)' /usr/bin/ld: :(.text.startup+0x1ff): > > undefined reference to `YLocale::~YLocale()' /usr/bin/ld: > > :(.text.startup+0x245): undefined reference to > > `die(int, char const*, ...)' /usr/bin/ld: > > :(.text.startup+0x292): undefined reference to > > `YLocale::~YLocale()' collect2: error: ld returned 1 exit status > > make[2]: *** [src/CMakeFiles/icewmhint.dir/build.make:98: > > icewmhint] Error 1 make[2]: Leaving directory > > '/scratch/working/icewm-2.2.1/build' make[1]: *** > > [CMakeFiles/Makefile2:1248: src/CMakeFiles/icewmhint.dir/all] > > Error 2 make[1]: *** Waiting for unfinished jobs > > > > followed by more than 13000 lines mostly containing similar > > reports fro mthe other jobs (lots of other items, such as many > > 'clr*' i nthe last report. > > > > So, I tried omitting those extra lines but the results were very > > similar, although starting at a slightly different place: > > > > [ 79%] Linking CXX executable ../icewmbg cd > > /scratch/working/icewm-2.2.1/build/src && /usr/bin/cmake -E > > cmake_link_script CMakeFiles/icewmbg.dir/link.txt --verbose=1 > > /usr/bin/c++ -O3 -march=native -fstack-clash-protection > > -D_FORTIFY_SOURCE=2 -fstack-protector-strong -D_GLIBCXX_ASSERTIONS > > -O3 -DNDEBUG -Wl,--as-needed CMakeFiles/icewmbg.dir/icewmbg.cc.o > > -o ../icewmbg ../libice.a -lXrender -lX11 -lXcomposite -lXdamage > > -lXfixes -lXfixes -lgdk_pixbuf_xlib-2.0 -lgdk_pixbuf-2.0 > > -lgobject-2.0 -lglib-2.0 -lX11 -lXpm -lX11 -lXft -lfribidi > > -lXrandr -lXinerama -lXext -lX11 -flto -lXcomposite -lXdamage > > -lXfixes -lgdk_pixbuf_xlib-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0 > > -lglib-2.0 -lXpm -lXft -lfribidi -lXrandr -lXinerama -lXext > > /usr/bin/ld: /tmp/icewmbg.LqGNPO.ltrans0.ltrans.o: in function > > `YArray::~YArray()': :(.text+0x87): undefined > > reference to `vtable for YBaseArray' /usr/bin/ld: > > :(.text+0x8c): undefined reference to > > `YBaseArray::clear()' /usr/bin/ld: > > /tmp/icewmbg.LqGNPO.ltrans0.ltrans.o: in function > > `YArray::~YArray()': > > > > (about 400 lines from that file before Error 1.) > > > > So, I start to assume that this might be caused by newer cmake. > > But since that has been working fine up to now, I went for the > > previous version of icewm which I had handy (2.1.2, I did not have > > 2.2.0 or 2.2.1) and that built without problems. > > > > I've said before that I think using cmake for icewm is a > > less-tested path (and I think cmake is horrible), but I've now got > > a version of icewm installed so I'll continue my build (currently > > on node.js so I can't yet use firefox to see if there is anything > > relevant). > > > > I'll maybe revisit this. But given what else I intend to do, I > > very much doubt that I'll look at this for the next week! > > > I was about to suspend another machine, so I tried a quick google on > that (nothing) followed by an unlogged -j4 build of 2.2.1 matching > the book using cmake-3.19.5 and -j4 : that seems to have failed at > the same place [89%] followed by a lot of similar output. > > Seems to me that the book is definitely broken, and yet it was > apparently working on 17th March. Tim, any thoughts ? I've tried building icewm today at -j5 on a 4-core processor with HT. It worked. There might be a race condition when building libice.a (since the missing symbols should be there). You might want to remove libice.a and run make -j1. Otherwise, it'd be interesting to run nm -C libice.a and see whether the missing symbols are there. That's all I can think of for now... Pierre
Re: [blfs-dev] vala-0.50.4 breaks dconf-editor build
On Thu, 2021-03-18 at 11:48 +0100, Pierre Labastie via blfs-dev wrote:
> On Thu, 2021-03-18 at 10:25 +0100, Tim Tassonis via blfs-dev wrote:
> >
> >
> > On 3/17/21 2:55 PM, Pierre Labastie via blfs-dev wrote:
> > > On Wed, 2021-03-17 at 14:44 +0100, Pierre Labastie via blfs-dev wrote:
> > > > Hi,
> > > >
> > > > I inadvertently removed dconf-editor from my system (when recompiling
> > > > dconf,
> > > > because dconf-editor and dconf are on the same page, and so are in the
> > > > same
> > > > package in porg's view). So I tried to recompile it and got:
> > > > --
> > > > [6/52] Compiling Vala source ../editor...bar.vala ../editor/source-
> > > > manager.vala
> > > > FAILED: editor/dconf-editor.p/about-list.c editor/dconf-
> > > > editor.p/adaptative-
> > > > [... a lot more like that ...]
> > > > Compilation failed: 31 error(s), 89 warning(s)
> > > > ninja: build stopped: subcommand failed.
> > > > ---
> > > > Downgrading to vala-0.50.3 allows to build ("only" 8 warnings in valac)
> > > >
> > > > Pierre
> > > >
> > >
> > > There is a patch upstream that fixes the errors (and now there are "just"
> > > 97 warnings).
> > >
> > > https://gitlab.gnome.org/GNOME/dconf-editor/-
> > > /commit/9272e9fb6867e71426bfd0aa5edce5ec39cf0ad4.patch
> > >
> > > Will include it.
> > >
> > > Pierre
> >
> > Just a quick question: does anybody actually use vala, or knows anybody
> > using vala, or knows any project using it?
>
> A lot of things in gnome at least? Let me check...
baobab, cheese, dconf-editor,evolution-data-server, folks, gettext (in one
test), gexiv2, gnome-calculator, grilo, gsound, libchamplain, libfm, libgeee,
librsvg, libsecret, libsoup, lightdm, lxsession, qemu (in tests), seahorse,
shared-mime-info (in a test), tracker, umockdev, upower, vinagre, vte, all have
.vala files in their tarball.
So I guess they use vala
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] vala-0.50.4 breaks dconf-editor build
On Thu, 2021-03-18 at 10:25 +0100, Tim Tassonis via blfs-dev wrote:
>
>
> On 3/17/21 2:55 PM, Pierre Labastie via blfs-dev wrote:
> > On Wed, 2021-03-17 at 14:44 +0100, Pierre Labastie via blfs-dev wrote:
> > > Hi,
> > >
> > > I inadvertently removed dconf-editor from my system (when recompiling
> > > dconf,
> > > because dconf-editor and dconf are on the same page, and so are in the
> > > same
> > > package in porg's view). So I tried to recompile it and got:
> > > --
> > > [6/52] Compiling Vala source ../editor...bar.vala
> > > ../editor/source-manager.vala
> > > FAILED: editor/dconf-editor.p/about-list.c
> > > editor/dconf-editor.p/adaptative-
> > > [... a lot more like that ...]
> > > Compilation failed: 31 error(s), 89 warning(s)
> > > ninja: build stopped: subcommand failed.
> > > ---
> > > Downgrading to vala-0.50.3 allows to build ("only" 8 warnings in valac)
> > >
> > > Pierre
> > >
> >
> > There is a patch upstream that fixes the errors (and now there are "just"
> > 97 warnings).
> >
> > https://gitlab.gnome.org/GNOME/dconf-editor/-/commit/9272e9fb6867e71426bfd0aa5edce5ec39cf0ad4.patch
> >
> > Will include it.
> >
> > Pierre
>
> Just a quick question: does anybody actually use vala, or knows anybody
> using vala, or knows any project using it?
A lot of things in gnome at least? Let me check...
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] vala-0.50.4 breaks dconf-editor build
On Wed, 2021-03-17 at 14:55 +0100, Pierre Labastie via blfs-dev wrote:
> On Wed, 2021-03-17 at 14:44 +0100, Pierre Labastie via blfs-dev wrote:
> > Hi,
> >
> > I inadvertently removed dconf-editor from my system (when recompiling dconf,
> > because dconf-editor and dconf are on the same page, and so are in the same
> > package in porg's view). So I tried to recompile it and got:
> > --
> > [6/52] Compiling Vala source ../editor...bar.vala
> > ../editor/source-manager.vala
> > FAILED: editor/dconf-editor.p/about-list.c editor/dconf-editor.p/adaptative-
> > pathbar.c editor/dconf-editor.p/adaptative-window.c
> > editor/dconf-editor.p/base-
> > headerbar.c editor/dconf-editor.p/base-view.c editor/dconf-editor.p/base-
> > window.c editor/dconf-editor.p/bookmarks.c editor/dconf-editor.p/bookmarks-
> > controller.c editor/dconf-editor.p/bookmarks-headerbar.c editor/dconf-
> > editor.p/bookmarks-list.c editor/dconf-editor.p/bookmarks-view.c
> > editor/dconf-
> > editor.p/bookmarks-window.c editor/dconf-editor.p/browser-content.c
> > editor/dconf-editor.p/browser-headerbar.c editor/dconf-editor.p/browser-
> > infobar.c editor/dconf-editor.p/browser-stack.c
> > editor/dconf-editor.p/browser-
> > view.c editor/dconf-editor.p/browser-window.c editor/dconf-editor.p/dconf-
> > editor.c editor/dconf-editor.p/dconf-headerbar.c
> > editor/dconf-editor.p/dconf-
> > model.c editor/dconf-editor.p/dconf-view.c
> > editor/dconf-editor.p/dconf-window.c
> > editor/dconf-editor.p/delayed-setting-view.c
> > editor/dconf-editor.p/key-editor-
> > child.c editor/dconf-editor.p/key-list-box-row.c
> > editor/dconf-editor.p/large-
> > pathbar.c editor/dconf-editor.p/model-utils.c editor/dconf-
> > editor.p/modifications-handler.c editor/dconf-editor.p/modifications-list.c
> > editor/dconf-editor.p/modifications-revealer.c editor/dconf-editor.p/night-
> > light-monitor.c editor/dconf-editor.p/notifications-revealer.c editor/dconf-
> > editor.p/overlayed-list.c editor/dconf-editor.p/pathentry.c editor/dconf-
> > editor.p/pathwidget.c editor/dconf-editor.p/registry-info.c editor/dconf-
> > editor.p/registry-list.c editor/dconf-editor.p/registry-placeholder.c
> > editor/dconf-editor.p/registry-search.c
> > editor/dconf-editor.p/registry-view.c
> > editor/dconf-editor.p/schemas-utility.c
> > editor/dconf-editor.p/setting-object.c
> > editor/dconf-editor.p/short-pathbar.c
> > editor/dconf-editor.p/source-manager.c
> > valac -C --debug --debug --pkg posix /sources/dconf/dconf-editor-
> > 3.38.2/editor/config.vapi --pkg gtk+-3.0 --pkg gmodule-2.0 --target-glib '
> > 2.56.0' --pkg glib-2.0 --pkg dconf --color=always --directory editor/dconf-
> > editor.p --basedir ../editor
> > --gresources=../editor/dconf-editor.gresource.xml
> > --enable-experimental-non-null ../editor/about-list.vala
> > ../editor/adaptative-
> > pathbar.vala ../editor/adaptative-window.vala ../editor/base-headerbar.vala
> > ../editor/base-view.vala ../editor/base-window.vala ../editor/bookmarks.vala
> > ../editor/bookmarks-controller.vala ../editor/bookmarks-headerbar.vala
> > ../editor/bookmarks-list.vala ../editor/bookmarks-view.vala
> > ../editor/bookmarks-window.vala ../editor/browser-content.vala
> > ../editor/browser-headerbar.vala ../editor/browser-infobar.vala
> > ../editor/browser-stack.vala ../editor/browser-view.vala ../editor/browser-
> > window.vala ../editor/dconf-editor.vala ../editor/dconf-headerbar.vala
> > ../editor/dconf-model.vala ../editor/dconf-view.vala ../editor/dconf-
> > window.vala ../editor/delayed-setting-view.vala
> > ../editor/key-editor-child.vala
> > ../editor/key-list-box-row.vala ../editor/large-pathbar.vala
> > ../editor/model-
> > utils.vala ../editor/modifications-handler.vala ../editor/modifications-
> > list.vala ../editor/modifications-revealer.vala ../editor/night-light-
> > monitor.vala ../editor/notifications-revealer.vala ../editor/overlayed-
> > list.vala ../editor/pathentry.vala ../editor/pathwidget.vala
> > ../editor/registry-info.vala ../editor/registry-list.vala
> > ../editor/registry-
> > placeholder.vala ../editor/registry-search.vala ../editor/registry-view.vala
> > ../editor/schemas-utility.vala ../editor/setting-object.vala
> > ../editor/short-
> > pathbar.vala ../editor/source-manager.vala
> > [...]
> > Compilation failed: 31 error(s), 89 warning(s)
> > ninja: build stopped: subcommand failed.
> > ---
> > Downgrading to vala-0.50.3 allows to build ("only" 8 warnings in valac)
> >
> > Pierre
> >
>
> There is a patch upstream that fixes the errors (and now there are "just"
> 97 warnings).
>
> https://gitlab.gnome.org/GNOME/dconf-editor/-/commit/9272e9fb6867e71426bfd0aa5edce5ec39cf0ad4.patch
>
> Will include it.
>
> Pierre
Done at r24380
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] vala-0.50.4 breaks dconf-editor build
On Wed, 2021-03-17 at 14:44 +0100, Pierre Labastie via blfs-dev wrote: > Hi, > > I inadvertently removed dconf-editor from my system (when recompiling dconf, > because dconf-editor and dconf are on the same page, and so are in the same > package in porg's view). So I tried to recompile it and got: > -- > [6/52] Compiling Vala source ../editor...bar.vala > ../editor/source-manager.vala > FAILED: editor/dconf-editor.p/about-list.c editor/dconf-editor.p/adaptative- > pathbar.c editor/dconf-editor.p/adaptative-window.c > editor/dconf-editor.p/base- > headerbar.c editor/dconf-editor.p/base-view.c editor/dconf-editor.p/base- > window.c editor/dconf-editor.p/bookmarks.c editor/dconf-editor.p/bookmarks- > controller.c editor/dconf-editor.p/bookmarks-headerbar.c editor/dconf- > editor.p/bookmarks-list.c editor/dconf-editor.p/bookmarks-view.c editor/dconf- > editor.p/bookmarks-window.c editor/dconf-editor.p/browser-content.c > editor/dconf-editor.p/browser-headerbar.c editor/dconf-editor.p/browser- > infobar.c editor/dconf-editor.p/browser-stack.c editor/dconf-editor.p/browser- > view.c editor/dconf-editor.p/browser-window.c editor/dconf-editor.p/dconf- > editor.c editor/dconf-editor.p/dconf-headerbar.c editor/dconf-editor.p/dconf- > model.c editor/dconf-editor.p/dconf-view.c > editor/dconf-editor.p/dconf-window.c > editor/dconf-editor.p/delayed-setting-view.c editor/dconf-editor.p/key-editor- > child.c editor/dconf-editor.p/key-list-box-row.c editor/dconf-editor.p/large- > pathbar.c editor/dconf-editor.p/model-utils.c editor/dconf- > editor.p/modifications-handler.c editor/dconf-editor.p/modifications-list.c > editor/dconf-editor.p/modifications-revealer.c editor/dconf-editor.p/night- > light-monitor.c editor/dconf-editor.p/notifications-revealer.c editor/dconf- > editor.p/overlayed-list.c editor/dconf-editor.p/pathentry.c editor/dconf- > editor.p/pathwidget.c editor/dconf-editor.p/registry-info.c editor/dconf- > editor.p/registry-list.c editor/dconf-editor.p/registry-placeholder.c > editor/dconf-editor.p/registry-search.c editor/dconf-editor.p/registry-view.c > editor/dconf-editor.p/schemas-utility.c editor/dconf-editor.p/setting-object.c > editor/dconf-editor.p/short-pathbar.c editor/dconf-editor.p/source-manager.c > valac -C --debug --debug --pkg posix /sources/dconf/dconf-editor- > 3.38.2/editor/config.vapi --pkg gtk+-3.0 --pkg gmodule-2.0 --target-glib ' > 2.56.0' --pkg glib-2.0 --pkg dconf --color=always --directory editor/dconf- > editor.p --basedir ../editor --gresources=../editor/dconf-editor.gresource.xml > --enable-experimental-non-null ../editor/about-list.vala ../editor/adaptative- > pathbar.vala ../editor/adaptative-window.vala ../editor/base-headerbar.vala > ../editor/base-view.vala ../editor/base-window.vala ../editor/bookmarks.vala > ../editor/bookmarks-controller.vala ../editor/bookmarks-headerbar.vala > ../editor/bookmarks-list.vala ../editor/bookmarks-view.vala > ../editor/bookmarks-window.vala ../editor/browser-content.vala > ../editor/browser-headerbar.vala ../editor/browser-infobar.vala > ../editor/browser-stack.vala ../editor/browser-view.vala ../editor/browser- > window.vala ../editor/dconf-editor.vala ../editor/dconf-headerbar.vala > ../editor/dconf-model.vala ../editor/dconf-view.vala ../editor/dconf- > window.vala ../editor/delayed-setting-view.vala > ../editor/key-editor-child.vala > ../editor/key-list-box-row.vala ../editor/large-pathbar.vala ../editor/model- > utils.vala ../editor/modifications-handler.vala ../editor/modifications- > list.vala ../editor/modifications-revealer.vala ../editor/night-light- > monitor.vala ../editor/notifications-revealer.vala ../editor/overlayed- > list.vala ../editor/pathentry.vala ../editor/pathwidget.vala > ../editor/registry-info.vala ../editor/registry-list.vala ../editor/registry- > placeholder.vala ../editor/registry-search.vala ../editor/registry-view.vala > ../editor/schemas-utility.vala ../editor/setting-object.vala ../editor/short- > pathbar.vala ../editor/source-manager.vala > ../editor/overlayed-list.vala:23.16-23.53: warning: [GtkChild] fields must be > declared as `unowned' > [GtkChild] protected ListBox main_list_box; > ^^ > ../editor/overlayed-list.vala:27.16-27.48: warning: [GtkChild] fields must be > declared as `unowned' > [GtkChild] private ScrolledWindow scrolled; > ^ > ../editor/overlayed-list.vala:28.16-28.53: warning: [GtkChild] fields must be > declared as `unowned' > [GtkChild] private Box edit_mode_box; > ^^ > ../editor/overlayed-list.vala:48.16-48.57: warning: [GtkChild] fields must be &
[blfs-dev] vala-0.50.4 breaks dconf-editor build
Hi, I inadvertently removed dconf-editor from my system (when recompiling dconf, because dconf-editor and dconf are on the same page, and so are in the same package in porg's view). So I tried to recompile it and got: -- [6/52] Compiling Vala source ../editor...bar.vala ../editor/source-manager.vala FAILED: editor/dconf-editor.p/about-list.c editor/dconf-editor.p/adaptative- pathbar.c editor/dconf-editor.p/adaptative-window.c editor/dconf-editor.p/base- headerbar.c editor/dconf-editor.p/base-view.c editor/dconf-editor.p/base- window.c editor/dconf-editor.p/bookmarks.c editor/dconf-editor.p/bookmarks- controller.c editor/dconf-editor.p/bookmarks-headerbar.c editor/dconf- editor.p/bookmarks-list.c editor/dconf-editor.p/bookmarks-view.c editor/dconf- editor.p/bookmarks-window.c editor/dconf-editor.p/browser-content.c editor/dconf-editor.p/browser-headerbar.c editor/dconf-editor.p/browser- infobar.c editor/dconf-editor.p/browser-stack.c editor/dconf-editor.p/browser- view.c editor/dconf-editor.p/browser-window.c editor/dconf-editor.p/dconf- editor.c editor/dconf-editor.p/dconf-headerbar.c editor/dconf-editor.p/dconf- model.c editor/dconf-editor.p/dconf-view.c editor/dconf-editor.p/dconf-window.c editor/dconf-editor.p/delayed-setting-view.c editor/dconf-editor.p/key-editor- child.c editor/dconf-editor.p/key-list-box-row.c editor/dconf-editor.p/large- pathbar.c editor/dconf-editor.p/model-utils.c editor/dconf- editor.p/modifications-handler.c editor/dconf-editor.p/modifications-list.c editor/dconf-editor.p/modifications-revealer.c editor/dconf-editor.p/night- light-monitor.c editor/dconf-editor.p/notifications-revealer.c editor/dconf- editor.p/overlayed-list.c editor/dconf-editor.p/pathentry.c editor/dconf- editor.p/pathwidget.c editor/dconf-editor.p/registry-info.c editor/dconf- editor.p/registry-list.c editor/dconf-editor.p/registry-placeholder.c editor/dconf-editor.p/registry-search.c editor/dconf-editor.p/registry-view.c editor/dconf-editor.p/schemas-utility.c editor/dconf-editor.p/setting-object.c editor/dconf-editor.p/short-pathbar.c editor/dconf-editor.p/source-manager.c valac -C --debug --debug --pkg posix /sources/dconf/dconf-editor- 3.38.2/editor/config.vapi --pkg gtk+-3.0 --pkg gmodule-2.0 --target-glib ' 2.56.0' --pkg glib-2.0 --pkg dconf --color=always --directory editor/dconf- editor.p --basedir ../editor --gresources=../editor/dconf-editor.gresource.xml --enable-experimental-non-null ../editor/about-list.vala ../editor/adaptative- pathbar.vala ../editor/adaptative-window.vala ../editor/base-headerbar.vala ../editor/base-view.vala ../editor/base-window.vala ../editor/bookmarks.vala ../editor/bookmarks-controller.vala ../editor/bookmarks-headerbar.vala ../editor/bookmarks-list.vala ../editor/bookmarks-view.vala ../editor/bookmarks-window.vala ../editor/browser-content.vala ../editor/browser-headerbar.vala ../editor/browser-infobar.vala ../editor/browser-stack.vala ../editor/browser-view.vala ../editor/browser- window.vala ../editor/dconf-editor.vala ../editor/dconf-headerbar.vala ../editor/dconf-model.vala ../editor/dconf-view.vala ../editor/dconf- window.vala ../editor/delayed-setting-view.vala ../editor/key-editor-child.vala ../editor/key-list-box-row.vala ../editor/large-pathbar.vala ../editor/model- utils.vala ../editor/modifications-handler.vala ../editor/modifications- list.vala ../editor/modifications-revealer.vala ../editor/night-light- monitor.vala ../editor/notifications-revealer.vala ../editor/overlayed- list.vala ../editor/pathentry.vala ../editor/pathwidget.vala ../editor/registry-info.vala ../editor/registry-list.vala ../editor/registry- placeholder.vala ../editor/registry-search.vala ../editor/registry-view.vala ../editor/schemas-utility.vala ../editor/setting-object.vala ../editor/short- pathbar.vala ../editor/source-manager.vala ../editor/overlayed-list.vala:23.16-23.53: warning: [GtkChild] fields must be declared as `unowned' [GtkChild] protected ListBoxmain_list_box; ^^ ../editor/overlayed-list.vala:27.16-27.48: warning: [GtkChild] fields must be declared as `unowned' [GtkChild] private ScrolledWindow scrolled; ^ ../editor/overlayed-list.vala:28.16-28.53: warning: [GtkChild] fields must be declared as `unowned' [GtkChild] private Boxedit_mode_box; ^^ ../editor/overlayed-list.vala:48.16-48.57: warning: [GtkChild] fields must be declared as `unowned' [GtkChild] private ModelButton enter_edit_mode_button; ^^ ../editor/overlayed-list.vala:49.16-49.57: warning: [GtkChild] fields must be declared as `unowned' [GtkChild] private ModelButton leave_edit_mode_button; ^^ ../editor/registry-placeholder.vala:23.16-23.46: warning: [GtkChild] fields must be declared as `unowned' [
Re: [blfs-dev] Couple of X Window System oddities
On Mon, 2021-03-08 at 19:49 +0800, Kevin Buckley via blfs-dev wrote: > 1) > > x7fonts.xml has an > > as_root rm -rf $packagedir > > in the loop over packages, although x7apps doesn't have the as_root, > and nor does x7libs. Not sure in this case, but being root for removing a build tree may occasionally be necessary because "as_root make install" may create files owned by root in the directory. In this case, as_root was added at revision 12833 (2014-03-07) with the log "Tweak font installation script". So it seems to have been done on purpose. Note that at the time, there were many more fonts installed, so the need for "as_root" may have disappeared when removing the extra fonts (some of which are now in the "Xorg Legacy" page, which does not have "as_root" for removing the build tree). > > > 2) > > Installation of intel-vaapi-driver > > appears to unpack the intel-vaapi-driver sources into the libva > directory. > > Does it need to be installed from within the libva source directory? > > I'd have thought one would have cd-d back up out of the libva dir? Well, I'm responsible for this... It does not hurt, and it allows to have only one directory to remove instead of two after building... It's this way for all the pages with two packages on them (see sassc for example)(I hate those pages, they just show our laziness). > > > 3) > > I also noted that many of the X Window System package instructions > (although I think it's a BLFS wide thing) follow this form : > > Installation of package > > Install package by running the following > commands: > > ./configure $XORG_CONFIG && > make > > This package does not come with a test suite. > > Now, as the root user: > > make install > > > I'd like to suggest that the "Install" sentence there should be > replaced by > > "Build package by running ..." > > as that's what the combined configure+make commands actually do > and that the "Now, as the root user:" becomes > > "As the root user, install the package as follows:" > > as that is what the commands to be done as the root user do. Well, I'm not a native English speaker, so I might be wrong, but I understand the first sentence is for all what follows, including the "Now, as the root user" part. > > > If truth be told, I'd rather see the "Patch; Configure; Make; Make > Install" > stages in separate boxes but think that's a bit too much of an ask? Well, that's a design decision made long ago (and before I started contributing). Changing it means changing ~800 pages of the book. That could be automated with a carefully crafted XSL stylesheet, but verification would be tedious. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Wierd svn update outcome
On Mon, 2021-03-01 at 14:53 +0800, Kevin Buckley via blfs-dev wrote: > This one is probably me getting the SVN stuff wrong. > > In my local BLFS trunk directory, I have just done (again, after > the rendering failed) an > > $ svn update > Updating '.': > At revision 24315. > $ > $ svn info > Path: . > Working Copy Root Path: /srv/distros/LFS/SVN/0- > svn.lfs.org/BLFS/trunk/BOOK > URL: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK > Relative URL: ^/trunk/BOOK > Repository Root: svn://svn.linuxfromscratch.org/BLFS > Repository UUID: af4574ff-66df-0310-9fd7-8a98e5e911e0 > Revision: 24315 > Node Kind: directory > Schedule: normal > Last Changed Author: pierre > Last Changed Rev: 24314 > Last Changed Date: 2021-02-28 23:53:56 +0800 (Sun, 28 Feb 2021) > $ > > and I currently have > > archive/gmime.xml > > and > > general/genlib/gmime3.xml > > However, the "lfs checked" macros seem to be the wrong way around > > $ grep _checked archive/gmime.xml > &lfs10_checked; > > $ grep _checked general/genlib/gmime3.xml > &lfs91_checked; It seems there is something wrong here, because I have it ok. Explained by the $Date below, though. > > and clearly the latter prevents me rendering the Book locally, > because what is defined is now: &lfs101_checked; > > I can see that the rendered BLFS development Book has the > correct text in the Gmime-3.2.7 section, though. > > > FWIW, I see this in my local gmime3.xml > > > $LastChangedBy: bdubbs $ > $Date: 2020-02-17 10:46:23 +0800 (Mon, 17 Feb 2020) > $ > > > which is clearly way too old. > > So what have I missed in getting my local copy so out-of-date? I cannot answer for sure. Maybe you have modified something manually in that file, and it's considered as modified working copy, that shouldn't be modified. But in that case, you should see a message when running svn update. You could try to run "svn status" and "svn diff" to see what is going on. If you have not done (on purpose) modifications to the working copy, you can also run "svn revert -R .", which will erase all (unwanted and wanted) modifications respective to the repository. HTH Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] cups 2.3.3op2 has been released
On Thu, 2021-02-04 at 01:56 -0500, Marty Jack via blfs-dev wrote: > > If the editors should choose to begin recommending the fork. > > https://github.com/OpenPrinting/cups/releases/ FWIIW, debian uses that one in unstable. Guess we should do the move too. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] (I know it's the wrong list) Be careful of binutils 2.36
On Tue, 2021-01-26 at 14:55 +0800, Xi Ruoyao via blfs-dev wrote: > On 2021-01-25 19:33 -0500, Marty Jack via blfs-dev wrote: > > I found that during the install phase the just installed ld won't > > run against > > the prior libctf which had not yet been installed. I ended up with > > a > > nonfunctional ld and had to recover it from another system and > > reinstall > > 2.35.1. Now holding off to see what others discover. I do not see > > anyone > > reporting a problem on their mailing list at this point. > > It's not so fatal. You can set LD_LIBRARY_PATH during make install > to > workaround. Sorry, I am unable to do that: I've tried: LD_LIBRARY_PATH=/build/dir/binutils-2.36/build/libctf/.libs \ make tooldir=/usr install and that is not enough... What worked for me is: make tooldir=/usr -C libctf install make toolsdir=/usr install Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Suggestion to mention webp-pixbuf-loader either on libwebp or gdk-pixbuf page
On Sat, 2021-01-23 at 21:20 +0100, Tim Tassonis via blfs-dev wrote: > > > On 1/23/21 6:43 PM, Pierre Labastie via blfs-dev wrote: > > On Sat, 2021-01-23 at 11:10 -0600, Douglas R. Reno via blfs-dev > > wrote: > > > > > > On 1/23/21 11:06 AM, Tim Tassonis via blfs-dev wrote: > > > > Hi all > > > > > > > Hi Tim, > > > > When setting up my new xfce4 based system, I stumbled across > > > > webp-pixbuf-loader. > > > > > > > > It easily adds support for webp images in gdk-pixbuf-loader, > > > > which > > > > then automatically gets picked up by thunar, tumbler and > > > > ristretto > > > > and > > > > will allow you to view and preview those images. I suppose it > > > > would > > > > be > > > > the same for gnome folks. > > > > > > > I think GPicView, Nautilus, EOG, and maybe PCManFM could use this > > > for > > > thumbnails :) > > > > > > > The repository is at > > > > > > > > https://github.com/aruiz/webp-pixbuf-loader > > > > > > > > > > > > > > > > Current version is. > > > > > > > > https://github.com/aruiz/webp-pixbuf-loader/archive/0.0.2.tar.gz > > > > > > > > which should be downloaded to webp-pixbuf-loader-0.0.2.tar.gz > > > > > > > > Build and install is a simple matter of: > > > > > > > > mkdir build > > > > cd build || exit > > > > meson --prefix=/opt/X11 -Dbuildtype=release .. > > > > ninja || exit > > > > cd .. > > > > cd build || exit > > > > DESTDIR=$DESTDIR ninja install || exit > > > > cd .. > > > > /opt/X11/bin/gdk-pixbuf-query-loaders --update-cache > > > > > > > > > > > > Of course, DESTDIR is my own choice, as is the /opt/X11 prefix. > > > > > > > > > > > > Maybe this could be added as a suggestion to the libwebp or the > > > > gdk-pixbuf page? > > > > > > > It looks simple enough, I think we should add it to the book, > > > probably > > > placing it into Graphics Libraries. Being able to read webp > > > images is > > > very useful now. I'd say mentioning it on the gdk-pixbuf page > > > would > > > be > > > useful. Bruce and others, what do you think? > > > > > > > Both libwebp and gdk-pixbuf are dependencies for webp-pixbuf- > > loader. We > > usually mention things the other way around. But definitely, we > > should > > mention it for any package that can use it (either as a runtime dep > > or > > a build dep, we need to check). So it may be more practical to have > > it > > in the book. Reading the issues, this package seems to be usable > > qith > > pcmanfm, eog, and a lot of viewer. > > I have installed and "tested" it, it is clearly a runtime dependency, > neither libwebp or gdk-pixbuf need it or can even use it when > building them. I may have not been clear: libwebp and gdk-pixbuf are required for building webp-pixbuf-loader (see meson.build), not the other way around... > > I can confirm that it is usable with ristretto tumbler, thunar and > pcmanfm, I have all these built and installed _before_ > webp-pixbuf-loader, and they now all display webp images just fine. > Animated webp files however are not supported for thumbnailing. > So webp-pixbuf-loader is definitely a rt dependency for all those apps. Good to know. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Suggestion to mention webp-pixbuf-loader either on libwebp or gdk-pixbuf page
On Sat, 2021-01-23 at 11:10 -0600, Douglas R. Reno via blfs-dev wrote: > > On 1/23/21 11:06 AM, Tim Tassonis via blfs-dev wrote: > > Hi all > > > Hi Tim, > > When setting up my new xfce4 based system, I stumbled across > > webp-pixbuf-loader. > > > > It easily adds support for webp images in gdk-pixbuf-loader, which > > then automatically gets picked up by thunar, tumbler and ristretto > > and > > will allow you to view and preview those images. I suppose it would > > be > > the same for gnome folks. > > > I think GPicView, Nautilus, EOG, and maybe PCManFM could use this for > thumbnails :) > > > The repository is at > > > > https://github.com/aruiz/webp-pixbuf-loader > > > > > > > > Current version is. > > > > https://github.com/aruiz/webp-pixbuf-loader/archive/0.0.2.tar.gz > > > > which should be downloaded to webp-pixbuf-loader-0.0.2.tar.gz > > > > Build and install is a simple matter of: > > > > mkdir build > > cd build || exit > > meson --prefix=/opt/X11 -Dbuildtype=release .. > > ninja || exit > > cd .. > > cd build || exit > > DESTDIR=$DESTDIR ninja install || exit > > cd .. > > /opt/X11/bin/gdk-pixbuf-query-loaders --update-cache > > > > > > Of course, DESTDIR is my own choice, as is the /opt/X11 prefix. > > > > > > Maybe this could be added as a suggestion to the libwebp or the > > gdk-pixbuf page? > > > It looks simple enough, I think we should add it to the book, > probably > placing it into Graphics Libraries. Being able to read webp images is > very useful now. I'd say mentioning it on the gdk-pixbuf page would > be > useful. Bruce and others, what do you think? > Both libwebp and gdk-pixbuf are dependencies for webp-pixbuf-loader. We usually mention things the other way around. But definitely, we should mention it for any package that can use it (either as a runtime dep or a build dep, we need to check). So it may be more practical to have it in the book. Reading the issues, this package seems to be usable qith pcmanfm, eog, and a lot of viewer. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [confirmed] Graphviz-2.44.1 doesn't compile with php-8.0.1
On Sun, 2021-01-17 at 16:37 +0100, Pierre Labastie via blfs-dev wrote: > On Sun, 2021-01-17 at 16:32 +0100, Pierre Labastie via blfs-dev > wrote: > > On Sun, 2021-01-17 at 15:02 +, John Burrell via blfs-dev wrote: > > > BLFS systemd version 2021-01-16 > > > > > > with php-8.0.1 installed, the graphviz-2.44.1 compile gives: > > > > > > [...] > > gv_php.cpp:772:3: error: #error These bindings need PHP7 - to > > generate > > PHP5 bindings use: SWIG < 4.0.0 and swig -php5 > > 772 | # error These bindings need PHP7 - to generate PHP5 > > bindings > > use: SWIG < 4.0.0 and swig -php5 > > > > > [ > > > Adding --enable-php=no to the configure script allows it to > > > compile. > > [...] > > Seems like the way to go, done at r24116 (using --disable-php) > > > Pierre > -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [confirmed] Graphviz-2.44.1 doesn't compile with php-8.0.1
On Sun, 2021-01-17 at 16:32 +0100, Pierre Labastie via blfs-dev wrote:
> On Sun, 2021-01-17 at 15:02 +, John Burrell via blfs-dev wrote:
> > BLFS systemd version 2021-01-16
> >
> > with php-8.0.1 installed, the graphviz-2.44.1 compile gives:
> >
> > In file included from gv_php.cpp:767:
> > /usr/include/php/Zend/zend_API.h:168:47: note: to match this ‘{’
> > 168 | static const zend_internal_arg_info name[] = { \
> > | ^
> > gv_php.cpp:5411:1: note: in expansion of macro
> > ‘ZEND_BEGIN_ARG_INFO_EX’
> > 5411 | ZEND_BEGIN_ARG_INFO_EX(swig_arginfo_000, 0, 0, 0)
> > | ^~
> > /usr/include/php/Zend/zend_API.h:172:30: error: expected
> > declaration
> > before ‘}’ token
> > 172 | #define ZEND_END_ARG_INFO() };
> > | ^
> > gv_php.cpp:5415:1: note: in expansion of macro ‘ZEND_END_ARG_INFO’
> > 5415 | ZEND_END_ARG_INFO()
> > | ^
> > make[4]: *** [Makefile:2479: libgv_php_la-gv_php.lo] Error 1
> > make[4]: Leaving directory
> > '/usr/src/genutils/graphviz/graphviz-2.44.1/tclpkg/gv'
> > make[3]: *** [Makefile:3003: all-recursive] Error 1
>
> Actually, the true error/reason is a little farther above:
> gv_php.cpp:772:3: error: #error These bindings need PHP7 - to
> generate
> PHP5 bindings use: SWIG < 4.0.0 and swig -php5
> 772 | # error These bindings need PHP7 - to generate PHP5 bindings
> use: SWIG < 4.0.0 and swig -php5
>
> So it looks like SWIG is unable to generate bindings for php 8...
>
> The question of when SWIG will support php 8 has been asked to SWIG
> devs [1], who haven't answered yet. In that issue, there is a link to
> an issue in another project that shows that the error is the same
> (for
> php 7).
>
> >
> > Adding --enable-php=no to the configure script allows it to
> > compile.
>
> Seems like the way to go, unless we really need php bindings, in
> which
> case, the best way is to reinstall php 7...
See also [2]
Pierre
> [1] https://github.com/swig/swig/issues/1915
[2] https://gitlab.com/graphviz/graphviz/-/issues/1903
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] [confirmed] Graphviz-2.44.1 doesn't compile with php-8.0.1
On Sun, 2021-01-17 at 15:02 +, John Burrell via blfs-dev wrote:
> BLFS systemd version 2021-01-16
>
> with php-8.0.1 installed, the graphviz-2.44.1 compile gives:
>
> In file included from gv_php.cpp:767:
> /usr/include/php/Zend/zend_API.h:168:47: note: to match this ‘{’
> 168 | static const zend_internal_arg_info name[] = { \
> | ^
> gv_php.cpp:5411:1: note: in expansion of macro
> ‘ZEND_BEGIN_ARG_INFO_EX’
> 5411 | ZEND_BEGIN_ARG_INFO_EX(swig_arginfo_000, 0, 0, 0)
> | ^~
> /usr/include/php/Zend/zend_API.h:172:30: error: expected declaration
> before ‘}’ token
> 172 | #define ZEND_END_ARG_INFO() };
> | ^
> gv_php.cpp:5415:1: note: in expansion of macro ‘ZEND_END_ARG_INFO’
> 5415 | ZEND_END_ARG_INFO()
> | ^
> make[4]: *** [Makefile:2479: libgv_php_la-gv_php.lo] Error 1
> make[4]: Leaving directory
> '/usr/src/genutils/graphviz/graphviz-2.44.1/tclpkg/gv'
> make[3]: *** [Makefile:3003: all-recursive] Error 1
Actually, the true error/reason is a little farther above:
gv_php.cpp:772:3: error: #error These bindings need PHP7 - to generate
PHP5 bindings use: SWIG < 4.0.0 and swig -php5
772 | # error These bindings need PHP7 - to generate PHP5 bindings
use: SWIG < 4.0.0 and swig -php5
So it looks like SWIG is unable to generate bindings for php 8...
The question of when SWIG will support php 8 has been asked to SWIG
devs [1], who haven't answered yet. In that issue, there is a link to
an issue in another project that shows that the error is the same (for
php 7).
>
> Adding --enable-php=no to the configure script allows it to compile.
Seems like the way to go, unless we really need php bindings, in which
case, the best way is to reinstall php 7...
Pierre
[1] https://github.com/swig/swig/issues/1915
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Errors accessing wiki.linuxfromscratch.org
On Tue, 2021-01-12 at 08:50 +0100, Tim Tassonis via blfs-dev wrote: > Hi all > > Since a couple of days, I'm experiencing connect issues to > wiki.linuxfromscratch.org. Is this a known issue, or is the problem > on > my side? > I have the same problems (I guess they are the same): very slow, and I get disconnected before being able to finish writing a comment, if by chance the connection procedure finishes. Other services on higgs seem to run ok now (svn, other parts of the web site, mail, ssh) Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Why do we patch polkit for elogind ?
On Tue, 2021-01-05 at 14:33 +0100, Pierre Labastie via blfs-dev wrote: > On Wed, 2020-12-30 at 18:21 +, Ken Moffat via blfs-dev wrote: > > Hi Guys, > > > > some of you may have noticed that I have an aversion to gtk-doc > > (I'm > > getting over it). This was triggered by occasional uses of > > autoreconf now needing gtkdocize. That first hit me in polkit with > > the patch for elogind, but my memory suggested that the patch has > > in > > the past been added or rolled forward a little after updates to > > polkit. > > > > From reading the patch that introduced gtkdocize in autoconf [1], > it appears that gtkdocize is not called if the -i (--install) flags > is > not passed. That flag is not needed for polkit. We might want to > check > whether it is really needed for the other packages that use > autoreconf. Forgot the ref... [1] http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blobdiff;f=bin/autoreconf.in;h=14e12895e2a2d98729dc19f38e442626f1d72444;hp=1ca11f284a0ba02cc92e4b96ce13be2b69769691;hb=dd880a0a6de5602cdd40b770ed6b083b34aa0768;hpb=aba75f6d4a9c875a9d5d90a07c6b3678db66a4bf -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Why do we patch polkit for elogind ?
On Wed, 2020-12-30 at 18:21 +, Ken Moffat via blfs-dev wrote: > Hi Guys, > > some of you may have noticed that I have an aversion to gtk-doc (I'm > getting over it). This was triggered by occasional uses of > autoreconf now needing gtkdocize. That first hit me in polkit with > the patch for elogind, but my memory suggested that the patch has in > the past been added or rolled forward a little after updates to > polkit. > From reading the patch that introduced gtkdocize in autoconf [1], it appears that gtkdocize is not called if the -i (--install) flags is not passed. That flag is not needed for polkit. We might want to check whether it is really needed for the other packages that use autoreconf. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Error building libxslt-1.1.34
On Tue, 2021-01-05 at 09:58 +0100, Tim Tassonis via blfs-dev wrote: > Hi all > > I am stuck at building libxslt-1.1.34, getting the following error: > > > > I/O error : Attempt to load network entity > http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd > doc/xsltproc.xml:8: warning: failed to load external entity > "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; > ]> > > > > For the record, the URL > "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; works fine > with curl or the browser. While I first ignored this error, it now > really bites mime at shared-mime-info. > > I have installed both docbook-xml-4.5 and docbook-xsl-1.79.2, and > also > libxml2, but not any other docbook stuff. > > Does anybody know where this error is coming from? > Guessing: you haven't run the instructions in the "Configuration" paragraph of docbook-xml-4.5. Note: usually, xsltproc is run with the --nonet switch, so that loading an external entity fails if it is not present locally. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] 2020-09-03" Pango-1.46.0: Cairo is "Recommended" but seems to be Required
On Sat, 2021-01-02 at 19:57 +0800, Kevin Buckley via blfs-dev wrote: > Been working against the BLFS Version 2020-09-03, so Pango 1.46.0 > but BLFS Version 2021-01-01 with Pango 1.48.0 has the same text. > > I read, > > Pango Dependencies > > Required > > Fontconfig-2.13.1 (must be built with FreeType-2.10.4 using > HarfBuzz-2.7.4), FriBidi-1.0.9, and GLib-2.66.4 > > Recommended > > Cairo-1.17.2+f93fc72c03e, gobject-introspection-1.66.1 (Required if > building GNOME), and Xorg Libraries > > Optional > > Cantarell fonts (for tests), GTK-Doc-1.33.1, help2man, and libthai > > > and whilst, later on, I read about these build switches I might be > able to use > > Command Explanations > > -Denable-docs: Use this switch if gtk-doc is installed and you wish > to > rebuild and install the API documentation. > > -Dgir=false: Use this switch if you do not want to use > gobject-introspection-1.66.1. > > > > however, although I'm not intending to build GNOME, it seems that > Pango's > lovely meson build system (Meson BS?) seems more than capable of > "determining" that I do want to really, and so tells me that cairo is > a run-time > depenedency, and so it's not going any further. > > How do I tell Pango that I don't want to build it with cairo ? > > I tried, well you would, wouldn't you: > > -Dcairo=false > > but no joy there. > > The NEWS file in the source tarball suggests that, once upon a time, > there > may have been a > > --with-cairo > > switch in the build system but, presumably something that obvious > didn't make > it out of Autotools-land when the python fan-boys took control? > > Any clues? > > I'm sure i can install Cairo, but the BLFS Book's suggestion that it > should not be needed got my hopes up ! > > Kevin Looking in more depth, normally, according to meson.build, the dependency on cairo is not required, even for 1.46. So it should be able to compile if cairo is not available. Also, I've grep'ed for "run.*time" in the source directory, and there is no sentence containing cairo and runtime or run-time or "run time"... What is the error message exactly? Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] 2020-09-03" Pango-1.46.0: Cairo is "Recommended" but seems to be Required
On Sat, 2021-01-02 at 19:57 +0800, Kevin Buckley via blfs-dev wrote: > Been working against the BLFS Version 2020-09-03, so Pango 1.46.0 > but BLFS Version 2021-01-01 with Pango 1.48.0 has the same text. > > I read, > > Pango Dependencies > > Required > > Fontconfig-2.13.1 (must be built with FreeType-2.10.4 using > HarfBuzz-2.7.4), FriBidi-1.0.9, and GLib-2.66.4 > > Recommended > > Cairo-1.17.2+f93fc72c03e, gobject-introspection-1.66.1 (Required if > building GNOME), and Xorg Libraries > > Optional > > Cantarell fonts (for tests), GTK-Doc-1.33.1, help2man, and libthai > > > and whilst, later on, I read about these build switches I might be > able to use > > Command Explanations > > -Denable-docs: Use this switch if gtk-doc is installed and you wish > to > rebuild and install the API documentation. > > -Dgir=false: Use this switch if you do not want to use > gobject-introspection-1.66.1. > > > > however, although I'm not intending to build GNOME, it seems that > Pango's > lovely meson build system (Meson BS?) seems more than capable of > "determining" that I do want to really, and so tells me that cairo is > a run-time > depenedency, and so it's not going any further. > > How do I tell Pango that I don't want to build it with cairo ? > > I tried, well you would, wouldn't you: > > -Dcairo=false > > but no joy there. > > The NEWS file in the source tarball suggests that, once upon a time, > there > may have been a > > --with-cairo > > switch in the build system but, presumably something that obvious > didn't make > it out of Autotools-land when the python fan-boys took control? > > Any clues? > > I'm sure i can install Cairo, but the BLFS Book's suggestion that it > should not be needed got my hopes up ! Well, looks like it is not optional in pango-1.46, but it is in pango- 1.48. Normally, you should look at meson_options.txt to determine which options are available. Note that "boolean" type is "true" or "false", but "feature" type is "enabled" or "disabled". In pango-1.48, disabling cairo is obtained with "-Dcairo=disabled" (note that the default is "auto", so disabling shouldn't be needed if cairo is not present). Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Why do we patch polkit for elogind ?
On Wed, 2020-12-30 at 18:21 +, Ken Moffat via blfs-dev wrote: > Hi Guys, > > some of you may have noticed that I have an aversion to gtk-doc (I'm > getting over it). This was triggered by occasional uses of > autoreconf now needing gtkdocize. That first hit me in polkit with > the patch for elogind, but my memory suggested that the patch has in > the past been added or rolled forward a little after updates to > polkit. > > So, I tried without the patch and (thus far) all of fluxbox, icewm, > openbox, sawfish don't need it. I'm still working through the other > packages which use autoreconf (and autoconf, to be sure), but so far > only polkit with the patch, and cairo, need gtkdocize. > > Cairo, of course, is why I've had to install gtk-doc. But when I > come to add gtk-doc as a dependency it would be better if I > understood why we patch polkit. Is it for users of desktop managers > and/or gnome shell (i.e. conventional startx will always work > without it), or is there a different reason ? Without a fix, "polkitunixsession" is linked to consolekit even if elogind is present. This means that it is impossible to register an authentication agent, or to use pkexec, for example. DEs that do not register an authentication agent do not need it, I guess. I'm sure conventional startx can be used to start lxde, and that without the patch, a warning is printed (about missing consolekit), so no, startx wouldn't always "work without it". Noe that it does not prevent the session to start. But it lacks several functionalities (ability to shutdown, hibernate, etc, without using the cli for example). Note that I think the patch could be rewritten to patch configure instead of configure.ac. That would remove the need to run autoconf. > > And a side question - mutter apparently gets invoked by gnome shell, > is there any way to do that without using a desktop manager ? I think you can start gnome without a dm, by putting "exec gnome- session" in .xinitrc. Now how to only start gnome-shell, I am not sure. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] elogind and rootless X
On Wed, 2020-12-30 at 15:29 +0100, Tim Tassonis via blfs-dev wrote: > Hi all > > I now seen to have everything in place for elogind and rootless X, > however, just calling startx still does not seem to work. > I get the following error on startx on the console: > > > [ 382.428] (EE) parse_vt_settings: Cannot open /dev/tty0 > (Permission > denied) > > > If I just call > > X vt7 > > I get: > > > [ 972.965] (EE) xf86OpenConsole: Cannot open virtual console 7 > (Permission denied) > > > However, I get a success using: > > startx -- vt1 > > , as /dev/tty1 seems to be my seat: > > > timtas@lfsda0:~$ loginctl > SESSION UID USER SEAT TTY > 4 1000 timtas pts/0 > 7 1000 timtas seat0 tty1 > > > So, is this all correct now, and I'm fine to go on? > Well, I've never have had to specify the vt with startx, so something is weird. Just to check: what is your version of elogind, and if using 246.9.1, have you applied the sed? sed -i '/running/,+1s:^://:' src/login/pam_elogind.c Also, the seat is tty1, but even without elogind, /dev/tty1 would be owned by you if logging in on it. Not sure exactly what is going on, though Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] harfbuzz-2.7.3 does not build the g-ir bindings with autotools
After updating to harfbuzz-2.7.3, gdm could not start, and the log had this: (gnome-shell:1641): Gjs-CRITICAL **: 13:52:47.640: JS ERROR: Error: Requiring Clutter, version 7: Typelib file for namespace 'HarfBuzz', version '0.0' not found @resource:///org/gnome/shell/ui/environment.js:13:66 After (quite) some investigations, I found that the file: /usr/lib/girepository-1.0/HarfBuzz-0.0.typelib was missing. The reason is: in "configure", there is: --- # Gobject-Introspection have_introspection=false if false; then HAVE_INTROSPECTION_TRUE= HAVE_INTROSPECTION_FALSE='#' else HAVE_INTROSPECTION_TRUE='#' HAVE_INTROSPECTION_FALSE= fi - So, no introspection, period. And at the end of configure there is: "Autotools is no longer our supported build system for building the library for *nix distributions, please migrate to meson." So I run: mkdir build && cd build meson --prefix=/usr -Dgraphite=enabled .. ninja sudo ninja install and everything is working again. Note that it builds the gtk-doc documentation if gtk-doc is found. -Ddocs=disabled allows to not built it. So I suggest moving to meson for harfbuzz. I'll do it after some time for allowing comments on this message. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] RFC: change the layout of Qt pages
Presently, in the book, we have two pages for the Qt library: one for full Qt, except we do not build qtwebengine, and another one for qtwebengine. This has a couple of drawbacks: - If a package needs only Qt core libraries, we require to build the whole Qt library. Building qtbase is just a couple of SBU, compared to the 22 SBU of the full Qt. Even KDE frameworks need just a handful of additional modules (which add not more than one SBU each, and several of them are much faster), and not the full qt. Also, building a full Qt for LXQt (which is supposed to be lightweight) is a big overkill... - when downloading the full Qt, qtwebengine is inside it. Then, when building qtwebengine, it is downloaded again. Since qtwebengine size is 247 MB, this is not insignificant... The proposition is the following: Two pages again, with: - first page for qtbase (~50 MB download, a couple of SBUs at -j4): this is where configure is run. Also the page would have /opt and startup file settings (as on the present Qt page), and .desktop file installation. - a second page with a layout similar to Xorg libs, KDE frameworks, and plasma, except the list of files would be divided into (tentative) "needed for LXQt", "needed in addition for KDE", "qtwebengine", and "optional not needed for the book", so that users would have information to build (and download) only what they need. The instructions for each module would be: qmake -- ; make; make install. But in most cases -- would not be needed. Maintenance would not be much harder (maybe a couple more measurements, but upstream provides a md5sum file). Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Bad kf5 URL ?
On Fri, 2020-12-11 at 12:39 -0600, Bruce Dubbs via blfs-dev wrote: > On 12/11/20 12:04 PM, Ken Moffat via blfs-dev wrote: > > On Fri, Dec 11, 2020 at 11:03:05AM -0600, Bruce Dubbs via blfs-dev > > wrote: > > > On 12/11/20 12:40 AM, Pierre Labastie via blfs-dev wrote: > > > > On Fri, 2020-12-11 at 02:43 +, Ken Moffat via blfs-dev > > > > wrote: > > > > > > > > > > Yes I've been bitten by that when trying to build LXQt. Note > > > > that it > > > > has nothing to do with jhalfs. Either put Attic instead of > > > > stable, or > > > > use a later version. > > > > > > Of course with a later version of kf5/plasma all the md5sums are > > > different. > > > > > > -- Bruce > > > > For plasma in particular, do not the dependencies (and perhaps even > > the available tarballs) change over time, so that we ought to stick > > to the current versions of both for the moment ? > > > > More generally, our releases are frozen at a point in time, and > > subject to errata. If a url becomes unusable, do we not fix that > > in the development book and add an erratum ? > > Most of the blfs packages we use are copied to > http://ftp.osuosl.org/pub/blfs/ as they are upgraded. An exception > to > that is kf5/plasma due to the number of packages and their size. The > size of the repository there is now 220G and has packages there going > back to BLFS-6.1 (2008). I do update osuosl virtually every day. > > What I think is appropriate is for this case is to add a note similar > to > the one in ImageMagick, but point it to Attic instead. > > > Pierre has explained to me on alfs-discuss about the jhalfs issue > > with kf5, I'll maybe come back to that next week. > > I do not use jhalfs for building BLFS. It is useful for showing the > order to build dependencies, but I have a long history of having BLFS > sources and scripts in /usr/src/. jhalfs does not support > that > organization and I do not want to re-download sources I already have. Just a note that I think this is possible with jhalfs (not tested much, because I do not have that layout): in envars.conf, set: export JH_SRC_ARCHIVE=/usr/src export JH_SRC_SUBDIRS=1 this should allow to have sources in /usr/src/. Of course, the scripts wouldn't reside there, since jhalfs creates its own scripts on the fly. > In addition, my scripts are instrumented to place logs and statistics > in > a consistent location tagged by which host built the package. Interesting. Right now the "work" directory (it contain the logs) can be manually moved to any location at the end of the build (that's what I do), but this could be automated and instrumented with some information (date, host, ...?). > > On the other hand, I find jhalfs invaluable for LFS. > > -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Bad kf5 URL ?
On Fri, 2020-12-11 at 02:43 +, Ken Moffat via blfs-dev wrote: > I must have been evil in a previous existence, because I'm not > trying to use jhalfs to build kde. > > In kf5 I stopped the build after a bit over an hour because nothing > was happening. The log said: > > > URL transformed to HTTPS due to an HSTS policy > --2020-12-11 02:14:37-- > https://download.kde.org/stable/frameworks/5.73/ > Resolving download.kde.org (download.kde.org)... 168.119.32.158, > 2a01:4f8:242:1ed5::3 > Connecting to download.kde.org > (download.kde.org)|168.119.32.158|:443... connected. > HTTP request sent, awaiting response... 302 Found > Location: https://download.kde.org/Attic/frameworks/5.73/ [following] > --2020-12-11 02:14:38-- > https://download.kde.org/Attic/frameworks/5.73/ > Reusing existing connection to download.kde.org:443. > HTTP request sent, awaiting response... 200 OK > Length: unspecified [text/html] > Saving to: ‘index.html.tmp’ > > 0K .. .. .. .. .. 686K > 50K .. .. > 24.3M=0.07s > Yes I've been bitten by that when trying to build LXQt. Note that it has nothing to do with jhalfs. Either put Attic instead of stable, or use a later version. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Qt 6 discussion
On Tue, 2020-12-08 at 15:54 -0600, Bruce Dubbs via blfs-dev wrote: > On 12/8/20 3:34 PM, Marty Jack via blfs-dev wrote: > > I see some discussion in the ticket on Qt 6.0. > > > > This is a case where you will need both Qt 5 and Qt 6 in parallel > > for potentially years, similar to the situation with GTK 2 and GTK > > 3 or Qt4 and Qt5. > > > > I predict very slow adoption of Qt 6 because they have deferred a > > lot of modules that are not expected until 6.2 in the fall of 2021 > > or later and they expect to repackage some classes into other > > modules. The two that affect me are qtmultimedia and qtwebengine. > > > > I had some trouble getting the directory layout the way I wanted it > > with cmake because it doesn't allow "..". > > -DCMAKE_INSTALL_PREFIX=/usr > > -DINSTALL_BINDIR=/usr/lib/qt6/bin > > -DINSTALL_DATADIR=/usr/share/qt6 > > -DINSTALL_DOCDIR=/usr/share/doc > > -DINSTALL_INCLUDEDIR=/usr/include/qt6 > > -DINSTALL_LIBDIR=/usr/lib > > -DINSTALL_LIBEXECDIR=/usr/lib/qt6/libexec > > -DINSTALL_MKSPECSDIR=/usr/lib/qt6/mkspecs > > -DINSTALL_PLUGINSDIR=/usr/lib/qt6/plugins > > -DINSTALL_QMLDIR=/usr/lib/qt6/qml > > -DINSTALL_SYSCONFDIR=/etc/xdg > > > > I don't plan to convert any code I work on to it or install any of > > it until something I build needs it or they ship qtmultimedia and > > qtwebengine. > > > Yes, it's way too early to add this package. I took a look at Arch > and > the only thing that depends on any of the modules so far are other > qt6 > modules. Yes, for some reason I haven't thought of all the implications of a new major version for Qt... As far as LXQt is concerned, Qt6 lacks the qtx11extras module, and I guess the API changes prevent building LXQt (and its kf5 dependencies) anyway. OTOH, I still plan to try various ways to build a trimmed down version of Qt, but I guess it should be another ticket (do not hold your breath)... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] asymptote fails to build with new ghostscript
On Thu, 2020-11-05 at 21:48 +0100, Pierre Labastie via blfs-dev wrote: > At some point, I get: > --- > /usr/bin/install -c -p -m 644 doc/asymptote.sty doc/asycolors.sty > doc/ocg.sty doc/latexmkrc /opt/texlive/2020/texmf- > dist/tex/latex/asymptote > /usr/bin/install -c -p -m 644 doc/colo-asy.tex > /opt/texlive/2020/texmf- > dist/tex/context/third/asymptote > cd doc && make man > make[2]: Entering directory '/sources/asymptote/asymptote-2.67/doc' > ../asy -dir ../base -config "" -render=0 -h 2>&1 | grep -iv Asymptote > > > options > ../asy -dir ../base -config "" -render=0 -f pdf -noprc axis3.asy > GPL Ghostscript 9.53.3: > *** EPS files may not contain multiple pages. > *** Use of the %d filename format is required to output pages to > multiple EPS files. > GPL Ghostscript 9.53.3: Unrecoverable error, exit code 1 > --- > Then nothing happens anymore. The build hangs. > > It's a known bug: > https://sourceforge.net/p/asymptote/discussion/409349/thread/a52414e613/?limit=25 > see also > https://github.com/vectorgraphics/asymptote/issues/176 > > There are two possibilities, fix ghostscript (only a proposal from > asymptote devs, not accepted upstream): > https://bugs.ghostscript.com/attachment.cgi?id=19921 > or fix asymptote (upstream commit > https://github.com/vectorgraphics/asymptote/commit/3361214340d58235f4dbb8f24017d0cd5d94da72 > ) > > Note that this is not present with ghostscript 9.52 > > I'll go with the the asymptote fix. I'll make a patch, no way for a > sed! > Done at revision 23876 Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] asymptote fails to build with new ghostscript
At some point, I get: --- /usr/bin/install -c -p -m 644 doc/asymptote.sty doc/asycolors.sty doc/ocg.sty doc/latexmkrc /opt/texlive/2020/texmf- dist/tex/latex/asymptote /usr/bin/install -c -p -m 644 doc/colo-asy.tex /opt/texlive/2020/texmf- dist/tex/context/third/asymptote cd doc && make man make[2]: Entering directory '/sources/asymptote/asymptote-2.67/doc' ../asy -dir ../base -config "" -render=0 -h 2>&1 | grep -iv Asymptote > options ../asy -dir ../base -config "" -render=0 -f pdf -noprc axis3.asy GPL Ghostscript 9.53.3: *** EPS files may not contain multiple pages. *** Use of the %d filename format is required to output pages to multiple EPS files. GPL Ghostscript 9.53.3: Unrecoverable error, exit code 1 --- Then nothing happens anymore. The build hangs. It's a known bug: https://sourceforge.net/p/asymptote/discussion/409349/thread/a52414e613/?limit=25 see also https://github.com/vectorgraphics/asymptote/issues/176 There are two possibilities, fix ghostscript (only a proposal from asymptote devs, not accepted upstream): https://bugs.ghostscript.com/attachment.cgi?id=19921 or fix asymptote (upstream commit https://github.com/vectorgraphics/asymptote/commit/3361214340d58235f4dbb8f24017d0cd5d94da72) Note that this is not present with ghostscript 9.52 I'll go with the the asymptote fix. I'll make a patch, no way for a sed! Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] If P2 modules are built for PyYaml and Markupsafe, then recommend P2
As the subject says... But another possibility is to not propose P2 modules at all for those packages. I'm almost sure nothing uses P2 modules for those packages: Markupsafe is here only for Mako and Jinja2, and we build only P3 for those packages. PyYAML is optional for llvm and kf5, and I think those use P3 only now... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] dbus needed for samba
When building samba with required and recommended and dependencies (but without dbus installed) on a SysV machine, I get (configure output): - [...] VFS_STATIC: vfs_default,vfs_not_implemented,vfs_posixacl VFS_SHARED: vfs_recycle,vfs_audit,vfs_extd_audit,vfs_full_audit,vfs_fake_perms,vfs_ default_quota,vfs_readonly,vfs_cap,vfs_expand_msdfs,vfs_shadow_copy,vfs _shadow_copy2,vfs_readahead,vfs_xattr_tdb,vfs_streams_xattr,vfs_streams _depot,vfs_acl_xattr,vfs_acl_tdb,vfs_preopen,vfs_catia,vfs_media_harmon y,vfs_unityed_media,vfs_fruit,vfs_shell_snap,vfs_commit,vfs_worm,vfs_cr ossrename,vfs_linux_xfs_sgid,vfs_time_audit,vfs_offline,vfs_virusfilter ,vfs_widelinks,vfs_snapper,vfs_fake_acls,vfs_nfs4acl_xattr,vfs_error_in ject,vfs_delay_inject,vfs_syncops,vfs_dirsort,vfs_fileid,vfs_aio_fork,v fs_aio_pthread,vfs_gpfs,vfs_btrfs,vfs_glusterfs_fuse PDB_STATIC: pdb_smbpasswd,pdb_tdbsam,pdb_ldapsam PDB_SHARED: AUTH_STATIC: auth_builtin,auth_sam,auth_winbind,auth_unix AUTH_SHARED: NSS_INFO_STATIC: nss_info_template NSS_INFO_SHARED: CHARSET_STATIC: CHARSET_SHARED: IDMAP_STATIC: idmap_tdb,idmap_passdb,idmap_nss,idmap_ldap IDMAP_SHARED: idmap_ad,idmap_rfc2307,idmap_autorid,idmap_rid,idmap_hash,idmap_tdb2,id map_script GPEXT_STATIC: GPEXT_SHARED: PERFCOUNT_STATIC: PERFCOUNT_SHARED: RPC_STATIC: rpc_mdssvc_module RPC_SHARED: Checking for dbus : not found vfs_snapper is enabled but prerequisite dbus-1 package not found. Use - -with-shared-modules=!vfs_snapper to disable vfs_snapper support. (complete log in /sources/samba/samba-4.13.0/bin/config.log) --- Note that "vfs_snapper" is in the long list after "VFS_SHARED:" This does not show up in systemd, and in my usual builds, I build dbus earlyn so it does not show up either. This time I have randomized the order of the requested packages (before running the blfs-tools dependency resolver), so it happens that samba is built before dbus. Owing to the fact that vfs_snapper may be disabled (see above), I'd add dbus to the recommended dependencies (only for SysV, of course). Is there a reason to either: - not do that - add it to required? Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] python2 as default python?
On Fri, 2020-10-23 at 07:00 +0100, Ken Moffat via blfs-dev wrote:
> On Thu, Oct 22, 2020 at 04:44:19PM +0100, Ken Moffat via blfs-dev
> wrote:
> > On Thu, Oct 22, 2020 at 11:24:52PM +0800, Xi Ruoyao via blfs-dev
> > wrote:
> > > On 2020-10-22 16:14 +0100, Ken Moffat via blfs-dev wrote:
> > > > On Thu, Oct 22, 2020 at 06:25:59AM -0500, Bruce Dubbs via blfs-
> > > > dev wrote:
> > > > > On 10/22/20 12:56 AM, DJ Lucas via blfs-dev wrote:
> > > > > > On October 21, 2020 10:48:39 PM CDT, Bruce Dubbs via blfs-
> > > > > > dev
> > > > > > wrote:
> > > > > > > On 10/21/20 10:06 PM, DJ Lucas via blfs-dev wrote:
> >
> > Ywah, I've now found a non-book package (youtube-dl) which defaults
> > to '/usr/bin/env python' (in its Makefile) but can be overridden by
> > passing PYTHON=/usr/bin/python3 (or probably just =python3).
> >
> > It turns out that whatever we do will probably cause some work.
> >
> Reluctantly, I have to go with a python symlink. Out of the more
> than 48000 tests in clang-11.0, one uses /usr/bin/env/python.
>
When we find something like that, couldn't we use:
grep -rl '#!.*python' | xargs sed -i
'1{s/python$/python3/;s/python[^3]/python3}'
or so?
Of course, P2 only scripts would still fail, but at least, nothing
would depend on a python symlink.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] gtkmm3 needs cairomm-1.14
On Thu, 2020-10-22 at 14:46 +0200, Pierre Labastie via blfs-dev wrote: > Actually, apart from cairomm, the C++ GTK stack has not been updated, > so gtkmm3 and pangomm require cairomm-1.0 (whose last release is > cairomm-1.14). > > I got an error while building gnome-system-monitor because of that. > The > other users of gtkmm3 are gparted, inkscape, and pavucontrol, as a > required dep in all cases. I do not have gparted nor pavucontrol, and > I > do not use inkscape very often. But actually, it cannot be built if > cairomm-1.14 is not installed, and it cannot start if cairomm-1.14 is > removed (using porg) after building cairomm-1.16. > > I'll add that page to the book. Both versions can be installed side > to > side without overlapping each other. > Done at revision 23833. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] gtkmm3 needs cairomm-1.14
Actually, apart from cairomm, the C++ GTK stack has not been updated, so gtkmm3 and pangomm require cairomm-1.0 (whose last release is cairomm-1.14). I got an error while building gnome-system-monitor because of that. The other users of gtkmm3 are gparted, inkscape, and pavucontrol, as a required dep in all cases. I do not have gparted nor pavucontrol, and I do not use inkscape very often. But actually, it cannot be built if cairomm-1.14 is not installed, and it cannot start if cairomm-1.14 is removed (using porg) after building cairomm-1.16. I'll add that page to the book. Both versions can be installed side to side without overlapping each other. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] python2 as default python?
On Thu, 2020-10-22 at 00:56 -0500, DJ Lucas via blfs-dev wrote: > On October 21, 2020 10:48:39 PM CDT, Bruce Dubbs via blfs-dev < > blfs-dev@lists.linuxfromscratch.org> wrote: > > On 10/21/20 10:06 PM, DJ Lucas via blfs-dev wrote: > > In LFS, we can make the symlink to p3. For p2 in BLFS, we will > > use > > 'make altinstall'. Everything else would be for non-python > > packages > > that either use p2 or create a p2 module. > > > > Ok, I'll go back and fix it that way locally then. I'm not too far. I > have only like 8 packages that have py2 optional deps listed. > > So for BLFS, just do it and fix on the fly, or create a tracker bug > and let the devs run through it a time or two? I don't think it's > going to be all that big of a deal, but might be nice to avoid any > interim breakage, do as one big commit or a small series of commits > to make it easier on people who are upgrading. > I think we have another problem besides gimp, which is lxde as it is in the book presently. Lxde with GTK+-2 wants pygtk, which is P2 only. I have changes in one of my sandboxes for moving LXDE to GTK+-3 (removing the need for P2), but there is one bug for which there is no patch available (in lxappearance-obconf, see https://sourceforge.net/p/lxde/bugs/768/). Upstream has done nothing about that bug, as with other bugs about GTK+-3, but for the other bugs, there are patches. So I have not put that into the book yet. If that bug is not considered a blocker, we could do the move. Another possibility is to remove LXDE and move to LXQt. But it would require some changes to the book to add a "Qt5-base" page, with only the relevant parts of Qt5 needed, and same for KF5. It would be silly to build full Qt5 and kf5 for a "lightweight" package. I am thinking about that with a way to not add too much maintenance burden. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Fwd: Re: mupdf
On Wed, 2020-10-14 at 11:52 -0500, Bruce Dubbs via blfs-dev wrote: > On 10/14/20 11:43 AM, Ken Moffat via blfs-dev wrote: > > On Tue, Oct 13, 2020 at 11:11:13AM -0500, Bruce Dubbs via blfs-dev > > wrote: > > > On 10/12/20 10:15 PM, Ken Moffat via blfs-dev wrote: > > > > On Mon, Oct 12, 2020 at 09:41:37PM -0500, Bruce Dubbs via blfs- > > > > dev > > > > wrote: > > > > > > They seem to be using system JBIG2DEC, JPEGXR, and GUMBO which we > > > do not > > > have. The package certainly doesn't document user.make. I see > > > it now for > > > the first time. The options -DJBIG_NO_MEMENTO -DTOFU -DTOFU_CJK > > > are > > > mysterious but appear to have soemthing to do with noto fonts. > > > > > > I can use that to do some tests, but I don't think it builds a > > > shared > > > library. Maybe we don't need a library though. > > > > > > > First, can I offer my thanks to both you and Pierre for your work > > on > > this. But I wonder if we really need the shared library. People > > know that I like shared libs, at least when they are properly > > versioned, but I'm happy to build static libs which are only used > > within the same package. > > > > For mupdf itself we install multiple variants, and one or two other > > programs. I guess that those link to the shared lib and therefore > > the size of each program is reduced. I have a vague recollection > > that in the past something external might have been able to use > > mupdf (/me looks ...) : zathura (see Arch - the mupdf dep is > > optional). > > > > As a heretical "run it up a pole and see who salutes it" option, > > maybe we could build the static lib and only install the useful > > progs (without headers or libraries) ? That begs the question, of > > course, "do we need all the variants of mupdf ?". Just a thought. > > We could do the static libraries, but I think we've got the shared > version working now. > >-- Bruce > Actually, the library contains fonts... So it's very big (30-40 MB). You need at least mutools (for cups-filters) and one mupdf (for displaying pdf's). With a static library, both would contain that big copy of the fonts. I think mupdfraster may be handy sometimes (replaces pdf2something). So that would be another big copy of the fonts... Why they can't use system fonts is another question, though... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Fwd: Re: mupdf
On Wed, 2020-10-14 at 15:41 +0200, Pierre Labastie via blfs-dev wrote: > On Tue, 2020-10-13 at 13:42 -0500, Bruce Dubbs via blfs-dev wrote: > > On 10/13/20 11:11 AM, Bruce Dubbs wrote: > > > > > > They seem to be using system JBIG2DEC, JPEGXR, and GUMBO which we > > > do not > > > have. The package certainly doesn't document user.make. I see > > > it > > > now > > > for the first time. The options -DJBIG_NO_MEMENTO -DTOFU > > > -DTOFU_CJK are > > > mysterious but appear to have soemthing to do with noto fonts. > > > > > > I can use that to do some tests, but I don't think it builds a > > > shared > > > library. Maybe we don't need a library though. > > > > > > I'll do some more with this tomorrow, thanks. > > > > > > - > > > > > > I was able to build mupdf with: > > > > > > > > > cat > user.make << EOF > > > USE_SYSTEM_FREETYPE := yes > > > USE_SYSTEM_HARFBUZZ := yes > > > USE_SYSTEM_JBIG2DEC := no > > > USE_SYSTEM_JPEGXR := no # not used without HAVE_JPEGXR > > > USE_SYSTEM_LCMS2 := no # need lcms2-art fork > > > USE_SYSTEM_LIBJPEG := yes > > > USE_SYSTEM_MUJS := no # build needs source anyways > > > USE_SYSTEM_OPENJPEG := yes > > > USE_SYSTEM_ZLIB := yes > > > USE_SYSTEM_GLUT := no # need freeglut2-art fork > > > USE_SYSTEM_CURL := yes > > > USE_SYSTEM_GUMBO := no > > > EOF > > > > > > export XCFLAGS=-fPIC && > > > > > > make $BFLAGS build=release && > > > make prefix=/usr install > > > > > > With the above I get: > > > > > > $ ll -h install/usr/lib > > > total 50M > > > -rw-r--r-- 1 bdubbs bdubbs 48M Oct 13 00:02 libmupdf.a > > > -rw-r--r-- 1 bdubbs bdubbs 2.2M Oct 13 00:02 libmupdf-third.a > > > > > > $ ll -h install/usr/bin > > > total 172M > > > -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-gl > > > -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-x11 > > > -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-x11-curl > > > -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 muraster > > > -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mutool > > > > > > If I add 'shared=yes to the 'make install' line, the build time > > > goes > > > from about 0.1 SBU to 0.7 SBU (at -j22) and the sizes are: > > > > > > $ ll -h install/usr/lib > > > total 46M > > > -rw-r--r-- 1 bdubbs bdubbs 46M Oct 13 10:58 libmupdf.so > > > > > > $ ll -h install/usr/bin > > > total 836K > > > -rwxr-xr-x 1 bdubbs bdubbs 364K Oct 13 10:58 mupdf-gl > > > -rwxr-xr-x 1 bdubbs bdubbs 72K Oct 13 10:58 mupdf-x11 > > > -rwxr-xr-x 1 bdubbs bdubbs 76K Oct 13 10:58 mupdf-x11-curl > > > -rwxr-xr-x 1 bdubbs bdubbs 35K Oct 13 10:58 muraster > > > -rwxr-xr-x 1 bdubbs bdubbs 287K Oct 13 10:58 mutool > > > > > > The extra time is used during the 'nmake install'. Adding > > > 'shared=yes' > > > to both the make and install lines fixes the build time. > > > > > > I think the package is good to go now. Will commit later today. > > > > Well it wasn't good. The linking was messed up. It took a while > > but > > I've got it solved and the package tested. Will update in a few > > minutes. > > > >-- Bruce > > > > I've tried the new instructions, and it failed to build because it > was > trying to link against the old libraries: > > /usr/bin/ld: build/shared-release/source/tools/murun.o: undefined > reference to symbol 'js_newuserdata' > /usr/bin/ld: /usr/lib/libmupdf-third.so: error adding symbols: DSO > missing from command line > collect2: error: ld returned 1 exit status > make: *** [Makefile:247: build/shared-release/mutool] Error 1 > make: *** Waiting for unfinished jobs > /usr/bin/ld: build/shared-release/source/tools/muraster.o: undefined > reference to symbol 'mu_unlock_mutex' > /usr/bin/ld: /usr/lib/libmupdf-threads.so: error adding symbols: DSO > missing from command line > collect2: error: ld returned 1 exit status > make: *** [Makefile:253: build/shared-release/muraster] Error 1 > > Removing previously installed libraries (and adding verbose=yes), I > get > another error: > --- > mkdir -p build/shared-release/ ; cc -Wl,--gc-sections -Wl,-
Re: [blfs-dev] Fwd: Re: mupdf
On Tue, 2020-10-13 at 13:42 -0500, Bruce Dubbs via blfs-dev wrote: > On 10/13/20 11:11 AM, Bruce Dubbs wrote: > > > > > > They seem to be using system JBIG2DEC, JPEGXR, and GUMBO which we > > do not > > have. The package certainly doesn't document user.make. I see it > > now > > for the first time. The options -DJBIG_NO_MEMENTO -DTOFU > > -DTOFU_CJK are > > mysterious but appear to have soemthing to do with noto fonts. > > > > I can use that to do some tests, but I don't think it builds a > > shared > > library. Maybe we don't need a library though. > > > > I'll do some more with this tomorrow, thanks. > > > > - > > > > I was able to build mupdf with: > > > > > > cat > user.make << EOF > > USE_SYSTEM_FREETYPE := yes > > USE_SYSTEM_HARFBUZZ := yes > > USE_SYSTEM_JBIG2DEC := no > > USE_SYSTEM_JPEGXR := no # not used without HAVE_JPEGXR > > USE_SYSTEM_LCMS2 := no # need lcms2-art fork > > USE_SYSTEM_LIBJPEG := yes > > USE_SYSTEM_MUJS := no # build needs source anyways > > USE_SYSTEM_OPENJPEG := yes > > USE_SYSTEM_ZLIB := yes > > USE_SYSTEM_GLUT := no # need freeglut2-art fork > > USE_SYSTEM_CURL := yes > > USE_SYSTEM_GUMBO := no > > EOF > > > > export XCFLAGS=-fPIC && > > > > make $BFLAGS build=release && > > make prefix=/usr install > > > > With the above I get: > > > > $ ll -h install/usr/lib > > total 50M > > -rw-r--r-- 1 bdubbs bdubbs 48M Oct 13 00:02 libmupdf.a > > -rw-r--r-- 1 bdubbs bdubbs 2.2M Oct 13 00:02 libmupdf-third.a > > > > $ ll -h install/usr/bin > > total 172M > > -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-gl > > -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-x11 > > -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-x11-curl > > -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 muraster > > -rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mutool > > > > If I add 'shared=yes to the 'make install' line, the build time > > goes > > from about 0.1 SBU to 0.7 SBU (at -j22) and the sizes are: > > > > $ ll -h install/usr/lib > > total 46M > > -rw-r--r-- 1 bdubbs bdubbs 46M Oct 13 10:58 libmupdf.so > > > > $ ll -h install/usr/bin > > total 836K > > -rwxr-xr-x 1 bdubbs bdubbs 364K Oct 13 10:58 mupdf-gl > > -rwxr-xr-x 1 bdubbs bdubbs 72K Oct 13 10:58 mupdf-x11 > > -rwxr-xr-x 1 bdubbs bdubbs 76K Oct 13 10:58 mupdf-x11-curl > > -rwxr-xr-x 1 bdubbs bdubbs 35K Oct 13 10:58 muraster > > -rwxr-xr-x 1 bdubbs bdubbs 287K Oct 13 10:58 mutool > > > > The extra time is used during the 'nmake install'. Adding > > 'shared=yes' > > to both the make and install lines fixes the build time. > > > > I think the package is good to go now. Will commit later today. > > Well it wasn't good. The linking was messed up. It took a while > but > I've got it solved and the package tested. Will update in a few > minutes. > >-- Bruce > I've tried the new instructions, and it failed to build because it was trying to link against the old libraries: /usr/bin/ld: build/shared-release/source/tools/murun.o: undefined reference to symbol 'js_newuserdata' /usr/bin/ld: /usr/lib/libmupdf-third.so: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make: *** [Makefile:247: build/shared-release/mutool] Error 1 make: *** Waiting for unfinished jobs /usr/bin/ld: build/shared-release/source/tools/muraster.o: undefined reference to symbol 'mu_unlock_mutex' /usr/bin/ld: /usr/lib/libmupdf-threads.so: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make: *** [Makefile:253: build/shared-release/muraster] Error 1 Removing previously installed libraries (and adding verbose=yes), I get another error: --- mkdir -p build/shared-release/ ; cc -Wl,--gc-sections -Wl,-s -o build/shared-release/mutool build/shared-release/source/tools/mutool.o build/shared-release/source/tools/muconvert.o build/shared- release/source/tools/mudraw.o build/shared-release/source/tools/murun.o build/shared-release/source/tools/mutrace.o build/shared- release/source/tools/cmapdump.o build/shared- release/source/tools/pdfclean.o build/shared- release/source/tools/pdfcreate.o build/shared- release/source/tools/pdfextract.o build/shared- release/source/tools/pdfinfo.o build/shared- release/source/tools/pdfmerge.o build/shared- release/source/tools/pdfpages.o build/shared- release/source/tools/pdfposter.o build/shared- release/source/tools/pdfshow.o build/shared- release/source/tools/pdfsign.o -lm -lfreetype -lharfbuzz -ljpeg -lz -lopenjp2 -lpthread -lcrypto -lmupdf /usr/bin/ld: cannot find -lmupdf collect2: error: ld returned 1 exit status make: *** [Makefile:247: build/shared-release/mutool] Error 1 --- After changing "-lmudpf' in the sed to "-lmudpf -L$(OUT)", it could build at -j1. But I got a race condition at -j4, so that I had to change again the sed to remove the "s/.(MUPDF_LIB)//" line. Will commit. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfro
Re: [blfs-dev] lxdm killing processes on logout
On Wed, 2020-10-07 at 23:33 +0200, Pierre Labastie via blfs-dev wrote: > On Wed, 2020-10-07 at 22:48 +0200, Pierre Labastie via blfs-dev > wrote: > > On Sun, 2020-09-20 at 17:22 -0400, Joe Locash via blfs-dev wrote: > > > I've been battling this problem and would appreciate a sanity > > > check. > > > In my testing of lxde any screen session I start and then detach > > > from > > > gets killed when I logout. If I bypass lxdm by changing run level > > > to > > > 3 and using startx to start lxde and then logout the screen > > > session > > > survives. > > > > > > This also happens in a systemd build. > > > > > > It's not a config issue. I build both elogind and systemd to not > > > kill > > > user processes on logout. > > > > > > Thoughts? > > > > Been pinged privately, but answering publicly. Sorry for not doing > > that > > earlier. I usually use gdm, and have never tried to keep any > > personal > > process open when loging out. > > But now, as you may have seen from the ticket, I've built lxdm > > (under > > gtk+-3), so I can try to reproduce. > > If I understand correctly, you start a screen session under lxde > > (started with lxdm), detach from that session (I'm not sure how to > > do > > that), then logout, which means you get back to the lxdm loging > > screen. > > But all your processes are killed then (including screen). You test > > that through a ssh connection or so? > > > > the other way, you start lxde from a linux console, you sart screen > > and > > detach, then you exit lxde, then you logout from the linux console. > > Or > > are you doing something different? > > > > I'll try and get back when I can confirm that behavior. > > > > I seem to observe the same behavior. Will look at it in more details > tomorrow. > FWIIW, neither lightdm, nor gdm kill the screen process... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] lxdm killing processes on logout
On Wed, 2020-10-07 at 22:48 +0200, Pierre Labastie via blfs-dev wrote: > On Sun, 2020-09-20 at 17:22 -0400, Joe Locash via blfs-dev wrote: > > I've been battling this problem and would appreciate a sanity > > check. > > In my testing of lxde any screen session I start and then detach > > from > > gets killed when I logout. If I bypass lxdm by changing run level > > to > > 3 and using startx to start lxde and then logout the screen session > > survives. > > > > This also happens in a systemd build. > > > > It's not a config issue. I build both elogind and systemd to not > > kill > > user processes on logout. > > > > Thoughts? > > Been pinged privately, but answering publicly. Sorry for not doing > that > earlier. I usually use gdm, and have never tried to keep any personal > process open when loging out. > But now, as you may have seen from the ticket, I've built lxdm (under > gtk+-3), so I can try to reproduce. > If I understand correctly, you start a screen session under lxde > (started with lxdm), detach from that session (I'm not sure how to do > that), then logout, which means you get back to the lxdm loging > screen. > But all your processes are killed then (including screen). You test > that through a ssh connection or so? > > the other way, you start lxde from a linux console, you sart screen > and > detach, then you exit lxde, then you logout from the linux console. > Or > are you doing something different? > > I'll try and get back when I can confirm that behavior. > I seem to observe the same behavior. Will look at it in more details tomorrow. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] lxdm killing processes on logout
On Sun, 2020-09-20 at 17:22 -0400, Joe Locash via blfs-dev wrote: > I've been battling this problem and would appreciate a sanity check. > In my testing of lxde any screen session I start and then detach from > gets killed when I logout. If I bypass lxdm by changing run level to > 3 and using startx to start lxde and then logout the screen session > survives. > > This also happens in a systemd build. > > It's not a config issue. I build both elogind and systemd to not kill > user processes on logout. > > Thoughts? Been pinged privately, but answering publicly. Sorry for not doing that earlier. I usually use gdm, and have never tried to keep any personal process open when loging out. But now, as you may have seen from the ticket, I've built lxdm (under gtk+-3), so I can try to reproduce. If I understand correctly, you start a screen session under lxde (started with lxdm), detach from that session (I'm not sure how to do that), then logout, which means you get back to the lxdm loging screen. But all your processes are killed then (including screen). You test that through a ssh connection or so? the other way, you start lxde from a linux console, you sart screen and detach, then you exit lxde, then you logout from the linux console. Or are you doing something different? I'll try and get back when I can confirm that behavior. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] LXDE and GTK+-3
On Tue, 2020-10-06 at 11:57 +0200, Pierre Labastie via blfs-dev wrote:
> On Wed, 2020-09-30 at 17:21 -0400, Joe Locash via blfs-dev wrote:
> > I'm curious why LXDE is built against GTK+-2 instead of 3. The only
> > mention of GTK+-3 for LXDE is in the lxsession page, which is
> > wrong.
> > libunique is listed as required. It isn't needed at all and I
> > believe
> > can be removed from the book.
> >
> > By building the other LXDE packages against GTK3 other packages
> > can
> > also be removed: vte-0.28.2, keybinder-0.3.1, and libwnck-2.30.7.
> > The
> > updated versions of those (already in the book) will be used
> > instead.
> >
> > Having said that, there was an issue I had in lxpanel but is
> > fixed
> > with a patch posted to a bug report for lxpanel which can be found
> > here: https://sourceforge.net/p/lxde/bugs/773/
>
>
Hi Joe,
Haven't you had another problem with lxsession? I had to remove some
.stamp files, to force vala to be run again and generate programs
compatible with gtk-3. Otherwise the build fails because of errors
("GtkObject not found" or so).
Haven't you seen that? Just checking because it may be an error on my
side. Passing --enable-gtk3 was not enough.
Otherwise, I am now running lxde without gtk2, and what is even more
important, without python2!
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] gobject-introspection should be recommended for harfbuzz
Usually, the first thing I do after building a new lfs VM, and the necessary tools to run jhalfs, is to build elogind first. In that case, jhalfs builds gobject-introspection early. This time, I've decided to ask jhalfs to directly install lxde-common, using only required and recommended dependencies: it generated a build order where harfbuzz comes before gobject-introspection. That's not wrong since g-ir is optional for harfbuzz. But then, when building pango, it fails because it cannot find harfbuzz.gir. Since pango is pretty sure to be needed by users building harfbuzz, I think g-ir should be recommended instead of optional for harfbuzz (with a statement that it can be omitted if pango is not to be built). Is there a reason for not doing that? Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] LXDE and GTK+-3
On Wed, 2020-09-30 at 17:21 -0400, Joe Locash via blfs-dev wrote: > I'm curious why LXDE is built against GTK+-2 instead of 3. The only > mention of GTK+-3 for LXDE is in the lxsession page, which is wrong. > libunique is listed as required. It isn't needed at all and I believe > can be removed from the book. > > By building the other LXDE packages against GTK3 other packages can > also be removed: vte-0.28.2, keybinder-0.3.1, and libwnck-2.30.7. The > updated versions of those (already in the book) will be used > instead. > > Having said that, there was an issue I had in lxpanel but is fixed > with a patch posted to a bug report for lxpanel which can be found > here: https://sourceforge.net/p/lxde/bugs/773/ Hmmm, this message went to my spam folder, and I see that nobody has answered, sorry for the delay. I once tried to port lxde to gtk+3 (ticket http://wiki.linuxfromscratch.org/blfs/ticket/11679), and it failed because at the time the various bugs had not fix. Maybe it is time to reopen the ticket... Thanks for the report. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Are the seds in gcr, seahorse, gsettings-desktop-schemas, and gnome-keyring really needed?
On Sat, 2020-10-03 at 20:54 +0800, Xi Ruoyao via blfs-dev wrote: > On 2020-10-03 13:03 +0200, Pierre Labastie via blfs-dev wrote: > > Hi, > > > > This morning, while updating to gcr-3.38, I realized that there was > > a > > sed to change the schema path from "/desktop/gnome/crypto/pgp/" to > > "/org/gnome/desktop/gnome/crypto/pgp/". It seemed a little weird, > > so I > > looked at what some distros do: neither archlinux nor debian change > > anything. > > > > This sed, together with similar ones in the pages listed in the > > subject, were added long ago "to fix deprecated paths". I am almost > > sure this is not necessary. But even if it is, I'm almost sure > > (again) > > that "modern" paths are either of the form "/org/gnome/..." or > > "/org/freedesktop/...". > > > > So the sed for gcr should be to "/org/gnome/crypto/pgp/", and a > > similar > > one in gnome-keyring. For seahorse and gsettings-desktop-schemas, > > the > > seds give a path of the right form. > > > > But all in all do we need that? What does it fix? > > I remember sometimes I missed it and glib-compile-schemas printed a > warning > regarding this. > Ah ok, thanks. I think that only gcr and gnome-keyring sed's should be changed to prevent those weird /org/gnome/desktop/gnome/... paths. Will do Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Are the seds in gcr, seahorse, gsettings-desktop-schemas, and gnome-keyring really needed?
Hi, This morning, while updating to gcr-3.38, I realized that there was a sed to change the schema path from "/desktop/gnome/crypto/pgp/" to "/org/gnome/desktop/gnome/crypto/pgp/". It seemed a little weird, so I looked at what some distros do: neither archlinux nor debian change anything. This sed, together with similar ones in the pages listed in the subject, were added long ago "to fix deprecated paths". I am almost sure this is not necessary. But even if it is, I'm almost sure (again) that "modern" paths are either of the form "/org/gnome/..." or "/org/freedesktop/...". So the sed for gcr should be to "/org/gnome/crypto/pgp/", and a similar one in gnome-keyring. For seahorse and gsettings-desktop-schemas, the seds give a path of the right form. But all in all do we need that? What does it fix? Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] sysv: postgresql boot script does not report an error if server cannot be started
The postgresql boot script uses: su - postgres -c '/usr/bin/pg_ctl start -W -D /srv/pgsql/data \ -l /srv/pgsql/data/logfile -o "-i" ' to start the server. The problem is that the -W option prevents the command to exit with an error, even if the server is not started. From the man page for pg_ctl: -W --no-wait Do not wait for the operation to complete. This is the opposite of the option -w. If waiting is disabled, the requested action is triggered, but there is no feedback about its success. In that case, the server log file or an external monitoring system would have to be used to check the progress and success of the operation. --- When updating to major version 13, the database has to be recreated (see release notes), but I failed to do that, so the server could not start... And the only failure was when shutting down the machine, because the .pid file did not exist. So I think the -W switch should be removed. Also, pg_ctl outputs "server starting ...\n", so the green "success" is not aligned with the "starting ..." line (not a big deal, but maybe the "-s" (silent) switch could be used...). Will wait for your thoughts for a day or so, then commit those changes. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Heads up: use of system lcms2 in ghostscript and mupdf is not thread safe
Hi, People at Artifex (who ship ghostscript and mupdf) have concerns with lcms2 not being thread safe. So they have forked it: https://www.ghostscript.com/doc/lcms2mt/doc/WhyThisFork.txt and they bundle lcms2mt (mt for multithread) into the respective packages. Right now, we use system lcms2 (patch in mupdf, directory removal in gs). So, if anybody gets weird errors with colors (I'm not sure in which circumstances) when using gs or mudpf, it may be that they have it that issue. Of course, we could revert to use the bundled lcms2mt, but there are two drawbacks: - risk of not having the latest version of lcms2 in those packages - the bundled library is statically linked into the executable, making it bigger... Not that future versions of the software may not be compatible anymore with system lcms2 at all (there are mandatory API changes to make the library thread safe). This message is for the record, but others may have something to say, so please do. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] accounts-daemon bootscript is not needed
Hi,
Since there is a dbus service file for accounts-daemon
(/usr/share/dbus-1/system-services/org.freedesktop.Accounts.service),
there is no need to start it at boot time: it will be automatically
started by d-bus if needed. I've tested removing the bootscript, and
after logging in to gdm, the acounts-service daemon is running.
I'll remove the bootscript installation from the accounts-service page
(sysv of course). Note that there is something weird in the bootscript
itself, since it remains in the process table ("ps aux" shows it).
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] new libnsl 1.3.0 not in book
On Fri, 2020-09-25 at 08:54 +0200, Tim Tassonis via blfs-dev wrote: > > On 9/25/20 8:39 AM, Tim Tassonis via blfs-dev wrote: > > Hi all > > > > I just noticed that although there was a new release of libnsl, > > version > > 1.3.0, released on Jul 6, it is not in the book, nor is there a > > ticket > > for it. > > > > I have downloaded and successfully built it on a fresh lfs 10.0 > > system, > > with minor modifications to the instructions from 1.2.0: > > > > - autoreconf -fi is gone > > > > I also had to add: > > > > TIRPC_CFLAGS="-I/usr/include/tirpc" export TIRPC_CFLAGS > > TIRPC_LIBS="-ltirpc" export TIRPC_LIBS > > > > as it fails to detect the present /usr/lib/pkgconfig/libtirpc.pc > > Correction: the TIRPC_CFLAGS and TIRPC_LIBS is unnecessary, I forgot > to > install pkg-config. After doing that, it finds tirpc just fine, and > builds without any problems. > > Thanks for the report. Making two tickets: - one for new version - the other one for updating the currency script. Regards Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] glib-2.66.0 meson fallback and gtk-doc
On Sat, 2020-09-19 at 22:46 +1000, Wayne Blaszczyk via blfs-dev wrote: > Hi All, > > Not sure if anyone else has noticed this, but with the right > conditions, glib-2.66.0 will install gtk-doc-1.32.1. > On a fresh build box I had gtk-doc-1.32 installed, and was in the > process of building glib-2.66.0 (for the second time) when it failed > with a git not found error. I have not seen that, because I used the book instructions verbatim, and we do not pass -Dgtk_doc=true (BTW, the book is wrong, there is no "doc" option, it is "gtk_doc"). > On closer inspection, it was trying to git clone gtk-doc repo due to > not meeting the gtk-doc >= 1.32.1 requirement as a fallback. > After installing git, this time the glib-2.66.0 build was > successfully and on closer inspection, it had actually installed the > gtk-doc-1.32.1 subproject. > what make it worse is that there is no gtk-doc 1.32.1 release, but in > fact just the latest from git repo from what I can tell. > This is not the first time I had noticed a "fallback" with a meson > gnome package build recently. I'm not happy that dependencies are > being installed without consent. Well, we'll have more and more to live with that. It's already the case for rust packages, python modules (setup.py downloads dependencies if needed), perl modules if you use cpan, java jars if you use maven, needed packages for libreoffice, and so on... With the notable exception of Ken for perl modules, book editors don't always try to mention those dependencies, because it is too time consuming, and it means adding a lot of packages to the book. Sometimes, downloading a non released version of a package is necessary (see cairo, for example) for other packages to be functional. In this case, gtk-doc is a circular dependency (it depends on glib2, but can use an older version). Maybe we could do like cairo, and provide gtk-doc "1.32.1" on anduin... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Linux-PAM (System V)
On Tue, 2020-09-15 at 19:14 -0400, Joe Locash via blfs-dev wrote: > Linux-PAM will create /usr/lib/systemd/system/pam_namespace.service > even when building on SystemV. > > This can cause > packages like make-ca (because it checks for the directory) to > install files not needed to be installed also. Confirmed. There are two solutions: either sed -i /service_DATA/d modules/pam_namespace/Makefile.am autoreconf # before running configure or rm -r /usr/lib/systemd # as root, after make install Thanks for reporting Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] clang as a hard dependency, was Re: firefox (and js) -> rust -> llvm dependency
On Tue, 2020-09-08 at 12:19 +0100, Ken Moffat via blfs-dev wrote: > [... trimming to keep just the question ...] > I guess the real question is: > > Do BLFS users build llvm without clang, and if so, what do they use > it for ? > I (or ranter jhalfs for blfs) always build llvm with clang and compiler-rt. For some packages, clang gets used instead of gcc. I've never tried to measure what is gained or lost because of that. I think llvm standalone is mainly used by various mesa drivers (llvmpipe, amdgpu). Maybe also by a few audio/video codecs, but not sure. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] symbol versioning in openssl
On Tue, 2020-09-08 at 11:51 +0200, Tim Tassonis via blfs-dev wrote: > Hi all > > Maybe a bit off-topic, but a while ago, the BLFS book had > instructions > on how to build openssl with symbol versioning, so openssl-1.0 and > openssl-1.1 can be mixed. As openssl-1.0 is out now, this seems to > have > been removed, but maybe somebody still remembers the instruction. I > now > have a program linking against a library that links to openssl-1.0, > but > itself requires openssl-1.1. > > Guess this is what you're looking for: http://www.linuxfromscratch.org/blfs/view/8.3/postlfs/openssl10.html Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] VLAN support in BLFS network scripts
On Thu, 2020-09-03 at 21:47 +0200, Tim Tassonis via blfs-dev wrote:
>
> On 9/1/20 7:55 PM, Bruce Dubbs via blfs-dev wrote:
> > On 9/1/20 12:24 PM, Tim Tassonis via blfs-dev wrote:
> > > Hi all
> > >
> > > As one of Switzerland largest ISP's requires pppoe with vlan
> > > tagging
> > > for fiber connections, I wondered if vlan tagging could get
> > > supported
> > > in the network scripts.
> > >
> > > As I found out via https://wiki.archlinux.org/index.php/VLAN, one
> > > can
> > > create a tagged VLAN using
> > >
> > > ip link add link $REAL_IFACE name $VLAN_IFACE type vlan id
> > > $VLAN_ID
> > >
> > > , so I guess this could be implemented by
> > >
> > > - checking for $VLAN_IFACE and $VLAN_ID being set
> > > - checking for $VLAN_ID and $REAL_IFACE (in which case IFACE
> > > then
> > > holds the $VLAN_IFACE)
> > >
> > > The latter would probably be more consistent with other network
> > > stuff,
> > > where iface always holds the resulting interface, and not the
> > > physical
> > > one.
> > >
> > > I could add this to /lib/services/pppoe, if anyone else cares.
> > > I'm not
> > > sure if, apart from pppoe, anyone else is interested in vlan
> > > stuff.
> > > I'm not even sure /lib/services/pppoe is still in blfs
> > >
> > > If yes, I could also add this to ipv4-static and dhcpcd.
> >
> > Tim, Can you send me a patch that I can review? I would want to
> > make
> > sure that changes will not affect users that do not need them.
>
> The patch against the pppoe service file I got is as follows:
>
>
> --- pppoe-service 2018-04-18 19:18:07.739547066 +0200
> +++ pppoe-service-vlan2020-09-03 21:37:27.613134901 +0200
> @@ -46,11 +46,24 @@
> exit 1
> fi
>
> +if [ "x${REAL_IFACE}" != "x" ] && [ "x$x${REAL_IFACE}" != "x" ]
I'm not sure what you want to do above: if the first test is true, the
second is true too, whatever the value of $x. Typo?
> +then
> + VLAN="Y"
> + /sbin/modprobe 8021q
> +else
> + VLAN="N"
> +fi
> +
> case "${2}" in
> up)
> /sbin/modprobe pppoe
> log_info_msg2 "\n"
> if is_true ${MANAGE_IFACE}; then
> +if [ "${VLAN}" = "Y" ]
> +then
> + /sbin/ip link set dev ${REAL_IFACE} up
> + /sbin/ip link add link ${REAL_IFACE} name ${IFACE} type
> vlan
> id ${VLAN_ID}
> +fi
> log_info_msg "Bringing up the ${IFACE} interface..."
> /sbin/ip link set dev ${IFACE} up
> evaluate_retval
> @@ -68,6 +81,11 @@
> if is_true ${MANAGE_IFACE}; then
> log_info_msg "Bringing down the ${IFACE} interface..."
> /sbin/ip link set dev ${IFACE} down
> +if [ "${VLAN}" = "Y" ]
> +then
> + /sbin/ip link set dev ${REAL_IFACE} down
> + /sbin/ip link del ${IFACE}
> +fi
> evaluate_retval
> fi
> ;;
>
>
>
> I'm not sure if this corresponds to latest BLFS, but I think it's
> pretty
> self-explanatory:
>
> - It checks for ${REAL_IFACE} and ${VLAN_ID} early on and then sets
> VLAN=Y and modprobes the vlan module in the kernel
>
> - In up, if MANAGE_IFACE is true, and VLAN=Y, it ups the REAL_IFACE
> and
> then adds the VLAN tagged iface
>
> - In down, it does the corresponding cleanup, if MANAGE_IFACE is
> true,
> and VLAN=Y
>
>
> If ${REAL_IFACE} and ${VLAN_ID} are not both set, it will do nothing
> special.
>
> I attach the service file and a corresponding ifconfig.ppp0, this
> currently works for me and brings the interface up cleanly.
>
> Bye
> Tim
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Fwd: Plasma-wayland-protocols install path
On Mon, 2020-08-31 at 16:40 -0500, Timothy Russo via blfs-dev wrote: > I've been struggling to get kf5 plasma-framework-5.73.0 to compile > and in my troubleshooting I came across the fact that plasma-wayland- > protocols is hard coded to use /usr as the install prefix, but the > installed directories shows it as $KF5_PREFIX/share/plasma-wayland- > protocols. > > the cmake line needs to be cmake -DCMAKE_INSTALL_PREFIX=$KF5_PREFIX > .. Hmmm, I haven't seen this. I've built plasma-wayland-protocols (in /usr) before the frameworks, and everything went Ok. > > This didn't fix the problem I'm having with plasma-framework-5.73.0 > though, which turned out to be some libraries in /usr/lib64 instead > of /usr/lib. You may be lacking some sed in cmake and in extra-cmake-modules > I'm not sure how many of us are using KDE on LFS, but everytime I've > tried to use build KDE I've run into tons of issues. xfce and even > mate work great, Gnome is a little painful, but KDE is a huge pain to > get working, and then it never seems quite right. The version ins 10.à worked without a problem for me. > Has anyone got KDEconnect to work with LFS? Thanks for mentioning this application, will give it a try. I see that the phone and the computer need to be on the same network, so it does not work in a VM, unless using a bridge (which I don't use ATM). Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] blfs-systemd-units-20200415
On Thu, 2020-08-27 at 18:31 -0400, Joe Locash via blfs-dev wrote: > When doing just a make a list of install targets should be displayed. > The Makefile greps for "^install" in Makefile.systemd which doesn't > exist. It should grep in Makefile Thanks for the report. A new version of the units should appear tomorrow. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] BIND Utilities-9.16.5 man pages
On Thu, 2020-08-13 at 17:31 -0400, Joe Locash via blfs-dev wrote:
> It seems bind now does not build the man pages. I had to do it
> manually after building the utilities:
> make man
> then as root
> cp -v doc/man/{dig,host,nslookup}.1 /usr/share/man/man1
Thanks for the report, fixed at revision 23529
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] asciidoc-9.0.2 requirements
On Wed, 2020-08-12 at 14:54 -0400, Joe Locash via blfs-dev wrote: > asciidoc will not build without libxml2 or libxslt installed. To > reproduce simply try building it on a fresh LFS install. Looks like it is a packaging problem: doc/testasciidoc.1 is not shipped, while the other manpages are. I've reported it upsteam: https://github.com/asciidoc/asciidoc-py3/issues/136 If upstream decides to address the issue, this should solve the problem. Meanwhile, there is apparently no easy workaround. OTOH, libxslt and docbook-xsl should at least be recommended at runtime anyway. Note that asciidoc itself does not need them. Only a2x and testasciidoc uses them. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] glibc-2.32 removal of sysctl.h
On Wed, 2020-08-12 at 02:40 +0100, Ken Moffat via blfs-dev wrote: > I think this is a genuine issue for BLFS with glibc-2.32, my only > intended deviations from the current LFS book are newer check and > using 5.8.1-rc1 headers and kernel - and I see that 5.8.1 is now > released, plus (of course) my own CFLAGS. > > Yhe 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. > > and I've now hit that with seamonkey: > > In file included from /scratch/working/seamonkey- > 2.53.3/mozilla/memory/build/mozjemalloc.cpp:224: > /scratch/working/seamonkey-2.53.3/obj-x86_64-pc-linux- > gnu/dist/system_wrappers/sys/sysctl.h:3:15: fatal error: > sys/sysctl.h: No such file or directory > 3 | #include_next > | ^~ > compilation terminated. > > I'll note that firefox built ok, this was just an attempt to drop in > a second browser until I can get qtwebengine built (and yes, I know > an issue for that has already been reported). > > Fedora are using glibc-32 and have a patch against seamonkey-2.53.2: > https://src.fedoraproject.org/rpms/seamonkey/blob/master/f/seamonkey-2.53.2-sysctl.patch > > looks as if a sed to delete the line from > mozilla/memory/build/mozjemalloc.cpp should do the job, but I > dislike using a sed to delete 3 lines (it's fine until the next > version, then you have to work out if it still does what was > intended), I thoght adding '&& !defined( XP_LINUX)' to the previous > line might do it : > > sed -i 's/!defined.XP_SOLARIS.*/& \&\& !defined(XP_LINUX)/' \ > mozilla/memory/build/mozjemalloc.cpp > > But that has the same problem that it is not at all obvious what is > being changed (turned off rather than deleted). I did a quick > gurgle for deleting lines before and after a match with sed, the > suggestions looked horrendous (and might have memory implications > because sed only works on the current patternspace). Why not just remove the line with #include? It would leave a #if ... #endif with empty body, which shouldn't be a problem: sed /sysctl/d -i mozilla/memory/build/mozjemalloc.cpp > > For maintenance, I think I'm going to go with the patch from fedora. > Testing now. > > ĸ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-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] graphviz 2.44.1 does not build if ghostscript is not installed
I get: - false cdt.3.ps cdt.3.pdf make[3]: *** [Makefile:1112: cdt.3.pdf] Error 1 - The reason is that if ps2pdf is not found, it is set to "false". Note that this has been true for years, but until recently, ps2pdf was used in a pipe, and that somehow did not stop "make". An easy workaround is to add PS2PDF=true to configure. Note that also ghostscript should be added as optional. Please speak up if there is anything wrong. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] a ttf font is required for cups-filters
On Tue, 2020-06-16 at 18:00 +0200, Pierre Labastie via blfs-dev wrote: > On Tue, 2020-06-16 at 16:24 +0100, Ken Moffat via blfs-dev wrote: > > On Tue, Jun 16, 2020 at 10:06:19AM -0500, Douglas R. Reno via blfs- > > dev wrote: > > > On 6/16/20 9:37 AM, Pierre Labastie via blfs-dev wrote: > > > > cups-filter-1.27.5 needs a font for its tests. The default one > > > > is > > > > DejaVuSans.ttf, but this can be changed with the --with-test- > > > > font-path > > > > switch. Normally this font is only used for tests, so shouldn't > > > > be > > > > required, but configure fails if DejaVuSans.ttf or the > > > > specified > > > > font > > > > is not installed. > > > > > > > > There are two possibilities: > > > > - make DejaVu fonts recommended > > > > - tweak configure so that it does not error out if the font is > > > > not > > > > there. > > > > > > > > Pierre > > > > > > > > > > > I suggest making the DejaVu fonts recommended. If I remember > > > correctly, this > > > isn't the only package that relies off their existence. I could > > > be > > > wrong > > > about that though :) > > > > > > - Doug > > > > > My memory says the same, but after yesterday I know I'm often > > flakey. > > > > For a desktop, I do not understand why anyone who natively uses an > > alphabetic language would NOT install DejaVu Sans. But for a > > server, probably it seems like useless overhead. > > > > However, we already list the DejaVu fotns as Optional (required for > > the tests), so I suggests changng them to Recommended (required for > > the tests). > > > > I often think it is nice to indicate _why_ something is > > recommended. > > > > Will do that, and for avahi, tell it is needed for cups-browsed, > which > allows finding a printer on the network. Note that I'm not very happy > with avahi: > it recommends qt5, which itself recommends (or requires) librsvg, > which > itself requires rustc... 2 or 3 more hours build for just something > that used to be optional! > > I'll mention --disable-avahi in the command explanations (there does > not seem to be a "disable-ttf-font" switch, but I may be wrong). > oops, we already have --disable-avahi in the instructions... Sorry for the noise in that part. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] a ttf font is required for cups-filters
On Tue, 2020-06-16 at 16:24 +0100, Ken Moffat via blfs-dev wrote: > On Tue, Jun 16, 2020 at 10:06:19AM -0500, Douglas R. Reno via blfs- > dev wrote: > > On 6/16/20 9:37 AM, Pierre Labastie via blfs-dev wrote: > > > cups-filter-1.27.5 needs a font for its tests. The default one is > > > DejaVuSans.ttf, but this can be changed with the --with-test- > > > font-path > > > switch. Normally this font is only used for tests, so shouldn't > > > be > > > required, but configure fails if DejaVuSans.ttf or the specified > > > font > > > is not installed. > > > > > > There are two possibilities: > > > - make DejaVu fonts recommended > > > - tweak configure so that it does not error out if the font is > > > not > > > there. > > > > > > Pierre > > > > > > > > I suggest making the DejaVu fonts recommended. If I remember > > correctly, this > > isn't the only package that relies off their existence. I could be > > wrong > > about that though :) > > > > - Doug > > > My memory says the same, but after yesterday I know I'm often > flakey. > > For a desktop, I do not understand why anyone who natively uses an > alphabetic language would NOT install DejaVu Sans. But for a > server, probably it seems like useless overhead. > > However, we already list the DejaVu fotns as Optional (required for > the tests), so I suggests changng them to Recommended (required for > the tests). > > I often think it is nice to indicate _why_ something is recommended. > Will do that, and for avahi, tell it is needed for cups-browsed, which allows finding a printer on the network. Note that I'm not very happy with avahi: it recommends qt5, which itself recommends (or requires) librsvg, which itself requires rustc... 2 or 3 more hours build for just something that used to be optional! I'll mention --disable-avahi in the command explanations (there does not seem to be a "disable-ttf-font" switch, but I may be wrong). Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] a ttf font is required for cups-filters
cups-filter-1.27.5 needs a font for its tests. The default one is DejaVuSans.ttf, but this can be changed with the --with-test-font-path switch. Normally this font is only used for tests, so shouldn't be required, but configure fails if DejaVuSans.ttf or the specified font is not installed. There are two possibilities: - make DejaVu fonts recommended - tweak configure so that it does not error out if the font is not there. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] LXDE logout menu items
On Sun, 2020-06-14 at 16:03 -0400, Joe Locash via blfs-dev wrote:
> polkit doesn't return a result if a user is in the wheel group so
> when a user
> logs out the options to shutdown, suspend, etc aren't displayed.
Do you mean a regular user gets those option and not a user in the
wheel group?
>
> I propose adding a file in /etc/polkit-1/rules.d in the build of
> lxsession
> with the following:
>
> polkit.addRule(function(action, subject) {
> if (subject.isInGroup("wheel")) {
> return polkit.Result.YES;
> }
> });
>
Could be added in the build of polkit maybe? It seems more general than
just for lxde
> If the user is in the group wheel they will now see the extra options
> when
> logging out.
>
> To test no logout is needed. Just create the file and lxpolkit will
> pick it up.
>
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] node: should we move to v14 ?
On Wed, 2020-06-03 at 16:29 +0200, Pierre Labastie via blfs-dev wrote: > On Wed, 2020-06-03 at 15:49 +0200, Pierre Labastie via blfs-dev > wrote: > > On Wed, 2020-06-03 at 14:46 +0200, Pierre Labastie via blfs-dev > > wrote: > > > On Wed, 2020-06-03 at 12:57 +0100, Ken Moffat via blfs-dev wrote: > > > > I started writing this in the ticket for node-v12.18.0 > > > > (#13628), > > > > but the C++ scope errors when using system nghttp2 prompted me > > > > to > > > > go > > > > with 12.18.0 for the moment. And then I discovered that the > > > > same > > > > FTBFS occurred in 12.18.0, but right at the end of the build > > > > instead > > > > of very early on. > > > > > > There is a new version of nghttp2, according to the tickets. Have > > > you > > > tried it? In case you say no, I'll try building node.js 14.x with > > > this > > > new version. Moving to python3 would be great... > > > > > > > Replying to myself. I've found that the missing function > > (nghttp2_option_set_max_settings) has just been implemented in > > nghttp2- > > 1.41.O to fix a CVE. Trying a build of node.js-12.18.0 with system > > nghttp2 right now. > > > > Confirming that both 12.18.0 and 14.4.0 build with system nghttp2. > And 14.4.0 builds without python2. FWIIW, firefox-68.9.0esr builds ok against node.js-14.4.0 (and runs). Of course, it needed Python-2. Don't know how to specifically test node.js though. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] node: should we move to v14 ?
On Wed, 2020-06-03 at 15:49 +0200, Pierre Labastie via blfs-dev wrote: > On Wed, 2020-06-03 at 14:46 +0200, Pierre Labastie via blfs-dev > wrote: > > On Wed, 2020-06-03 at 12:57 +0100, Ken Moffat via blfs-dev wrote: > > > I started writing this in the ticket for node-v12.18.0 (#13628), > > > but the C++ scope errors when using system nghttp2 prompted me to > > > go > > > with 12.18.0 for the moment. And then I discovered that the same > > > FTBFS occurred in 12.18.0, but right at the end of the build > > > instead > > > of very early on. > > > > There is a new version of nghttp2, according to the tickets. Have > > you > > tried it? In case you say no, I'll try building node.js 14.x with > > this > > new version. Moving to python3 would be great... > > > > Replying to myself. I've found that the missing function > (nghttp2_option_set_max_settings) has just been implemented in > nghttp2- > 1.41.O to fix a CVE. Trying a build of node.js-12.18.0 with system > nghttp2 right now. > Confirming that both 12.18.0 and 14.4.0 build with system nghttp2. And 14.4.0 builds without python2. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] node: should we move to v14 ?
On Wed, 2020-06-03 at 14:46 +0200, Pierre Labastie via blfs-dev wrote: > On Wed, 2020-06-03 at 12:57 +0100, Ken Moffat via blfs-dev wrote: > > I started writing this in the ticket for node-v12.18.0 (#13628), > > but the C++ scope errors when using system nghttp2 prompted me to > > go > > with 12.18.0 for the moment. And then I discovered that the same > > FTBFS occurred in 12.18.0, but right at the end of the build > > instead > > of very early on. > > There is a new version of nghttp2, according to the tickets. Have you > tried it? In case you say no, I'll try building node.js 14.x with > this > new version. Moving to python3 would be great... > Replying to myself. I've found that the missing function (nghttp2_option_set_max_settings) has just been implemented in nghttp2- 1.41.O to fix a CVE. Trying a build of node.js-12.18.0 with system nghttp2 right now. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] node: should we move to v14 ?
On Wed, 2020-06-03 at 12:57 +0100, Ken Moffat via blfs-dev wrote: > I started writing this in the ticket for node-v12.18.0 (#13628), > but the C++ scope errors when using system nghttp2 prompted me to go > with 12.18.0 for the moment. And then I discovered that the same > FTBFS occurred in 12.18.0, but right at the end of the build instead > of very early on. There is a new version of nghttp2, according to the tickets. Have you tried it? In case you say no, I'll try building node.js 14.x with this new version. Moving to python3 would be great... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] About Initramfs and PARTUUID
On Tue, 2020-05-26 at 14:24 +0200, Alain Dumont via blfs-dev wrote:
>
> Le 23/05/2020 à 22:56, Pierre Labastie via blfs-dev a écrit :
> > On Fri, 2020-05-15 at 21:34 +0200, Alain Dumont via blfs-dev wrote:
> > > Hi all,
> > >
> > > With grub I usually use PARTUUID rather than UUID to specify the
> > > location of my file system :
> > > linux/boot/vmlinuz root=PARTUUID="7d896f5 ."
> > > It works very well. But recently I needed to use initrd (*) and I
> > > used
> > > the script mkinitramfs described in the blfs-book chapter 5.
> > > But then my system refused to start. The reason is that the
> > > init.in
> > > script does not support the case of PARTUUID.
> > > It is very easy to include this functionality in the script by
> > > simply
> > > adding a single line in the function do_mount_root() :
> > >
> > > do_mount_root()
> > > {
> > > mkdir /.root
> > > [ -n "$rootflags" ] && rootflags="$rootflags,"
> > > rootflags="$rootflags$ro"
> > >
> > > case "$root" in
> > >/dev/*) device=$root ;;
> > >UUID=*) eval $root; device="/dev/disk/by-
> > > uuid/$UUID" ;;
> > >PARTUUID=*) eval $root;
> > > device="/dev/disk/by-partuuid/$PARTUUID" ;; <=== add this line
> > >LABEL=* ) eval $root; device="/dev/disk/by-
> > > label/$LABEL"
> > > ;;
> > >"") echo "No root device specified." ; problem
> > > ;;
> > > esac
> > >
> > > et voila!
> > >
> > > a simple suggestion which could be included definitively in the
> > > script
> > > hoping that it would be useful for others.
> > >
> > > Alain
> > >
> > > (*) Here, initrd is required by lvm to check thin-pools at boot
> > > time
> > > (I
> > > use optional thin-provisonning-tools).
> > >
> > >More info about that in an other post if needed.
> > >
> > >
> >
> > Done at r23196, together with a fix and another improvement. Thanks
> >
> > Pierre
> >
>
> Thank you for considering my remark regarding the init.in script.
> However, upon re-reading this script I notice that the
> do_try_resume()
> function requires the same modification
>
> PARTUUID = *) eval $resume; resume="/dev/disk/by-partuuid/$PARTUUID"
> ;;
This has to be tested, I suspect that if the kernel is able to find the
partition by himself (which is the case if using PARTUUID), it bypasses
the initrd, since it has the memory image anyway.
>
> Moreover and for the sake of homogeneity with do_mount_root(), the
> do_try_resume() function should also accept the option
> /dev/*) resume=$root ;;
nope, this would be resume=$resume, which is a nop.
>
> However, the kernel does not allow the specification of the swap
> partition by its UUID.
> This option would be removed in the do_try_resume().
>
> Documentation/admin-guide/kernel-parameters.txt
> resume= [SWSUSP]
> Specify the partition device for software
> suspend
> Format:
> {/dev/ | PARTUUID= | :
> |
> }
>
> I did the test on my own machine and I can confirm this, UUID is
> useless
> in do_try_resume()
What the kernel does not accept on its command line is left for
initramfs... Last time I checked, it was working with UUID... Maybe
they have changed something in the kernel now, but there is no reason
that it stops working: we do convert UUID to a true /dev/something, and
run the command for resuming from that device.
If we use resume=/dev/ or resume=PARTUUID=, then
the kernel is able to load the memory image without help, and it
resumes from there (bypasses the initrd, I think, so the do_try_resume
function does not need any change). If using /dev/ or
UUID=, or LABEL=, it is a job for the initramfs.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] OpenJDK-14.0.1 2020-05-24 gcc-10 Patch
On Mon, 2020-05-25 at 07:27 -0400, Jean-Marc Pigeon via blfs-dev wrote: > Hello, > > OpenJDK do not compile with gcc-10 > > Was successfull with attached patch sequence > (hope that help) > > Thanks Jean-Marc. Actually, this fix will be in OpenJDK 15, which is due in July. Meanwhile, we thought that adding --with-extra-cflags=- fcommon allowed to compile. Now, if there is a popular demand to prefer a patch, let me know, and I'll include it. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] About Initramfs and PARTUUID
On Fri, 2020-05-15 at 21:34 +0200, Alain Dumont via blfs-dev wrote:
> Hi all,
>
> With grub I usually use PARTUUID rather than UUID to specify the
> location of my file system :
> linux/boot/vmlinuz root=PARTUUID="7d896f5 ."
> It works very well. But recently I needed to use initrd (*) and I
> used
> the script mkinitramfs described in the blfs-book chapter 5.
> But then my system refused to start. The reason is that the init.in
> script does not support the case of PARTUUID.
> It is very easy to include this functionality in the script by
> simply
> adding a single line in the function do_mount_root() :
>
> do_mount_root()
> {
> mkdir /.root
> [ -n "$rootflags" ] && rootflags="$rootflags,"
> rootflags="$rootflags$ro"
>
> case "$root" in
> /dev/*) device=$root ;;
> UUID=*) eval $root; device="/dev/disk/by-uuid/$UUID" ;;
> PARTUUID=*) eval $root;
> device="/dev/disk/by-partuuid/$PARTUUID" ;; <=== add this line
> LABEL=* ) eval $root; device="/dev/disk/by-label/$LABEL"
> ;;
> "") echo "No root device specified." ; problem ;;
> esac
>
> et voila!
>
> a simple suggestion which could be included definitively in the
> script
> hoping that it would be useful for others.
>
> Alain
>
> (*) Here, initrd is required by lvm to check thin-pools at boot time
> (I
> use optional thin-provisonning-tools).
>
> More info about that in an other post if needed.
>
>
Done at r23196, together with a fix and another improvement. Thanks
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] replacing transcode with handbrake
On Thu, 2020-05-21 at 19:51 +0100, Ken Moffat via blfs-dev wrote: > On Wed, May 20, 2020 at 07:50:52PM -0400, Jean-Marc Pigeon via blfs- > dev wrote: > > Bonjour Pierre, > > > > On Wed, 2020-05-20 at 18:28 +0200, Pierre Labastie via blfs-dev > > wrote: > > > Transcode is an old, unmaintained, transcoder for video and > > > audio. > > > I've made a patch to allow building it with GCC 10, but I am not > > > sure > > > how to test it. So maybe time to drop it... > > > At this point, I've discussed with D. Reno, who pointed up that > > > there is a replacement, whose name is handbrake [1]. > > > > > > I've not tried to build it yet, but it has both a cli and a gui, > > > and > > > seems to be able to do all what transcode was able to do (correct > > > me > > > if > > > not). > > > > > > So my proposition is (after some tests maybe) to drop transcode > > > and > > > add > > > handbrake (building does not seem hard [2], no idea of the > > > SBU's). > > > > > > Thoughts? > > > > > > Pierre > > > > > > [1] https://handbrake.fr/ > > > [2] > > > https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/handbrake > > > > I have HandBrake fully working (cli and GUI) with BLFS-9.1 > > no trouble with building. > > I am still at version 1.2.2 (while current is 1.3.2) > > -- > > You have seen "Linux from scratch" and looking for ISO files > > www.osukiss.org > > > Hi Guys, > > I'm surprised to find I'm back online (no broadband or cable TV for > a couple of days), so just some brief comments on this: > > I looked at HandBrake-1.1.1 in July 2018. I'm sure that > dependencies have changed since then (it needed Python2), At that > time I needed janssson (ISTR that is now in BLFS), and lots AV libs > we already had. I don't have any interest in bluray, so I tried to > do without that - my notes suggest that system libbluray needed > java, which I normally omit, but the shipped libbluray was ok > without it. > > At that time it "shipped" (in practice, like libreoffice, it > downloaded) libav (the fork of ffmpeg - maybe it is now back on > ffmpeg), libvpx, and qsv (for intel, if enabled). In general, it > seemed to be keen to used bundled libs in contrib/. > > But after building it, I was very disappointed - > > 1. Not able to extract PCM audio (e.g. to take a music DVD and > extract the PCM audio if it has that). With transcode I could rip a > vob (I think, ages since I had any need) and then use ffmpeg to get > the audio. More generally, there seem to be options for video > quality, but audio is only aac. At the time, most online articles > about handbrake ignored audio quality. > > 2. For aac, I tried using fdk-aac but it downloaded an older version > and used that instead of the system version. I suspect that it is > another package which wants to use its own versions. > > 3. I haven't made kept notes on a lot of the details, but it seems > the commandline version was very poorly documented, and the graphic > application (ghb) seemed to lack useful options for what I wanted to > do. > > Summary: it needed a lot of work - I was thinking about making a > hint, but the results discouraged me. > Thanks for this detailed report. I've now patched transcode, but am not sure I did right. So if you get a chance to test it (transcode rebuilt with gcc 10, or at least with -fno-common), I'd be happy to hear about it. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] replacing transcode with handbrake
Transcode is an old, unmaintained, transcoder for video and audio. I've made a patch to allow building it with GCC 10, but I am not sure how to test it. So maybe time to drop it... At this point, I've discussed with D. Reno, who pointed up that there is a replacement, whose name is handbrake [1]. I've not tried to build it yet, but it has both a cli and a gui, and seems to be able to do all what transcode was able to do (correct me if not). So my proposition is (after some tests maybe) to drop transcode and add handbrake (building does not seem hard [2], no idea of the SBU's). Thoughts? Pierre [1] https://handbrake.fr/ [2] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/handbrake -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] cmake annoyance (?)
On Fri, 2020-05-15 at 15:58 -0500, Bruce Dubbs via blfs-dev wrote: > On 5/15/20 2:40 PM, Pierre Labastie via blfs-dev wrote: > > On Fri, 2020-05-15 at 13:42 -0500, Bruce Dubbs via blfs-dev wrote: > > > On 5/15/20 12:54 PM, Pierre Labastie via blfs-dev wrote: > > > > On Fri, 2020-05-15 at 12:31 -0500, Bruce Dubbs via blfs-dev > > > > wrote: > > > > > On 5/15/20 8:16 AM, Pierre Labastie via blfs-dev wrote: > > > > > > libmusibrainz fails early with: > > > > > > --- > > > > > > make[2]: *** No rule to make target 'src/*.inc', needed by > > > > > > 'src/mb5_c.cc'. Stop. > > > > > > --- > > > > > > It looks like there is an upstream commit > > > > > > https://github.com/metabrainz/libmusicbrainz/commit/8be45b12a86bc0e46f2f836c8ac88e1e98d82aee > > > > > > > > > > > > I've verified it allows building. > > > > > > It can be applied with: > > > > > > > > > > > > pushd src > > > > > > sed 's/\*\.inc/'"$(echo *.inc)"/ -i CMakeLists.txt > > > > > > popd > > > > > > > > > > > > > > > > > > But I am amazed nobody has seen this yet. It must be a new > > > > > > oddity > > > > > > with > > > > > > recent cmake... > > > > > > > > > > I saw it, but skipped it until now. Updated the above with: > > > > > > > > > > sed -i 's/\*\.inc/"$(echo *.inc)"/' src/CMakeLists.txt > > > > > > > > > > -- Bruce > > > > > > > > Doesn't work: "echo *.inc" returns the list of .inc files in > > > > the > > > > current directory (which is empty if you do not change dir, I > > > > think). > > > > And if you put src/*.inc, they are prefixed with src, which is > > > > not > > > > right. > > > > > > Worked for me. Note that you are modifying src/CMakeLists.txt > > > and > > > that > > > doesn't run the echo until cmake is run. > > > > > > > Ah, you moved the single quote... But I won't trust cmake to keep > > this > > valid: having a bash command inside a CMakeLists.txt. The behavior > > already changed from expanding to not expanding *.inc... That's why > > we > > need a sed. > > We will only need this until the next version is released. > Last version is from 2014. The change to src/CMakeLists.txt has been done in 2018, and there is no release since then. So maybe next release is not coming soon :) Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] cmake annoyance (?)
On Fri, 2020-05-15 at 13:42 -0500, Bruce Dubbs via blfs-dev wrote: > On 5/15/20 12:54 PM, Pierre Labastie via blfs-dev wrote: > > On Fri, 2020-05-15 at 12:31 -0500, Bruce Dubbs via blfs-dev wrote: > > > On 5/15/20 8:16 AM, Pierre Labastie via blfs-dev wrote: > > > > libmusibrainz fails early with: > > > > --- > > > > make[2]: *** No rule to make target 'src/*.inc', needed by > > > > 'src/mb5_c.cc'. Stop. > > > > --- > > > > It looks like there is an upstream commit > > > > https://github.com/metabrainz/libmusicbrainz/commit/8be45b12a86bc0e46f2f836c8ac88e1e98d82aee > > > > > > > > I've verified it allows building. > > > > It can be applied with: > > > > > > > > pushd src > > > > sed 's/\*\.inc/'"$(echo *.inc)"/ -i CMakeLists.txt > > > > popd > > > > > > > > > > > > But I am amazed nobody has seen this yet. It must be a new > > > > oddity > > > > with > > > > recent cmake... > > > > > > I saw it, but skipped it until now. Updated the above with: > > > > > > sed -i 's/\*\.inc/"$(echo *.inc)"/' src/CMakeLists.txt > > > > > > -- Bruce > > > > Doesn't work: "echo *.inc" returns the list of .inc files in the > > current directory (which is empty if you do not change dir, I > > think). > > And if you put src/*.inc, they are prefixed with src, which is not > > right. > > Worked for me. Note that you are modifying src/CMakeLists.txt and > that > doesn't run the echo until cmake is run. > Ah, you moved the single quote... But I won't trust cmake to keep this valid: having a bash command inside a CMakeLists.txt. The behavior already changed from expanding to not expanding *.inc... That's why we need a sed. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] cmake annoyance (?)
On Fri, 2020-05-15 at 12:31 -0500, Bruce Dubbs via blfs-dev wrote: > On 5/15/20 8:16 AM, Pierre Labastie via blfs-dev wrote: > > libmusibrainz fails early with: > > --- > > make[2]: *** No rule to make target 'src/*.inc', needed by > > 'src/mb5_c.cc'. Stop. > > --- > > It looks like there is an upstream commit > > https://github.com/metabrainz/libmusicbrainz/commit/8be45b12a86bc0e46f2f836c8ac88e1e98d82aee > > > > I've verified it allows building. > > It can be applied with: > > > > pushd src > > sed 's/\*\.inc/'"$(echo *.inc)"/ -i CMakeLists.txt > > popd > > > > > > But I am amazed nobody has seen this yet. It must be a new oddity > > with > > recent cmake... > > I saw it, but skipped it until now. Updated the above with: > > sed -i 's/\*\.inc/"$(echo *.inc)"/' src/CMakeLists.txt > >-- Bruce Doesn't work: "echo *.inc" returns the list of .inc files in the current directory (which is empty if you do not change dir, I think). And if you put src/*.inc, they are prefixed with src, which is not right. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] cmake annoyance (?)
libmusibrainz fails early with: --- make[2]: *** No rule to make target 'src/*.inc', needed by 'src/mb5_c.cc'. Stop. --- It looks like there is an upstream commit https://github.com/metabrainz/libmusicbrainz/commit/8be45b12a86bc0e46f2f836c8ac88e1e98d82aee I've verified it allows building. It can be applied with: pushd src sed 's/\*\.inc/'"$(echo *.inc)"/ -i CMakeLists.txt popd But I am amazed nobody has seen this yet. It must be a new oddity with recent cmake... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Missing link-shared=true in config.toml (rustc)?
Hi, I see that, although we now use system llvm, we do not have link-shared=true anymore in config.toml, while we used to have: # When using system llvm prefer shared libraries link-shared = true Is it an oversight, or should it be like that? Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Semantics for dependencies
On Mon, 2020-05-11 at 02:03 +0100, Ken Moffat via blfs-dev wrote: > Usually, I can work out whether dependencies don't apply (e.g. > packages only relevant to OSX), but for the current version of > fontforge I'm having difficulty about how to treat 'git'. > > On my normal build git is of course installed, and cmake reports > the version it found. Looking at the cmake files it seems as if > this is needed so that it can report the git version which was used > for a build from git (i.e. not a release), and it certainly builds > ok if I hide git. > > So, my question is: should I not mention git in the dependencies > (and wait for some smart alec to complain that it tests for git), or > do something else ? I think more and more build systems test for git (meson almost systematically does, but even some configure scripts). Up to now, I've always seen a fallback, so git is optional. I think git should be added to optional deps in this case. Since you have spent some time on it, it will show ;) Also, knowing that it depends optionally on git may help investigating bugs resulting of git usage, if any. But I agree that having git in the opt deps is not very useful... > > More generally with cmake, I get the distinct impression that > finding out *how* cmake determines if a program/library is present > was specified by a devotee of Anoia (the goddess of things stuck in > drawers) - So do I > > [...] > Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] cpio breakage with GCC 10
On Sat, 2020-05-09 at 07:27 -0400, Ryan Marsaw via blfs-dev wrote: > Hi all. > > The cpio package has breakage with GCC 10. Here's a link to the > issue > (Gentoo): > > https://bugs.gentoo.org/705900 > > The fix is rather easy: > > sed -i '/The name/,+2 d' src/global.c > > Cheers, > > --Ryan Added to ticket #13511, thanks. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] shared-mime-info's "update-mime-database" will need to be run after install
On Fri, 2020-05-08 at 06:38 -0400, Ryan Marsaw via blfs-dev wrote: > Hello. > > One of the changes with the latest shared-mime-info package is that > its > "update-mime-database" program is no longer called during the install > phase. Without the MIME data in the database, gdk-pixbuf (at least > -- > there could be others) will fail to build. > > I suggest either having the (as root) user issue > "/usr/bin/update-mime-database -V /usr/share/mime/" after install, or > add "-Dupdate-mimedb=true" to the meson config options. > Thanks for reporting. Added -Dupdate-mimedb=true at revision 23085. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Sudo: expanding the explanation of the --with-passprompt Configure argument
On Sat, 2020-05-02 at 15:35 +0800, Kevin Buckley via blfs-dev wrote: > On Wed, 29 Apr 2020 at 13:21, Pierre Labastie via blfs-dev > wrote: > > What you propose in V2 is what is used in the lfs book. It looks > > slightly better when rendered, but is much less readable when > > editing. > > Yes, it was inspired by the LFS Book. > > > Now, from my POV, command explanations in blfs are rationales > > explaining why they are there, not really full explanations of the > > commands themselves. The user is supposed to be able to find those > > details by him/herself. So the explanations can be sketchy. But > > explanations don't hurt OTOH... I've applied the first version at > > r23041. Thanks. > > I do think that Bruce had a point, when he said that the BLFS book > doesn't need to explain the "%p" because a reader can just go and > read the man page, however, I'd rather see the Book explain the > "%p" AND point them in the direction of the man page, in respect > of other "placeholder" parameters in the prompt, so something akin > to > > --with-passprompt: > This switch sets the password prompt. > The %p will be expanded to the name of the user whose password is > being requested. > See the manual page for details of other ways to in which to > customise > the Sudo prompt. I think people building blfs should know that the manual pages should be consulted for details... Note that referring to the manual page in the command explanations is not timely if the package is not installed yet. And we refer to the sudoers manual page in the configuration section. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Sudo: expanding the explanation of the --with-passprompt Configure argument
On Wed, 2020-04-29 at 12:04 +0800, Kevin Buckley via blfs-dev wrote: > At present, the Book has this argument to configure > > --with-passprompt="[sudo] password for %p: " > > but doesn't explain the "%p", merely saying > > --with-passprompt: This switch sets the password prompt. > > which might leave the user wondering what the %p stands for. > > The attached patch adds an explanation, taken from the sudo man page, > as follows: > > --with-passprompt: This switch sets the password prompt. The %p will > be expanded to the name of the user whose password is being > requested. > > Having added that extra explanation though, I found that the text > looked a bit "unwieldy", > in that the text flows under the argument, and so version 2 of the > patch replaces the > "standard paragraph text", used for the command explanations, with a > > that makes things look a lot tidier, and has the advantage, at least > in my rendering, of > having the argument in the same font as it appears in the command > instructions above > the explanation. Right now, we try to stick to the file template/template.xml style for blfs. If we want to change the style, we have to do this for all the packages in the book (~800)! What you propose in V2 is what is used in the lfs book. It looks slightly better when rendered, but is much less readable when editing. Now, from my POV, command explanations in blfs are rationales explaining why they are there, not really full explanations of the commands themselves. The user is supposed to be able to find those details by him/herself. So the explanations can be sketchy. But explanations don't hurt OTOH... I've applied the first version at r23041. Thanks. And the commands are there to explain why they are not used, or to point to the right switch in case the user wants to add/remove some functionalities, or use some optional package. Note that this is not done in a systematic way, because it's a big job to do it systematic, and specially to maintain when updating packages: what may be true now may become wrong after a couple of version upgrades... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Names of SGML/XML/DocBook files
On Thu, 2020-04-09 at 23:05 +0800, Kevin Buckley via blfs-dev wrote: > I'd like to make a suggestion, as regards the names of the > BLFS XML files for the SGML/XML/DocBook sections. > > I've just come to add some of the DocBook packages to my > LFS/BLFS system, and hence my own copy of the Book sources, > and got a bit confused as to what related to what. > > > As things stand the relevant BLFS sources files, and the > package sources they expect to have unpacked are: > > > sgml-common.xmlsgml-common-0.6.3.tgz >sgml-common-0.6.3-manpage-1.patch > > sgml-dtd.xml docbook-4.5.zip > > docbook.xmldocbook-xml-4.5.zip > > docbook-xsl.xmldocbook-xsl-nons-1.79.2.tar.bz2 >docbook-xsl-nons-1.79.2-stack_fix-1.patch >docbook-xsl-doc-1.79.2.tar.bz2 > > sgml-dtd-3.xml docbk31.zip > > docbook5.xml docbook-5.0.zip > > docbook51.xml docbook-v5.1-os.zip > > > however, sgml-dtd.xml and sgml-dtd-3.xml are actually about > installting DocBook SGML DTDs, not generic SGML DTDs, as can > be read in the introductory paragraph for each package. > > > Given that multiple SGML and XSL DTDs cam exist on the > same system, I feel that is would be more consistent if > the BLFS source files were renamed as follows: > > sgml-common.xmlsgml-common-0.6.3.tgz >sgml-common-0.6.3-manpage-1.patch > > docbock-sgml-45.xmldocbook-4.5.zip > > docbook-xml-45.xml docbook-xml-4.5.zip > > docbook-xsl.xmldocbook-xsl-nons-1.79.2.tar.bz2 >docbook-xsl-nons-1.79.2-stack_fix-1.patch >docbook-xsl-doc-1.79.2.tar.bz2 > > docbook-sgml-31.xmldocbk31.zip > > docbook-xml-50.xml docbook-5.0.zip > > docbook-xml-51.xml docbook-v5.1-os.zip > > > but, in suggesting that, I'm unsure as to what that entails > for the Book gneration process as a whole, not least the > > > > tags, > > So, even though I can't present a fully formed "change > request", I hope that the underlying idea is seen as > a sensible thing to do. > file names are only referenced in the file that has the same name as the directory plus .xml extension (the tags). So when changing the filenames, those files have to be changed too. This is the only mandatory thing But: it is better to have the html file have a name close to the xml one (the html name is defined in the processing instruction). And also the id attribute in the tag, should be close to that. But this is not mandatory. If changing the id, it has to be changed also in all http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] [BLFS Trac] #13355: mozjs-68.6.1
On Sat, 2020-04-04 at 20:58 -0500, Bruce Dubbs via blfs-dev wrote: > On 4/4/20 8:33 PM, Ken Moffat via blfs-dev wrote: > > On Sat, Apr 04, 2020 at 07:41:45PM +0100, Ken Moffat via blfs-dev > > wrote: > > > On Sat, Apr 04, 2020 at 12:54:57PM -0500, Bruce Dubbs via blfs- > > > dev wrote: > > > > On 4/4/20 12:15 PM, Ken Moffat via blfs-book wrote: > > > > > [ Cc: -dev added ] > > > > > > > > > > I left it open because I hope there is some better way of > > > > > keepign > > > > > the version, tarball size and md5sum in-sync. I sort of > > > > > assumed > > > > > that using e.g. md5sum from one package in another would > > > > > break > > > > > things (don't have time to check that at the moment). > > > > > > > > Well the md5sum and package size won't change. We kinda to the > > > > same thing > > > > with bind and bind-utilities. They are two different builds of > > > > the same > > > > tarball. > > > > > > > > In a similar situation we have qt5 and QtWebEngine. Although > > > > 'webengine' is > > > > available as a separate tarball, we almost always build both at > > > > each new > > > > release. > > > > > > > > The problem with js is if some package, e.g. seamonkey or > > > > thunderbird, does > > > > not keep up with firefox. We also have the issue of polkit > > > > still at js60. > > > > I checked into that and polkit does not build with js68. > > > > However it does > > > > seem that there is only one polkit file that uses js. > > > > > > > > > > Thanks for the pointer to bind and bind-utils : I'll change JS68 > > > and > > > packages. > > > > > And now I'll note tht it isn't an ideal solution - copying > > firefox-size into js68 worked, but only because it was (re) defined > > in js68. If I comment that part, js68 does not validate because > > firefox-size is not defined (i.e. the definition is local to each > > xml file). > > > > What I was hoping for was some way of defining it once, so that > > both > > users can only show the same value. I suppose putting the size and > > md5sum in packages could do that (ditto for bind), but that would > > look messy. > > > > I'm also grumpy that I've now got to measure js68 when I update > > firefox, but at least js68 can be used generally after the next > > polkit release happens. > > OK, Grumpy. We could try to use common md5sums by creating entities > in > general.ent, but that would make things inconsistent. Since jsxx > needs > to be rebuilt anyway for timing and build size, is it really that > hard > to just copy the md5sum into the page? I double check the md5sums > for > all new packages anyway, so a mistake can be caught quickly. > What can be done is having small .ent files for entities common to several .xml sources, like ff-js-common.ent containing: then in say, firefox.xml: http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"; [ %general-entities; %ffjs-entities; That's how XML works normally. True, it's verbose :) Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] linux kernel 5.6 stable SVN-20200401
On Fri, 2020-04-03 at 10:18 -0500, Douglas R. Reno via blfs-dev wrote: > On 4/3/20 9:35 AM, Jean-Marc Pigeon via blfs-dev wrote: > > Hello, > > > > According to me, kernel 5.6 is now "mainline" and stable. > > > > Is there something wrong with 5.6 such LFS SVN-20200401 > > is not including the 5.6 family?? > > > > My own point of interest with 5.6 is the time_namespace > > (for containers). > > > > Is 5.6.2 too new to be considered for the (B)LFS project? > > > With early 5.6 versions, 5.6/5.6.1, the Intel Wireless driver > (IWLWIFI) > was broken. I think we're holding to see if any other regressions > show > up under this release Hmm I think from the thread on lfs-dev, that the kernel version will be updated when other packages need to be updated in lfs. It does not prevent users to update to recent kernels, of course... Maybe we could amend the note on the "All packages" page by telling to update to the most recent mainline version instead of the most recent 5.5.x version. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] dhcpcd-9.0.0 privilege separation: what uid shall be used
On Fri, 2020-04-03 at 09:56 +0200, Tim Tassonis via blfs-dev wrote: > Hi all > > I'm about to give the new dhcpcd 9.0.0 a go, which has quite an > important change: it does privilege separation now. > > This means that an unprivileged user has to be created and that user > needs to have access to /var/lib/dhcpcd > > I thought of doing something similar to openssh: > > install -v -m700 -d /var/lib/dhcpcd > > > groupadd -g 50 dhcpcd&& > useradd -c 'dhcpcd PrivSep' \ > -d /var/lib/dhcpcd \ > -g dhcpcd \ > -s /bin/false \ > -u 50 dhcpcd > > chown dhcpcd:dhcpcd /var/lib/dhcpcd > > > > Now, the question is: what uid and gid shall I use? 50 as above is > taken > by openssh, so what number shall we reserve for dhcpcd? > > > > Bye > Tim First, you may try to look at what other distros do for the uid/gid, but whatever your choice, have a look at the "About System Users and Groups" page, and add the id's there (after verifying it does not clash, I guess you'd thought of that :). Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Our instructions for stripping in BLFS only strip shared libraries
Try those instructions with the last line replaced by "| grep -v '.so'"
(that is, print all the found filenames, except those containing .so):
find /{,usr/}{bin,lib,sbin} \
-type f \( -name \*.so* -a ! -name \*dbg \) | grep -v '\.so'
(empty output)
The reason is that the default predicate in find is -a, so the above is
equivalent to:
find /{,usr/}{bin,lib,sbin} \
-type f -a -name \*.so* -a ! -name \*dbg
I'd suggest (but I am sure there are better alternatives)
-type f \( -name \*.so* -a ! -name \*dbg -o ! -name \*.so*\)
or separate bin,sbin (where we can "strip --stripall") from lib, where
we should just "strip --unneded" *.so* files, or "strip --debug" *.a
files (as in lfs)
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On Sat, 2020-03-28 at 01:48 +, Ken Moffat via blfs-dev wrote: > On Fri, Mar 27, 2020 at 08:26:39PM +0100, Pierre Labastie via > blfs-dev wrote: > > On Fri, 2020-03-27 at 17:59 +, Ken Moffat via blfs-dev wrote: > > > On Fri, Mar 27, 2020 at 06:34:17PM +0100, Pierre Labastie via > > > blfs- dev wrote: > > > > On Fri, 2020-03-27 at 16:02 +, Ken Moffat via blfs-dev > > > > wrote: > > > > > > > > Sorry for arguing again. The problem is that SHELL needs to be > > > > _exported_. It can be set to /bin/bash without problem. And > > > > for me, it is not exported for _root_ after entering chroot > > > > (but it is set): root [ / ]# echo $SHELL /bin/bash root [ > > > > / ]# env | grep SHELL root [ / ]# Now when doing su - > > > > pierre [ ~ ]$ echo $SHELL /bin/bash pierre [ ~ ]$ > > > > env | grep SHELL SHELL=/bin/bash pierre [ ~ ]$ So no need > > > > to set/export anything as a user. And SHELL only needs to be > > > > exported as root. Pierre > > > > > > > > > > I'm puzzled by that - if it is not set, the configure breaks. > > > Does SHELL also get queried when root is running the install ? > > > > > > > > > > When it is set, but not exported, it's not set in ./wmach, so not > > found... So I'd just suggest something like: Second, you should > > ensure that the SHELL variable is set and exported to the > > environment, possibly by prepending SHELL= to the > > .mach command. > > > > Pierre > > > I see you are moving away from saying /bin/sh which we have in the > current firefox note. Are you using dash or zsh on the quiet ? > (joke/). I can see we don't accomodate tcsh (setenv SHELL /bin/tcsh > or similar) and certainly not fish (env SHELL=/usr/bin/fish command > - I guess). > Just wanted to tell that "/bin/bash" can be used. Actually, dash can certainly be used too (I've come to the conclusion long ago, that recent dash is perfectly suitable for lfs, but for some reason the debian maintainer does not want to use recent dash, so lfs fails to build on debian+dash). No experience with zsh, and I guess tcsh might be not enough POSIX compliant (but not tried either). We do not propose fish in the book, do we? Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On Fri, 2020-03-27 at 17:59 +, Ken Moffat via blfs-dev wrote: > On Fri, Mar 27, 2020 at 06:34:17PM +0100, Pierre Labastie via blfs- > dev wrote: > > On Fri, 2020-03-27 at 16:02 +, Ken Moffat via blfs-dev wrote: > > > The thread Python multiprocessing checks in chroot is getting > > > long > > > and widening to cover how /dev/shm is treated in LFS. > > > > > > What I'd like to do is put the following note in the BLFS > > > mozilla-derived packages where shm needs to be mounted when the > > > package is configured: > > > > > > - - - > > > If you are compiling this package in chroot you must do two > > > things: > > > > > > First, as the root user, ensure that /dev/shm is mounted: > > > > > > mountpoint /dev/shm >/dev/null || mount -t tmpfs devshm > > > /dev/shm > > > > > > If you do not do this, configuring will fail with a python > > > traceback > > > report referencing a > > > /usr/lib/pythonN.N/multiprocessing/synchronize.py > > > file. > > > > > > Second, as your normal user either ensure the $SHELL environment > > > variable is set to /bin/sh, or prepend SHELL=/bin/sh. > > > - - - > > > > > > Is that acceptable to everyone ? > > > > > > > > > > Sorry for arguing again. The problem is that SHELL needs to be > > _exported_. It can be set to /bin/bash without problem. And for me, > > it > > is not exported for _root_ after entering chroot (but it is set): > > > > root [ / ]# echo $SHELL > > /bin/bash > > root [ / ]# env | grep SHELL > > root [ / ]# > > > > Now when doing su - > > > > pierre [ ~ ]$ echo $SHELL > > /bin/bash > > pierre [ ~ ]$ env | grep SHELL > > SHELL=/bin/bash > > pierre [ ~ ]$ > > > > So no need to set/export anything as a user. And SHELL only needs > > to be > > exported as root. > > Pierre > > > > I'm puzzled by that - if it is not set, the configure breaks. Does > SHELL also get queried when root is running the install ? > > When it is set, but not exported, it's not set in ./wmach, so not found... So I'd just suggest something like: Second, you should ensure that the SHELL variable is set and exported to the environment, possibly by prepending SHELL= to the .mach command. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc 1.39 broken with llvm 10?
On Fri, 2020-03-27 at 18:24 +, Ken Moffat via blfs-dev wrote: > On Fri, Mar 27, 2020 at 10:09:49AM -0500, Douglas R. Reno via blfs- > dev wrote: > > On 3/27/20 9:24 AM, Pierre Labastie via blfs-dev wrote: > > > Just built cmake 1.17, llvm 10.0? and trying rustc-1.39. Got an > > > error: > > > See attached log (with ~3300 lines cut). Sorry it is a little > > > long, but > > > it really looks like some LLVM header file is missing or API has > > > changed. > > > > > > Has anybody seen this too? > > > > > > Pierre > > > > Yes I have! > > > > It seems that using system LLVM is broken with rustc-1.39. I had to > > do the > > following to get rustc to build using it's builtin version of LLVM > > for now > > (I believe it's LLVM9? LLVM-10 has changed a lot of the public API > > for > > applications that use bindings such as rustc). > > > > - Comment out the [target.x86_64-unknown-linux-gnu] line > > > > - Comment out the llvm-config= line > > > > > > If you are on i686 (untested), comment out the i686 portions of > > that > > statement. > > > > > > That will unfortunately force rustc to build using it's builtin > > LLVM though, > > which is less than desirable > > > > > > - Doug > > > To my surprise, I've found today that the system where I'm waiting > to test a TL2020-pretest update has enough space to play with > putting llvm in /opt/llvm. So far, I've merely confirmed that > clang++ doesn't like it (with both llvm-config entries pointing to > "/opt/llvm/bin/llvm-config". > > For the *first* step I think we will need to revert to the shipped > llvm (I'm not at all sure about commenting out the target line, I > think that will make it build for all possible targets, and probably > be _much_ bigger). > > The failing command specified c++-14, but the errors > look like the sort of scope errors that happen when g++ moves to a > newer default standard. But since c++-14 is already specified, I > doubt that trying to override that will be useful. > > For the *second* step, we need to think abou moving to rustc-1.42.0. > Looking at Fresh Ports (for FreeBSD, I think) if I read them right > they can build all of firefox-esr, firefox-current (74.0) and > thunderbird without changes from their previous builds. Doesn't > mean that our builds of the 68.6.0 packages will work, but worth > trying. I assume that librsvg and cbindgen should be a walk in the > park, but again obviously need to be tested. And for seamonkey > there are the patches for rust-1.40+ (one looked large) and perhaps > the upstream bug at mozilla has been updated. > > Tedious. > > I'll try that (but starting ony tomorrow Western European time). Will report. Will make some occupation while being locked down... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing in chroot, proposed note V2
On Fri, 2020-03-27 at 16:02 +, Ken Moffat via blfs-dev wrote: > The thread Python multiprocessing checks in chroot is getting long > and widening to cover how /dev/shm is treated in LFS. > > What I'd like to do is put the following note in the BLFS > mozilla-derived packages where shm needs to be mounted when the > package is configured: > > - - - > If you are compiling this package in chroot you must do two things: > > First, as the root user, ensure that /dev/shm is mounted: > > mountpoint /dev/shm >/dev/null || mount -t tmpfs devshm /dev/shm > > If you do not do this, configuring will fail with a python traceback > report referencing a > /usr/lib/pythonN.N/multiprocessing/synchronize.py > file. > > Second, as your normal user either ensure the $SHELL environment > variable is set to /bin/sh, or prepend SHELL=/bin/sh. > - - - > > Is that acceptable to everyone ? > > Sorry for arguing again. The problem is that SHELL needs to be _exported_. It can be set to /bin/bash without problem. And for me, it is not exported for _root_ after entering chroot (but it is set): root [ / ]# echo $SHELL /bin/bash root [ / ]# env | grep SHELL root [ / ]# Now when doing su - pierre [ ~ ]$ echo $SHELL /bin/bash pierre [ ~ ]$ env | grep SHELL SHELL=/bin/bash pierre [ ~ ]$ So no need to set/export anything as a user. And SHELL only needs to be exported as root. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Python multiprocessing checks in chroot
On Fri, 2020-03-27 at 15:47 +, Ken Moffat via blfs-dev wrote: > On Fri, Mar 27, 2020 at 10:11:20PM +0800, Xi Ruoyao via blfs-dev > wrote: > > [...] > > For me, I do not use my normal script for entering chroot when I'm > building a desktop in chroot. Whenever I do that I've normally done > a boot test, and then removed or renamed /tools, so invoking > /tools/bin/env etc doesn't work. I use the commands at the end of chapter 6 (Cleaning up). They do not refer to /tools. Anyway, I agree with what you say below. > > Anyway, I'm not concerned with whether or not the commands for > entering chroot in the LFS book should be changed - I expect to be > able to use the process I mentioned earlier (e.g. when using a rescue > stick) to get into a completed system, and I use the same approach > when building packages in chroot. > > And so far it is only these mozilla derivatives which need shm > during their configure stages. > > If you wish to change what is in LFS I'll leave that > discussion/decision to those with a better understanding than I > have. > Agreed, we should have another thread for changing lfs on lfs-dev (or not). Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
