[blfs-dev] Acknowledgement to Ken.

[Fernando de Oliveira]

Thank you for undoing all you can find that I did. Even when the book
becomes worse (less exact) or even wrong.

This is a characteristics I did not know you had.

Until recently I liked you even more than Bruce.

Perhaps my masochism should make me change may aka.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Qupzilla-1.8.9 broken with qtwebkit-5.6.0

[Fernando de Oliveira]

Em 19-03-2016 12:27, Fernando de Oliveira escreveu:
> 
> 
> 

Please, disregard. It was supposed to be a private message.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] Qupzilla-1.8.9 broken with qtwebkit-5.6.0

[Fernando de Oliveira]

-- 
[]s,
Fernando, aka Sísifo
cd src/lib/ && ( test -e Makefile || /opt/qt5/bin/qmake /tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/lib/lib.pro -o Makefile ) && make -f Makefile 
make[1]: Entering directory '/tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/lib'
make[1]: Nothing to be done for 'first'.
make[1]: Leaving directory '/tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/lib'
cd src/main/ && ( test -e Makefile || /opt/qt5/bin/qmake /tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/main/main.pro -o Makefile ) && make -f Makefile 
make[1]: Entering directory '/tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/main'
g++ -Wl,-O1 -Wl,--enable-new-dtags -Wl,-rpath-link,/opt/qt5/lib -o ../../bin/qupzilla ../../build/main.o   /tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/../bin/libQupZilla.so -L/opt/qt5/lib -lQt5WebKitWidgets -lQt5PrintSupport -lQt5Widgets -lQt5WebKit -lQt5Gui -lQt5Network -lQt5Sql -lQt5Script -lQt5DBus -lQt5Core -lGL -lpthread 
/usr/bin/ld: warning: libANGLE.so.1, needed by /opt/qt5/lib/libQt5WebKitWidgets.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libWebKit1.so.1, needed by /opt/qt5/lib/libQt5WebKitWidgets.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libWebCore.so.1, needed by /opt/qt5/lib/libQt5WebKitWidgets.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libJavaScriptCore.so.1, needed by /opt/qt5/lib/libQt5WebKitWidgets.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libWTF.so.1, needed by /opt/qt5/lib/libQt5WebKitWidgets.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libleveldb.so.1, needed by /opt/qt5/lib/libQt5WebKit.so, not found (try using -rpath or -rpath-link)
../../build/main.o: In function `qupzilla_signal_handler(int) [clone .part.13]':
main.cpp:(.text+0x8d7): undefined reference to `qWebKitVersion()'
/opt/qt5/lib/libQt5WebKitWidgets.so: undefined reference to `QWebPageAdapter::setDevicePixelRatio(float)'
/opt/qt5/lib/libQt5WebKitWidgets.so: undefined reference to `QWebPageAdapter::selectedText() const'
/opt/qt5/lib/libQt5WebKitWidgets.so: undefined reference to `QWebPageAdapter::defaultUserAgentString()'
/tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/../bin/libQupZilla.so: undefined reference to `QWebHistoryInterface::setDefaultInterface(QWebHistoryInterface*)'
/tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/../bin/libQupZilla.so: undefined reference to `QWebHistory::backItem() const'
/opt/qt5/lib/libQt5WebKitWidgets.so: undefined reference to `QWebPageAdapter::handleShortcutOverrideEvent(QKeyEvent*)'
/tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/../bin/libQupZilla.so: undefined reference to `QWebHistory::canGoForward() const'
/tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/../bin/libQupZilla.so: undefined reference to `QWebHistory::forward()'
/opt/qt5/lib/libQt5WebKitWidgets.so: undefined reference to `QWebFrameAdapter::handleGestureEvent(QGestureEventFacade*)'
/opt/qt5/lib/libQt5WebKitWidgets.so: undefined reference to `QWebHitTestResultPrivate::operator=(QWebHitTestResultPrivate const&)'
/tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/../bin/libQupZilla.so: undefined reference to `QWebSettings::fontSize(QWebSettings::FontSize) const'
/opt/qt5/lib/libQt5WebKitWidgets.so: undefined reference to `QWebFrameAdapter::ensureAbsoluteUrl(QUrl const&)'
/opt/qt5/lib/libQt5WebKitWidgets.so: undefined reference to `QWebPageAdapter::inputMethodQuery(Qt::InputMethodQuery) const'
/opt/qt5/lib/libQt5WebKitWidgets.so: undefined reference to `typeinfo for QtPluginWidgetAdapter'
/tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/../bin/libQupZilla.so: undefined reference to `operator<<(QDataStream&, QWebHistory const&)'
/opt/qt5/lib/libQt5WebKitWidgets.so: undefined reference to `QWebPageAdapter::focusOutEvent(QFocusEvent*)'
/tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/../bin/libQupZilla.so: undefined reference to `QWebHistory::items() const'
/tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/../bin/libQupZilla.so: undefined reference to `QWebHistoryInterface::qt_metacall(QMetaObject::Call, int, void**)'
/opt/qt5/lib/libQt5WebKitWidgets.so: undefined reference to `QWebPageAdapter::dragUpdated(QMimeData const*, QPoint const&, QFlags)'
/tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/../bin/libQupZilla.so: undefined reference to `QWebSettings::globalSettings()'
/opt/qt5/lib/libQt5WebKitWidgets.so: undefined reference to `QWebFrameAdapter::hasView() const'
/opt/qt5/lib/libQt5WebKitWidgets.so: undefined reference to `QWebPageAdapter::inputMethodEvent(QInputMethodEvent*)'
/tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/../bin/libQupZilla.so: undefined reference to `QWebElementCollection::QWebElementCollection(QWebElementCollection const&)'
/tmp/porg-build-2016.03.19-10h21m51s/qupzilla-1.8.9/src/../bin/libQupZilla.so: undefined reference to 

Re: [blfs-dev] terminals

[Fernando de Oliveira]

Em 14-03-2016 10:08, Fernando de Oliveira escreveu:
> Em 14-03-2016 01:00, Ken Moffat escreveu:
>> On Sun, Mar 13, 2016 at 08:30:00PM -0500, Bruce Dubbs wrote:
>>> I would like to cut down the number of packages in BLFS.  The maintenance
>>> burden is tremendous and we have lots of duplication of capabilities. When
>>> it comes to terminals, we have:
>>>
>>> xterm
>>> gnome-terminal
>>> xfce4-terminal
>>> lxterminal
>>> qterminal
>>> konsole4
>>> konsole5
>>>
>>> I propose that we remove konsole4 and gnome-terminal.
>>>
>> I've read your other post on gnome-terminal - glad it now works, and
>> I have no objection to removing either of these.
>>
> 
> 
> I have no right t ask anything, but would like gnome-terminal to remain
> in the book.
> 
> 
>> But you missed one - rxvt-unicode aka urxvt :
>> actually, I would be happy if we removed xterm (and luit) because
>> rxvt-unicode is so much better (when pointed to a sensible set of
>> fonts)
>>
>> /me decides to run ;-)
>>
> 
> 

Thanks, Bruce, for attending my request.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] terminals

[Fernando de Oliveira]

Em 14-03-2016 01:00, Ken Moffat escreveu:
> On Sun, Mar 13, 2016 at 08:30:00PM -0500, Bruce Dubbs wrote:
>> I would like to cut down the number of packages in BLFS.  The maintenance
>> burden is tremendous and we have lots of duplication of capabilities. When
>> it comes to terminals, we have:
>>
>> xterm
>> gnome-terminal
>> xfce4-terminal
>> lxterminal
>> qterminal
>> konsole4
>> konsole5
>>
>> I propose that we remove konsole4 and gnome-terminal.
>>
> I've read your other post on gnome-terminal - glad it now works, and
> I have no objection to removing either of these.
> 


I have no right t ask anything, but would like gnome-terminal to remain
in the book.


> But you missed one - rxvt-unicode aka urxvt :
> actually, I would be happy if we removed xterm (and luit) because
> rxvt-unicode is so much better (when pointed to a sensible set of
> fonts)
> 
> /me decides to run ;-)
> 


-- 
[]s,
Fernando de Oliveira
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] gnome-terminal

[Fernando de Oliveira]

Em 13-03-2016 23:53, Bruce Dubbs escreveu:
> Ken Moffat wrote:
>> On Sun, Mar 13, 2016 at 02:16:54PM -0500, Bruce Dubbs wrote:
>>> Fernando de Oliveira wrote:
>>>> Em 12-03-2016 22:50, Bruce Dubbs escreveu:
>>>>> I'm trying to update the book to gnome-terminal-3.18.3.
>>>>>
>>>>> Using the current instructions it builds with no issues.
>>>>>
>>>>> However it won't run.  I get:
>>>>>
>>>>> Error constructing proxy for
>>>>> org.gnome.Terminal:/org/gnome/Terminal/Factory0:
>>>>> Error calling StartServiceByName for org.gnome.Terminal:
>>>>> GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process
>>>>> org.gnome.Terminal exited with status 8
>>>>
>>>> I don't know if this is related to new grep, but there are many
>>>>
>>>> about new 50 references to 'terminal-regex' plus 'terminal_regex' in
>>>> the
>>>> new code.
>>>
>>> I do not know what I am doing differently.  Ken is the one that tagged
>>> gnome-terminal for lfs79.  I reverted grep to 2.22 and went back and
>>> reverted gnome-terminal to 3.18.2.  I get the same problem.
>>>
>>
>> I've now got back to the machine where I did that.  I'm running
>> xfce, and from Applications -> System -> Terminal it opens.
>>
>> Help -> About  shows it is:
>>
>> GNOME Terminal
>> 3.18.2
>> A terminal emulator for the GNOME desktop
>>  Using VYE version 0.42.4 +GNUTLS
>>
>> I'll paste the output from running printenv in that terminal (I've
>> got sddm running, hence the QML items, and plexi is the machine name).
>>
>> Maybe something in the XDG variables ?
>>
>> XDG_VTNR=7
>> MANPATH=/usr/share/man:/opt/texlive/2015/texmf-dist/doc/man
>> SSH_AGENT_PID=1483
>> GLADE_PIXMAP_PATH=:
>> TERM=xterm-256color
>> SHELL=/bin/bash
>> XDG_MENU_PREFIX=xfce-
>> VTE_VERSION=4204
>> QML2_IMPORT_PATH=/opt/qt5/qml:/usr/lib/qml
>> XDG_SESSION_COOKIE=plexi-1457917390.222309-1486849046
>> WINDOWID=50331654
>> LC_ALL=en_GB.UTF-8
>> XDG_SESSION_CLASS=user
>> USER=ken
>> XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
>> GLADE_MODULE_PATH=:
>> QML_IMPORT_PATH=/opt/qt5/qml:/usr/lib/qml
>> XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
>> SSH_AUTH_SOCK=/tmp/ssh-qEUWTM0VyYuk/agent.1482
>> SESSION_MANAGER=local/plexi:@/tmp/.ICE-unix/1474,unix/plexi:/tmp/.ICE-unix/1474
>>
>> XDG_CONFIG_DIRS=/etc/xdg
>> PATH=/bin:/usr/bin:/usr/local/bin:/opt/kf5/bin:/opt/qt5/bin:/opt/texlive/2015/bin/x86_64-linux:/home/ken/bin
>>
>> DESKTOP_SESSION=/usr/share/xsessions/xfce
>> INPUTRC=/etc/inputrc
>> XDG_SESSION_TYPE=x11
>> PWD=/home/ken
>> LANG=en_GB.UTF-8
>> PS1=\u@\h \w \$
>> XDG_SEAT=seat0
>> HOME=/home/ken
>> SHLVL=2
>> XDG_SESSION_DESKTOP=XFCE
>> LOGNAME=ken
>> WINDOWID=50331654
>> LC_ALL=en_GB.UTF-8
>> XDG_SESSION_CLASS=user
>> USER=ken
>> XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
>> GLADE_MODULE_PATH=:
>> QML_IMPORT_PATH=/opt/qt5/qml:/usr/lib/qml
>> XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
>> SSH_AUTH_SOCK=/tmp/ssh-qEUWTM0VyYuk/agent.1482
>> SESSION_MANAGER=local/plexi:@/tmp/.ICE-unix/1474,unix/plexi:/tmp/.ICE-unix/1474
>>
>> XDG_CONFIG_DIRS=/etc/xdg
>> PATH=/bin:/usr/bin:/usr/local/bin:/opt/kf5/bin:/opt/qt5/bin:/opt/texlive/2015/bin/x86_64-linux:/home/ken/bin
>>
>> DESKTOP_SESSION=/usr/share/xsessions/xfce
>> INPUTRC=/etc/inputrc
>> XDG_SESSION_TYPE=x11
>> PWD=/home/ken
>> LANG=en_GB.UTF-8
>> PS1=\u@\h \w \$
>> XDG_SEAT=seat0
>> HOME=/home/ken
>> SHLVL=2
>> XDG_SESSION_DESKTOP=XFCE
>> LOGNAME=ken
>> XDG_DATA_DIRS=/usr/local/share:/usr/share
>> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-TTTl8Ve0nV,guid=3be6249363b0c73c9f8b073656e60dce
>>
>> INFOPATH=/usr/share/info:/opt/texlive/2015/texmf-dist/doc/info
>> DISPLAY=:0
>> GLADE_CATALOG_PATH=:
>> QT_PLUGIN_PATH=/opt/qt5/plugins:/usr/lib/plugins:/usr/plugins
>> XDG_CURRENT_DESKTOP=XFCE
>> GTK_IM_MODULE=xim
>> XAUTHORITY=/home/ken/.Xauthority
>> _=/usr/bin/printenv
>>
>>> I am running lxde and using lxterminal to try gnome-terminal from the
>>> command line.  The locale is set to en_US.utf8 which matches what
>>> locale -a
>>> says it has.
>>>
>>> dbus is running.  From p

Re: [blfs-dev] gnome-terminal

[Fernando de Oliveira]

Em 12-03-2016 22:50, Bruce Dubbs escreveu:
> I'm trying to update the book to gnome-terminal-3.18.3.
> 
> Using the current instructions it builds with no issues.
> 
> However it won't run.  I get:
> 
> Error constructing proxy for
> org.gnome.Terminal:/org/gnome/Terminal/Factory0:
> Error calling StartServiceByName for org.gnome.Terminal:
> GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process
> org.gnome.Terminal exited with status 8

I don't know if this is related to new grep, but there are many

about new 50 references to 'terminal-regex' plus 'terminal_regex' in the
new code.

Bug:



Reported:   2015-10-04 11:50 UTC by Egmont Koblinger
Modified:   2016-02-21 15:10 UTC (History)

Changelog:

{{{
diff -Naur gnome-terminal-3.18.2/ChangeLog gnome-terminal-3.18.3/ChangeLog

...

+commit 3bd692f5d63f0bdfb526d570c92da3270601c155
+Author: Christian Persch 
+Date:   Sun Feb 21 15:46:05 2016 +0100
+
+screen: Rewrite URL regexes
+
+Rewrite the URL match regex to be more correct.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=756038
+(cherry picked from commit 1a94499aca8f9a06479f5149e70e246bf9249ac0)
+
+ src/Makefile.am   |  27 +
+ src/terminal-regex.c  | 313
++
+ src/terminal-regex.h  | 145 +++
+ src/terminal-screen.c |  27 ++---
+ 4 files changed, 493 insertions(+), 19 deletions(-)
+
+commit f508d6b2c145cbccef1d2b5b1d1a469df31ca55e
+Author: Christian Persch 
+Date:   Mon Nov 9 20:59:06 2015 +0100
+
+Post release version bump
+
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
 commit b7c8f7ba4149a8b6f156d85529ef2aadf2b79378
 Author: YunQiang Su 
 Date:   Mon Nov 9 18:44:46 2015 +0800
}}}

However, this has generated controversy, just before 3.18.2 was realeased:



it was reverted:



Then, it finally landed:







-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] gnome-terminal

[Fernando de Oliveira]

Em 12-03-2016 22:50, Bruce Dubbs escreveu:
> I'm trying to update the book to gnome-terminal-3.18.3.
>
> Using the current instructions it builds with no issues.
>
> However it won't run.  I get:
>
> Error constructing proxy for
> org.gnome.Terminal:/org/gnome/Terminal/Factory0:
> Error calling StartServiceByName for org.gnome.Terminal:
> GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process
> org.gnome.Terminal exited with status 8
>
> I checked google, but the messages all have to do with systemd
> (localectl), but setting the locale to en_US.UTF-8 does not help.
>
> $ locale
> LANG=en_US.UTF-8
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE="en_US.UTF-8"
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER="en_US.UTF-8"
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT="en_US.UTF-8"
> LC_IDENTIFICATION="en_US.UTF-8"
>
>
> I normally only use gnome-terminal for testing.
>
> What am I missing?


Installed in LFS7.8, without updating the other packages from gnome and
works without any message, starting from lxterminal.

It starts as normal user or as root (some reports complain about
starting as root, one of them from xterm).

One report gives the (temporary) workaround

dbus-launch gnome-terminal

Is it possible that you are running in a session without dbus? Actually,
from waht DE are you running it?

One report complaints it does not start in Red Hat Enterprise Linux 7

I will try to build an LFS7.9 to check.


OT:

Typo:

Command Explanations
--disable-migration is displayed as , not 

s/option/parameter/

-- 
[]s,
Fernando de Oliveira
-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] pciutils download

[Fernando de Oliveira]

Em 04-03-2016 17:23, Bruce Dubbs escreveu:
> Pierre Labastie wrote:
>> Hi,
>>
>> It seems that ftp.kernel.org does not work for downloading pciutils. I
>> succeeded with
>> https://www.kernel.org/pub/software/utils/pciutils/pciutils-3.4.1.tar.xz,
>> and was unable to use ftp.
>>
>> Should I change the download link on the pciutils page?
> 
> I don't think so.  Both links in the book work for me.  Perhaps it was a
> transient error.

Yes, it works for me, now.


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] dependencies for LXQt

[Fernando de Oliveira]

Em 04-03-2016 18:09, Bruce Dubbs escreveu:
> Pierre Labastie wrote:
>> On 04/03/2016 17:16, Ken Moffat wrote:
>>> On Fri, Mar 04, 2016 at 12:10:46PM -0300, Fernando de Oliveira wrote:
>>>> Em 04-03-2016 09:08, Pierre Labastie escreveu:
>>> (trimming severely)
>>>>> On 04/03/2016 11:36, Fernando de Oliveira wrote:
>>>>>> Em 04-03-2016 06:15, Pierre Labastie escreveu:
>>>>>>> Does somebody know which kf5 and
>>>>>>> plasma deps are really needed?
>>>>> Anyway, I'll build all of plasma because I am in a hurry to tag lxqt,
>>>>> and I do not have time to search which lib needs which dep.
>>>> Perhaps I am understanding now.
>>>>
>>>> When the LXQt instructions where written, they worked for what we
>>>> had in
>>>> Plasma and KF5. Now, Plasma and KF5 changed and consequently the LXQt
>>>> instructions have to change in order to sync?
>>>>
>>>> When I did the pages, everything was there.
>>>>
>>>> Now, someone, perhaps you(?) needs to do it again. I never liked LXQt,
>>>> because the the devs are KDE devs, each new version, new "KDE"
>>>> dependencies are always introduced.
>>>>
>>>> something else was modified, now the dependency chain is modified.
>>>>
>>>> I cannot fix.
>>>>
>>>>
>>>> However, the list of dependencies are at:
>>>>
>>>> https://github.com/lxde/lxqt/wiki/Building-From-Source
>>>>
>>>> and do not seem to have been modified.
>>>>
>>> The last time I built lxqt, the only KF5 deps it needed were:
>>>
>>> extra-cmake-modules
>>>
>>> kwindowsystem (I built those two before liblxqt)
>>>
>>> kguiaddons (I built that before libstatgrab)
>>>
>>> I can see that I also built oxygen-icons from kde4, and the qt5
>>> version of polkit-qt.
>>>
>>>  From what I remember, it really required openbox (I had thought
>>> other 'box WMs might pass muster).
>>>
>>> ĸen
>> Thanks,
>>
>> Actually, as I said, I built all of kf5 and plasma. I found a small (but
>> annoying, because libksysguard was not applied the fix) bug in the plasma
>> instructions, (see commit r17061), so hopefully, making the book better.
>>
>> Otherwise, the LXQT build went smoothly, so I think the instructions are
>> good. I have built openbox, lxdm and sddm. I still have to test that now.
>>
>> To Fernando, I understood you hadn't understood my first post. That's why
>> I explained. I'm glad we agree (I do not like LXQt either, for the same
>> reasons as you...).
> 
> I've read the thread.  I have to admit that I haven't built LXQt. 
> Looking through the instructions, I don't really like the way the
> kf5/plasma dependencies are presented.
> 
> From what I can see, the following are needed:
> 
> From KF5: kwindowsystem, kguiaddons, solid
> Form Plasma: libkscreen
> 
> These in turn have dependencies.  Looking at the CMakeLists.txt files in
> those packages tells me that they need extra-cmake-modules and the xcb
> libraries in xorg.  libkscreen has an optional dependency of doxygen.
> 
> Solid has optional dependencies media-player-info (not in the book),
> udisks2, and upower.
> 
> 
> My preference would be to add pages for  kwindowsystem, kguiaddons,
> solid, and libkscreen to the book in the LXQt section and add a note
> that they are also built as a part of KF5 and (or plasma for libkscreen)
> and do not need to be rebuilt if those multiple package installs have
> been made.
> 
> If needed I can test it by just renaming /opt/kf5.  (Another good reason
> for building in /opt).

Second time you propose.

Please, make it readable. I always fail.

Thanks.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] pciutils download

[Fernando de Oliveira]

Em 04-03-2016 14:27, Pierre Labastie escreveu:
> Hi,
> 
> It seems that ftp.kernel.org does not work for downloading pciutils. I
> succeeded with
> https://www.kernel.org/pub/software/utils/pciutils/pciutils-3.4.1.tar.xz, and
> was unable to use ftp.
> 
> Should I change the download link on the pciutils page?
> 
> Regards
> Pierre
> 

Please, go ahead.

Thanks.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] dependencies for LXQt

[Fernando de Oliveira]

Em 04-03-2016 09:08, Pierre Labastie escreveu:
> On 04/03/2016 11:36, Fernando de Oliveira wrote:
>> Em 04-03-2016 06:15, Pierre Labastie escreveu:
>>> Hi,
>>>
>>> I am struggling through the dependency chain for LXQt, and I end up
>>> needing all the dependencies for KDE-frameworks and plasma.
>> I know the reason.
>>
>>> Of course
>>> for each of KF5 and plasma, there are only a couple libraries needed,
>>> but nothing is said about the dependencies for those libraries.
>> You confirm that the needed libraries are stated. Don't you think you
>> should rplace LXQt by KF5 and plasma in the subject, so this would not
>> be misleading for someone searching in the internet?
>>
>> Your sentence should read: "nothing is said in in KF5 and plasma about
>> their own individual dependencies". I found it, Ken found it.
>>
>> I think KF5 and plasma are good as they are.
>>
>> It is not the role of LXQt to state which are the dependencies of Plasma
>> or KF5.
>>
>>> So it is
>>> hard to know what deps are needed (I may have missed something in the
>>> book),
>> Perhaps scripting, instead of jhalfing?
>>
>>> and building LXQt is therefore very heavy (far from the
>>> "lightweight" desktop advertised).
>> Yes, it may be very heavyweight for jhalfs. I may have advertised that
>> it is lightweight, but surely was not referring to jhalfs.
>>
>>
>>> Does somebody know which kf5 and
>>> plasma deps are really needed?
>> As with other criticisms I was expecting this post.
>>
>> There is a simple solution: tell Bruce to divide the pages so that
>> jhalfs find them.
>>
>> This would not be news, as many of the book is modified to solve jhalfs
>> problem, when the contrary should be the correct.
>>
>> Sometimes I think that the project is jhalfs and the sub-projects are
>> (B)LFS.
>>
>> Would you please try to script this part, instead of using jhalfs?
>>
> What I ask has nothing to do with jhalfs. Following a dependency chain
> has to be done anyway! Jhalfs allows to automate that, but I do not ask
> to change the book for jhalfs. In that post, I did not even ask to
> change the book in any way. Of course, I could find for myself what the
> dependencies are, as you and Ken did, but since you did it, and you
> usually are happy to share what you find, I thought I could ask... Also,
> in the book, we usually try to be explicit about dependencies, so that's
> the subject of this thread. Sorry if I sounded criticizing, that was not
> my aim.
> 
> Anyway, I'll build all of plasma because I am in a hurry to tag lxqt,
> and I do not have time to search which lib needs which dep.

Perhaps I am understanding now.

When the LXQt instructions where written, they worked for what we had in
Plasma and KF5. Now, Plasma and KF5 changed and consequently the LXQt
instructions have to change in order to sync?

When I did the pages, everything was there.

Now, someone, perhaps you(?) needs to do it again. I never liked LXQt,
because the the devs are KDE devs, each new version, new "KDE"
dependencies are always introduced.


From what you write, perhaps semething new has been included in "KDE"
something else was modified, now the dependency chain is modified.

I cannot fix.


However, the list of dependencies are at:

https://github.com/lxde/lxqt/wiki/Building-From-Source

and do not seem to have been modified.


Apologies for the posts, please.

I do not like LXQt. I much prefer LXDE. If LXDE survives, I'd rather
remove LXQt from the book than LXDE.

Some new versions have recently been released, you saw. And a lot of
development to port to gtk+3 is going on (not sure if this is a good
thing or not).


Very sorry with the mood of the other posts. Hope you accept my apologies.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Chapter 9 Qca-2.1.1

[Fernando de Oliveira]

Em 04-03-2016 07:03, Pierre Labastie escreveu:
> On 29/02/2016 00:04, Bruce Dubbs wrote:
>> Lee Hancock wrote:
>>> hi,
>>> In the build instructions for Qca-2.1.1 it states "There are no
>>> packages in
>>> BLFS that use the Qt5 version of Qca.". This is not technically true
>>> as in
>>> chapter 34 Plasma5 one of the requirements is "qca-2.1.1 (built with
>>> qt5)".
>>> This was observed in Version 2016-02-27 of BLFS.
>>>
>>> Sorry if I'm been a bit fussy, Lee.
>>
>> Well it was true when it was written.  I'll remove that sentence,
>>
> Hi,
> 
> I see also that all the instructions reference QT4DIR and that there is
> a switch
> 
> -DQT4_BUILD=ON, which should not be present if building with Qt5. I am
> not sure what
> to do. Maybe having two versions of the build, one for Qt4 and one for
> Qt5 (as for some other packages)?

No, just a sentence: if building with Qt5, replace -DQT4_BUILD=ON by
-DQT4_BUILD=OFF.

Oh! I know, jhalfs rules (as for some other packages). I think jhalfs
should be fixed definitely, unless we state: to develop (B)LFS, you need
to test if the instructions pass with jhalfs. Or: jhalfs is required for
all packages in (B)LFS.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] dependencies for LXQt

[Fernando de Oliveira]

Em 04-03-2016 06:15, Pierre Labastie escreveu:
> Hi,
> 
> I am struggling through the dependency chain for LXQt, and I end up
> needing all the dependencies for KDE-frameworks and plasma.

I know the reason.

> Of course
> for each of KF5 and plasma, there are only a couple libraries needed,
> but nothing is said about the dependencies for those libraries.

You confirm that the needed libraries are stated. Don't you think you
should rplace LXQt by KF5 and plasma in the subject, so this would not
be misleading for someone searching in the internet?

Your sentence should read: "nothing is said in in KF5 and plasma about
their own individual dependencies". I found it, Ken found it.

I think KF5 and plasma are good as they are.

It is not the role of LXQt to state which are the dependencies of Plasma
or KF5.

> So it is
> hard to know what deps are needed (I may have missed something in the
> book),

Perhaps scripting, instead of jhalfing?

> and building LXQt is therefore very heavy (far from the
> "lightweight" desktop advertised).

Yes, it may be very heavyweight for jhalfs. I may have advertised that
it is lightweight, but surely was not referring to jhalfs.


> Does somebody know which kf5 and
> plasma deps are really needed?

As with other criticisms I was expecting this post.

There is a simple solution: tell Bruce to divide the pages so that
jhalfs find them.

This would not be news, as many of the book is modified to solve jhalfs
problem, when the contrary should be the correct.

Sometimes I think that the project is jhalfs and the sub-projects are
(B)LFS.

Would you please try to script this part, instead of using jhalfs?

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Video problems

[Fernando de Oliveira]

Em 03-03-2016 17:18, Bruce Dubbs escreveu:
> Fernando de Oliveira wrote:
>> Em 02-03-2016 01:05, Bruce Dubbs escreveu:
>>> Ken Moffat wrote:
>>>> On Tue, Mar 01, 2016 at 04:13:03PM -0600, Bruce Dubbs wrote:
>>>>> Bruce Dubbs wrote:
>>>>>>
>>>>>> I'm not sure about the hardware support messages.   This is a nvida
>>>>>> card
>>>>>> (GeForce 210) on my -dev system.  Wouldn't x264 give h264 support?
>>>>>
>>>>> Armin gave me some links and I installed some nvidia firmware.  Now
>>>>> melt
>>>>> works and the this hardware doesn't support messages above are gone.
>>>>>
>>>> That is good to know, but it implies that 'About Firmware' needs an
>>>> addition for (some) nvidia cards ?  At the moment we only cover
>>>> video cards in
>>>>
>>>> Firmware for ATI video chips (R600 and later)
>>>>
>>>> Also, did you have to load other firmware for your Skylake, or was
>>>> that just the CPU firmware ?
>>>
>>> I do have /lib/firmware/cpia2/stv0672_vp4.bin which, IIRC, is for a
>>> camera on my laptop.  Nothing else for either my Haswell or Skylake.
>>>
>>> The details for nvidia are at https://nouveau.freedesktop.org/wiki/VP4/
>>
>> Yesterday, after som time, found
>>
>> https://aur.archlinux.org/packages/nouveau-fw
>>
>> An interesting thing is that I didn't have to reboot or reinstall the
>> kernel. Not sure about mesa, because only tested after reinstalling it.
> 
> Interesting link.  Do you think the addition to the firmware page for
> nvidia firmware needs to be updated or is is it good enough?
> 
>   -- Bruce
> 

I like it. Not sure about the notes

https://nouveau.freedesktop.org/wiki/VP4/

{{{
In order to get pre-NVC0 chips to work, you need to

Extract firmware from the blob (see VideoAcceleration).
Install Mesa 10.0.1 or later.
Build kernel 3.12-rc1 or later, install, reboot
Run mplayer -vo vdpau -vc
ffmpeg12vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau, 

In order to make these settings more permanent, you can add
[vo.vdpau]
vc=ffmpeg12vdpau,ffwmv3vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau,

to

/etc/mplayer/mplayer.conf
}}}

I did it to /etc/mplayer/gui.conf, which I copied from
/etc/mplayer/example.conf, wich already had the line ready to be
uncommented.


Alternatively, I had obtained:

vo_driver=vdpau in ~/.mplayer/gui.conf

configuring with the gui.

To be sure, I did (with either configurations:

$ sudo lsof -c gmplayer | grep -i vdpau
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /home/fernando/.gvfs
  Output information may be incomplete.
gmplayer 15548 fernando  mem   REG   8,27   5405104
1251523 /usr/lib/vdpau/libvdpau_nouveau.so.1.0.0
gmplayer 15548 fernando  mem   REG   8,27 64328
1215493 /usr/lib/libvdpau.so.1.0.0


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] feh seems to be broken

[Fernando de Oliveira]

Em 02-03-2016 23:19, Ken Moffat escreveu:
> I needed to test a fix for my logging, and I had noticed feh was not
> tagged - I have a script for that and its deps.
> 
> But for me, feh's tests fail:
> 
> make[1]: Leaving directory
> '/scratch/working/feh-2.14.1/share/applications'
> 
> #   Failed test 'stdout_is_file: src/feh --list --quiet test/ok/gif
> #   test/ok/jpg test/ok/png test/ok/pnm test/fail/gif test/fail/jpg
> #   test/fail/png test/fail/pnm, test/list/default'
> #   at test/feh.t line 130.
> # STDOUT differs from test/list/default starting at line 2.
> # got: 1jpeg16  16  256 354 -
> # test/ok/jpg
> # exp: 1gif 16  16  256 953 -
> # test/ok/gif
> #^
> 
> #   Failed test 'stdout_is_file: src/feh --quiet --list --action
> #   'echo "%f %wx%h" >&2' test/ok/gif test/ok/jpg test/ok/png
> #   test/ok/pnm test/fail/gif test/fail/jpg test/fail/png
> #   test/fail/pnm, test/list/default'
> #   at test/feh.t line 137.
> # STDOUT differs from test/list/default starting at line 2.
> # got: 1jpeg16  16  256 354 -
> # test/ok/jpg
> # exp: 1gif 16  16  256 953 -
> # test/ok/gif
> #^
> # Looks like you failed 2 tests of 71.
> test/feh.t . 
> Dubious, test returned 2 (wstat 512, 0x200)
> Failed 2/71 subtests 
> Can't exec "mandoc": No such file or directory at test/mandoc.t line
> 9.
> # mandoc not installed, test skipped. This is NOT fatal.
> test/mandoc.t .. ok
> 
> This is, of course, with the patch.  It looks as if gif is not
> supported : there is a release note at
> https://feh.finalrewind.org/archive/2.14.2/ which says
> 
> make test: Ignore results on arm and mips since they expose a bug in
> Imlib2 1.4.7 and/or giflib 5.1.2. Note that due to this bug, feh may
> be unable to display gif images. x86 and amd64 are also affected.
> Again, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813729
> for more information
> 
> I am on x86_64 and running src/feh on my one gif image reports
> feh WARNING: /sources/languages.gif - No Imlib2 loader for that file
> format
> feh: No loadable images specified.
> 
> That report blames Imlib2 (with details).
> 
> So then I tried 2.14.2.  The patch does not apply, but without it I
> get the same two failures and the same error if I try to use it to
> display a gif.
> 
> And since feh does seem to be broken for gifs, I have no interest in
> trying to fix the patch.
> 
> What I find odd is that our last upgrade of feh was after the giflib
> update in January, and we have been on that version of Imlib since
> 7.8 or earlier.
> 
> ĸen
> 

I struggled with that for some time. At the end, wrote:

http://wiki.linuxfromscratch.org/blfs/changeset/16905/trunk/BOOK/xsoft/other/feh.xml

{{{
@@ -124,4 +135,11 @@
   
 Installation of feh
+
+ Due to well-known problems when
feh try to
+load gif images (sometimes imlib2
being blamed
+for that), some tests fail. To avoid that, apply the following
patch, if you
+intend to run the test suite: 
+
+patch -Np1 -i
../feh--disable_some_tests-1.patch

 
}}}

For me, it is broken with gif

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Video problems

[Fernando de Oliveira]

Em 02-03-2016 01:05, Bruce Dubbs escreveu:
> Ken Moffat wrote:
>> On Tue, Mar 01, 2016 at 04:13:03PM -0600, Bruce Dubbs wrote:
>>> Bruce Dubbs wrote:

 I'm not sure about the hardware support messages.   This is a nvida
 card
 (GeForce 210) on my -dev system.  Wouldn't x264 give h264 support?
>>>
>>> Armin gave me some links and I installed some nvidia firmware.  Now melt
>>> works and the this hardware doesn't support messages above are gone.
>>>
>> That is good to know, but it implies that 'About Firmware' needs an
>> addition for (some) nvidia cards ?  At the moment we only cover
>> video cards in
>>
>> Firmware for ATI video chips (R600 and later)
>>
>> Also, did you have to load other firmware for your Skylake, or was
>> that just the CPU firmware ?
> 
> I do have /lib/firmware/cpia2/stv0672_vp4.bin which, IIRC, is for a
> camera on my laptop.  Nothing else for either my Haswell or Skylake.
> 
> The details for nvidia are at https://nouveau.freedesktop.org/wiki/VP4/

Yesterday, after som time, found

https://aur.archlinux.org/packages/nouveau-fw

An interesting thing is that I didn't have to reboot or reinstall the
kernel. Not sure about mesa, because only tested after reinstalling it.


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Video problems

[Fernando de Oliveira]

Em 01-03-2016 17:40, Ken Moffat escreveu:
> On Tue, Mar 01, 2016 at 01:46:34PM -0600, Bruce Dubbs wrote:
>> I've run into a brick wall.  I'm trying to finish up kf5 but can't get
>> kdenlive to work.  Trying to trace it, I looked at the dependencies.
>>
>> The mlt package installs an executable named melt.  This program plays an
>> mp4 file.  The one I use for testing is
>>
>> http://anduin.linuxfromscratch.org/~bdubbs/files/big_buck_bunny.mp4
>>
>> It is a 1 minute video/audio file for testing.
>>
>> It plays fine with ffplay, vlc, and mplayer.  In a previous version of BLFS,
>> SVN-20150703, it also plays fine with melt.
>>
>> The problem with the latest version is that I get:
>>
>> $ melt big_buck_bunny.mp4
>>
>> [producer avformat] big_buck_bunny.mp4
>>
>> VDPAU failed to initialize decoder
>> (An invalid/unsupported VdpDecoderProfile value was supplied.)
>> [h264 @ 0x1eee2c0] Could not find an AVHWAccel for the pixel format:
>> vdpau_h264 Assertion choices[n] != AV_PIX_FMT_NONE
>> failed at libavcodec/utils.c:1258
>> Aborted
>>
>> I've tried rebuilding mlt and its dependencies as well as ffmpeg, x264,
>> libva and libvdpau.  I also tried reverting from mlt-0.9.8 to mlt-0.9.6.
>>
>> Can I please get someone to build/test melt (package mlt) for me and see if
>> it works for you.
>>
> I can't test it for the moment, but does vdpau actually work for
> you ?  I normally use xine to check that - on most of my boxen it
> moans (if run from a term) if vdpau is not available - and neither
> my SandyBridge, my Phenom, nor my Haswell have workign vdpau so I
> stopped building it on them.
> 
> The Aruba used to have working vdpau (that mobo died), the Kaveri
> does - I'm on the Kaveri, but no qt5 in this build and I'm
> struggling to get libreoffice to build after turning off SSLv2.
> 
> ĸen
> 


Works fine with mplayer-SVN-r37794 (notice that ffmpeg is newer than 3.0.

{ time mplayer big_buck_bunny.mp4; } 2>&1 | tee
big_buck_bunny.mp4-mplayer.log

Could not get language to change to C above.


For VLC, needed to choose VA-API via DRM.

{ time env LC_ALL=C vlc big_buck_bunny.mp4; } 2>&1 | tee
big_buck_bunny.mp4-vlc.log


My general impression is that mplayer was better (sound and video).



-- 
[]s,
Fernando, aka Sísifo


big_buck_bunny.mp4-mplayer.log.xz
Description: application/xz
Blocked: call to strerror(19)
Blocked: call to strerror(19)
Blocked: call to strerror(19)
Blocked: call to strerror(19)
Blocked: call to strerror(2)
[024c3148] core libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
Blocked: call to setlocale(6, "")
Warning: call to srand(1456870575)
Warning: call to rand()
Warning: call to srand(1456870575)
Warning: call to rand()
Warning: call to srand(1456870575)
Warning: call to rand()
Warning: call to srand(1456870575)
Warning: call to rand()
Warning: call to srand(1456870575)
Warning: call to rand()
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
[7fa7140009c8] vaapi_drm generic error: Failed to initialize the VAAPI device

real	1m16.996s
user	0m7.012s
sys	0m2.180s
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Video problems

[Fernando de Oliveira]

Em 01-03-2016 18:20, Bruce Dubbs escreveu:
> Ken Moffat wrote:
>> On Tue, Mar 01, 2016 at 01:46:34PM -0600, Bruce Dubbs wrote:
>>> I've run into a brick wall.  I'm trying to finish up kf5 but can't get
>>> kdenlive to work.  Trying to trace it, I looked at the dependencies.
>>>
>>> The mlt package installs an executable named melt.  This program
>>> plays an
>>> mp4 file.  The one I use for testing is
>>>
>>> http://anduin.linuxfromscratch.org/~bdubbs/files/big_buck_bunny.mp4
>>>
>>> It is a 1 minute video/audio file for testing.
>>>
>>> It plays fine with ffplay, vlc, and mplayer.  In a previous version
>>> of BLFS,
>>> SVN-20150703, it also plays fine with melt.
>>>
>>> The problem with the latest version is that I get:
>>>
>>> $ melt big_buck_bunny.mp4
>>>
>>> [producer avformat] big_buck_bunny.mp4
>>>
>>> VDPAU failed to initialize decoder
>>> (An invalid/unsupported VdpDecoderProfile value was supplied.)
>>>  [h264 @ 0x1eee2c0] Could not find an AVHWAccel for the pixel
>>> format:
>>>  vdpau_h264 Assertion choices[n] != AV_PIX_FMT_NONE
>>>  failed at libavcodec/utils.c:1258
>>>  Aborted
>>>
>>> I've tried rebuilding mlt and its dependencies as well as ffmpeg, x264,
>>> libva and libvdpau.  I also tried reverting from mlt-0.9.8 to mlt-0.9.6.
>>>
>>> Can I please get someone to build/test melt (package mlt) for me and
>>> see if
>>> it works for you.
>>>
>> I can't test it for the moment, but does vdpau actually work for
>> you ?  I normally use xine to check that - on most of my boxen it
>> moans (if run from a term) if vdpau is not available - and neither
>> my SandyBridge, my Phenom, nor my Haswell have workign vdpau so I
>> stopped building it on them.
>>
>> The Aruba used to have working vdpau (that mobo died), the Kaveri
>> does - I'm on the Kaveri, but no qt5 in this build and I'm
>> struggling to get libreoffice to build after turning off SSLv2.
> 
> xine plays the file fine, but I do get some messages:
> 
> $ xine big_buck_bunny.mp4
> This is xine (X11 gui) - a free video player v0.99.9.
> (c) 2000-2014 The xine Team.
> vo_vdpau: vdpau API version : 1
> vo_vdpau: vdpau implementation description : G3DVL VDPAU Driver Shared
> Library version 1.0
> vo_vdpau: maximum video surface size for chroma type 4:2:2 is 8192x8192
> vo_vdpau: maximum video surface size for chroma type 4:2:0 is 8192x8192
> vo_vdpau: maximum output surface size is 8192x8192
> vo_vdpau: hold a maximum of 10 video output surfaces for reuse
> vo_vdpau: using 3 output surfaces of size 1920x1080 for display queue
> vo_vdpau: this hardware doesn't support h264.
> vo_vdpau: this hardware doesn't support vc1.
> vo_vdpau: this hardware doesn't support mpeg1/2.
> vo_vdpau: this hardware doesn't support mpeg4-part2.
> vdpau_set_property: property=1, value=0
> vo_vdpau: deinterlace: none
> vo_vdpau: set_scaling_level=0
> vo_vdpau: disable noise reduction.
> vo_vdpau: disable sharpness.
> vo_vdpau: skip_chroma = 0
> 
> I'm not sure about the hardware support messages.   This is a nvida card
> (GeForce 210) on my -dev system.  Wouldn't x264 give h264 support?

Played locally with FF.


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Fonts

[Fernando de Oliveira]

Em 26-02-2016 22:49, Bruce Dubbs escreveu:
> Ken Moffat wrote:


>> Oh, and isn't testing wonderful, now that we have so many packages
>> in the book ?
> 
> It would be a lot easier if we had more testers.  From my perspective,
> I'd like someone independent to test gcc, java, all of typesetting,
> lxde, lxqt, display managers and gnome.  I'm comfortable with kde4/5 and
> xfce.

Why are only confortable with kde4/5 and xfce?


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] Virus

[Fernando de Oliveira]

I am sick, as already wrote privately and in one of the lists.

Probability is to a virus.

Yesterday, I tried to work., but couldn't complete and am not sure if
what I did was all correct.

Several tasks must be taken befero a release: packages that are only
updated for a release is what I think is the most important.

I don't know when I will be back, but I can't work now.

Please, releasing BLFS is not just tagging.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] Dependency is missing or other requests to modify the book

[Fernando de Oliveira]

Please, someone take care of them.

These always bring trouble for me, I hate to fight and always end up
blocking some emails.

Many times, someone else, not me, had missed the point before me, when
the request is reasonable.

Since yesterday I was worried about those, and could  not do any work,
until decided to create the tickets.


Thanks.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Dependency is missing or other requests to modify the book

[Fernando de Oliveira]

Em 13-02-2016 14:09, Fernando de Oliveira escreveu:
> Please, someone take care of them.
> 
> These always bring trouble for me, I hate to fight and always end up
> blocking some emails.
> 
> Many times, someone else, not me, had missed the point before me, when
> the request is reasonable.
> 
> Since yesterday I was worried about those, and could  not do any work,
> until decided to create the tickets.
> 
> 
> Thanks.
> 

Forgot to tell:

in valgrind, which is in configure already while host seems o appear
only in the testsm IIRC, related to darwin.

I have finished thunderbird, but will commit only tomorrow.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] qca-qt5

[Fernando de Oliveira]

Em 11-02-2016 23:42, Ken Moffat escreveu:
> On Fri, Feb 12, 2016 at 02:12:26AM +, Ken Moffat wrote:
>> Since I've now got the horsepower, I'm adding (to my scripts) the
>> parts of qt5 which I normally regard as "not wanted on voyage".
>>
>> At plasma-nm, I find that I need Qca-qt5 : fair enough, the plasma
>> deps mention it as:
>>  qca-2.1.1 (built with qt5)
>>
>> But, when I come to look at qca I see that we force a QT4 build and
>> install it into $QT4DIR.
>>
>> For the build, the explanation says:
>>
>> -DQT4_BUILD=ON: This switch is used to force building with Qt4 even
>> if Qt5 is found. There are no packages in BLFS that use the Qt5
>> version of Qca.
>>
>> I assume I need to use $KF5_PREFIX as well as forcing QT4, but I
>> think the Qca page needs a little love before 7.9.
>>
> Sod this for a game of soldiers.
> 
> I've looked at #7182, I'm running cmake with
> 
> cmake -DCMAKE_INSTALL_PREFIX=$KF5_PREFIX\
>   -DCMAKE_BUILD_TYPE=Release\
>   -DQCA_MAN_INSTALL_DIR:PATH=${KF5_PREFIX}/share/man \
>   ..
> 

ĸen,

I have built it with Qt4 and with Qt5.

On 2015.11.30-07h31m08s with Qt4:

{{{
cmake -DCMAKE_INSTALL_PREFIX=$QT4DIR \
  -DCMAKE_BUILD_TYPE=Release \
  -DQT4_BUILD=ON \
  -DQCA_MAN_INSTALL_DIR=/usr/share/man \
  ..
}}}

{{{
QCA prefix is /opt/qt4
Plugins will be installed to /opt/qt4/lib/qca
Binary will be installed to /opt/qt4/bin
Library will be installed to /opt/qt4/lib
Public headers will be installed to /opt/qt4/include
Private headers will be installed to /opt/qt4/include
Feature file will be installed to /opt/qt4/mkspecs/features
Documentation will be installed to /opt/qt4/share/doc/qca/html
Man page will be installed to /usr/share/man
Pkg-config file will be installed to /opt/qt4/lib/pkgconfig
}}}

{{{
100% tests passed, 0 tests failed out of 24

Total Test time (real) =  56.41 sec
}}}

On 2015.11.30-07h40m03s with Qt5:

{{{
cmake -DCMAKE_INSTALL_PREFIX=$QT5DIR \
  -DCMAKE_BUILD_TYPE=Release \
  -DQCA_MAN_INSTALL_DIR=/usr/share/man \
  ..
}}}

{{{
QCA prefix is /opt/qt5
Plugins will be installed to /opt/qt5/lib/qca-qt5
Binary will be installed to /opt/qt5/bin
Library will be installed to /opt/qt5/lib
Public headers will be installed to /opt/qt5/include/Qca-qt5
Private headers will be installed to /opt/qt5/include/Qca-qt5
Feature file will be installed to /opt/qt5/mkspecs/features
Documentation will be installed to /opt/qt5/share/doc/qca-qt5/html
Man page will be installed to /usr/share/man
Pkg-config file will be installed to /opt/qt5/lib/pkgconfig
}}}

{{{
100% tests passed, 0 tests failed out of 24

Total Test time (real) =  56.36 sec
}}}

Notice that you used

-DCMAKE_INSTALL_PREFIX=$KF5_PREFIX

but should have been

-DCMAKE_INSTALL_PREFIX=$QT5DIR

and that there is an *error* in the book:

s:MAN_INSTALL_DIR:PATH=${KF5_PREFIX}/share/man:MAN_INSTALL_DIR=/usr/share/man:

or simply

s/:PATH=${KF5_PREFIX}//

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] libreoffice - failure in CppunitTest_dbaccess_firebird_test

[Fernando de Oliveira]

Em 11-02-2016 23:01, Ken Moffat escreveu:
> On Thu, Feb 11, 2016 at 09:15:17AM -0300, Fernando de Oliveira wrote:
>> Em 10-02-2016 14:06, Fernando de Oliveira escreveu:
>>> Em 10-02-2016 13:20, Ken Moffat escreveu:
>>>> On Sun, Feb 07, 2016 at 07:49:09AM -0300, Fernando de Oliveira wrote:
>>>>> Em 07-02-2016 07:45, Fernando de Oliveira escreveu:
>>>>>> Em 06-02-2016 22:37, Ken Moffat escreveu:
>>>>>>> In my current build, libreoffice failed with:
>>>>>>>
>>>> [...]
>>>>>>>
>>>>>>> Error: a unit test failed, please do one of:
>>>>>>>
>>>>>>> export DEBUGCPPUNIT=TRUE# for exception catching
>>>>>>> export CPPUNITTRACE="gdb --args"# for interactive debugging on Linux
>>>>>>> export VALGRIND=memcheck# for memory checking
>>>>>>>
>>>>>>> and retry using: make CppunitTest_dbaccess_firebird_test
>>>>>>>
>>>>>
>>>>>>> ĸen
>>>>>>>
>>>>>>
>>>>>> There has been problems when building in ssh or chroot. I had it a
>>>>>> couple of times. e.g.
>>>>>>
>>>>>> <http://lists.linuxfromscratch.org/pipermail/blfs-support/2014-October/075800.html>
>>>>>>
>>>>>
>>>>> Found another one, where I intentionally reproduced the problem via ssh:
>>>>>
>>>>> <http://lists.linuxfromscratch.org/pipermail/blfs-dev/2014-October/028718.html>
>>>>>
>>>> So, do you think we should add --disable-firebird-sdbc to the
>>>> configure ('the firebird support sometimes fails its unit test'), or
>>>> else docment it as an optional switch ?
>>>>
>>>> I see you have taken the next release of LO.
>>>>
>>>> ĸen
>>>>
>>>
>>> If it fails for me, we add. If not, I will (kindly) ask you to add it to
>>> page, it is worth documenting.
>>
>> No error with Firebired. Please, add your words to document the
>> CppunitTest_dbaccess_firebird_failed test.
>>>
>>> I am building with system boost. The patch failed to apply, mostly for
>>> "gave already been applied". If correct, we will all be happy. :-)
>>
>> Worked fine with system-boost and no patch.
>>
> Sorry, I got distracted - first I tried to use my new kvm switch,
> only to find that my old server does not talk to a usb keyboard, and
> then somebody reported a problem with our (my) texlive instructions
> on the tl-build list of all places (for the moment, I have indicated
> what I think he did wrong).
> 
> Added, as an option, at r16950.  For the moment I do not know how
> reliably it occurs, and next time I might build gdb anyway (if I
> remember).
> 
> ĸen
> 

Thanks!!!

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] libreoffice - failure in CppunitTest_dbaccess_firebird_test

[Fernando de Oliveira]

Em 10-02-2016 14:06, Fernando de Oliveira escreveu:
> Em 10-02-2016 13:20, Ken Moffat escreveu:
>> On Sun, Feb 07, 2016 at 07:49:09AM -0300, Fernando de Oliveira wrote:
>>> Em 07-02-2016 07:45, Fernando de Oliveira escreveu:
>>>> Em 06-02-2016 22:37, Ken Moffat escreveu:
>>>>> In my current build, libreoffice failed with:
>>>>>
>> [...]
>>>>>
>>>>> Error: a unit test failed, please do one of:
>>>>>
>>>>> export DEBUGCPPUNIT=TRUE# for exception catching
>>>>> export CPPUNITTRACE="gdb --args"# for interactive debugging on Linux
>>>>> export VALGRIND=memcheck# for memory checking
>>>>>
>>>>> and retry using: make CppunitTest_dbaccess_firebird_test
>>>>>
>>>
>>>>> ĸen
>>>>>
>>>>
>>>> There has been problems when building in ssh or chroot. I had it a
>>>> couple of times. e.g.
>>>>
>>>> <http://lists.linuxfromscratch.org/pipermail/blfs-support/2014-October/075800.html>
>>>>
>>>
>>> Found another one, where I intentionally reproduced the problem via ssh:
>>>
>>> <http://lists.linuxfromscratch.org/pipermail/blfs-dev/2014-October/028718.html>
>>>
>> So, do you think we should add --disable-firebird-sdbc to the
>> configure ('the firebird support sometimes fails its unit test'), or
>> else docment it as an optional switch ?
>>
>> I see you have taken the next release of LO.
>>
>> ĸen
>>
> 
> If it fails for me, we add. If not, I will (kindly) ask you to add it to
> page, it is worth documenting.

No error with Firebired. Please, add your words to document the
CppunitTest_dbaccess_firebird_failed test.
> 
> I am building with system boost. The patch failed to apply, mostly for
> "gave already been applied". If correct, we will all be happy. :-)

Worked fine with system-boost and no patch.


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] libreoffice - failure in CppunitTest_dbaccess_firebird_test

[Fernando de Oliveira]

Em 10-02-2016 13:20, Ken Moffat escreveu:
> On Sun, Feb 07, 2016 at 07:49:09AM -0300, Fernando de Oliveira wrote:
>> Em 07-02-2016 07:45, Fernando de Oliveira escreveu:
>>> Em 06-02-2016 22:37, Ken Moffat escreveu:
>>>> In my current build, libreoffice failed with:
>>>>
> [...]
>>>>
>>>> Error: a unit test failed, please do one of:
>>>>
>>>> export DEBUGCPPUNIT=TRUE# for exception catching
>>>> export CPPUNITTRACE="gdb --args"# for interactive debugging on Linux
>>>> export VALGRIND=memcheck# for memory checking
>>>>
>>>> and retry using: make CppunitTest_dbaccess_firebird_test
>>>>
>>
>>>> ĸen
>>>>
>>>
>>> There has been problems when building in ssh or chroot. I had it a
>>> couple of times. e.g.
>>>
>>> <http://lists.linuxfromscratch.org/pipermail/blfs-support/2014-October/075800.html>
>>>
>>
>> Found another one, where I intentionally reproduced the problem via ssh:
>>
>> <http://lists.linuxfromscratch.org/pipermail/blfs-dev/2014-October/028718.html>
>>
> So, do you think we should add --disable-firebird-sdbc to the
> configure ('the firebird support sometimes fails its unit test'), or
> else docment it as an optional switch ?
> 
> I see you have taken the next release of LO.
> 
> ĸen
> 

If it fails for me, we add. If not, I will (kindly) ask you to add it to
page, it is worth documenting.

I am building with system boost. The patch failed to apply, mostly for
"gave already been applied". If correct, we will all be happy. :-)

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Building with gold

[Fernando de Oliveira]

Em 10-02-2016 00:52, Ken Moffat escreveu:
> After last month's discussions on lfs-dev about building with gold, I
> thought I would give it a go.  I'll CC this to blfs-dev and
> blfs-support : if you reply, please consider which list is
> appropriate.
> 
> For those who have not encountered it, gold is a different linker,
> developed by google and supposedly much faster.  I was initially
> dubious - when I last saw comments about it (a long while ago) I
> recall that the linux kernel failed to link, perhaps only for some
> .config options, and I anticipated problems in BLFS.
> 
> I built using LFS-svn from the 2nd of this month, and BLFS from the
> 4th - my normal desktop, plus all of TeX and most of kde5.
> 
> This was with GNU gold (GNU Binutils 2.26.20160125) 1.11 -
> for LFS I had to add bison to the end of chapter five and pass
>  --enable-gold --enable-plugins
> to chapter six binutils.  I managed to get a vast amount of output on
> my screen while running the tests (instead of to my test log), but
> all that my log shows for the gold summary is:
> ==
> All 3 tests passed
> ==
> 
> When I initially built gold on a completed system, I think there
> were about 225 other tests before or after that, so I need to fix my
> script (2>>&1 in the wrong place!).
> 
> I did not attempt to use gold until chapter 6 had completed (so, my
> first package was the linux kernel) and I hacked up an ld symlink at
> /usr/bin/gold/ld to avoid major changes to my scripts (i.e. just
> alter the PATH in my main scripts - this also simplifies trying to
> test if a build failure is because of gold: just drop that part of
> the PATH).
> 
> In practice, my problems were few.  A list of the packages I built
> is at
> http://www.linuxfromscratch.org/~ken/gold-tests/packages-built-with-gold-Feb-2016
> and of those only libglade [ patch now in patches ], firefox (! :
> it told me to use --disable-elf-hack
> https://bugzilla.mozilla.org/show_bug.cgi?id=1246416) and
> gtkimageview-1.6.4 (for ufraw : fixed with a sed which is in my
> lsit).
> 
> Please note that I did not attempt to compare build times with gold
> and regular old ld.  This was just a test to estimate how many
> packages will need fixes, and the number looks manageable.
> I also have no idea whether gold can be used when building chapter
> five.

Just to confirm what you wrote in a previous mail:



> * Switching from ld.bfd to *ld.gold* will speed things up
> dramatically if you're doing a debug build (with -g). I don't
> remember how much faster it is for non-debug builds, but I would
> guess the difference is significant.
> * Switching from GCC 4.8 to Clang 3.4 made non-debug builds go ~15%
> faster for me. This probably depends a lot on the specific compiler
> version, though. Upgrading from Fedora 20 (with GCC 4.8) to Fedora 21
> (GCC 4.9) caused my build time to increase by >20%, which was sad.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] firefox and gtk+-3

[Fernando de Oliveira]

Em 26-01-2016 21:08, Ken Moffat escreveu:
> I recall trying gtk+-3 with ff-32.0 and finding the combination
> unusable (my notes are in the wiki).  When 43.0 came out I noted
> that gtk+-3 is now supposed to be working, but I didn't have time or
> a spare box to try that (my test machine was temporarily out of
> use).  Now that 44.0 is here and my test machine is again usable
> (bigger drive), I've given it a go.
> 
> For safety I copied ~/.mozilla to ~/.mozilla-gtk2 in case I needed
> to go back, but it is working fine.  This is with ffmpeg-2.7.5,
> grepping for ffmpeg in the .so libs shows media.ffmpeg.enabled
> and libavcodec-ffmpeg.so.56.  The only addition to my build is
> 
>  echo 'ac_add_options --enable-default-toolkit=cairo-gtk3' >>mozconfig
> 
> (I start with most of the book's .mozconfig in the usual way, but
> then from time to time I conditionally add changes such as this).
> 
> I suppose that I'll probably stay with the default gtk2 on my main
> two machines, but this is definitely looking usable.


Is it time to change the book, or should we wait until after the release?


-- 
[]s,
Fernando, aka Sísifo
-- 
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 : static library ?

[Fernando de Oliveira]

Em 10-02-2016 16:59, Ken Moffat escreveu:
> I noted that for Python-2.7.11 we do not mention libpython2.7.a :
> not a big deal, but my script used to automatically remove that lib
> at the end of the install.  I thought I had changed my script to rm
> -v (so that I would get a confirmation in the log), but I forgot.
> 
> So, for the moment I am only 99% certain that this static lib still
> gets installed.  If anybody can confirm its presence, I think we
> ought to document it.

It is not installed:

$ porg -f python-2.7.11-1 | grep libpython2.7.a
/usr/lib/python2.7/config/libpython2.7.a


However I was instructed to only document under /usr/lib or /lib, and
had to remove the ones under a major depth, as in this case.

My script finds all of them, when I am searching libraries in the
DESTINODIR.

If you want to document, I am not against, but will defend my right to
do a big increase in the libraries listed in the book.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] libpwquality : should cracklib be required ?

[Fernando de Oliveira]

Em 08-02-2016 17:28, Ken Moffat escreveu:
> On Mon, Feb 08, 2016 at 03:27:10PM -0300, Fernando de Oliveira wrote:
>> Em 08-02-2016 00:40, William Harrington escreveu:
>>> On Mon, 8 Feb 2016 02:17:25 +
>>> Ken Moffat <zarniwh...@ntlworld.com> wrote:
>>>
>>>> I'm trying to build libpwquality, for whichever part of kde5 now
>>>> requires it.  I noted that we have PAM and Cracklib as
>>>> "Recommended".
>>>
>>> Fedora has a patch which is supposed to make it optional, as far as I can 
>>> tell.
>>>
>>> https://lists.fedorahosted.org/archives/list/libpwquality-comm...@lists.fedorahosted.org/thread/7QJQZCJYNFTX3BQ2UILGQQUBIOTJXAAL/
>>>
>>> Could make it required or optional with the patch if it is valid.
>>>
>>> Sincerely,
>>>
>>> William Harrington
>>>
>>
>> My preference is recommended, if possible. But agree with Ken's decision
>> if he still wishes to promote to required
>>
> My rational is that Recommended either means
> 
> (i.) The package can build without this, and without extra configure
> switches, but the recommended package provides useful extra
> functionality (is that a word ?)
> 
> or
> 
> (ii.) The package can be built without this, but you need to supply
> extra configure switches.
> 
> This package, as shipped, matches neither option.  I am reluctant to
> include a patch in the book just so that people can detune what
> upstream shipped.

Agreed!


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Minor correction to curl install

[Fernando de Oliveira]

Em 06-02-2016 18:53, Tim Tassonis escreveu:
> On 02/06/16 13:26, Fernando de Oliveira wrote:
>> Em 05-02-2016 13:48, Tim Tassonis escreveu:
>>> Hi all
>>>
>>> I just install curl from blfs and would suggest a minor correction to
>>> the install section:
>>>
>>> find docs \( -name Makefile\* \
>>>-o -name \*.1   \
>>>-o -name \*.3 \)\
>>>-exec rm {} \;  &&
>>> install -v -d -m755 /usr/share/doc/curl-7.47.0 &&
>>> cp -v -R docs/* /usr/share/doc/curl-7.47.0
>>>
>>>
>>> This works ok, but it has the effect that the build directory gets
>>> broken, e.g. a following make (or make install) will miss files and
>>> fail. Also, it will still copy a
>>> /usr/share/doc/curl-7.47.0/examples/.deps folder that is unneeded.
>>> Therefore I suggest to change this to:
>>>
>>> install -v -d -m755 /usr/share/doc/curl-7.47.0 &&
>>> cp -v -R docs/* /usr/share/doc/curl-7.47.0 &&
>>> find /usr/share/doc/curl-7.47.0 \( -name Makefile\* \
>>> -o -name \*.1 \
>>> -o -name \*.3 \) \
>>> -exec rm {} \; &&
>>> rm -rf /usr/share/doc/curl-7.47.0/examples/.deps
>>>
>>> This will leave the build directory unharmed and do the necessary
>>> cleanups in the destination directory.
>>
>> Wontfix.
>>
>> Thanks.
>>
>> <http://wiki.linuxfromscratch.org/blfs/ticket/7432>
> 
> Fine me with, although I don't understand the refusal to change one
> single line that won't harm anything. The reason I'm suggesting this is
> that one simple typo in those three lines will force you to fully
> unpack, ./configure and make the whole package again, only to be able to
> call "make install" again.
> 
> I won't bother commenting on your refusal to accept that it's a good
> idea to remove the unneeded .deps Directory in the resulting docucment...

You are not being fair.

Have you read this?

<http://wiki.linuxfromscratch.org/blfs/ticket/7432#comment:1>

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] libpng-1.6.21 - minor correction

[Fernando de Oliveira]

Em 06-02-2016 19:38, Ken Moffat escreveu:
> On Sun, Feb 07, 2016 at 08:53:40AM +1100, Wayne Blaszczyk wrote:
>> Hi,
>>
>> The patch command should have -p1 rather than -p0.
>>
>>
>> Regards,
>> Wayne.
> 
> Hi Wayne,
> 
> it's an upstream patch created in the top-level directory, it won't
> apply with -p1.
> 
> ĸen
> 

Thanks, ĸen.

Sorry for the other post.

Only now I have read yours.

Thanks again.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] libpng-1.6.21 - minor correction

[Fernando de Oliveira]

Em 06-02-2016 18:53, Wayne Blaszczyk escreveu:
> Hi,
> 
> The patch command should have -p1 rather than -p0.
> 
> 
> Regards,
> Wayne.
> 

No, Wayne.

we are using the patch from another source.

Have been discussed in the ticket:




Good to hearing from you!!!

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Minor correction to curl install

[Fernando de Oliveira]

Em 06-02-2016 09:17, akhiezer escreveu:
>> Date: Fri, 05 Feb 2016 17:47:27 +
>> From: lf...@cruziero.com (akhiezer)
>> To: BLFS Development List 
>> Subject: Re: [blfs-dev] Minor correction to curl install
>>
>>> To: BLFS Development List 
>>> From: Tim Tassonis 
>>> Date: Fri, 5 Feb 2016 17:48:14 +0100
>>> Subject: [blfs-dev] Minor correction to curl install
>>>
>>> Hi all
>>>
>>> I just install curl from blfs and would suggest a minor correction to 
>>> the install section:
>>>
>>> find docs \( -name Makefile\* \
>>>-o -name \*.1   \
>>>-o -name \*.3 \)\
>>>-exec rm {} \;  &&
>>
>>
>> (Also, '[-depth] ... -delete' instead of the '-exec rm {} \;' ? The
>> latter isn't wrong; just a little unnecessary to call-out via '-exec' .)
>>
> 
> 
> The '-exec rm {} \;' will return false on dirs (& spew out
> errors/warnings) - tho' not cause find() to return non-zero.
> 
> 
> Normally that'd be tightened-up (proactively, defensively) a bit.
> 
> 
> According to blfs svn for curl (
> http://www.linuxfromscratch.org/blfs/view/svn/basicnet/curl.html ),
> the intent of the find-rmv is to remove files.
> 
> 
> So depending on whether it's just ordinary files, or just non-dirs,
> then one would use '-type f' or '! -type d' after the 'docs' or at
> least before the '-exec' (tho' of course some find() implems can/will
> do some 'optimising'/rearranging of some parts of their cmdlines).
> 
> 
> And for completeness, if dirs are to be included in the rmvl, then
> one would normally use the '[-depth] ... -delete' construct instead
> of the '-exec ...'  .

Sorry to intrude, as it was not directed to me.

Thanks for the valuable info.

You are right: we are only removing files.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Minor correction to curl install

[Fernando de Oliveira]

Em 05-02-2016 13:48, Tim Tassonis escreveu:
> Hi all
> 
> I just install curl from blfs and would suggest a minor correction to
> the install section:
> 
> find docs \( -name Makefile\* \
>   -o -name \*.1   \
>   -o -name \*.3 \)\
>   -exec rm {} \;  &&
> install -v -d -m755 /usr/share/doc/curl-7.47.0 &&
> cp -v -R docs/* /usr/share/doc/curl-7.47.0
> 
> 
> This works ok, but it has the effect that the build directory gets
> broken, e.g. a following make (or make install) will miss files and
> fail. Also, it will still copy a
> /usr/share/doc/curl-7.47.0/examples/.deps folder that is unneeded.
> Therefore I suggest to change this to:
> 
> install -v -d -m755 /usr/share/doc/curl-7.47.0 &&
> cp -v -R docs/* /usr/share/doc/curl-7.47.0 &&
> find /usr/share/doc/curl-7.47.0 \( -name Makefile\* \
> -o -name \*.1 \
> -o -name \*.3 \) \
> -exec rm {} \; &&
> rm -rf /usr/share/doc/curl-7.47.0/examples/.deps
> 
> This will leave the build directory unharmed and do the necessary
> cleanups in the destination directory.

Wontfix.

Thanks.



-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] fuse moved

[Fernando de Oliveira]

Em 02-02-2016 18:31, Tim Tassonis escreveu:
> Hi all
> 
> Just wanted to build fuse and noticed it's not available from
> sourceforge anymore.
> 
> The new location is:
> 
> https://github.com/libfuse/libfuse/releases/download/fuse_2_9_5/fuse-2.9.5.tar.gz
> 
> 
> 
> The mentioned version 2.9.4 is also available there:
> 
> https://github.com/libfuse/libfuse/releases/download/fuse_2_9_4/fuse-2.9.4.tar.gz
> 
> 
> Cheers
> Tim
> 

I fixed some time ago in svn.

-- 
[]s,
Fernando, aka Sísifo
-- 
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] #7403: OpenJDK-1.8.0.72

[Fernando de Oliveira]

Em 30-01-2016 03:26, DJ Lucas escreveu:
>
>
> On 1/29/2016 4:29 PM, BLFS Trac wrote:
>>   What I read is that 8u71 has security fixes, but not 8u72, which
>> they told
>>   to be ''improvements''.
>
> Not exactly.

Found it at

https://blogs.oracle.com/java/entry/new_release_jdk_8u71_and

{{{
New Release JDK 8u71 and JDK 8u72
By Yolande Poirier-Oracle on Jan 19, 2016

JDK 8u71 and 8u72, two new Java 8 updates are now available. Oracle
strongly recommends that most Java SE users upgrade to the latest Java
8u71 CPU release, which includes important security fixes. Java SE 8u72
is a patch-set update, including all of 8u71 plus additional features.
}}}

Sorry if I was not exact, having used "improvements" instead of
*additional features*.

> The Java release schedule is an odd duck. The way they are
> releasing the distributed binaries now is that odd number update (on
> release schedule) is a CPU (critical patch update), which is security
> patches and regression fixes to the previous PSU (patch set update).
> PSUs are the even numbered updates, which is the previous CPU update
> revision +1 and includes the security fixes in that CPU. PSUs are
> feature changes and enhancements - and aren't usually pushed to java.com
> (binary release for regular users) for a while after release (if at all).
>
> This explains the CPU vs PSU releases:
>
http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html
>
>
> As to the CPU release schedule and planning (and lately PSU, with its
> CPU+1 update):
> http://www.oracle.com/technetwork/topics/security/alerts-086861.html
>
> This partially explains the oddball release numbering:
>
http://www.oracle.com/technetwork/java/javase/overview/jdk-version-number-scheme-1918258.html
> There was a post on the old -dev list that explained it in more detail,
> but I'm unable to find it right now.
>
> In addition to all of that, they have even by 20 (20, 40, 60, 80) for
> "Limited" (off cycle updates). And finally, all other numbers in the
> space are reserved for special updates, usually for particularly nasty
> bugs or security flaws. 7u7, 7u17 and 7u67 were the last three (though
> 67 is listed as Limited on the history, think this is a typo), haven't
> been any for 8 yet. See a pattern there?
>
> https://www.java.com/en/download/faq/release_dates.xml
>
> As to which version to use...I keep my Windows clients who use JRE/JDK
> on the CPU releases (and disable automatic updates and deploy via GPO or
> like) unless a new feature or bug fix is needed (which has yet to happen).
>
> All that said, given the audience, I think PSU/Limited/Special is the
> correct release for BLFS. These designations do not mean unstable, just
> newer and not largely tested in the wild (but still tested pretty
> thoroughly, at least among the java devs).

Thank you very much for this text. I will keep it in my folder of
important information.

-- 
[]s,
Fernando, aka Sísifo


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] vlc-2.2.1 does not build with opencv-3.1.0

[Fernando de Oliveira]

Em 29-01-2016 22:55, Fernando de Oliveira escreveu:
> Em 27-01-2016 23:23, DJ Lucas escreveu:
>>
>>
>> On 1/22/2016 1:45 PM, Fernando de Oliveira wrote:
>>> Error:
>>>
>>> {{{
>>> Making all in video_filter
>>> make[4]: Entering directory '/tmp/vlc-2.2.1/modules/video_filter'
>>> make  all-am
>>> make[5]: Entering directory '/tmp/vlc-2.2.1/modules/video_filter'
>>>CXX  libopencv_example_plugin_la-opencv_example.lo
>>> opencv_example.cpp: In function ‘picture_t* Filter(filter_t*,
>>> picture_t*)’:
>>> opencv_example.cpp:197:58: error: ‘CV_RGB’ was not declared in this scope
>>>   cvRectangle( p_img[0], pt1, pt2, CV_RGB(0,0,0), 3, 8, 0 );
>>>^
>>> opencv_example.cpp:197:69: error: ‘cvRectangle’ was not declared in this
>>> scope
>>>   cvRectangle( p_img[0], pt1, pt2, CV_RGB(0,0,0), 3, 8, 0 );
>>>   ^
>>> opencv_example.cpp:201:57: warning: deprecated conversion from string
>>> constant to ‘char*’ [-Wwrite-strings]
>>>   p_sys->event_info.p_region[i].p_description = "Face
>>> Detected";
>>>   ^
>>
>> Here is a copy, not sure where the real one is...
>> http://fossies.org/linux/privat/buildroot-2015.11.1.tar.gz/buildroot-2015.11.1/package/vlc/0009-opencv_example-add-missing-include-statements.patch?m=t
>>
>>
> 
> Thanks, DJ.
> 
> Fixed at r16865.
> 
> Patch can also be found at
> https://git.videolan.org/?p=vlc.git;a=patch;h=b82416d7000a993b33e903095a590fe32212a85e
> 
> Don't know if I have something wrong here, but I needed to include one
> more fix, for
> 
> {{{
> /usr/bin/ld: cannot find -lippicv
> }}}
> 

From the lack of reply by DJ, I am assuming the he does not have the
problem. Should I remove this fix for finding libippicv.a from the book?

-- 
[]s,
Fernando, aka Sísifo
-- 
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-1.8.10 dependency

[Fernando de Oliveira]

Em 16-01-2016 21:24, Richard escreveu:
> 
> In building Doxygen-1.8.10 in BLFS-7.8,
> I found that I could not run the tests
> without first installing libxml2-2.9.2.
> If libxml2 is not installed, all the
> tests fail with the message that
> Doxygen can't find the xmllint command.
> 
> In the BLFS-7.8 book libxml2-2.9.2 is
> listed as an optional dependency.
> Perhaps there should also be a
> statement that it is a required
> dependency to run the tests?
> 
> Richard

Fixed.

Thanks.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] LVM2 and the the use of pathappend

[Fernando de Oliveira]

Em 17-01-2016 07:05, Pierre Labastie escreveu:
> On 17/01/2016 03:48, Bruce Dubbs wrote:
>> Wayne Blaszczyk wrote:
>>> Hi All,
>>>
>>> First off, Happy New Year to everyone.
>>>
>>> After going through the LVM2 instruction, I noticed the use
>>> of pathappend. Does this imply that the 'The Bash Shell Startup Files'
>>> is a mandatory step for the rest of the book, or should there be a
>>> dependency listed back to this page? If the former, then I don't see
>>> this stated anywhere.
>>
>> There are several places where pathappend is mentioned: kf5, kde, lxqt, etc,
>> but in LVM21, it would be just as easy to say:
>>
>> export PATH=$PATH:/sbin:/usr/sbin
>>
>> I suppose that adding a recommended dependency would be reasonable.
>>
>>   -- Bruce
>>
> Hi,
> 
> The "Bash shell Startup Files" page is mentionned in "Command explanations",
> but not in dependencies, sorry for that.
> 
> The purpose of using "pathappend" is to avoid duplicate entries in the PATH if
> for some reason it is already containing the "{/usr,}/sbin" entries. Since
> this is marginally an inconvenience, it could be changed to what Bruce
> proposes ("export" is not needed, I think, since PATH is already exported).
> 
> There is a new version of LVM2 around. Fernando has already taken the ticket,
> so I'll wait for the update and change the command, unless somebody speaks out
> (or Fernando does it).

Please, take the ticket. I am giving it back to the book.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] kf5 based applications

[Fernando de Oliveira]

Em 13-01-2016 21:52, Bruce Dubbs escreveu:
> I'm about to start updating the book's kf5 apps.  Right now we only have
> 4 apps there: konsole, kmix, kdenlive, and kate.
> 
> I'd appreciate it if I could get some opinions on what other apps to
> add.  The full list of apps is at
> 
> http://download.kde.org/stable/applications/15.12.1/src/
> 
> There are 187 packages there, not counting the i18n files.
> 
> Not all are ready for kf5 (e.g. okular) and some need dependencies
> outside BLFS.
> 
> A git version okular can be added for kf5 and that works.
> 
> I will add spectacle which is the kf5 replacement for ksnapshot.  Many
> apps can be covered in a 'Further KF5 Based Packages' section.
> 
> So...
> 
> What other packages should be explicitly added?
> 
>   -- Bruce
> 
> 

I am minimally familiar with KDE.

Understand from the ticket #7354 that you would try to keep as many as
possible applications equivalent to KDE4.

For me kalarm is good, and I see

kalarmcal-15.12.1.tar.xz

which uses kdepim-15.12.1.tar.xz, if I understood correctly something I
read earlier.

Seems useful what you planned and also the following, but I trust you if
you disagree:

gwenview-15.12.1.tar.xz
kamera-15.12.1.tar.xz
kcalc-15.12.1.tar.xz
kcalutils-15.12.1.tar.xz
kcharselect-15.12.1.tar.xz
kcolorchooser-15.12.1.tar.xz
ksaneplugin-15.12.1.tar.xz
ktimer-15.12.1.tar.xz
print-manager-15.12.1.tar.xz


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] yelp problems

[Fernando de Oliveira]

Em 13-01-2016 16:37, Bruce Dubbs escreveu:
> Fernando de Oliveira wrote:
> 
>> I think Ken, long ago, was the first one to notice that problem, not
>> only in this thread.
> 
> Ken identified the need to run update-desktop-database and there is
> rationale in the Command Explanations.  It is not, strictly speaking,
> required for build, but it is for proper execution.
> 
> My problem was not that it wasn't installed.  It was because I responded
> (incorrectly) to warnings when running update-desktop-database.
> 
>> Don't you both think we should add gsettings-desktop-schema as required
>> by yelp?
> 
> We expect that recommended dependencies are installed, but I do not have
> a problem with promoting desktop-file-utils to required. However, I
> don't think it's needed.

I think you are confusing gsettings-desktop-schema with
desktop-file-utils. I did it at r16804, but will change it tomorrow, as
you wish, if you please don't mind doing it before.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] yelp problems

[Fernando de Oliveira]

Em 13-01-2016 16:42, Bruce Dubbs escreveu:
> Fernando de Oliveira wrote:
>> Em 12-01-2016 15:40, Bruce Dubbs escreveu:
>>> Bruce Dubbs wrote:
>>>
>>>> OK, I got it working.  I reinstalled gsettings-desktop-schemas.  What I
>>>> had done was respond to some warnings when I ran glib-compile-schemas.
>>>> For
>>>> example:
>>>>
>>>> warning: Schema 'org.gnome.system.proxy.https' has path
>>>> '/system/proxy/https/'.  Paths starting with '/apps/', '/desktop/' or
>>>> '/system/' are deprecated.
>>>>
>>>> So I had deleted org.gnome.system.proxy.gschema.xml to get rid of the
>>>> warning.
>>>>
>>>> Checking the web, it seems that others just ignore the warnings.  For
>>>> instance: https://bugzilla.redhat.com/show_bug.cgi?id=814053
>>>
>>> It turns out that fixing the warnings is not hard.  I wonder why
>>> upstream has not done it.
>>>
>>> sed -i -r 's:"(/system):"/org/gnome\1:'  \
>>>/usr/share/glib-2.0/schemas/*system*
>>>
>>> Should we add it to the book?
>>
>> Don't know how. Have:
>>
>> {{{
>> Out 26 org.gnome.system.locale.gschema.xml
>> Out 26 org.gnome.system.proxy.gschema.xml
>> Out 26 org.gnome.system.location.gschema.xml
>> Nov 14 org.gnome.gnome-system-monitor.gschema.xml
>> Nov 14 org.gnome.gnome-system-monitor.enums.xml
>> Nov 15 org.gnome.system.smb.gschema.xml
>> Nov 15 org.gnome.system.gvfs.enums.xml
>> Nov 15 org.gnome.system.dns_sd.gschema.xml
>> }}}
>>
>> This means that different packages installed them.
> 
> Yes, but the only ones that are incorrect are installed by
> desktop-file-utils.  Specifically proxy and locale.

Let me rephrase:

I am very much in agreement for the addition of the sed.

I think you mean gsettings-desktop-schemas, I am confused. I was
confused with other one too, replying after this one.

If it is just adding the sed to gsettings-desktop-schemas page, or even
a couple of pages, also agree it is easy. My eyes are letting me down at
the moment.

Please, if you don't mind, do it, or I will tomorrow.


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] yelp problems

[Fernando de Oliveira]

Em 12-01-2016 15:40, Bruce Dubbs escreveu:
> Bruce Dubbs wrote:
> 
>> OK, I got it working.  I reinstalled gsettings-desktop-schemas.  What I
>> had done was respond to some warnings when I ran glib-compile-schemas.
>> For
>> example:
>>
>> warning: Schema 'org.gnome.system.proxy.https' has path
>> '/system/proxy/https/'.  Paths starting with '/apps/', '/desktop/' or
>> '/system/' are deprecated.
>>
>> So I had deleted org.gnome.system.proxy.gschema.xml to get rid of the
>> warning.
>>
>> Checking the web, it seems that others just ignore the warnings.  For
>> instance: https://bugzilla.redhat.com/show_bug.cgi?id=814053
> 
> It turns out that fixing the warnings is not hard.  I wonder why
> upstream has not done it.
> 
> sed -i -r 's:"(/system):"/org/gnome\1:'  \
>   /usr/share/glib-2.0/schemas/*system*
> 
> Should we add it to the book?

Don't know how. Have:

{{{
Out 26 org.gnome.system.locale.gschema.xml
Out 26 org.gnome.system.proxy.gschema.xml
Out 26 org.gnome.system.location.gschema.xml
Nov 14 org.gnome.gnome-system-monitor.gschema.xml
Nov 14 org.gnome.gnome-system-monitor.enums.xml
Nov 15 org.gnome.system.smb.gschema.xml
Nov 15 org.gnome.system.gvfs.enums.xml
Nov 15 org.gnome.system.dns_sd.gschema.xml
}}}

This means that different packages installed them.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] yelp problems

[Fernando de Oliveira]

Em 12-01-2016 15:15, Bruce Dubbs escreveu:
> Fernando de Oliveira wrote:
>> Em 11-01-2016 20:16, Bruce Dubbs escreveu:
>>> Ken Moffat wrote:
>>>> On Mon, Jan 11, 2016 at 04:23:58PM -0600, Bruce Dubbs wrote:
>>>>> I'm having a problem with yelp.  The window kinda works, but I don't
>>>>> get any
>>>>> text in the window.
>>
>> Same here. Probably more than a year ago, I discovered one gnome package
>> that installs the text for that window (tried to remember these tow last
>> BLFS releases, but failed). It didn't seem to be useful just for that
>> sake.
>>
>> What I think matters is that the applications have their help displayed.
>> Hope that they are working for you.
> 
> That's the main problem.  They are not.  For example, evince.  Selecting
> help there brings up the yelp window, but no contents.  I can find no
> error messages either.
> 
>> However, I do have "org.gnome.system.proxy" installed:
>>
>> {{{
>> $ ls /usr/share/glib-2.0/schemas/org.gnome.system.proxy.gschema.xml
>> /usr/share/glib-2.0/schemas/org.gnome.system.proxy.gschema.xml
>> }}}
> 
> I do not.  Do you know what application installed it?  On my
> developement system, I do have it.  From the timestamp and my logs, it
> looks like it was installed at the dame time as
> gsettings-desktop-schemas when I was doing the validation for BLFS 7.8.
> 
> 
>> {{{
>> $ gsettings list-recursively org.gnome.system.proxy
>> org.gnome.system.proxy use-same-proxy true
>> org.gnome.system.proxy mode 'none'
>> org.gnome.system.proxy autoconfig-url ''
>> org.gnome.system.proxy ignore-hosts ['localhost', '127.0.0.0/8', '::1']
>> org.gnome.system.proxy.ftp host ''
>> org.gnome.system.proxy.ftp port 0
>> org.gnome.system.proxy.socks host ''
>> org.gnome.system.proxy.socks port 0
>> org.gnome.system.proxy.http host ''
>> org.gnome.system.proxy.http port 8080
>> org.gnome.system.proxy.http use-authentication false
>> org.gnome.system.proxy.http authentication-password ''
>> org.gnome.system.proxy.http authentication-user ''
>> org.gnome.system.proxy.http enabled false
>> org.gnome.system.proxy.https host ''
>> org.gnome.system.proxy.https port 0
>> }}}
> 
> I get that too on the development system but not on my workstations.
> Checking gsettings-desktop-schemas, I did install it.
> 
> OK, I got it working.  I reinstalled gsettings-desktop-schemas.  What I
> had done was respond to some warnings when I ran glib-compile-schemas.
> For example:
> 
> warning: Schema 'org.gnome.system.proxy.https' has path
> '/system/proxy/https/'.  Paths starting with '/apps/', '/desktop/' or
> '/system/' are deprecated.
> 
> So I had deleted org.gnome.system.proxy.gschema.xml to get rid of the
> warning.
> 
> Checking the web, it seems that others jsut ignore the warnings.  For
> instance: https://bugzilla.redhat.com/show_bug.cgi?id=814053
> 
> Fernando, thanks for responding.  Without your input I would not have
> figured this out.

I think Ken, long ago, was the first one to notice that problem, not
only in this thread.

Don't you both think we should add gsettings-desktop-schema as required
by yelp?


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Libunique still needed ?

[Fernando de Oliveira]

Em 12-01-2016 14:59, Gen escreveu:
> Ah, OK - Sorry.
> 
> But as this library is no longer used to buil xfce, your proposition to
> move it to a more general chapter makes sense.
> 
> -- 
> Nico
> 
> On 16-01-12 18:09, Fernando de Oliveira wrote:
>> Em 12-01-2016 12:57, Gen escreveu:
>>> In the Xfce Applications chapter Libunique-1.6.6 was needed only by the
>>> xfce4 mixer...
>>
>> Yes, it is still needed.
>>
>> That was not the only application needing it. A couple of applications
>> do use it.
>>
>> Perhaps (and I have thought that many times, for that reason) it could
>> be moved to a more general chapter, probably "9. General Libraries".

Done.

Thanks for trimming. Please don't top post. Example: I am "bottom"
posting. You can also use inline (between previous post lines. These are
the formats used in the (B)LFS lists.

Citation from the lfs-support list footer, added by Bruce Dubbs:

{{{
Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
}}}

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] yelp problems

[Fernando de Oliveira]

Em 11-01-2016 20:16, Bruce Dubbs escreveu:
> Ken Moffat wrote:

Forgot to send a link that helped me to reply:

https://github.com/getlantern/lantern/issues/3129#issuecomment-139730928

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] yelp problems

[Fernando de Oliveira]

Em 11-01-2016 20:16, Bruce Dubbs escreveu:
> Ken Moffat wrote:
>> On Mon, Jan 11, 2016 at 04:23:58PM -0600, Bruce Dubbs wrote:
>>> I'm having a problem with yelp.  The window kinda works, but I don't
>>> get any
>>> text in the window.

Same here. Probably more than a year ago, I discovered one gnome package
that installs the text for that window (tried to remember these tow last
BLFS releases, but failed). It didn't seem to be useful just for that sake.

What I think matters is that the applications have their help displayed.
Hope that they are working for you.

But can search again t add to the book, the data file for just yelp, if
it is agreed to matter.

>>>
>>> If I start it from the command line, I get (WebKitWebProcess:16261):
>>>
>>> GLib-GIO-ERROR **: Settings schema 'org.gnome.system.proxy' is not
>>> installed
>>>
>>> In the logs, there is a message:
>>>
>>> traps: WebKitWebProces[16261] trap int3 ip:7f1edfaf0cc3 sp:7ffc372613a0
>>> error:0

Nothing here: no terminal message, when I start yelp from command line.

No "WebKitWebProces" in the logs, either:

{{{
# grep -r WebKitWebProces /var/log
/var/log/porg/webkitgtk3-2.4.9:/usr/libexec/WebKitWebProcess|12104|
/var/log/porg/webkitgtk-2.10.3:/usr/libexec/webkit2gtk-4.0/WebKitWebProcess|13648|
/var/log/porg/webkitgtk-2.10.4:/usr/libexec/webkit2gtk-4.0/WebKitWebProcess|13648|
}}}

Those are "porg" install logs.

However, I do have "org.gnome.system.proxy" installed:

{{{
$ ls /usr/share/glib-2.0/schemas/org.gnome.system.proxy.gschema.xml
/usr/share/glib-2.0/schemas/org.gnome.system.proxy.gschema.xml
}}}

{{{
$ gsettings list-recursively org.gnome.system.proxy
org.gnome.system.proxy use-same-proxy true
org.gnome.system.proxy mode 'none'
org.gnome.system.proxy autoconfig-url ''
org.gnome.system.proxy ignore-hosts ['localhost', '127.0.0.0/8', '::1']
org.gnome.system.proxy.ftp host ''
org.gnome.system.proxy.ftp port 0
org.gnome.system.proxy.socks host ''
org.gnome.system.proxy.socks port 0
org.gnome.system.proxy.http host ''
org.gnome.system.proxy.http port 8080
org.gnome.system.proxy.http use-authentication false
org.gnome.system.proxy.http authentication-password ''
org.gnome.system.proxy.http authentication-user ''
org.gnome.system.proxy.http enabled false
org.gnome.system.proxy.https host ''
org.gnome.system.proxy.https port 0
}}}

{{{
$ grep -r org.gnome.system.proxy /var/log/porg/
/var/log/porg/gsettings-desktop-schemas-3.18.1:/usr/share/glib-2.0/schemas/org.gnome.system.proxy.gschema.xml|6240|
/var/log/porg/gsettings-desktop-schemas-3.18.0:/usr/share/glib-2.0/schemas/org.gnome.system.proxy.gschema.xml|6240|
}}}

In one log, I have:

{{{
$ xzgrep -A1 org.gnome.system.proxy \
> gsettings-desktop-schemas-3.18.1-2015.10.26-09h57m41s.log.xz \
> | grep -A1 install
/usr/bin/install -c -m 644
org.gnome.desktop.default-applications.gschema.xml
org.gnome.desktop.interface.gschema.xml
org.gnome.desktop.lockdown.gschema.xml
org.gnome.system.locale.gschema.xml
org.gnome.system.location.gschema.xml org.gnome.system.proxy.gschema.xml
org.gnome.desktop.sound.gschema.xml
org.gnome.desktop.thumbnail-cache.gschema.xml
org.gnome.desktop.a11y.gschema.xml
org.gnome.desktop.a11y.keyboard.gschema.xml
org.gnome.desktop.a11y.applications.gschema.xml
org.gnome.desktop.a11y.magnifier.gschema.xml
org.gnome.desktop.a11y.mouse.gschema.xml
org.gnome.desktop.thumbnailers.gschema.xml
org.gnome.desktop.session.gschema.xml
org.gnome.desktop.background.gschema.xml
org.gnome.desktop.datetime.gschema.xml
org.gnome.desktop.media-handling.gschema.xml
org.gnome.desktop.screensaver.gschema.xml
org.gnome.desktop.search-providers.gschema.xml
org.gnome.desktop.wm.keybindings.gschema.xml
org.gnome.desktop.wm.preferences.gschema.xml
org.gnome.desktop.input-sources.gschema.xml
org.gnome.desktop.privacy.gschema.xml
org.gnome.desktop.notifications.gschema.xml
org.gnome.desktop.app-folders.gschema.xml
org.gnome.desktop.peripherals.gschema.xml org.gnome.desktop.enums.xml
"/usr/share/glib-2.0/schemas"; \
test -n "" || glib-compile-schemas /usr/share/glib-2.0/schemas; \
}}}

>>> Does anyone have an idea about what is going on?
> 
>> Have you installed gsettings-desktop-schemas ?
> 
> Yes. I installed everything in Chapter 35, GNOME Libraries and Utilities.
> 

Suggestions (obvious, for you, but this thread might eventually help
others):

1. Check your install log for org.gnome.system.proxy

2. If org.gnome.system.proxy.gschema.xml is installed, update  again:

glib-compile-schemas /usr/share/glib-2.0/schemas

>> Google has a couple
>> of links which point to that.  Failing that, perhaps better on a
>> blfs list ? ;-)
> 
> Oops, typo.


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Libunique still needed ?

[Fernando de Oliveira]

Em 12-01-2016 12:57, Gen escreveu:
> In the Xfce Applications chapter Libunique-1.6.6 was needed only by the
> xfce4 mixer (xfce4-mixer-4.10.0 based on GStreamer-0.10). Since this
> package has been withdrawn, libunique may be removed as well (IMO).

Yes, it is still needed.

That was not the only application needing it. A couple of applications
do use it.

Perhaps (and I have thought that many times, for that reason) it could
be moved to a more general chapter, probably "9. General Libraries".

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Libgusb tests

[Fernando de Oliveira]

Em 11-01-2016 11:01, Gen escreveu:
> Testing libgusb package requires the directory /usr/share/hwdata
> populated with the file usb.ids, as described in «Configuring USB Utils»
> section of the usbutils-008 package.
> 
> Perhaps a note about this should be added in the book.
> 
> I don't know if this has been already addressed; if yes, sorry for the
> noise.
> 
> HTH

Fixed.

Thanks.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] v4l-utils make install fails

[Fernando de Oliveira]

Em 11-01-2016 05:58, wil...@tuta.io escreveu:
> Installing v4l-utils using make install fails when using a parallel build. 
> The build itself using "make" works fine.  I can reproduce the make install 
> failure, the error is as follows:
> 
> /usr/bin/ld: cannot find -lv4l1
> collect2: error: ld returned 1 exit status
> 
>   I think the install command should be changed, from
> make install
> to
> MAKEFLAGS="-j1" make install
> 
> This is also what Arch Linux uses in their build scripts and fixes the error.

Sorry, cannot confirm this issue. Tried with "make -j8 install" and
MAKEFLAGS="-j8" make install, still no problem.

Used:

sed -e 's/targets):/& ; $(info $$MAKEFLAGS is [${MAKEFLAGS}])/' \
-i.orig Makefile.in &&

before configure, with results:

{{{
# xzgrep MAKEFLAGS /logs/v4l-utils-1.8.1-2016.01.11-11h51m30s.log.xz
$MAKEFLAGS is [w -j --jobserver-fds=3,4]
$MAKEFLAGS is []
# xzgrep MAKEFLAGS
/logs/v4l-utils-1.8.1-simulation-2016.01.11-11h49m29s.log.xz
$MAKEFLAGS is [w -j --jobserver-fds=3,4]
$MAKEFLAGS is [ --
DESTDIR=/tmp/porg-build-2016.01.11-11h49m29s/DEST-v4l-utils-1.8.1]
}}}

Therefore, even if you have MAKEFLAGS set, I cannot understand what is
happening.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] PHP/MySQL configure option

[Fernando de Oliveira]

Em 07-01-2016 00:46, Mikel Rychliski escreveu:
> Hello,
> 
> While building PHP for BLFS, I noticed that one of the "Command
> Explanations" is out of date. --with-mysql is referenced both on the
> page and in the php_configure.txt file.
> 
> Support for the old MySQL extension was dropped in PHP 7.0, with mysqli
> or PDO recommended as replacements.
> 
> Upstream commit:
> ***
> From fd1578c196575c7e120a84ee030bb87c14a199b0 Mon Sep 17 00:00:00 2001
> From: Adam Harvey 
> Date: Thu, 5 Mar 2015 00:18:40 +
> Subject: [PATCH] Remove the deprecated MySQL extension.
> 
> Relevant RFC:
> https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7
> ***
> 
> Configuring using the "--with-mysql" switch results in an error.
> 
> Thanks,
> Mikel Rychliski
> 
> Index: general/prog/php.xml
> ===
> --- general/prog/php.xml  (revision 16792)
> +++ general/prog/php.xml  (working copy)
> @@ -350,11 +350,17 @@
>
>  
>
> ---with-mysql: This option
> -includes MariaDB/MySQL support.
> +--with-mysqli=mysqlnd: This option
> +includes MariaDB/MySQL support using
> +the MySQL Native Driver.
>
>  
>
> +--with-mysql-sock=/var/run/mysql: This option sets
> +the default location of the MySQL unix socket file.
> +  
> +
> +  
>  --disable-libxml: This option
>  allows building PHP without libxml2
>  installed.
> 

Done.

Thanks.


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] xf86-input-evdev requires mtdev

[Fernando de Oliveira]

Em 04-01-2016 18:14, Tobias Stoeckmann escreveu:
> xf86-input-evdev requires mtdev now. It's not optional anymore
> since version 2.9.99. See this Changelog entry:
> 
> commit 56a5e6716204916691a67082e3e6a1698df2061b
> Author: Peter Hutterer 
> Date:   Mon Mar 16 07:55:34 2015 +1000
> 
> Unconditionally require mtdev
> 
> 
> Index: x/installing/x7driver-evdev.xml
> ===
> --- x/installing/x7driver-evdev.xml   (revision 16789)
> +++ x/installing/x7driver-evdev.xml   (working copy)
> @@ -78,15 +78,11 @@
>  
>Required
>
> - and
> +,
> +, and
>  
>
>  
> -  Recommended
> -  
> -
> -  
> -
>
>  User Notes: 
>
> 

Fixed.

Thanks.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] KDE4

[Fernando de Oliveira]

Em 29-12-2015 16:17, Bruce Dubbs escreveu:
> Fernando de Oliveira wrote:
>> Em 28-12-2015 19:10, Ken Moffat escreveu:
>>> On Mon, Dec 28, 2015 at 07:27:52AM -0300, Fernando de Oliveira wrote:
> 
>>>> Think that as soon as the main applications are ported from KDE4. Not
>>>> having used KDE other than for testing (BLFS/edition and Kubuntu/how it
>>>> looks and feels), cannot pinpoint.
>>>>
>>> You might need to define 'main' ;-)  I never used kmail since kde2,
>>> nor dolphin (at all), and for sites I commonly visit (e.g. slashdot-
>>> not much useful content there these days, but the weird attitudes are
>>> sometimes amusing), konqueror in both 4 and 5 tended to crash.
>>
>> Yes, but not having used much KDE, makes it very difficult. One
>> application I like and have always found the best one is in KDE: KAlarm.
>> Even for KDE users, it would vary, very subjective choice.
> 
> Personally, I cannot get along without konsole.  To me it is the best
> virtual terminal available.  I also use okular, kruler, and ksnapshot as
> well as the occasional kde game.  I also occasionally use k3b.  I have
> built and tested kdenlive and intend to use it someday to make a podcast
> about LFS.  Most of these apps work fine using KF5.  Some I have not yet
> tried to build in that environment.

I like k3b better than brasero, but have been using the latter comfortably.

Interesting the kruler.
> 
> What I do not use is the plasma desktop.  I prefer xfce for that.
> 

> My thought is to leave KDE4 as is for the next stable BLFS release and
> then immediately remove it from -dev.  That gives us (and the KDE devs)
> 6 months to get all the needed packages up to date.

This seems a good plan.

PS: I needed to stop working yesterday. Problem solved, back now.


-- 
[]s,
Fernando, aka Sísifo
-- 
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 will mostly be doing: nothing

[Fernando de Oliveira]

Em 28-12-2015 16:33, Ken Moffat escreveu:
> Just a note to explain my current position.  A bit over two weeks
> ago I injured a calf muscle when I was kneeling (fell over
> backwards, landed my body weight on it).  It is healing, but slowly.
> I normally manage without my walking sticks in my own home, but I'm
> having to use them [ for the first few days, I had to use crutches ]
> and when I do go out I need crutches, otherwise I cannot step up/down
> kerbs.  This makes things in real life, even preparing my meals,
> much slower and more tiring than usual.  So, I'm not getting on with
> things as much as normal
> 
> Beyond that, I've now got to do my tax return (that always takes
> ages), and various things in my home are all wearing out.  So, for
> the next 2 or 3 months I don't think I'll be doing much, if
> anything, on the editorial side.
> 
> I hope to produce a hint I've been testing, and I'll still be
> reading the lists.

I am very sorry. Wishing you a quick recovery.


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] KDE4

[Fernando de Oliveira]

Em 28-12-2015 19:10, Ken Moffat escreveu:
> On Mon, Dec 28, 2015 at 07:27:52AM -0300, Fernando de Oliveira wrote:
>>>
>>> The question is how much longer should we support kde4?  kf5/plasma5 is
>>> now usable.  Should we archive kde4?  If not now, when?
>>
>> Think that as soon as the main applications are ported from KDE4. Not
>> having used KDE other than for testing (BLFS/edition and Kubuntu/how it
>> looks and feels), cannot pinpoint.
>>
> You might need to define 'main' ;-)  I never used kmail since kde2,
> nor dolphin (at all), and for sites I commonly visit (e.g. slashdot-
> not much useful content there these days, but the weird attitudes are
> sometimes amusing), konqueror in both 4 and 5 tended to crash.

Yes, but not having used much KDE, makes it very difficult. One
application I like and have always found the best one is in KDE: KAlarm.
Even for KDE users, it would vary, very subjective choice.

Though a lot, and I would make immediatley the the transition, using the
git ones, for the ones not yes ported.This would be a deviation from
what we normally do. Then, progressively transform into released ones,
when they appear. For the next BLFS release, I would then upload to
anduin the remaining ones as tarballs. This would allow us to completely
remove KF4.

Thought that, because we have a page "Further KDE4 packages" (which
would become "Further KDE4 packages"):

http://www.linuxfromscratch.org/blfs/view/svn/kde/add-pkgs.html

It has a generic set of instructions for all list packages there.

We would add another page before that one, with the packages in KDE not
yet ported:

"Packages from git, that will be progressively modified until all are
released", with generic instruction using git to download. And the
explanation why it is like that for the moment, telling that is not our
normal procedure, but due to the KDE status and lack of manpower, we
have extraordinarily decided for that.


>> Another thought is to ask in the support list some of the questions,
>> perhaps the above rationale and a simple question "are there BLFS users
>> that still need KDE4?".
>>
> That sounds a good idea - unfortunately, few people on -support ever
> read this list.

Yes. But if we replace as I describe above, no need for asking any more.


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] KDE4

[Fernando de Oliveira]

Since the day it was posted, I was waiting for replies to this post.
Seems that no reply means that nobody cares whatever you decide.

Em 22-12-2015 02:00, Bruce Dubbs escreveu:
> I just finished updating kde4.  Upstream has made building this a mess.
> There are files needed from many different releases:
> 
> 4.14.3
> 4.14.10
> 15.04.3
> 15.08.2
> 15.12.0
> 
> In many cases they provide new applications in a release, but the new
> app is targeted for KF5/Plasma5 and not KDE4.  For instance, in the
> latest release, 15.12.0, they have libkcddb, libkdcraw, and libkexiv2. 
> Of these libkcddb is still compatible with kde4, but the other two are
> not.  there are several other examples.  The latest konsole is not
> compatible with kde4, but okular is.  kde-runtime and kde-baseapps have
> been updated, but kde-workspace is still from 15.04.3.

Those are reasons that I have not yet come back to KDE related updates.

> 
> The question is how much longer should we support kde4?  kf5/plasma5 is
> now usable.  Should we archive kde4?  If not now, when?

Think that as soon as the main applications are ported from KDE4. Not
having used KDE other than for testing (BLFS/edition and Kubuntu/how it
looks and feels), cannot pinpoint.

Another thought is to ask in the support list some of the questions,
perhaps the above rationale and a simple question "are there BLFS users
that still need KDE4?".


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] icon files

[Fernando de Oliveira]

Em 27-12-2015 19:13, Bruce Dubbs escreveu:
> I've been working with upgrading kf5.  What is new is that it now
> contains oxygen-icons5-5.17.0 and breeze-icons-5.17.0.  These really
> should go into /usr/share/icons and not the kf5 directory.  I'll need to
> create new pages for them.

OK.

> 
> Since all icon themes can really be used by any desktop environment, I'm
> thinking about moving all icon files to a separate section.  The
> location would be right after Window Managers so we would have a new
> chapter:
> 
> 27. Icons
> adwaita-icon-theme-3.18.0
> breeze-icons-5.17.0
> hicolor-icon-theme-0.15
> icon-naming-utils-0.8.90
> gnome-icon-theme-3.12.0
> gnome-icon-theme-extras-3.12.0
> gnome-icon-theme-symbolic-3.12.0
> gnome-themes-standard-3.18.0
> lxde-icon-theme-0.5.1
> oxygen-icons-15.04.3
> oxygen-icons5-5.17.0

I like the idea.

> 
> I'm not sure about the difference between oxygen-icons-15.04.3 and
> oxygen-icons5-5.17.0.  The oxygen-icons5 package is missing
> CMakeLists.txt as well as 8x8 and 22x22 icons.  I can replace the short
> CMakeLists.txt file on the page or as a separate download.

OK. Isn't it possible that oxygen-icons-15.04.3 could be completely
replaced by oxygen-icons5-5.17.0?

> Although both oxygen-icons packages have a 'scalable' directory, neither
> is installed using current instructions.  I'm undecided about whether to
> install it or not and would like opinions about that.

I would like to have them installed.

> Overall, is this a reasonable thing to do?

Yes.


-- 
[]s,
Fernando, aka Sísifo
-- 
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 Package Currency Check - 2015-12-06 12:19:59 GMT

[Fernando de Oliveira]

Em 06-12-2015 09:32, Fernando de Oliveira escreveu:
> BLFS PackageBLFS Version Latest  Ticket

Sorry, wrong list.


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] BLFS Package Currency Check - 2015-12-06 12:19:59 GMT

[Fernando de Oliveira]

BLFS PackageBLFS Version Latest  Ticket
chapter 05: LVM22.02.134 2.02.137#7157
chapter 06: nano2.4.32.5.0   #7218
chapter 12: p7zip   9.38.1   15.09   #7048
chapter 13: gcc 5.2.05.3.0   #7216
chapter 13: gdb 7.10 7.10.1
chapter 13: git 2.6.02.6.3   #6982
chapter 13: libwww-perl 6.13 6.15
chapter 13: lua15.3.20
chapter 13: npapi-sdk   0.27.2   0
chapter 13: python2 2.7.10   2.7.11
chapter 17: libtirpc1.0.10.3.2
chapter 24: mesa11.0.6   11.1.0  #6984
chapter 25: gdk-pixbuf  2.32.1   2.33.1  #7054
chapter 27: baloo   4.14.3   check
chapter 27: baloo-widgets   4.14.3   check
chapter 27: kactivities 4.13.3   check
chapter 27: kde-base-artwork15.08.2  15.08.3
chapter 27: kde-baseapps15.08.2  15.08.3
chapter 27: kde-runtime 15.08.2  15.08.3 #7118
chapter 27: kde-workspace   4.11.21  check
chapter 27: kdelibs 4.14.13  4.14.14
chapter 27: kdepimlibs  4.14.10  check
chapter 27: kfilemetadata   4.14.3   check
chapter 27: oxygen-icons15.04.3  check
chapter 29: ark 15.04.3  check
chapter 29: gwenview4.14.3   check
chapter 29: kate4.14.3   check
chapter 29: kdepim  4.14.10  check
chapter 29: kdepim-runtime  4.14.10  check
chapter 29: kdeplasma-addons4.14.3   check
chapter 29: kmix15.04.3  check
chapter 29: konsole 4.14.3   check
chapter 29: libkcddb15.08.2  15.08.3
chapter 29: libkdcraw   15.08.2  15.08.3
chapter 29: libkexiv2   15.08.2  15.08.3
chapter 29: okular  15.08.2  15.08.3
chapter 36: gimp2.8.16   2.9.2   #7172
chapter 36: rxvt-unicode9.21 0
chapter 36: tigervnc1.5.01.6.0   #7177
chapter 39: x264264-snapshot-20150908-224daily   #6915
chapter 39: x2651.8  0
chapter 40: amarok  2.8.02.8.90  #6923
chapter 40: mplayer SVN-r37561   daily   #7174
chapter 40: transcode   1.1.70
chapter 43: docbook-xsl 1.78.1   1.79.0  #7026
chapter 43: docbook-xsl-doc 1.78.1   1.79.0  #7026
chapter 43: gutenprint  5.2.10   5.2.11  #6996
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Some packages with doc directory not matching version

[Fernando de Oliveira]

Em 30-11-2015 13:09, Bruce Dubbs escreveu:
> Fernando de Oliveira wrote:
>> Noticed today that the following packages are not installing doc

Sorry, sentence is wrong. Should read:

Noticed today that the following packages are not installing doc in the
correct versioned directories:

   actual   should be
>>
>> atkmm-1.6   atkmm-2.24.2
>> cairomm-1.0 cairomm-1.12.0
>> glibmm-2.4  glibmm-2.46.2
>> gtkmm-2.4   gtkmm-2.24.4
>> gtkmm-3.0   gtkmm-3.18.0
>> pangomm-1.4 pangomm-2.38.1
>>
>> Tried without success docdir=/usr/share/doc/atkmm-,
>> searched the configure and Makefile and it was there, but the variables
>> involved are different.
>>
>> Have not tried further investigation, before discussing here if we
>> should try to fix them, or not.
> 
> Looking at my glibmm-2.46.2.log, I see:
> 
> configure: WARNING: Location of external libstdc documentation not set
> checking for libsigc documentation...
> /usr/share/doc/libsigc++-2.0/reference/libsigc++-2.0.tag@file:///usr/share/doc/libsigc++-2.0/reference/html
> 
> ...
> 
> Making all in docs
> make[2]: Entering directory '/tmp/glibmm/glibmm-2.46.2/docs'
> ...
> Making check in docs
> make[1]: Entering directory '/tmp/glibmm/glibmm-2.46.2/docs'
> ...
> 
> Making install in docs
> make[1]: Entering directory '/tmp/glibmm/glibmm-2.46.2/docs'
> make[2]: Entering directory '/tmp/glibmm/glibmm-2.46.2/docs'
> make[2]: Nothing to be done for 'install-exec-am'.
> /bin/mkdir -p '/usr/share/doc/glibmm-2.4/reference/html'

We need to modify so that last line reads:

/bin/mkdir -p '/usr/share/doc/glibmm-2.46.2/reference/html

> /usr/bin/perl -- "../docs/doc-install.pl" --verbose --mode=0644 -l
> 'libsigc++-2.0.tag@../../../libsigc++-2.0/reference/html/' -t
> '/usr/share/doc/glibmm-2.4/reference/html' --glob --
> 'reference/html/*.css' 'reference/html/*.gif' 'reference/html/*.html'
> 'reference/html/*.js' 'reference/html/*.png'
> doc-install: Using base path ../../../libsigc++-2.0/reference/html/ for
> tag file libsigc++-2.0.tag
> doc-install: Copying tabs.css
> doc-install: Copying doxygen.css
> doc-install: Copying doxygen-extra.css
> doc-install: Translating namespaceGlib.html (rewrote 8 of 199 references)
> ...
> and a lot more doc-install entries.
> 
> I didn't check the other packages.  Do you have doxygen installed?

Yes, the log is the same as mine.


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Some packages with doc directory not matching version

[Fernando de Oliveira]

Em 30-11-2015 14:08, Fernando de Oliveira escreveu:
> Em 30-11-2015 13:09, Bruce Dubbs escreveu:
>> Fernando de Oliveira wrote:
>>> Noticed today that the following packages are not installing doc
> 
> Sorry, sentence is wrong. Should read:
> 
> Noticed today that the following packages are not installing doc in the
> correct versioned directories:
> 
>actual   should be
>>>
>>> atkmm-1.6   atkmm-2.24.2
>>> cairomm-1.0 cairomm-1.12.0
>>> glibmm-2.4  glibmm-2.46.2
>>> gtkmm-2.4   gtkmm-2.24.4
>>> gtkmm-3.0   gtkmm-3.18.0
>>> pangomm-1.4 pangomm-2.38.1

Fixed at r16699.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] Some packages with doc directory not matching version

[Fernando de Oliveira]

Noticed today that the following packages are not installing doc

atkmm-1.6   Atkmm-2.24.2
cairomm-1.0 Cairomm-1.12.0
glibmm-2.4  GLibmm-2.46.2
gtkmm-2.4   Gtkmm-2.24.4
gtkmm-3.0   Gtkmm-3.18.0
pangomm-1.4 Pangomm-2.38.1

Tried without success docdir=/usr/share/doc/atkmm-,
searched the configure and Makefile and it was there, but the variables
involved are different.

Have not tried further investigation, before discussing here if we
should try to fix them, or not.

-- 
[]s,
Fernando, aka Sísifo
-- 
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 for LXQT 0.10.0 building

[Fernando de Oliveira]

Em 11-11-2015 02:34, Bruce Dubbs escreveu:
> Fernando de Oliveira wrote:
>> Em 10-11-2015 18:17, Bruce Dubbs escreveu:
>>> Fernando de Oliveira wrote:
>>>
>>>> My preference is linking, not adding this extra line to the packages
>>>> cmake switches.
>>>>
>>>> Reason: eventually a developer or user will build KF5 and Plasma in the
>>>> same system.
>>>
>>> OK, go ahead and do what you think best.  I was just offering possible
>>> alternatives.
>>
>> Sorry, I forgot to thank you for replying.
>>
>> I liked your idea.
>>
>> I was not closing the discussion. If you really think that it is best to
>> separate the KF5 and Plasma pages and include the build in the LXQt
>> category, I am ready to gratefully accept.
> 
> I'll look at it tomorrow.  There are only four packages AFAIK right now
> that are needed.  If they are the only ones, it might be better to put
> them in /usr/lib instead of /opt/kf5.  However I can't decide until I
> look at the packages in a little more detail.

That is a good idea. Thanks.


-- 
[]s,
Fernando, aka Sísifo
-- 
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 for LXQT 0.10.0 building

[Fernando de Oliveira]

Em 10-11-2015 17:44, Bruce Dubbs escreveu:
> Fernando de Oliveira wrote:
>> Em 10-11-2015 14:39, Bruce Dubbs escreveu:
>>> hykw...@sina.com wrote:
>>
>>
>>>> 2. My build environment: chroot under Ubuntu LXQT target path:
>>>> /opt/lxqt KF5 path: /opt/kf5
>>>>
>>>> In order to build LXQT, I have to add "-DCMAKE_PREFIX_PATH=$KF5_PREFIX"
>>>> option otherwise cmake cannot find any KF5 components.
>>>
>>> There probably needs to be some additional detail if
>>> /etc/profile.d/kf5.sh is not installed.  I have not yet built lxqt.
>>>
>>>> 3. Add more information about "how to build the required KF5 components
>>>> and dependencies" such as KWindowSystem. That's because some KF5
>>>> required dependencies is not needed if we only build LXQT. For example,
>>>> I did not build Boost and Phonon in my system.
>>
>> Think I understand, now.
>>
>> In order to build any needed KF5 you only need that particular
>> application ans dependencies.
>>
>> But: you need to do the same thing as if building all KF5 and first, do
>> what is in "KDE Frameworks 5 Pre-installation Configuration":
>>
>>
>> http://www.linuxfromscratch.org/blfs/view/svn/kde/kf5-intro.html
>>
>> hykwok1: did you that? And then, "source profile", before start buildng:
>>
>> Bruce or Ken: Should these instructions be linked to LXQt? Where would
>> be the best place: in the pages with KF5 dependencies, in the note about
>> "just the named package needs to be installed, or in the Pre-Install
>> instructions?
> 
> We could add separate sections for KWindowSystem, kguiaddons, and solid.

Problem is that each release includes new KF5 and/or Plasma5 packages.

This time: solid (KF5) and libkscreen (Plasma5)
> 
> Dependencies for KWindowSystem is as I mentioned before.
> 
> kguiaddons:
> solid:  cmake, Qt5, and cmake-extras
> 
> libkscreen: cmake, Qt5, cmake-extras, and xcb-utils
> 
> As far as instruction about paths go, I think either setting
> -DCMAKE_PREFIX_PATH=$KF5_PREFIX in the cmake options or setting paths in
> the lxqt pre-install instructions would be appropriate.
> 
> I'll note that if I was going to install lxqt without kf5 or plasma, I
> would probably install KWindowSystem, kguiaddons, solid, and libkscreen
> in the lxqt hierarchy.
> 

My preference is linking, not adding this extra line to the packages
cmake switches.

Reason: eventually a developer or user will build KF5 and Plasma in the
same system.

-- 
[]s,
Fernando, aka Sísifo
-- 
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 for LXQT 0.10.0 building

[Fernando de Oliveira]

Em 10-11-2015 14:39, Bruce Dubbs escreveu:
> hykw...@sina.com wrote:


>> 2. My build environment: chroot under Ubuntu LXQT target path:
>> /opt/lxqt KF5 path: /opt/kf5
>>
>> In order to build LXQT, I have to add "-DCMAKE_PREFIX_PATH=$KF5_PREFIX"
>> option otherwise cmake cannot find any KF5 components.
> 
> There probably needs to be some additional detail if
> /etc/profile.d/kf5.sh is not installed.  I have not yet built lxqt.
> 
>> 3. Add more information about "how to build the required KF5 components
>> and dependencies" such as KWindowSystem. That's because some KF5
>> required dependencies is not needed if we only build LXQT. For example,
>> I did not build Boost and Phonon in my system.

Think I understand, now.

In order to build any needed KF5 you only need that particular
application ans dependencies.

But: you need to do the same thing as if building all KF5 and first, do
what is in "KDE Frameworks 5 Pre-installation Configuration":


http://www.linuxfromscratch.org/blfs/view/svn/kde/kf5-intro.html

hykwok1: did you that? And then, "source profile", before start buildng:

Bruce or Ken: Should these instructions be linked to LXQt? Where would
be the best place: in the pages with KF5 dependencies, in the note about
"just the named package needs to be installed, or in the Pre-Install
instructions?


-- 
[]s,
Fernando, aka Sísifo
-- 
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 for LXQT 0.10.0 building

[Fernando de Oliveira]

Em 10-11-2015 18:17, Bruce Dubbs escreveu:
> Fernando de Oliveira wrote:
> 
>> My preference is linking, not adding this extra line to the packages
>> cmake switches.
>>
>> Reason: eventually a developer or user will build KF5 and Plasma in the
>> same system.
> 
> OK, go ahead and do what you think best.  I was just offering possible
> alternatives.

Sorry, I forgot to thank you for replying.

I liked your idea.

I was not closing the discussion. If you really think that it is best to
separate the KF5 and Plasma pages and include the build in the LXQt
category, I am ready to gratefully accept.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] New lgpllibs included in Seamonkey-2.39 and Firefox, probably, 42.0

[Fernando de Oliveira]

I was intrigued about this in Seamonkey-2.39, perhaps menaing new
dependencies to be incuded in the update. After some search found this
curious new file

seamonkey-2.39/mozilla/config/external/lgpllibs/moz.build:


{{{
# -*- Mode: python; c-basic-offset: 4; indent-tabs-mode: nil; tab-width:
40 -*-
# vim: set filetype=python:
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.

# The lgpllibs library stores symbols from third-party LGPL licensed
libraries,
# such as libav and libsoundtouch. It fulfills the requirement of
dynamically
# linking these symbols into gecko.
#
# Any library added here should also be reflected in the about:license page.

SharedLibrary('lgpllibs')
SHARED_LIBRARY_NAME = 'lgpllibs'

if CONFIG['MOZ_LIBAV_FFT']:
DIRS += ['/media/libav']
DEFFILE = SRCDIR + '/lgpllibs.def'
}}}



-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Kernel 4.3 and openssl

[Fernando de Oliveira]

Em 07-11-2015 11:30, Pierre Labastie escreveu:
> On 07/11/2015 13:59, Fernando de Oliveira wrote:
>> Em 07-11-2015 05:52, Pierre Labastie escreveu:
>>> On 07/11/2015 02:41, Bruce Dubbs wrote:
>>>> Ken Moffat wrote:
>>>>> On Sat, Nov 07, 2015 at 01:10:53AM +0100, Tim Tassonis wrote:
>>>>>> Hi all
>>>>>>
>>>>>> I just read that in order to sign modules in the latest 4.3 kernel, one 
>>>>>> has
>>>>>> to have openssl installed.
>>>>>>
>>>>>> I just wondered if it would be an idea to move openssl from blfs to lfs? 
>>>>>> Not
>>>>>> that I personally need this feature urgently or really want to advocate 
>>>>>> the
>>>>>> change.
>>>>>>
>>>>>> But since openssl probably already is one of the first blfs packages 
>>>>>> people
>>>>>> install (to get remote ssh access via openssh), it also wouldn't harm 
>>>>>> much
>>>>>> moving it to lfs.
>>>>
>>>>> I think most LFS builders do not need to sign kernel modules, indeed
>>>>> some LFS users try to avoid modules altogether.  I really do not
>>>>> think that many of our (LFS,BLFS) users will get any benefit from
>>>>> signng their modules.
>>>>>
>>>>> Also, while people building {.B}LFS on servers or firewalls are likely
>>>>> to use ssh, I suspect that the proportion of our desktop builders who
>>>>> use openssh is below 50%.
>>>>
>>>> I agree with you Ken that LFS users don't really have a need to sign (or 
>>>> use)
>>>> modules.  However, I would think that desktop users would want ssh too.  
>>>> Even
>>>> if a build is in a virtual system, ssh makes it very easy to build where
>>>> copy/paste is not always easy directly into a virtual system.
>>>>
>>>> I think one of the hardest parts of building a desktop is between the end 
>>>> of
>>>> LFS and when Xorg is completed with a decent graphical browser.  I know it 
>>>> can
>>>> be done in chroot, but I don't think that is the easiest way.
>>>>
>>>
>>> I try to avoid chroot as soon as possible, and the survival kit for that, in
>>> the absence of X, is gpm (for copy-paste), wget (for downloading tarballs) 
>>> and
>>> lynx (for reading the book and browsing). But owing to the number of https
>>> adresses on the internet nowadays, openssl needs to be built in the last 
>>> two.
>>>
>>> Not sure it justifies having openssl in LFS, though.
>>>
>>> Pierre
>>>
>>
>> MIT Kerberos V5-1.13.2 is an optional dependency.
>>
>> There are also two circular dependencies:
>>
>> {{{
>> Most users will want to install Certificate Authority Certificates for
>> validation of downloaded certificates. For example, these certificates
>> can be used by git-2.6.0, cURL-7.45.0 or Wget-1.16.3 when accessing
>> secure (https protocol) sites. To do this, follow the instructions from
>> the Certificate Authority Certificates page.
>> }}
>>
>> I think this a package for BLFS.

s/this/this is/

> 
> We did not say it the same way, but I think we agree...
> Pierre
> 

Yes, thanks. Was trying to be more assertive, so there was no doubt
about it.
-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Kernel 4.3 and openssl

[Fernando de Oliveira]

Em 07-11-2015 05:52, Pierre Labastie escreveu:
> On 07/11/2015 02:41, Bruce Dubbs wrote:
>> Ken Moffat wrote:
>>> On Sat, Nov 07, 2015 at 01:10:53AM +0100, Tim Tassonis wrote:
 Hi all

 I just read that in order to sign modules in the latest 4.3 kernel, one has
 to have openssl installed.

 I just wondered if it would be an idea to move openssl from blfs to lfs? 
 Not
 that I personally need this feature urgently or really want to advocate the
 change.

 But since openssl probably already is one of the first blfs packages people
 install (to get remote ssh access via openssh), it also wouldn't harm much
 moving it to lfs.
>>
>>> I think most LFS builders do not need to sign kernel modules, indeed
>>> some LFS users try to avoid modules altogether.  I really do not
>>> think that many of our (LFS,BLFS) users will get any benefit from
>>> signng their modules.
>>>
>>> Also, while people building {.B}LFS on servers or firewalls are likely
>>> to use ssh, I suspect that the proportion of our desktop builders who
>>> use openssh is below 50%.
>>
>> I agree with you Ken that LFS users don't really have a need to sign (or use)
>> modules.  However, I would think that desktop users would want ssh too.  Even
>> if a build is in a virtual system, ssh makes it very easy to build where
>> copy/paste is not always easy directly into a virtual system.
>>
>> I think one of the hardest parts of building a desktop is between the end of
>> LFS and when Xorg is completed with a decent graphical browser.  I know it 
>> can
>> be done in chroot, but I don't think that is the easiest way.
>>
> 
> I try to avoid chroot as soon as possible, and the survival kit for that, in
> the absence of X, is gpm (for copy-paste), wget (for downloading tarballs) and
> lynx (for reading the book and browsing). But owing to the number of https
> adresses on the internet nowadays, openssl needs to be built in the last two.
> 
> Not sure it justifies having openssl in LFS, though.
> 
> Pierre
> 

MIT Kerberos V5-1.13.2 is an optional dependency.

There are also two circular dependencies:

{{{
Most users will want to install Certificate Authority Certificates for
validation of downloaded certificates. For example, these certificates
can be used by git-2.6.0, cURL-7.45.0 or Wget-1.16.3 when accessing
secure (https protocol) sites. To do this, follow the instructions from
the Certificate Authority Certificates page.
}}

I think this a package for BLFS.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] lxqt-sudo

[Fernando de Oliveira]

Em 05-11-2015 00:23, Fernando de Oliveira escreveu:
> Em 04-11-2015 22:49, Ken Moffat escreveu:
>> On Wed, Nov 04, 2015 at 07:02:43PM -0600, Bruce Dubbs wrote:
>>> Fernando de Oliveira wrote:
>>>> Em 04-11-2015 21:02, ferna...@higgs.linuxfromscratch.org escreveu:
>>>>> Author: fernando
>>>>> Date: Wed Nov  4 16:02:43 2015
>>>>> New Revision: 16607
>>>>>
>>>>
>>>>> • Update to Update to LXQt 0.10.0.
>>>>
>>>>
>>>> Haven't included the new ''lxqt-sudo (usable as `lxsu` or `lxsudo`)'',
>>>> because I have great doubt if somebody using (B)LFS will ever use it.
>>>> Many don't even like sudo.
>>>>
>>>> However it should be easy to add.
>>>
>>> I do need and like sudo, but I do that from the command line.  I don't know
>>> what lxqt-sudo  would do for the user.
>>>
>>>   -- Bruce
>>>
>> I'm from the "I dislike sudo" tendency - it has its uses (I use it
>> to allow swsuspend with xbindkeys, and maybe in one or two other
>> places - I also use it on my netbook to allow a user to connect to
>> my wifi).  For installing software, I deviate from BLFS bt
>> configuring and building as root.  But on this one, I'm with Bruce -
>> an example of what it would allow|simplify would help.
>>
>> ĸen
>>
> 
> I didn't know the answer. Searched and one thing is that pcmanfm has an
> option to "open as root" under "Tools". This could be used for files,
> folders or even applications (pcmanfm has a place named Applications).
> Then, apparently, a graphical dialogue should pop up to enter the
> password (I've seen an example in qsudo:
> 
> https://github.com/lxde/lxqt/issues/537#issuecomment-102769178
> 
> The project was at
> 
> https://github.com/alfredobonino/qsudo
> 
> but was abandoned in favour of lxqt-sudo.
> 
> If you know what is gksudo gksu kdesu kdesudo, it should be similar.
> 
> At about 2007 or 8, Ubuntu had a recomendation to use gksudo, not sudo,
> for running graphical programs as root.
> 
> Well, as I wrote in the first post, don't see any point for any of us
> use it (the three ones that have already posted in the thread).
> 
> We don't even use file managers/navigators, but terminals.
> 
> Question would be relevant for heavy graphical interface users or some
> users that build for the family or friends or companies...
> 

I've remembered one possible use: to include in .desktop files and
(don't know yet how), commands, like mount. Perhaps this last use can be
worked around with the Tools/"Open as Root"). I have included
ssh-askpass exactly with the similar objective of using a graphical
password dialogue to execute gparted as administrator without the need
of pkexec.

We have been having many problems with permissions, like ssh-askpass, it
could help.

Pro argument is that it is Qt based and only depends on liblxqt.

Against, I still have the arguments that we already have ssh-askpass and
nobody thought we would need the similar (deprecated?) ones like
gksu(do) and kdesu(do).

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] lxqt-sudo

[Fernando de Oliveira]

Well, have been thinking about all this, got news from LXQt [1]
including news from Fedora LXQt [2], and experimented little with
Siduction LXQt, which brings news from Debian unstable.

Decided that it is better to follow upstream and include three packages
that were in the ticket #7081 and I ignored:

lxqt-admin
lxqt-openssh-askpass
lxqt-sudo

I'm reopening the ticket to fix those. The package lxqt-admin is very
good, it allows change of system time fuse and users. The other two,
definitely are wanted for some users afraid of terminals.

My sister and some close to me people come to mind: it is easier to
support them by telephone with "click here click there" because the
respond with very negative interjections, when I try to tell them "open
the terminal". And after I tell the command to use in the terminal, they
ask "and now?" - "as before, press the Enter key". When asked for a
password, "I typed but nothing is appearing" - "It's OK, just press
Enter again".

I apologize for having asked, instead of deciding after a better study.

Thank you very much for the replies, they motivated me to better study
the issue.

Any objections, please?

Now, officially our choice for QTerminal (with QTermWidget) is the
official terminal of LXQT, replacing LXTerminal, and has been
incorporated to the LXQT project, although keeping independent release
cicle [1]. It already was the choice in Fedora LXQt [2]. Before, the
official one was LXTerminal. Next release will be available on
downloads.lxqt.org and it is promised they will be "pushing harder for
fixes and polishing on it" [1].

References:

[1] http://sourceforge.net/p/lxde/mailman/message/34596414/

[2] http://sourceforge.net/p/lxde/mailman/message/34596455/
-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] lxqt-sudo

[Fernando de Oliveira]

Em 04-11-2015 21:02, ferna...@higgs.linuxfromscratch.org escreveu:
> Author: fernando
> Date: Wed Nov  4 16:02:43 2015
> New Revision: 16607
> 

> • Update to Update to LXQt 0.10.0.


Haven't included the new ''lxqt-sudo (usable as `lxsu` or `lxsudo`)'',
because I have great doubt if somebody using (B)LFS will ever use it.
Many don't even like sudo.

However it should be easy to add.

Opinions, please?

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Fix for KDE Frameworks 5 Pre-installation Configuration

[Fernando de Oliveira]

Em 04-11-2015 12:06, Bruce Dubbs escreveu:
> Fernando de Oliveira wrote:
>> Bruce,
>>
>> I copy/pasted one part and it gave me a hard time, I couldn't build
>> KwindowSystem, because it broke PATH, removing  /opt/qt5.
>>
>>
>> I'm talking about:
>>
>> http://www.linuxfromscratch.org/blfs/view/svn/kde/kf5-intro.html
>>
>>
>> We have (in /opt):
>>
>> {{{
>> cat > /etc/profile.d/qt5.sh << "EOF"
>> # Begin /etc/profile.d/kf5.sh
>> # Begin Qt5 changes for KF5
>> ...
>> }}}
>>
>> I think it should be:
>>
>> {{{
>> cat >> /etc/profile.d/qt5.sh << "EOF"
>> # Begin Qt5 changes for KF5
>> ...
>> }}}
> 
> You're right.  Fixed.  This is why I needed more eyes on the page.
>   -- Bruce
> 
> 

No problem. Thanks.

I would like to thank you very much again for all this work in KF5 and
Plasma 5 and just in time!

I'm now using about 3 from KF5 and finishing the script to install
libkscreen-5.4.2, from Plasma 5, for the LXQt-0.10.0 update. In other
words, I'm a user, for development for my personal need, of both of your
works.

Small other fix for Plasma 5, now:

{{{
 Package Information

Download (HTTP): http://download.kde.org/stable/plasma5/5.4.2
}}}

URL in the commands is correct, but not here:

s/plasma5/plasma/

Of course, just what I think you call "oversight".

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Need help validating Plasma 5

[Fernando de Oliveira]

Em 03-11-2015 12:13, Pierre Labastie escreveu:
> On 03/11/2015 03:30, Bruce Dubbs wrote:
>> I've been working quite a while now on Plasma5.  This is a very
>> complex set of packages, but I think I've got it working now.
>>
>> My problem before was installation paths and environment variables.
>>
>> In any case, I'm too close to the changes I've made to properly
>> validate it.  I'd like to get a volunteer to do a test build. There
>> are a lot of dependencies, but most of those should be already
>> available if you've built another window manager.
>>
>> The pages are now up at http://www.linuxfromscratch.org/blfs/view/svn/.
>>
>> If you haven't built KDE before, you will need to do the 6 packages in
>> Chapter 28 and then Chapters 31 and 33.  Building konsole in Chapter
>> 32 is also helpful.
>>
>> Please let me know if you can do this.
>>
>> One note:  The digital clock does not work correctly.  I can only get
>> it to show GMT.  I've found a lot of complaints via google about the
>> digital clock, so consider that to be a work in progress.   The analog
>> clock is fine.
>>
>>   -- Bruce
> I may give it a try. I'll commit soon a small patch for an obvious
> change needed, but I am worried that kf5 does not appear in plasma
> dependencies... Shouldn't it?
> 
> Pierre

I am planning to copy this development system and turn the new one in
development and keep this as host only. This will be done later, when I
feel the "host" is complete for my needs.

The reason is that I panned to the same thing with LFS77, but got it not
perfectly working, afyer updating to the new gcc minor.

In my future dev system, I will come back to get kde related installed,
so will be able to make updates in this part of the book.

I'm not ignoring the need for helping you with those matters.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] samba-4.3.1 quicktest

[Fernando de Oliveira]

I'm so sorry for having sent this message to -book.

Em 01-11-2015 20:59, ferna...@higgs.linuxfromscratch.org escreveu:
> Author: fernando
> Date: Sun Nov  1 15:59:31 2015
> New Revision: 16590
> 
> Log:
> • Update to samba-4.3.1.

> -  quicktest, reputedly up to 500 MB additional for all tests)">
> -  SBU for the quicktest, reputedly up to 110 SBU to run all tests)">
> +  quicktest, reputedly up to 500 MB additional for all tests)">
> +  SBU for the quicktest, reputedly up to 110 SBU to run all tests)">

Tests didn't run successfully.

I have no clue for solving the problem.

Attaching "make -k quicktest" and "quicktest summary" logs.

I don't understand in the full test log, the end message:

{{{
quicktest results
FAILED (0 failures, 0 errors and 0 unexpected successes in 48 testsuites)
}}}

if I have there 48 ERRORS:

{{{
$ xzgrep 'ERROR: Testsuite'
samba-4.3.1-make-k-quicktest-2015.11.01-13h27m33s.log.xz | wc -l
48
}}}

About one hour to run the tests. Most of the time coming from the
failures, apparently. That's the reason for the large test SBU.

-- 
[]s,
Fernando, aka Sísifo



samba-4.3.1-make-k-quicktest-2015.11.01-13h27m33s.log.xz
Description: application/xz


samba-4.3.1-quick-summary-2015.11.01-13h27m33s.log.xz
Description: application/xz
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] currency scripts

[Fernando de Oliveira]

Em 30-10-2015 19:29, Bruce Dubbs escreveu:
> I finally got around to updating the currency scripts.  It took me about
> 6 hours today to get them in shape.  They still need work though.  There
> are several newer packages that are not checked at all including lxqt,
> kf5, and plasma5.
> 
> In any case, this is the current list.
> 
>   -- Bruce

Thanks.
> 


> chapter 13: cmake   3.3.2pending

This is not pending, to the best of my knowledge.


> chapter 13: php 5.6.14   5.6.15  #7068

> chapter 20: postfix 3.0.23.0.3   #7069

> chapter 20: postgresql  9.4.49.4.5   #7070

> chapter 25: cairo   1.14.2   1.14.4  #7071

I've fixed those four erlier today


-- 
[]s,
Fernando, aka Sísifo
-- 
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 LVM test hanging

[Fernando de Oliveira]

Em 26-10-2015 18:11, Pierre Labastie escreveu:
> As noted in ticket #6931, one test (test/shell/lvcreate-large-raid.sh) hangs
> forever and may even trash the system, which then needs a hard reboot.
> 
> I've found the explanation, but really upstream is too "fedora-centric" (see
> below why). In file test/lib/aux, there is this function (look at the 4 line
> long comment):
> 
> have_raid() {
> test "$RAID" = shared -o "$RAID" = internal || {
> echo "Raid is not built-in." >&2
> return 1;
> }
> target_at_least dm-raid "$@"
> 
> # some kernels have broken mdraid bitmaps, don't use them!
> # may oops kernel, we know for sure all FC24 are currently broken
> # in general any 4.1, 4.2 is likely useless unless patched
> # hopefully 4.3 will be patched
> case "$(uname -r)" in
>   4.[123].*fc24*) return 1 ;;
> esac
> ---
> The comment shows that mdraid is broken in kernels version 4.1 and 4.2, but
> then, only fc24 kernels lead to non zero exit! Note that according to the
> comment, any test using raid could be hanging too. I've only observed that for
> one test.
> 
> Anyway, I tried linux-4.0.9 and linux-4.3-rc7, and the test passes on both.
> Looks like 4.3 has been patched.
> I'll change the book to warn against versions 4.1 and 4.2 of the kernel (in
> both LVM and mdadm).

Yes, good change for all users end developers.

And I left one comment in the ticket.

Thanks again for your deep investigation about these so problematic checks.


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] x265 and ffmpeg

[Fernando de Oliveira]

Em 24-10-2015 14:49, Tim Tassonis escreveu:
> Hi all
> 
> I just did compiled / installed x265 as in the book, and then ffmepg
> with --enable-libx265, so it would pick up the x265 stuff.
> 
> While this went ok, I noticed that ffmpeg will link to the static
> libx265 library instead of the shared one, as both are produced and
> installed. Moving libx265.a away from /usr/lib before the ffmpeg
> build/install fixed that.
> 
> I just wondered if there is a cleaner way to achieve that? I'm not
> really familiar with cmake, the autoconf usually lets you specify
> --disable-static on configure.

Thanks for the info.

To find the options with cmake, run:

cmake  -LH

Normally you are inside the source, where CMakeLists.txt is.

With mariadb:

$ cd mariadb-
$ cmake . -LH

I wrote that, because the case of x264 is a little peculiar: the source
with CMakeLists.txt is not under x264_1.8, but under "source", so that:

$ cd x264_1.8
$ cmake source -LH

Unfortunately there is no ENABLE_STATIC option, so we have to do either
what you have just done, or use a patch to create the option. I have
submitted that patch and modified the x264 page to use it should be in
svn tomorrow.

Attached is the patch, if you wish to try it before that.

Use

cmake -DCMAKE_INSTALL_PREFIX=/usr \
  -DENABLE_STATIC=OFF ../source

> 
> Kind regards
> Tim


-- 
[]s,
Fernando, aka Sísifo
Submitted By:Fernando de Oliveira 
Date:2015-10-24
Initial Package Version: 1.8
Upstream Status: not submitted
Origin:  https://bitbucket.org/TimothyGu/x265/commits/a9aacc5a16116f1c663d1fcb62ad9a0985043b94/raw/
 https://bitbucket.org/TimothyGu/x265/commits/578c5ef3dff46db38e7c36a8d3c6198a65c9746b/raw/
Description: Add ENABLE_STATIC:BOOL=ON, so that static lib
 can be disabled.



--- x265_11047/source/CMakeLists.txt.orig	2015-10-08 07:01:36.0 -0300
+++ x265_11047/source/CMakeLists.txt	2015-10-24 17:10:57.919861668 -0300
@@ -419,16 +419,21 @@
 endif()
 
 source_group(ASM FILES ${YASM_SRCS})
-add_library(x265-static STATIC $ $ ${YASM_OBJS} ${YASM_SRCS})
-if(NOT MSVC)
-set_target_properties(x265-static PROPERTIES OUTPUT_NAME x265)
-endif()
-if(EXTRA_LIB)
-target_link_libraries(x265-static ${EXTRA_LIB})
-endif()
-install(TARGETS x265-static
-LIBRARY DESTINATION ${LIB_INSTALL_DIR}
-ARCHIVE DESTINATION ${LIB_INSTALL_DIR})
+
+option(ENABLE_STATIC "Build static library" ON)
+if(ENABLE_STATIC)
+add_library(x265-static STATIC $ $ ${YASM_OBJS} ${YASM_SRCS})
+if(NOT MSVC)
+set_target_properties(x265-static PROPERTIES OUTPUT_NAME x265)
+endif()
+if(EXTRA_LIB)
+target_link_libraries(x265-static ${EXTRA_LIB})
+endif()
+install(TARGETS x265-static
+LIBRARY DESTINATION ${LIB_INSTALL_DIR}
+ARCHIVE DESTINATION ${LIB_INSTALL_DIR})
+endif(ENABLE_STATIC)
+
 install(FILES x265.h "${PROJECT_BINARY_DIR}/x265_config.h" DESTINATION include)
 
 if(CMAKE_RC_COMPILER)
@@ -490,6 +495,10 @@
 endif()
 endif()
 
+if(NOT ENABLE_STATIC AND NOT ENABLE_SHARED)
+message(FATAL_ERROR "Neither static nor shared libraries are enabled.")
+endif()
+
 if(X265_LATEST_TAG)
 # convert lists of link libraries into -lstdc++ -lm etc..
 foreach(LIB ${CMAKE_CXX_IMPLICIT_LINK_LIBRARIES} ${PLATFORM_LIBS})
@@ -551,12 +560,14 @@
 else()
 add_executable(cli ../COPYING ${InputFiles} ${OutputFiles} ${GETOPT} ${X265_RC_FILE}
${ExportDefs} x265.cpp x265.h x265cli.h x265-extras.h x265-extras.cpp)
-if(WIN32 OR NOT ENABLE_SHARED OR INTEL_CXX)
-# The CLI cannot link to the shared library on Windows, it
-# requires internal APIs not exported from the DLL
-target_link_libraries(cli x265-static ${PLATFORM_LIBS})
-else()
+if(WIN32 AND NOT ENABLE_STATIC)
+message(FATAL_ERROR "The CLI cannot link to shared library on Windows as it requires internal APIs not exported from the DLL.")
+elseif(INTEL_CXX AND NOT ENABLE_STATIC)
+message(FATAL_ERROR "The CLI cannot link to shared library with Intel C++ Compiler as it requires internal APIs not exported from the shared library.")
+elseif(ENABLE_SHARED)
 target_link_libraries(cli x265-shared ${PLATFORM_LIBS})
+else()
+target_link_libraries(cli x265-static ${PLATFORM_LIBS})
 endif()
 endif()
 set_target_properties(cli PROPERTIES OUTPUT_NAME x265)
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] mesa-11.0.3-add_xdemos-2.patch not found

[Fernando de Oliveira]

Bruce,

After two days, it seems the patch is not yet in place:

$ LANG=C wget -c
http://www.linuxfromscratch.org/patches/blfs/svn/mesa-11.0.3-add_xdemos-2.patch
--2015-10-19 06:35:51--
http://www.linuxfromscratch.org/patches/blfs/svn/mesa-11.0.3-add_xdemos-2.patch
Resolving www.linuxfromscratch.org (www.linuxfromscratch.org)...
192.155.86.174, 2600:3c01::f03c:91ff:fe70:25e8
Connecting to www.linuxfromscratch.org
(www.linuxfromscratch.org)|192.155.86.174|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2015-10-19 06:35:53 ERROR 404: Not Found.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Firefox 41.0.3 build problem

[Fernando de Oliveira]

Em 19-10-2015 03:51, Markku Pesonen escreveu:
> Bruce Dubbs wrote:
>> I've got a problem building firefox on a new system.  On my normal 
>> development system it builds fine, but using the same procedures on a 
>> brand new build gives:
>>
>> /usr/src/firefox/firefox/mozilla-release/gfx/skia/trunk/src/ports/SkFontHost_FreeType.cpp:560:
>>  
>> undefined reference to `FT_Get_X11_Font_Format'
>> collect2: error: ld returned 1 exit status
>> /usr/src/firefox/firefox/mozilla-release/config/rules.mk:812: recipe for 
>> target 'libxul.so' failed
> 
> Freetype 2.6.1 changed the location of ftfntfmt.h, so
> config/system-headers must be patched yet again. This works for me:
> 
> sed -i '/^freetype\/ftcache.h/a freetype\/ftfntfmt.h' config/system-headers

