Re: [blfs-dev] BLFS tagging is finished

[Bruce Dubbs]

Pierre Labastie wrote:

On 29/09/2015 20:43, Bruce Dubbs wrote:

OK, tagging is finally finished and all tickets for 7.8 are closed.

Let's take a day to review and fix up any outstanding issues.  If anyone knows
of something else that needs to be fixed, please speak up here.

If nothing comes up, I plan on releasing LFS-7.8 and BLFS-7.8 stable versions
on Thursday, October 1st.



I do not know whether KF5-intro is correct in the /usr part, and also, it
seems to me that there is some redundancy in the parts added to
/etc/profile.d/qt5.sh and /etc/profiles.d/kf5.sh (in the /opt/kf5 case).
Problem is: there are 4 cases:
- Qt5 in /usr, Kf5 in /usr
- Qt5 in /usr, Kf5 in /opt
- Qt5 in /opt, Kf5 in /usr
- Qt5 in /opt, Kf5 in /opt, which, although not recommended (only thelast one
is), are all possible according to the book. I am not sure all cases are 
covered.


In reviewing the /usr install setuup for kf5,  all the pathappend 
statements depend on the location of qt5.  We do have a note in the qt5 
section about installing in /usr/bin/qt5 and similar qt5 subdirectories 
of other system directories.


This is my analysis:

If qt5 is in /usr/bin/qt5 (and similar), then we need

pathappend /usr/lib/qt5/plugins QT_PLUGIN_PATH

If it is in /opt, then we need:

pathappend /opt/qt5/plugins QT_PLUGIN_PATH

Actually, the script should be appended to /etc/profile.d/qt5.sh, not 
/etc/profile.d/kf5.sh.



cat >> /etc/profile.d/qt5.sh << "EOF"
# Begin Qt5 changes for KF5

# Assuming $QT5DIR == '/usr'

pathappend /usr/lib/qt5/plugins QT_PLUGIN_PATH
pathappend /usr/lib/qt5/qml QML_IMPORT_PATH
pathappend /usr/lib/qt5/qml QML2_IMPORT_PATH

# End Qt5 changes for KF5
EOF

We also need to add

pathappend /usr/bin/qt5 PATH

to the qt5.sh in the qt5 section of the book.


Does this look right to you?

  -- Bruce

--
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] libnotify-0.7.6 in Seamonkey, Thunderbird and Firefox

[Bruce Dubbs]

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.  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


--
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

[Bruce Dubbs]

Pierre Labastie wrote:


I just got an error building frameworks:
in kdoctools-5.14.0:
-
-- Could NOT find PerlModules_URI::Escape (missing:
PerlModules_URI_Escape_FOUND)



we have URI-1.69 in perl modules (which contains URI/Escape), but I do not see
it in dependencies.


Confirmed.  Updated dependencies at revision 16491.

Also commented out baloo.

  -- Bruce


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

Re: [blfs-dev] ... 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

[Bruce Dubbs]

Fernando de Oliveira wrote:

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.


Thanks for the reminder.  I will add him to the release announcement.

  -- Bruce

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

Re: [blfs-dev] BLFS 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

Re: [blfs-dev] BLFS tagging is finished

[Pierre Labastie]

