Re: [blfs-dev] : Add package: lsof_4.87
Date: Tue, 14 Jan 2014 01:08:20 + From: Ken Moffat zarniwh...@ntlworld.com To: BLFS Development List blfs-dev@linuxfromscratch.org Subject: Re: [blfs-dev] : Add package: lsof_4.87 . . [...] and then replying to a thread elsewhere by people who are well-intentioned but don't have the item being discussed :) D'you have lsof - the item being discussed here ? ;) (You said you don't build it; or have you for the purposes of this thread done a test-build (doesn't sound like it) or using an installed distro (doesn't sound like it) ? ) ;) (Jus' jesting, ??en), take care, akhiezer -- -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] : Add package: lsof_4.87
Date: Mon, 13 Jan 2014 21:33:21 -0300
From: Fernando de Oliveira fam...@yahoo.com.br
To: BLFS Development List blfs-dev@linuxfromscratch.org
Subject: Re: [blfs-dev] : Add package: lsof_4.87
.
.
In a terminal where I first used when it was installed at /usr/sbin/,
when tried using again, after installing now in /usr/bin, it complained
that there was no /usr/sbin/lsof/, weird.
Might that be due to shell hashing remembering paths for previously-given
commands (cf e.g. bash's 'set +h').
Anyway, there seems to be very heavy weather being made of lsof. Really, the
build shown at:
ftp://ftp.slackware.com/pub/slackware/slackware64-14.1/source/ap/lsof/lsof.SlackBuild
is the way to go; with perhaps adding in some blfs-specific library
cmdline-flag stuff (re libtirpc c?) at one of the stages per
Bruce/Fernando post early in thread.
Note in particular - as noted early in thread:
* the 'echo n | ...' part: that adjusts 'machine.h' appropriately.
(Don't let the nomenclature in the adjusted part of 'machine.h', frighten
the horses: it just means that you're letting the OS handle
accesses/security, rather than lsof try to do (parts of) it.)
* the # No, NOT suid. part.
That, as said, lets the OS handle permissions, accesses, c: root can do all
the usual root things; and non-root can do, and is restricted to, the usual
range of non-root things. Period. You don't need to do anything else, e.g. to
'head off' non-root users from '/run', or bother about perfectly-normal
'permission denied' output, or stash lsof away into an 'sbin' dir rather than
a 'bin' dir ('security through obscurity'?), usw: the OS permissions c
system is handling/addressing all that kind of stuff, in the usual way.
As for install-location: fwiw, am agnostic here on the matter of /bin -vs-
/usr/bin; tho', also fwiw, have never 'needed' to use lsof when it wasn't
avail (e.g. in single-user mode or otherwise without /usr ). As noted, though:
put it in /bin or /usr/bin : don't try to 'hide' away in /sbin or /usr/sbin -
not least as it's a perfectly reasonable command for non-root users to use
without having to go find it in and sbin dir.
Finally, yes the documentation perhaps can seem a bit
vague/crufty/inconsistent/c in parts; but the source is pretty simple and
clear - it's not a complex piece of software. And especially if something
says, install me with extra privileges (e.g set*id): default position should
be 'no', unless strong, known, understood, considered reason to the contrary.
rgds,
akh
--
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] Util-linux
I found out that util-linux and udev have a circular dependency. What we do now is OK, but there are some things disabled. What we need to do is add util-linux-pass2 after udev. What I'm thinking about doing is move the current full install to be after udev and replace the current page with only: ./configure make make install The tests can be done in the 2nd pass and adjustment of the path to adjtime is only in the man pages, rtcwake, and hwclock. All these would be updated after the 2nd install. Does this seem like a reasonable approach? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] libidn and dev note[Was: ... r12578 - trunk/BOOK/networking/netutils ]
Em 14-01-2014 20:15, i...@higgs.linuxfromscratch.org escreveu: Author: igor Date: Tue Jan 14 15:15:06 2014 New Revision: 12578 Log: whois can use libidn Modified: trunk/BOOK/networking/netutils/whois.xml Modified: trunk/BOOK/networking/netutils/whois.xml == --- trunk/BOOK/networking/netutils/whois.xml Tue Jan 14 13:14:02 2014 (r12577) +++ trunk/BOOK/networking/netutils/whois.xml Tue Jan 14 15:15:06 2014 (r12578) @@ -60,6 +60,13 @@ ... +bridgehead renderas=sect3Whois Dependencies/bridgehead + +bridgehead renderas=sect4Optional/bridgehead +para role=optional + xref linkend=libidn/ +/para + First, I have doubt if it would be better to use this as recommended and add to the instructions, after second further below. ... +!-- dev note: make BASEDIR=DESTDIR prefix=/usr install-whois -- + I need to remember to leave these. Second time I notice you doing it. (I am also trying to add things to the pages to help development.) Very good. Thanks. ... + sect2 role=commands +titleCommand Explanations/title + +para + optionHAVE_LIBIDN=1/option: This make variable adds internationalized + string handling support to commandwhois/command. +/para + + /sect2 + Second: I noticed this in the previous update I did, thought a little, tried with and without. I do not remember if I read something about it or not. Should have asked before. The point (or the dumb question, forgive me for not knowing much about this) is: although it is easy to see whois is linked to libidn, I cannot notice any difference with or without. Would you an example, please? With an example, I would come to first above: being useful, should it not be recommended? $ ldd /usr/bin/whois | grep libidn libidn.so.11 = /usr/lib/libidn.so.11 (0xb76f1000) $ scanelf -F %f: %n /usr/bin/whois FILE NEEDED whois: libidn.so.11,libc.so.6 $ diff whois-google.com-before-idn.log whois-google.com-after-idn.log 266c266 Last update of whois database: Wed, 15 Jan 2014 00:15:54 UTC --- Last update of whois database: Wed, 15 Jan 2014 00:20:27 UTC -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libidn and dev note
On 1/14/2014 6:41 PM, Fernando de Oliveira wrote: The point (or the dumb question, forgive me for not knowing much about this) is: although it is easy to see whois is linked to libidn, I cannot notice any difference with or without. Would you an example, please? With an example, I would come to first above: being useful, should it not be recommended? I am of the opinion that the recommended dependencies are being used too often in recent updates to the book. Recommended used to be something that was used to indicate that future builds against the package would fail if the recommended package was not installed. Now it seems that if a package can use a dependency and that dependency provides something useful it is recommended. Why? Can't it be like it used to and just annotate it in the optional dependencies? If it really provides something useful, simply add the parameter in the command explanations with the explanatory text saying that adding it will provide xyz support to the package. I appreciate the work that you do for the book, Fernando, but I think that you need to let users decide for themselves what they need in each package. The Command Explanations section is used to provide information for users to decide if they need to install a package and add the necessary parameters to the configure command. My point being, let the users decide what they want. Recommended dependencies should be something that (well, this was just discussed in a previous thread) avoids failure in the future. For example, years and years ago, Gimp-Print was added as a recommended dependency to the Gimp instructions because the editor felt that you needed to print some image. I objected then and still feel the same way. A simple entry into the Command Explanations lets users know that if they don't install an optional dependency, then functionality will be lost. Let them decide. I hope this makes sense. I feel the users should be the ones that make decisions for their systems. Not BLFS developers. Additionally, making the users decide what they need (functionality-wise) is much better than developers blindly recommending packages because they feel users need it. JMHO -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r12580 - in trunk/BOOK: introduction/welcome xfce/apps
On 01/15/2014 04:38 AM, ferna...@higgs.linuxfromscratch.org wrote: Author: fernando Date: Tue Jan 14 19:38:24 2014 New Revision: 12580 Log: Move libzeitgeist to optional dependency in Midori-0.5.6. Thanks, Randy M. Modified: trunk/BOOK/introduction/welcome/changelog.xml trunk/BOOK/xfce/apps/midori.xml Modified: trunk/BOOK/introduction/welcome/changelog.xml == --- trunk/BOOK/introduction/welcome/changelog.xml Tue Jan 14 19:26:32 2014(r12579) +++ trunk/BOOK/introduction/welcome/changelog.xml Tue Jan 14 19:38:24 2014(r12580) @@ -47,6 +47,10 @@ paraJanuary 14th, 2014/para itemizedlist listitem + para[fernando] - Move libzeitgeist to optional dependency in + Midori-0.5.6. Thanks, Randy M./para +/listitem +listitem para[fernando] - Move optional switches to 'Command Explanations' in Sudo-1.8.9p3 and Audacious-3.4.3. Thanks, Randy M./para /listitem Modified: trunk/BOOK/xfce/apps/midori.xml == --- trunk/BOOK/xfce/apps/midori.xml Tue Jan 14 19:26:32 2014(r12579) +++ trunk/BOOK/xfce/apps/midori.xml Tue Jan 14 19:38:24 2014(r12580) @@ -77,20 +77,20 @@ para role=required xref linkend=cmake/, xref linkend=webkitgtk/ or - xref linkend=webkitgtk2/ and + xref linkend=webkitgtk2/, and xref linkend=vala/ /para bridgehead renderas=sect4Recommended/bridgehead para role=recommended - xref linkend=libnotify/, - xref linkend=librsvg/ and - xref linkend=libzeitgeist/ + xref linkend=libnotify/ and + xref linkend=librsvg/ /para bridgehead renderas=sect4Optional/bridgehead para role=optional - xref linkend=gtk-doc/ and + xref linkend=gtk-doc/, + xref linkend=libzeitgeist/, and xref linkend=libunique/ or ulink url=gnome-download-http;/libunique/libunique (3.x)/ulink /para This was rather valid. Recommended dependencies are the ones that need a switch to disable and shouldn't be disabled explicitly unless the dependency isn't present in BLFS. As a side note, midori no longer requires libunique in any way. -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r12580 - in trunk/BOOK: introduction/welcome xfce/apps
Em 15-01-2014 00:47, Armin K. escreveu: This was rather valid. Recommended dependencies are the ones that need a switch to disable and shouldn't be disabled explicitly unless the dependency isn't present in BLFS. As a side note, midori no longer requires libunique in any way. Yes, Thanks. Why those two info were missing in the ticket that you created and I accepted, only narcissus knows. Meanwhile, libunique stays there... -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] libidn and dev note[Was: ... r12578 - trunk/BOOK/networking/netutils ]
On 01/15/2014 01:41 AM, Fernando de Oliveira wrote: The point (or the dumb question, forgive me for not knowing much about this) is: although it is easy to see whois is linked to libidn, I cannot notice any difference with or without. Would you an example, please? With an example, I would come to first above: being useful, should it not be recommended? $ ldd /usr/bin/whois | grep libidn libidn.so.11 = /usr/lib/libidn.so.11 (0xb76f1000) $ scanelf -F %f: %n /usr/bin/whois FILE NEEDED whois: libidn.so.11,libc.so.6 $ diff whois-google.com-before-idn.log whois-google.com-after-idn.log 266c266 Last update of whois database: Wed, 15 Jan 2014 00:15:54 UTC --- Last update of whois database: Wed, 15 Jan 2014 00:20:27 UTC For example: whois кыргызстан.icom.museum without libidn gives: % The selected character encoding US-ASCII is not able to represent And with libidn: % Object xn--80afmksoji0fc.icom.museum NOT FOUND. -- LEGO won't be ready for the average user until it comes pre-assembled, in a single unified look, and glued together so it doesn't come apart. -- Iranon -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