Thanks, Markku.

Yes:

{{{

II. IMPORTANT CHANGES

- The header  file layout  has been  changed (again),  moving  all
  header files except `ft2build.h' into a subdirectory tree.

  Doing so  reduces the  possibility of  header file  name clashes
  (e.g., FTGL's  `FTGlyph.h' with FreeType's `ftglyph.h')  on case
  insensitive file systems like Mac OS X or Windows.

  Applications  that  use  (a)  the  `freetype-config'  script  or
  FreeType's `freetype2.pc' file for pkg-config to get the include
  directory  for the  compiler,  and (b)  the  documented way  for
  header inclusion like

#include 
#include FT_FREETYPE_H
...

  don't need any change to the source code.
}}}

It is in the ticket.

We are expecting some more problems, but I'm building the new dev system
quite slow, and could not test everything yet, to try and fix.

Markku's fix is very appreciated not only for FF, but it should
facilitate our job with other packages.

-- 
[]s,
Fernando de Oliveira


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Poppler-0.37.0 and OpenJPEG

[Fernando de Oliveira]

Em 19-10-2015 15:28, Bruce Dubbs escreveu:
> Fernando de Oliveira wrote:
>> Is this OK?
>>
>> {{{
>> Optional
>>
>> ...
>>
>> OpenJPEG-2.1.0 (preference is for OpenJPEG1, due to regressions with
>> OpenJPEG2)
> 
> I looked at that the other day and the log still says:
> 
> 
> checking for libjpeg6b... no
> checking for libjpeg... -ljpeg
> checking jpeglib.h usability... yes
> checking jpeglib.h presence... yes
> checking for jpeglib.h... yes
> checking libjpeg.h works correctly... ok
> 
>   use libjpeg:yes
>   ...
>   use libopenjpeg:yes
>   with openjpeg1
> 
> I'm not sure how to interpret that, but it looks like it is saying the
> above note may be overcome by events.
> 
>   -- Bruce
> 

problem is that only openjepeg2 is listed as dependency.

What makes sense (not if is the correct one)

1. Both are listed and we we keep the note.

2. Only openjpeg1 is listed, and remove the note?

Option 2, I wrote after seen that your log is catching openjpeg1.

What seems wrong is listing openjpeg2 only as dependency, with or
without a note.

Did I make any sense?

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] mesa-11.0.3-add_xdemos-2.patch not found

[Fernando de Oliveira]

Em 19-10-2015 13:32, Bruce Dubbs escreveu:
> Bruce Dubbs wrote:
>> Fernando de Oliveira wrote:
>>> Bruce,
>>>
>>> After two days, it seems the patch is not yet in place:
>>>
>>> $ LANG=C wget -c
>>> http://www.linuxfromscratch.org/patches/blfs/svn/mesa-11.0.3-add_xdemos-2.patch
>>>
>>>
>>> --2015-10-19 06:35:51--
>>> http://www.linuxfromscratch.org/patches/blfs/svn/mesa-11.0.3-add_xdemos-2.patch
>>>
>>>
>>> Resolving www.linuxfromscratch.org (www.linuxfromscratch.org)...
>>> 192.155.86.174, 2600:3c01::f03c:91ff:fe70:25e8
>>> Connecting to www.linuxfromscratch.org
>>> (www.linuxfromscratch.org)|192.155.86.174|:80... connected.
>>> HTTP request sent, awaiting response... 404 Not Found
>>> 2015-10-19 06:35:53 ERROR 404: Not Found.
>>
>> I saw that yesterday and I thought I fixed it.  I'll look again.
>> I'm sure it has to do with the server migration.
> 
> Actually it was a problem with general.ent.  I had written a note that
> duplicated an entity name in a comment and that was being picked up by
> the nightly script.
> 
> Should be OK now.

Checked.

Thank you!!!


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] screen cluttered by kernel messages

[Fernando de Oliveira]

Em 16-10-2015 02:37, Pierre Labastie escreveu:
> Hi,
> 
> Just want to share something everybody may be knowing already...
> 
> In the past years, we have seen more and more kernel messages cluttering
> the screen (when mounting an ext2 system, when setting up network, etc).
> It culminates with the LVM tests, where it is almost impossible to work
> on another console during the tests (since the kernel messages go the
> the console you are working on, not the console where you started the
> test).
> 
> The command "dmesg -D" can be used to avoid those annoyances. Normally,
> critical messages should still show up through the sysklogd system.
> 
> Pierre
> 

It is good discussing this. First time I wrote to help a client, IIRC,
DJ warned me, because I instructed a user to change a bootscript. :-)