On 30/09/2015 19:18, Bruce Dubbs wrote:
> Pierre Labastie wrote:
>> On 29/09/2015 20:43, Bruce Dubbs wrote:
>>> OK, tagging is finally finished and all tickets for 7.8 are closed.
>>>
>>> Let's take a day to review and fix up any outstanding issues.  If anyone 
>>> knows
>>> of something else that needs to be fixed, please speak up here.
>>>
>>> If nothing comes up, I plan on releasing LFS-7.8 and BLFS-7.8 stable 
>>> versions
>>> on Thursday, October 1st.
>>>
>>
>> I do not know whether KF5-intro is correct in the /usr part, and also, it
>> seems to me that there is some redundancy in the parts added to
>> /etc/profile.d/qt5.sh and /etc/profiles.d/kf5.sh (in the /opt/kf5 case).
>> Problem is: there are 4 cases:
>> - Qt5 in /usr, Kf5 in /usr
>> - Qt5 in /usr, Kf5 in /opt
>> - Qt5 in /opt, Kf5 in /usr
>> - Qt5 in /opt, Kf5 in /opt, which, although not recommended (only thelast one
>> is), are all possible according to the book. I am not sure all cases are
>> covered.
> 
> In reviewing the /usr install setuup for kf5,  all the pathappend statements
> depend on the location of qt5.  We do have a note in the qt5 section about
> installing in /usr/bin/qt5 and similar qt5 subdirectories of other system
> directories.
> 
> This is my analysis:
> 
> If qt5 is in /usr/bin/qt5 (and similar), then we need
> 
> pathappend /usr/lib/qt5/plugins QT_PLUGIN_PATH
> 
> If it is in /opt, then we need:
> 
> pathappend /opt/qt5/plugins QT_PLUGIN_PATH
> 
> Actually, the script should be appended to /etc/profile.d/qt5.sh, not
> /etc/profile.d/kf5.sh.
> 
> 
> cat >> /etc/profile.d/qt5.sh << "EOF"
> # Begin Qt5 changes for KF5
> 
> # Assuming $QT5DIR == '/usr'
> 
> pathappend /usr/lib/qt5/plugins QT_PLUGIN_PATH
> pathappend /usr/lib/qt5/qml QML_IMPORT_PATH
> pathappend /usr/lib/qt5/qml QML2_IMPORT_PATH
> 
> # End Qt5 changes for KF5
> EOF
> 
> We also need to add
> 
> pathappend /usr/bin/qt5 PATH
> 
> to the qt5.sh in the qt5 section of the book.
> 
> 
> Does this look right to you?
> 
>   -- Bruce
> 

I think I would need to test. I guess it would be OK, though. The only test I
have done is : KF5 in /usr, Qt5 in /opt. Then I used:
--
cat > /etc/profile.d/kf5.sh << "EOF"
# Begin /etc/profile.d/kf5.sh

. /etc/profile.d/qt5.sh

export KF5_PREFIX=/usr

pathappend /usr/lib/qt5/plugins  QT_PLUGIN_PATH
pathappend $QT5DIR/plugins   QT_PLUGIN_PATH

pathappend /usr/lib/qt5/qml  QML_IMPORT_PATH
pathappend $QT5DIR/qml   QML_IMPORT_PATH

pathappend /usr/lib/qt5/qml  QML2_IMPORT_PATH
pathappend $QT5DIR/qml   QML2_IMPORT_PATH

# End /etc/profile.d/kf5.sh
EOF

and Qt5.sh as per the Qt5 page instructions. I could build (not tested yet,
still have to build a wm) LXQt with this setup.

Now, I think it'd be better to have everything in qt5.sh, except the
KF5_PREFIX part.

I think that's all I can say before release...
Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] BLFS tagging is finished

[Pierre Labastie]

On 30/09/2015 05:50, Bruce Dubbs wrote:

Pierre Labastie wrote:

I just got an error building frameworks:
in kdoctools-5.14.0:
-

/usr/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:148 
(message):

   Could NOT find PerlModules (missing: PerlModules_all_modules_found
   URI::Escape)

-

we have URI-1.69 in perl modules (which contains URI/Escape), but I 
do not see

it in dependencies.

It is late here. I'll tell you more tomorrow.


Yes, Having URI allows kdoctools to build.

