[blfs-dev] graphviz fails to build
swig -c++ -ocaml -o gv_ocaml.cpp ./gv.i
SWIG:1: Warning 524: Experimental target language. Target language OCaml
specified by -ocaml is an experimental language. Please read about SWIG
experimental languages,
http://swig.org/Doc4.0/Introduction.html#Introduction_experimental_status.
mv gv_ocaml.cpp gv_ocaml.cpp.orig
sed '/int caml_array_length/d' gv_ocaml.cpp.orig > gv_ocaml.cpp
rm gv_ocaml.cpp.orig
CXX libgv_ocaml_la-gv_ocaml.lo
gv_ocaml.cpp: In function 'long int caml_long_val_full(caml_value_t, const
char*)':
gv_ocaml.cpp:1362:48: error: invalid conversion from 'const caml_value_t*'
{aka 'const long int*'} to 'caml_value_t*' {aka 'long int*'} [-fpermissive]
1362 | CAML_VALUE *enum_to_int = caml_named_value(SWIG_MODULE
"_enum_to_int");
|
^~~~
||
|const caml_value_t*
{aka const long int*}
gv_ocaml.cpp: In function 'int caml_ptr_val_internal(caml_value_t, void**,
swig_type_info*)':
gv_ocaml.cpp:1416:37: error: invalid conversion from 'const caml_value_t*'
{aka 'const long int*'} to 'caml_value_t*' {aka 'long int*'} [-fpermissive]
1416 | func_val = caml_named_value("caml_obj_ptr");
| ^~~~
| |
| const caml_value_t* {aka const
long int*}
gv_ocaml.cpp: In function 'caml_value_t SWIG_Ocaml_ptr_to_val(const char*,
void*, swig_type_info*)':
gv_ocaml.cpp:1529:47: error: invalid conversion from 'const caml_value_t*'
{aka 'const long int*'} to 'caml_value_t*' {aka 'long int*'} [-fpermissive]
1529 | CAML_VALUE *fromval = caml_named_value(name);
| ^~
| |
| const caml_value_t*
{aka const long int*}
make[4]: *** [Makefile:2227: libgv_ocaml_la-gv_ocaml.lo] Error 1
make[4]: Leaving directory
'/var/lib/sources/graphviz/graphviz-2.42.1/tclpkg/gv'
make[3]: *** [Makefile:2758: all-recursive] Error 1
make[3]: Leaving directory
'/var/lib/sources/graphviz/graphviz-2.42.1/tclpkg/gv'
make[2]: *** [Makefile:646: all-recursive] Error 1
make[2]: Leaving directory
'/var/lib/sources/graphviz/graphviz-2.42.1/tclpkg'
make[1]: *** [Makefile:825: all-recursive] Error 1
make[1]: Leaving directory '/var/lib/sources/graphviz/graphviz-2.42.1'
make: *** [Makefile:633: all] Error 2
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Storing settings of gtk3 applications in a non-gnome (xfce4) desktop enviromnent
On Tue, Sep 10, 2019 at 06:38:44PM +0200, Tim Tassonis via blfs-dev wrote: > On 9/10/19 6:32 PM, Pierre Labastie via blfs-dev wrote: > > On 10/09/2019 17:49, Tim Tassonis via blfs-dev wrote: > > > It seems to me that while the BLFS has dconf in it, and it is problably > > > referenced in the gnome section, there is no mention of it in the xfce4 > > > section (apart from mousepad, which is in the editors section). > > > > > > I'm not sure about where the best place would be, but as gtk3 already uses > > > gsettings/dconf as it's coonfiguration mechanism, it maybe could be > > > listed as > > > an optional dependency of gtk3? > > > > or a recommended run time dep? (if it prevents annoying warnings, it is in > > the > > category "that won't have issues [...] at run-time") Actually, I think dconf > > can be built before gtk3, but dconf-editor seems to need gtk3. > > Yes, I think dconf only needs glib, while dconf-editor also needs vala > unconditionally. > > I agree that a recommended run-time dep would be best, as that's what it > actually is. Apps using gsettings work without it, but won't store settings > over reboots. > Yes, it is definitely beneficial on xfce, at least on laptops - I needed it to get network-manager-applet working enough to let me conenct to my wifi as a regular user. ĸen -- thread 'main' panicked at 'giraffe', /tmp/rustc-1.32.0-src/src/test/run-fail/while-panic.rs:17:13 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libqmi fails to build with glib-2.62
On 10/09/2019 22:24, Bruce Dubbs via blfs-dev wrote: > On 9/10/19 3:18 PM, Pierre Labastie via blfs-dev wrote: >> Hi, >> >> I get: >> -- >> make[4]: Entering directory '/sources/libqmi/libqmi-1.22.4/src/libqmi-glib' >> CC libqmi_glib_la-qmi-device.lo >> qmi-device.c: In function ‘qmi_device_init’: >> qmi-device.c:3139:13: error: G_ADD_PRIVATE [-Werror] >> 3139 | QmiDevicePrivate); >> | ^ >> cc1: all warnings being treated as errors >> -- >> >> Note that the message is cryptic, but it means that some macro is deprecated. >> That sends a warning, and since -Werror is enabled, an error is generated. >> The >> solution is to add "--enable-more-warnings" to the configure invocation. >> Reason: --enable-more-warnings can take 3 values: no/yes/error, where error >> means yes+error, and is the default... >> >> Now, there is a new version of libqmi, and I see that they will "Explicitly >> define max allowed GLib version", which might cure the problem. Will try, >> since it's just been added to the book. > > I just updated to libqmi-1.22.6. Does that help? > Just tried. Yes, they've fixed 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] libqmi fails to build with glib-2.62
On 9/10/19 3:18 PM, Pierre Labastie via blfs-dev wrote: Hi, I get: -- make[4]: Entering directory '/sources/libqmi/libqmi-1.22.4/src/libqmi-glib' CC libqmi_glib_la-qmi-device.lo qmi-device.c: In function ‘qmi_device_init’: qmi-device.c:3139:13: error: G_ADD_PRIVATE [-Werror] 3139 | QmiDevicePrivate); | ^ cc1: all warnings being treated as errors -- Note that the message is cryptic, but it means that some macro is deprecated. That sends a warning, and since -Werror is enabled, an error is generated. The solution is to add "--enable-more-warnings" to the configure invocation. Reason: --enable-more-warnings can take 3 values: no/yes/error, where error means yes+error, and is the default... Now, there is a new version of libqmi, and I see that they will "Explicitly define max allowed GLib version", which might cure the problem. Will try, since it's just been added to the book. I just updated to libqmi-1.22.6. Does that help? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] libqmi fails to build with glib-2.62
Hi, I get: -- make[4]: Entering directory '/sources/libqmi/libqmi-1.22.4/src/libqmi-glib' CC libqmi_glib_la-qmi-device.lo qmi-device.c: In function ‘qmi_device_init’: qmi-device.c:3139:13: error: G_ADD_PRIVATE [-Werror] 3139 | QmiDevicePrivate); | ^ cc1: all warnings being treated as errors -- Note that the message is cryptic, but it means that some macro is deprecated. That sends a warning, and since -Werror is enabled, an error is generated. The solution is to add "--enable-more-warnings" to the configure invocation. Reason: --enable-more-warnings can take 3 values: no/yes/error, where error means yes+error, and is the default... Now, there is a new version of libqmi, and I see that they will "Explicitly define max allowed GLib version", which might cure the problem. Will try, since it's just been added to the book. 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] lsb-tools and initd-tools
On 9/10/19 1:09 PM, Tim Tassonis via blfs-dev wrote: On 10 September 2019 19:51:22 Bruce Dubbs via blfs-dev wrote: On 9/10/19 12:36 PM, Tim Tassonis via blfs-dev wrote: Hi all I noticed that initd-tools is gone from BLFS and seems to have been replaced by lsb-tools. I also noticed that BLFS bootscripts have been updated with tons of fixes for dependency information, so thanks for all the work on that! However, I noticed that lsb-tools is implemented in python3, which of course is no problem for the book, as python3 is needed for meson/ninja in lfs already. My own personal problem is that my lfs/blfs-based distro does contain initd-tools in the minimal install I use for my routers, but not python3, and I'd like to keep it that way, for size and security reasons (less software means less bugs). So, what I wanted to ask: In what functional way do the new python-based install_initd and remove_initd differ from the old, c-based ones? Will the old ones not be able to correctly manage the new BLFS init scrips due to missing functionality? And if not, what is missing from the old ones? I would then try to add this to initd-tools, so I can still use those. For a minimal install on a router why do you need to install a boot script at all? For LFS based systems you can always use 'make install= from the bootscripts tarball. Because I like to activate init scrips using install_initd and l also don' t have "make" on my routers. As my routers do dns/dhcp server, iptables, rely on ntp for time, use nginx for the web interface and ssh for administration, etc etc, I do have the need to manage bootscripts. I'm also really not in anyway complaining about the switch to python, I just have a specific use-case and wanted to know how I can stay as close to lfs/blfs as possible while still be able to handle my differences. I naturally would be completely lost maintaining my own distro without such a great upstream as lfs/blfs, so forgive me if I stepped on any toes. No toes. :) Your distro, your rules. I'd suggest just using the previous version of lsb_release for your custom installations. -- 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] lsb-tools and initd-tools
On 10 September 2019 19:51:22 Bruce Dubbs via blfs-dev wrote: On 9/10/19 12:36 PM, Tim Tassonis via blfs-dev wrote: Hi all I noticed that initd-tools is gone from BLFS and seems to have been replaced by lsb-tools. I also noticed that BLFS bootscripts have been updated with tons of fixes for dependency information, so thanks for all the work on that! However, I noticed that lsb-tools is implemented in python3, which of course is no problem for the book, as python3 is needed for meson/ninja in lfs already. My own personal problem is that my lfs/blfs-based distro does contain initd-tools in the minimal install I use for my routers, but not python3, and I'd like to keep it that way, for size and security reasons (less software means less bugs). So, what I wanted to ask: In what functional way do the new python-based install_initd and remove_initd differ from the old, c-based ones? Will the old ones not be able to correctly manage the new BLFS init scrips due to missing functionality? And if not, what is missing from the old ones? I would then try to add this to initd-tools, so I can still use those. For a minimal install on a router why do you need to install a boot script at all? For LFS based systems you can always use 'make install= from the bootscripts tarball. Because I like to activate init scrips using install_initd and l also don' t have "make" on my routers. As my routers do dns/dhcp server, iptables, rely on ntp for time, use nginx for the web interface and ssh for administration, etc etc, I do have the need to manage bootscripts. I'm also really not in anyway complaining about the switch to python, I just have a specific use-case and wanted to know how I can stay as close to lfs/blfs as possible while still be able to handle my differences. I naturally would be completely lost maintaining my own distro without such a great upstream as lfs/blfs, so forgive me if I stepped on any toes. 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] lsb-tools and initd-tools
On September 10, 2019 12:36:00 PM CDT, Tim Tassonis via blfs-dev wrote: >Hi all > >I noticed that initd-tools is gone from BLFS and seems to have been >replaced by lsb-tools. I also noticed that BLFS bootscripts have been >updated with tons of fixes for dependency information, so thanks for >all >the work on that! > >However, I noticed that lsb-tools is implemented in python3, which of >course is no problem for the book, as python3 is needed for meson/ninja > >in lfs already. > >My own personal problem is that my lfs/blfs-based distro does contain >initd-tools in the minimal install I use for my routers, but not >python3, and I'd like to keep it that way, for size and security >reasons >(less software means less bugs). > >So, what I wanted to ask: > >In what functional way do the new python-based install_initd and >remove_initd differ from the old, c-based ones? > >Will the old ones not be able to correctly manage the new BLFS init >scrips due to missing functionality? > >And if not, what is missing from the old ones? I would then try to add >this to initd-tools, so I can still use those. > > >Bye >Tim > >-- >http://lists.linuxfromscratch.org/listinfo/blfs-dev >FAQ: http://www.linuxfromscratch.org/blfs/faq.html >Unsubscribe: See the above information page I added was $first and $last facilities, specifically for our use of bootscripts instead of inittab for display manager. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] lsb-tools and initd-tools
On 9/10/19 12:36 PM, Tim Tassonis via blfs-dev wrote: Hi all I noticed that initd-tools is gone from BLFS and seems to have been replaced by lsb-tools. I also noticed that BLFS bootscripts have been updated with tons of fixes for dependency information, so thanks for all the work on that! However, I noticed that lsb-tools is implemented in python3, which of course is no problem for the book, as python3 is needed for meson/ninja in lfs already. My own personal problem is that my lfs/blfs-based distro does contain initd-tools in the minimal install I use for my routers, but not python3, and I'd like to keep it that way, for size and security reasons (less software means less bugs). So, what I wanted to ask: In what functional way do the new python-based install_initd and remove_initd differ from the old, c-based ones? Will the old ones not be able to correctly manage the new BLFS init scrips due to missing functionality? And if not, what is missing from the old ones? I would then try to add this to initd-tools, so I can still use those. For a minimal install on a router why do you need to install a boot script at all? For LFS based systems you can always use 'make install= from the bootscripts tarball. Really, the only reason I know of to use install_initd is to support some binary only package and even then you could insert the boot script and symlinks on the rare times you would need it. If you just need the lsb_release program, use the oldeer version. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] lsb-tools and initd-tools
Hi all I noticed that initd-tools is gone from BLFS and seems to have been replaced by lsb-tools. I also noticed that BLFS bootscripts have been updated with tons of fixes for dependency information, so thanks for all the work on that! However, I noticed that lsb-tools is implemented in python3, which of course is no problem for the book, as python3 is needed for meson/ninja in lfs already. My own personal problem is that my lfs/blfs-based distro does contain initd-tools in the minimal install I use for my routers, but not python3, and I'd like to keep it that way, for size and security reasons (less software means less bugs). So, what I wanted to ask: In what functional way do the new python-based install_initd and remove_initd differ from the old, c-based ones? Will the old ones not be able to correctly manage the new BLFS init scrips due to missing functionality? And if not, what is missing from the old ones? I would then try to add this to initd-tools, so I can still use those. 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] Storing settings of gtk3 applications in a non-gnome (xfce4) desktop enviromnent
On 9/10/19 6:32 PM, Pierre Labastie via blfs-dev wrote: On 10/09/2019 17:49, Tim Tassonis via blfs-dev wrote: Hi all After installing yad, a gtk3 shell-script dialog implementation, I finally decided to solve my long-standing issue of some applications (evince) complaining about GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. at startup. After digging a bit into gconf and gsettings, I finally found out that the solution for my problem is to install dconf, which then serves as a real working backend for gsettings. After installing dconf and restarting the desktop, the message disappeared and I am now able to view and changes settings of those applications. And finally also allow me to change the stupid default of the gtk3 file chooser to: gsettings set org.gtk.Settings.FileChooser sort-directories-first true It seems to me that while the BLFS has dconf in it, and it is problably referenced in the gnome section, there is no mention of it in the xfce4 section (apart from mousepad, which is in the editors section). I'm not sure about where the best place would be, but as gtk3 already uses gsettings/dconf as it's coonfiguration mechanism, it maybe could be listed as an optional dependency of gtk3? or a recommended run time dep? (if it prevents annoying warnings, it is in the category "that won't have issues [...] at run-time") Actually, I think dconf can be built before gtk3, but dconf-editor seems to need gtk3. Yes, I think dconf only needs glib, while dconf-editor also needs vala unconditionally. I agree that a recommended run-time dep would be best, as that's what it actually is. Apps using gsettings work without it, but won't store settings over reboots. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Storing settings of gtk3 applications in a non-gnome (xfce4) desktop enviromnent
Hi all After installing yad, a gtk3 shell-script dialog implementation, I finally decided to solve my long-standing issue of some applications (evince) complaining about GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. at startup. After digging a bit into gconf and gsettings, I finally found out that the solution for my problem is to install dconf, which then serves as a real working backend for gsettings. After installing dconf and restarting the desktop, the message disappeared and I am now able to view and changes settings of those applications. And finally also allow me to change the stupid default of the gtk3 file chooser to: gsettings set org.gtk.Settings.FileChooser sort-directories-first true It seems to me that while the BLFS has dconf in it, and it is problably referenced in the gnome section, there is no mention of it in the xfce4 section (apart from mousepad, which is in the editors section). I'm not sure about where the best place would be, but as gtk3 already uses gsettings/dconf as it's coonfiguration mechanism, it maybe could be listed as an optional dependency of gtk3? Bye Tim -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