Found in man 2 syslog.

   Kernel constant   Level value   Meaning
   KERN_EMERG 0System is unusable
   KERN_ALERT 1Action must be taken immediately
   KERN_CRIT  2Critical conditions
   KERN_ERR   3Error conditions
   KERN_WARNING   4Warning conditions
   KERN_NOTICE5Normal but significant condition
   KERN_INFO  6Informational
   KERN_DEBUG 7Debug-level messages

I use /etc/sysconfig/rc.site:

$ grep LOGLEVEL /etc/sysconfig/rc.site
#LOGLEVEL=5
LOGLEVEL=3


Perhaps it would do with level 4.
-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] screen cluttered by kernel messages

[Fernando de Oliveira]

Em 16-10-2015 10:20, Pierre Labastie escreveu:
> On 16/10/2015 12:41, Fernando de Oliveira wrote:
>> Em 16-10-2015 02:37, Pierre Labastie escreveu:
>>> Hi,
>>>
>>> Just want to share something everybody may be knowing already...
>>>
>>> In the past years, we have seen more and more kernel messages cluttering
>>> the screen (when mounting an ext2 system, when setting up network, etc).
>>> It culminates with the LVM tests, where it is almost impossible to work
>>> on another console during the tests (since the kernel messages go the
>>> the console you are working on, not the console where you started the
>>> test).
>>>
>>> The command "dmesg -D" can be used to avoid those annoyances. Normally,
>>> critical messages should still show up through the sysklogd system.
>>>
>>> Pierre
>>>
>> It is good discussing this. First time I wrote to help a client, IIRC,
>> DJ warned me, because I instructed a user to change a bootscript. :-)
>>
>> Found in man 2 syslog.
>>
>> Kernel constant   Level value   Meaning
>> KERN_EMERG 0System is unusable
>> KERN_ALERT 1Action must be taken immediately
>> KERN_CRIT  2Critical conditions
>> KERN_ERR   3Error conditions
>> KERN_WARNING   4Warning conditions
>> KERN_NOTICE5Normal but significant condition
>> KERN_INFO  6Informational
>> KERN_DEBUG 7Debug-level messages
>>
>> I use /etc/sysconfig/rc.site:
>>
>> $ grep LOGLEVEL /etc/sysconfig/rc.site
>> #LOGLEVEL=5
>> LOGLEVEL=3
>>
>>
>> Perhaps it would do with level 4.
> Thanks Fernando,
> 
> You gave me pointers to where to look for. Actually, it seems to
> me that there is a small issue in rc.site: it has:
> 
> "#LOGLEVEL=5"
> 
> and I would imagine that it means the default log level is 5. But the
> rc script has:
> 
> dmesg -n "${LOGLEVEL:-7}"
> 
> which means the default level is 7. I'd suggest put "#LOGLEVEL=7" in
> rc.site. There is a thread in 2010 (most relevant message is
> http://lists.linuxfromscratch.org/pipermail/lfs-dev/2010-February/063518.html)
> 
> where Bruce explains why the log level should be 7.
> 
> Now, for BLFS, we always assume that the user uses the defaults,
> so that log level is 7 (all messages printed except DEBUG). In this
> case, running the LVM test just renders any virtual console unusable
> (I have not tried on an X display). What do you think if change the test
> command to:
> dmesg -D;make -k check;dmesg -E
> 
> Pierre
> 

Both are OK, for me.

But I had seen in man dmesg:

{{{
-n, --console-level level
   Set the level at which printing of messages is done to the  con‐
   sole.   The level is a level number or abbreviation of the level
   name.  For all supported levels see the --help output.

   For example, -n 1 or -n  alert  prevents  all  messages,  except
   emergency  (panic) messages, from appearing on the console.  All
   levels of messages are still  written  to  /proc/kmsg,  so  sys‐
   logd(8)  can  still be used to control exactly where kernel mes‐
   sages appear.  When the -n option is used, dmesg will not  print
   or clear the kernel ring buffer.
}}}

Therefore, it is more useful to having default in the rc script and
rc.site as 4, explaining somwhere (if it isn't already done, that all
messages are still logged in /dev/kmsg, and can be read with, e.g.:

dd if=/dev/kmsg iflag=nonblock

I believe they are also in /var/log/sys.log and /var/log/kern.log.

But while this is not discussed, for the status quo, at least the LVM
tests could be modified as you suggested.

Almost OT: I am impressed how your tests results improved. What have you
done?

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] LLVM-3.7.0 typo?

[Fernando de Oliveira]

Em 15-10-2015 19:56, Fernando de Oliveira escreveu:

> Getting order, brain cells seem to be dying very quickly.

s/order/older/

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] LLVM-3.7.0 typo?