But I found also that the LMDB dependency has not been addressed (see 
http://lists.linuxfromscratch.org/pipermail/blfs-dev/2015-September/031151.html). 
It's required for baloo-kf5 and we do not have it in the book. I do not 
know about the xcb-... packages mentionned in the thread.


I do not know what uses baloo-kf5 in the book, now that plasma has been 
removed. Maybe, just comment out baloo?


Pierre

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

[blfs-dev] LXQt power actions are called through DBus (was [Lxde-list] LXQt poweroff is too hard)

[Fernando de Oliveira]

I sent this which confirms some recent modifications were correct.


 Mensagem encaminhada 
Assunto: Re: [Lxde-list] LXQt poweroff is too hard
Data: Wed, 30 Sep 2015 09:18:34 -0300
De: Paulo Lieuthier 
Para: Stanislav Baiduzhyi 
CC: lxde-l...@lists.sourceforge.net

Hi Stanislav,

I don't know how this part of Plasma works, but I know how LXQt does :).
In LXQt power actions (shutdown, reboot, logout, hibernate, suspend) are
handled by an independent provider, and it is called through DBus. There
are some available providers that will be triggered if available, in a
priority order. See the list in [1]. As you can see, the systemd
provider is the default one if available (if no custom provider is
available), followed by UPower and ConsoleKit.

That said, I don't what could be the reason for your problem. Please,
fill a bug report so that someone can further investigate that (and
probably take a look at Plasma's source).

Paulo Lieuthier

[1] https://github.com/lxde/liblxqt/blob/master/lxqtpower/lxqtpower.cpp#L41

On 09/23/2015 10:55 AM, Stanislav Baiduzhyi wrote:
> Hi All,
>
> I have a "multimedia" machine, htpc used only to watch films and play
> music via mpd. Recently I've switched that machine from plasma5 to
> lxqt 0.9 (openSUSE 13.2 x86_64). And now occasionally when I'm
> powering off the machine mpd loses its configs. Never happened before
> I moved to lxqt.
>
> What's the difference between poweroff in lxqt and plasma5? What can I
> do to make it little softer?
>


--
___
Lxde-list mailing list
lxde-l...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-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

Re: [blfs-dev] BLFS tagging is finished

[Bruce Dubbs]

Pierre Labastie wrote:


I think I would need to test. I guess it would be OK, though. The only test I
have done is : KF5 in /usr, Qt5 in /opt. Then I used:
--
cat > /etc/profile.d/kf5.sh << "EOF"
# Begin /etc/profile.d/kf5.sh

. /etc/profile.d/qt5.sh

export KF5_PREFIX=/usr

pathappend /usr/lib/qt5/plugins  QT_PLUGIN_PATH
pathappend $QT5DIR/plugins   QT_PLUGIN_PATH

pathappend /usr/lib/qt5/qml  QML_IMPORT_PATH
pathappend $QT5DIR/qml   QML_IMPORT_PATH

pathappend /usr/lib/qt5/qml  QML2_IMPORT_PATH
pathappend $QT5DIR/qml   QML2_IMPORT_PATH

# End /etc/profile.d/kf5.sh
EOF

and Qt5.sh as per the Qt5 page instructions. I could build (not tested yet,
still have to build a wm) LXQt with this setup.

Now, I think it'd be better to have everything in qt5.sh, except the
KF5_PREFIX part.


I made some clarifications.  They should be OK for release, but please 
review.


  -- Bruce


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

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

[Fernando de Oliveira]

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,
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 dependencies

[Fernando de Oliveira]

Em 24-09-2015 13:44, Tim Tassonis escreveu:
> On 09/24/15 17:45, Ken Moffat wrote:
>> On Thu, Sep 24, 2015 at 12:15:25PM +0200, Tim Tassonis wrote:
>>>
>>> Have built and installed it now exactly like that (without system cairo,
>>> disable-gconf and SQLITE_ENABLE_DBSTAT_VTAB in sqlite3). Will report
>>> if I
>>> expierience any crashes.
>>>
>> Well, I've now rebuilt mine without system cairo for 7.8.  Just to
>> make sure that we're all singing from the same sheet - even though
>> I'm no longer telling it to enable system cairo, ldd shows that
>> /usr/lib/firefox-41.0/libxul.so _is_ linked to system cairo.  I
>> assume this is because of libgdk-x11-2.0.so which pulls in
>> libpangocairo and therefore libcairo.
>>
>> And in about:config we're using
>> layers.offmainthread.composiiton.enabled true

Just to be sure, if someone does not find:

The correct is

layers.offmainthreadcomposition.enabled true

No dot in second name, and no double "i".

s/offmainthread.composiiton/offmainthreadcomposition/

Simplest way is right click copy:

layers.offmainthreadcomposition.enabled;true

Gives

name;value

Although, for my personal use, I am testing the oposite:

layers.offmainthreadcomposition.enabled;false

and using system cairo.

Reason: two kinds of checks.

>>
>> Yes ?
> 
> Yes, I just checked, it is set to true (default)
> 
> And, as you say, system cairo is pulled by libxul, despite having left
> out "ac_add_options --enable-system-cairo":
> 
> 
> 
> timtas@coutinho:~$ ldd /opt/firefox/libxul.so  |grep cairo
> libpangocairo-1.0.so.0 => /opt/X11/lib/libpangocairo-1.0.so.0
> (0x7f3554b9d000)
> libcairo.so.2 => /usr/lib/libcairo.so.2 (0x7f3554643000)
> 
> 
> So far, no crash expierienced.
> 
> 
> Kind regards
> Tim
> 
>>
>> ĸen
>>
> 
> 


-- 
[]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] On new build, svn is asking for my password

[Ken Moffat]

On Tue, Sep 29, 2015 at 11:20:14PM -0500, Bruce Dubbs wrote:
> Bruce Dubbs wrote:
> 
> >I think the difference is in either ssh or ssl.  I think there are some
> >ciphers no longer supported.  Try ssh -vv to see some debugging messages.
> >
> >I had the same problem between my normal workstation and my lfs
> >development system.  On my devel system I had to add
> >
> >PubkeyAcceptedKeyTypes +ssh-dss
> >
> >to /etc/ssh/sshd_config.  You may just want to generate new keys.
> 
> I also now have
> 
> PubkeyAcceptedKeyTypes +ssh-dss
> 
> in ~/.ssh/config
> 

Thanks.  While I was tring to sleep it occurred to me that my (old)
key format might have been deprecated.  I've just found the
following in the Arch wiki:

Note: As of August 11, 2015, DSA is deprecated and disabled by
default in OpenSSH 7.0 due to discovered vulnerabilities.

That links to
https://www.archlinux.org/news/openssh-70p1-deprecates-ssh-dss-keys/

I'll need to generate new keys and upload the required part from the
old system.

ĸen
-- 
Il Porcupino Nil Sodomy Est! (if you will excuse my latatian)
  aka "The hedgehog song"
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] On new build, svn is asking for my password