[Fernando de Oliveira]

Em 15-10-2015 19:44, Bruce Dubbs escreveu:
> Fernando de Oliveira wrote:
>> Consider the instructions:
>>
>> {{{
>> install -v -dm755 /usr/lib/clang-analyzer &&
>>
>> for prog in scan-build scan-view
>> do
>>cp -rfv ../tools/clang/tools/$prog /usr/lib/clang-analyzer/
>>ln -sfv ../lib/clang-analyzer/$prog/$prog /usr/bin/
>> done
>> }}}
>>
>> I can't understand the line:
>>
>> ln -sfv ../lib/clang-analyzer/$prog/$prog /usr/bin/
>>
>> Why the double $prog/$prog?
>>
>> My first impression is that it is a typo, but I've been using it like
>> that, apparently it is working?
>>
>> It comes from r11334 ()
> 
> Take a look at:
> 
> ls /usr/lib/clang-analyzer/scan-*
> 
>   -- Bruce
> 

Duh!?

I had done it in the past and understood!

Getting order, brain cells seem to be dying very quickly.

Thanks and sorry for the noise.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] LLVM-3.7.0 typo?

[Fernando de Oliveira]

Consider the instructions:

{{{
install -v -dm755 /usr/lib/clang-analyzer &&

for prog in scan-build scan-view
do
  cp -rfv ../tools/clang/tools/$prog /usr/lib/clang-analyzer/
  ln -sfv ../lib/clang-analyzer/$prog/$prog /usr/bin/
done
}}}

I can't understand the line:

ln -sfv ../lib/clang-analyzer/$prog/$prog /usr/bin/

Why the double $prog/$prog?

My first impression is that it is a typo, but I've been using it like
that, apparently it is working?

It comes from r11334 ()


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] Strange (Was: Firefox needs gconf)

[Fernando de Oliveira]

Em 05-10-2015 17:17, Tim Tassonis escreveu:
> On 10/05/15 21:49, Pierre Labastie wrote:
>> Hi,
>>
>> When upgrading to Firefox 41.0, the build failed with:
>> ---
>> configure: error: * * * Could not find gconf-2.0
>> ---
>> Actually, the behavior has changed for FF 41, see:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1167201
>>
>> There are two possibilities:
>> a) Add --disable-gconf to mozconfig
>> b) Make gconf a recommended dependency
>>
>> Thoughts?
> 
> 
> Same goes for thunderbird, btw. Has been mentioned by several people
> before, but strangely still didn't make it into the book.
> 

First, I didn't do the update, but I defend who did it.

Tim, we are not perfect, who did the update probably was expecting me to
do it and didn't took note of the problem.

The only strange thing is your use of "strange"; Unfortunately, or no
adverb at all would have been nore fortunate use of words.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] Firefox needs gconf

[Fernando de Oliveira]