[Ken Moffat]

On Wed, Sep 30, 2015 at 03:58:12PM +0100, Ken Moffat wrote:
> https://www.archlinux.org/news/openssh-70p1-deprecates-ssh-dss-keys/
> 
> I'll need to generate new keys and upload the required part from the
> old system.
> 
I'm connecting again.  I used chroot, bound /dev and /home (should
have also bound /proc. apparently) to save rebooting.  Shame, the
old key was only 10 years old, I thought it would be good for years
more ;-)

BTW - the duplicated posts I received were probably because I
rebooted the new system whilst fetchmail was running.

ĸen
-- 
Il Porcupino Nil Sodomy Est! (if you will excuse my latatian)
  aka "The hedgehog song"
-- 
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

[Bruce Dubbs]

Pierre Labastie wrote:

On 30/09/2015 05:50, Bruce Dubbs wrote:

Pierre Labastie wrote:

I just got an error building frameworks:
in kdoctools-5.14.0:
-

/usr/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:148
(message):
   Could NOT find PerlModules (missing: PerlModules_all_modules_found
   URI::Escape)

-

we have URI-1.69 in perl modules (which contains URI/Escape), but I
do not see
it in dependencies.

It is late here. I'll tell you more tomorrow.


Yes, Having URI allows kdoctools to build.

But I found also that the LMDB dependency has not been addressed (see
http://lists.linuxfromscratch.org/pipermail/blfs-dev/2015-September/031151.html).
It's required for baloo-kf5 and we do not have it in the book. I do not
know about the xcb-... packages mentionned in the thread.

I do not know what uses baloo-kf5 in the book, now that plasma has been
removed. Maybe, just comment out baloo?


Yes, I'll do that.  We only need the kf5 version of baloo for plasma.

  -- Bruce


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