Em 05-10-2015 17:27, Bruce Dubbs escreveu:
> Pierre Labastie wrote:
>> Hi,
>>
>> When upgrading to Firefox 41.0, the build failed with:
>> ---
>> configure: error: * * * Could not find gconf-2.0
>> ---
>> Actually, the behavior has changed for FF 41, see:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1167201
>>
>> There are two possibilities:
>> a) Add --disable-gconf to mozconfig
>> b) Make gconf a recommended dependency
> 
> The definition we use for gconf is : contains a configuration database
> system used by many GNOME applications.
> 
> Does FF need that?  I suspect not.  My reaction is to put gconf into the
> optional dependencies and use --disable-gconf in the mozconfig file.
> 
> Has FF been tested without gconf?

I don't think it is going to help us in any way. I have gconf, always,
because update gnome.

I vote for option a).

As you often say, Bruce, we are in -dev. Cam't believe that firefox
would become or remain definitely dependent as required on gconf2.

BTW, wherever does the modification, it ould be done in the three: FF,
TB, SM

And please, remove from mosconfig libnotify.

What to do with libnotify in the dependencies, remains to be decided,
for the three, All indicatess until now it is broken, but if not, woulf
be optional, runtime.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] MPlayer 1.2 released

[Fernando de Oliveira]

Em 04-10-2015 08:05, Aleksandar Kuktin escreveu:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
>> On Sun, 4 Oct 2015 06:38:05 -0300
>> Fernando de Oliveira <fam...@yahoo.com.br> wrote:
>>
>> I'm posting just to inform, because don't think we want to change what
>> we are doing updating for each BLFS release. The release jokes with
>> those who were using previous release:
>>
>> * you aren't using a 3 years old release, hopefully*
>>
>> *If you are, read on and find out what you missed!*
> 
> Have they fixed that part where a file that is being downloaded can not
> be played continuously?
> 
> In previous versions of MPlayer, if you have the start of a file
> downloaded, you could start playing it, and as the new data was being
> downloaded, the playback would continue through the area that didn't
> exist when it started. Then, about 3 years ago, that feature went away
> so now you have to restart the playback when you consume the part of
> the file that existed when you started playing. If they brought it back, all 
> will be forgiven.

Sorry, I don't know the answer.


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] MPlayer 1.2 released

[Fernando de Oliveira]

I'm posting just to inform, because don't think we want to change what
we are doing updating for each BLFS release. The release jokes with
those who were using previous release:

* you aren't using a 3 years old release, hopefully*

*If you are, read on and find out what you missed!*


{{{
News
2015-10-03, Saturday :: MPlayer 1.2 released
posted by the release team

FrameCounter

Our latest release was getting stale, so it's time to make a new one.

Mplayer 1.2 is compatible with the recent FFmpeg 2.8 release. The
tarball already includes a copy of FFmpeg, so you don't need to fetch it
separately.
Due to some big API changes coming to FFmpeg, this release will not work
with new FFmpeg master branch, nor with future FFmpeg releases.

If you want to follow the latest improvements in MPlayer and FFmpeg, you
are strongly encouraged to use Subversion HEAD and benefit from the
latest features and bug fixes.
You know how to do it. Because you aren't using a 3 years old release,
hopefully. If you are, read on and find out what you missed!

...

}}}


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] libnotify-0.7.6 in Seamonkey, Thunderbird and Firefox

[Fernando de Oliveira]

Em 30-09-2015 19:46, Fernando de Oliveira escreveu:
> Em 30-09-2015 14:58, Bruce Dubbs escreveu:
>> Fernando de Oliveira wrote:
>>> This is bothering me for years, perhaps. Have asked long ago, no reply.
>>>
>>> It is always there in the pages and scripts. It does nothing, for me, at
>>> runtime. Or does it?
>>
>> I really don't know what it does here.
> 
> Many things: when it worked, it notified when a restart was needed due
> to an extension update, when a download had finished, and with the right
> extensions, when a ne mail arrived. It was done with the same
> notification system that tels you if a connection is up or down, with
> Network Manager. And the notifications were kept one below the other
> until libnotify changed and the notifications were ket as an ivon in the
> panel notification area.
> 
> Just discovered that there is an extension that makes it work back with
> libnotify, but have not tested and don't know if works with latest firefox:
> 
> http://www.omgubuntu.co.uk/2014/02/g-notifier-firefox-ubuntu-notification-bubbles
> 
> I am finally building firefox-41.0 (got courage, today) building new FF
> (several days without building anything), last update was on September
> 13th, 2015.
> 
>> In SM, grepping through my build
>> directory I see:
>>
>> mailnews/base/src/nsMessengerUnixIntegration.cpp:
>>
>> // determine if we should use libnotify or the built-in alert system
>>
>> Reading more comments there indicate that there should be an indication
>> of new mail in the system tray.  I don't know if it is used in FF or not.
>>
>>> I don't know enough to completely understand this code, worse yet the
>>> entire file, but it seems to me this is a left over code.
>>
>> Me either.  AFAIK, the build doesn't complain if
>>
>> ac_add_options --disable-libnotify
>>
>> is in mozconfig, so I would prefer to leave it.
>>
>>> These results seem to demonstrate that from the three mozconfigs
>>> libnotify can be removed.
>>>
>>> I am not 100% sure if it can be remove from the dependencies.
>>>
>>> Please, some opinions? Should it be completely removed?
>>
>> Not before release, but have you tried to build SM without
>> --disable-libnotify and with libnotifyso removed?
>>
>>   -- Bruce
>>
>>
> 
> 
> I was almost sure that libnotify could be removed from all of the three:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=853104#c8
> 
> {{{
>> William Chen [:wchen] 2013-03-27 17:28:24 PDT
>>
>> (In reply to Alex Keybl [:akeybl] from comment #5)
>>> wchen - can you confirm comment 4, and move this into the TB product
>>> if we can't make core changes to support them in FF22?
>>
>> I can confirm that removing libnotify was intentional. It is important
>> that notifications work on all platforms, not just the ones that had
>> libnotify installed. In addition, not all libnotify implementations
>> support necessary features to implement the updated alerts service API
>> (being able to click and close them).
>>
>> (In reply to Alex Keybl [:akeybl] from comment #7)
>>> I'm trying to understand whether bug 782211 was landed assuming
>>> resolution of bug 852648 and bug 852917 in FF22, or whether
>>> engineering was hoping TB would make a comm-specific backout and
>>> diverge from Firefox.
>>
>> The idea was to use the XUL notifications and add back support for
>> native notifications if they could support the updated alerts service
>> API. There was no intent for a comm backout.
> }}}
> 
> But this long thread
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=858919
> 
> Reported: 2013-04-06 05:53 PDT by Stephan Sokolow
> Modified: 2015-07-20 15:27 PDT
> 
> made me confuse again.
> 
s/confuse/confused/


I've been reading about this.

I have

$ ls mozillas/
comm-esr38  comm-release  mozilla-release

The use of libnotify is defined in TB and SM for email and news by the
preference variable "mail.biff.use_system_alert".

There are 6 references to system_alert:

$ grep -r system_alert
comm-esr38/mailnews/base/src/nsMessengerUnixIntegration.cpp:#define
SHOW_ALERT_SYSTEM  "mail.biff.use_system_alert"
comm-esr38/mailnews/mailnews.js:pref("mail.biff.use_system_alert", false);
comm-esr38/mail/test/mozmill/notification/test-notification.js:
remember_and_set_bool_pref("mail.biff.use_system_alert", true);
comm-release/mailnews/base/src/nsMessengerUnixIntegration.cpp:#define
SHOW_ALERT_SYSTEM  "mail.biff.use_system_alert"
comm-release/mailn

[blfs-dev] Status

[Fernando de Oliveira]

Bad.

I really got depressed last month with so many things that I forget
which ones. Well, just remembered Doulgas, systemd and you, think these
were the start.

I fought a lot to no get depressed, baut more things happened, even
yesterday.

I am trying each day to get one more hour of work, but it is hard.

Got first back up, not for the system, but at least for docs, mail and
blfs stuff perhaps in a month, today.

Each day I promess that will start building 7.8, but never do.

I'm really sorry.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] libnotify-0.7.6 in Seamonkey, Thunderbird and Firefox

[Fernando de Oliveira]

Em 02-10-2015 14:54, Bruce Dubbs escreveu:
> Fernando de Oliveira wrote:
> 
>>  From the options in mozconfig, all are in configure --help (firefox),
>> except libnotify. Not present in the other configure --help (SM, TB).
>>
>> It does not appear in about:buildconfig (FF, SM, TB).
>>
>> It shouldn't be in an mozconfig of the book.
>>
>> It should be stated that support for it is broken.
>>
>> I won't do that, because it is complicated to decide. But would sugest
>> it should be done in svn, and soon someone would manifest if there is a
>> problem.
> 
> I have not done the research you have, but trust yours.  I'm OK with
> removing libnotify from mozilla apps.  Why don't you want to do it after
> we agree?

I am sure about the mozconfig part, but not about the dependency.

Did two tests:

In TB, there is

mail.biff.use_system_alert;false

If true, it does not open a libnotify alert, and does not open its own,
nothing, just the sound.

I SM, I don't use mail, but tried download. To do that, needed a patch
(I still have both patched and normal) installed). The patch is attached
to "Bug 1152644 - Add UI in Notifications preference pane whether or not
to use libnotify for new-mail alerts on Linux":

https://bug1152644.bmoattachments.org/attachment.cgi?id=8665659

First problem, needs to use SM in en-US. It would be easy, extend to
other language in particular. But the window to use for setting the
options: Edit -> Preferences -> Mail and News Groups -> Notifications
will be blank with the patch, if not deactivating language packages.

It includes two dialogue options in that window, to select built-in or
system's notification.

Tested with Download. Therw was the download, ate the end a window
opened as in the old days of FF, but no libnotify type alert.

Have two big doubts:

1. Is it right to say that it is broken?

2. Is it right to say that it is runtime (if/when not broken)?

3. Am I doing something wrong, is it working?

I really liked those libnotify messages in FF, SM, TB.

But to answer your questions:

I am not sure about points 1. to 3.

Remove libnotify, leave telling currently broken, leave telling runtime
currently broken? There is that addon for FF to make it work, but it
does not matter for us, it is not in our FF.

Only thing I'm 100% sure: we can remove from the 3 mozconfigs. Hope I am
not wrong here.

Would like other mind(s) investigation(s). It is bothering me for years,
I would prefer to be completely wrong and make it work back again.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] Status

[Fernando de Oliveira]

Sorry, it was supposed to be private to Bruce.

Please, ignore.

-- 
[]s,
Fernando, aka Sísifo

-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] libnotify-0.7.6 in Seamonkey, Thunderbird and Firefox

[Fernando de Oliveira]

This is bothering me for years, perhaps. Have asked long ago, no reply.

It is always there in the pages and scripts. It does nothing, for me, at
runtime. Or does it?

I'm almost 100% sure that SM, TB and FF do not use libnotify, because
there were times in which I I had a notification with the same
configurations (color, position) as the ones for notify send:

notify-send Test "Hello World"

I've found some references out of "testing" directory to libnotify.so.4
and libnotify.so.1 in comments, but outside that, only the following
files (out of "testing" directory) refer to it:

{{{
[ /tmp/seamonkey-2.38/comm-release ]$ grep --exclude-dir testing -rl
libnotif
mozilla/python/mozboot/mozboot/debian.py
mozilla/webapprt/gtk/webapprt.cpp
mozilla/toolkit/system/gnome/nsAlertsIconListener.cpp
mozilla/toolkit/system/gnome/nsAlertsIconListener.h
mailnews/base/src/nsMessengerUnixIntegration.cpp
mail/components/activity/modules/alertHook.js

fernando [ /tmp/thunderbird-38.3.0/comm-esr38 ]$ grep --exclude-dir
testing -rl libnotif
mozilla/python/mozboot/mozboot/debian.py
mozilla/webapprt/gtk/webapprt.cpp
mozilla/toolkit/system/gnome/nsAlertsIconListener.cpp
mozilla/toolkit/system/gnome/nsAlertsIconListener.h
mailnews/base/src/nsMessengerUnixIntegration.cpp
mail/components/activity/modules/alertHook.js

fernando [ /tmp/firefox-41.0/mozilla-release ]$ grep --exclude-dir
testing -rl libnotif
python/mozboot/mozboot/debian.py
webapprt/gtk/webapprt.cpp
toolkit/system/gnome/nsAlertsIconListener.cpp
toolkit/system/gnome/nsAlertsIconListener.h
}}}

I have difficulty believing that those applications in gnome would
benefit from libnotify. Suspect those are left-overs needed to be
cleaned up.

In FF, webapprt/gtk/webapprt.cp, for example:

{{{
  char uninstallMsg[MAXPATHLEN];
  if (NS_SUCCEEDED(parser.GetString("Webapp", "UninstallMsg",
uninstallMsg, MAXPATHLEN))) {
/**
 * The only difference between libnotify.so.4 and libnotify.so.1 for
these symbols
 * is that notify_notification_new takes three arguments in
libnotify.so.4 and
 * four in libnotify.so.1.
 * Passing the fourth argument as nullptr is binary compatible.
 */
typedef void  (*notify_init_t)(const char*);
typedef void* (*notify_notification_new_t)(const char*, const char*,
const char*, const char*);
typedef void  (*notify_notification_show_t)(void*, void**);

void *handle = dlopen("libnotify.so.4", RTLD_LAZY);
if (!handle) {
  handle = dlopen("libnotify.so.1", RTLD_LAZY);
  if (!handle)
return;
}
}}}

I don't know enough to completely understand this code, worse yet the
entire file, but it seems to me this is a left over code.

Then, I searched in the configure* files:

{{{
# ls firefox-41.0/ seamonkey-2.38/ thunderbird-38.3.0/
firefox-41.0/:
mozilla-release

seamonkey-2.38/:
comm-release

thunderbird-38.3.0/:
comm-esr38
}}}

Just  to show that SM, TB and FF source code are in the directory where
I searched before and will search below.

{{{
root [ /tmp ]# find -type f -name configure\* -exec grep notify-send \{} \;
root [ /tmp ]# find -type f -name configure\* -exec grep libnotify \{} \;
}}}

No reference to libnotify. I also searcched in the millions of
mozconfigs inside the directories: nada (this is in my native language).

{{{
root [ /tmp ]# find -type f -name configure\* -exec grep
libstartup-notification \{} \; | wc -l
21
}}}

This is to show what happens when something is tested by configure.


These results seem to demonstrate that from the three mozconfigs
libnotify can be removed.

I am not 100% sure if it can be remove from the dependencies.

Please, some opinions? Should it be completely removed?


-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] ... r16492 - in trunk/BOOK: . introduction/welcome networking/netprogs xsoft/other

[Fernando de Oliveira]

Em 30-09-2015 17:46, bdu...@higgs.linuxfromscratch.org escreveu:
> Author: bdubbs
> Date: Wed Sep 30 13:46:13 2015
> New Revision: 16492
> 
> Log:
> Update to wpa_supplicant-2.5.
> Update to thunderbird-38.3.0.

Thank you for these!!!


-- 
[]s,
Fernando, aka Sísifo
-- 
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 tagging is finished

[Fernando de Oliveira]

Bruce,

I asked this privately, but I am sure you lost in the multitude of
things you are doing.

I would like to thank Denis Mugnier for his many contributions with the
"Short Descriptions", which I consider a good improvement in BLFS.

I don't know if in the release announcement there is a place mentioning
this improvement.

But I believe we all are grateful to Denis by his constant work.

-- 
[]s,
Fernando, aka Sísifo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page