Re: [blfs-dev] shadow 4.1.5 update
Hi, On Sun, 11 Mar 2012, Armin K. wrote: Also, I noticed there is pam_securetty module, and according to that module documentation, it looks for /etc/securetty file to check from which tty's is root user allowed to login. But grepping through book I don't see where is that file created, neither I see it in LFS. Am I missing something? That file should be present if we are going to use pam_securetty or it's useless without it. Reading this I remember having stumbled across that myself a few months ago. Most likely because of some prominent enough warning complaining about /etc/securetty. Just didn't say anything, because before that I intended to have a look what the correct way to deal with it is supposed to be... Uwe -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Variability in build times.
On Tue, 19 Oct 2010, Ken Moffat wrote: So, on the assumption that this variability is a uniprocessor feature, I'll conclude that a lightly loaded desktop can have at least a 15% range of build times. Well, after all, do you really think this is astonishing? On a single core machine just (constantly) moving the mouse can easily (depending on the system) cost a few percent of cpu resources. If consistent build times are a concern I would never have thought about starting X at all. Even on my dual core machine I only have a few console screens (may be running midnight commander) during builds. Its not really a concern with multiple cores (as measurements show), but on a single one it is for sure. Uwe -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Variability in build times.
On Mon, 18 Oct 2010, Ken Moffat wrote: Any thoughts, or alternative suggestions ? Yes, a few: Over the past years I took a look at the build times quite often. Never systematically, but this is what I experienced: Most of the time I'm building a package its because of a new version. I'm using scripts per package close to LFS but package version independant and with optimization and only run few of them in a row, just as much as I prepared packages in advance. As I tend to be impatient, I tail my previous log file of the package currently building quite often to see when the package building right now is expected to be finished. Most of the time the build times are pretty close to the previous attempt, even though I'm building a newer version of that package. So in my case a certain package is usually built the first time after booting the machine and the build times are pretty close even after (minor) version updates. As others already suspected, I would expect latency (like seek times) of the hard drive to have a significant influence on build times and thus times might be influenced by caching as well as by significantly changed fill level of a partition. If thats the case then using an SSD should improve the relyability of build times. I'll run a series of builds of the same package this night (binutils as well for comparison) on a quite fast SSD and report back. If HD turns out not to be the problem: what about those modern processors that overclock some cores automatically? That might easily be influenced by running *something* in the background that keeps yet another core active and prevents the package building core(s) from overclocking... Uwe -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Variability in build times.
On Tue, 19 Oct 2010, Aleksandar Kuktin wrote: On Tue, 19 Oct 2010 01:12:50 +0200 (CEST) Uwe Düffert dueff...@uwe-dueffert.de wrote: If thats the case then using an SSD should improve the relyability of build times. I'll run a series of builds of the same package this night (binutils as well for comparison) on a quite fast SSD and report back. If you'll be comparing with my times, be advised that I changed my mind about binutils and will use glibc in order to minimise caching. The logic being that, since it is bigger, the main memory won't be able to stretch and encompass all the files. Maybe. I stopped testing binutils anyway. All results were very close, just as I was used to it for years. The difference between the slowest and the fastest run was about 0.6% (3m04.095 vs 3m05.282 real time measured by time), no matter what I was doing in the background (console only, 4850e (dual core), only 1 core compiling). I'll run glibc next, but don't expect much difference. May be we should all test abiword, but I don't usually build it and probably quite a lot of its prerequisites neither... Uwe-- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Variability in build times.
On Tue, 19 Oct 2010, Ken Moffat wrote: But, I'm only ever comparing times on the same system, and this package (abiword) was almost at the end of my build, so the amount of '/' used is almost the same (for me, /home is always a separate filesystem - ok, I've probably extended the usage of /var/log - and yes, updating the browser cache involves head movement, but such a large variation ? No, that does not sound reasonable. Does that only happen with abiword or are there other examples (worth mentioning)? With respect, if we *have to* use SSDs then most of us won't be able to edit the book Well, it was just an idea in case HD would be the reason. And even then it would only be needed for build times. So far we do not even have any prove for that. Thats why we a running tests right now... If HD turns out not to be the problem: what about those modern processors that overclock some cores automatically? That might easily be influenced by running *something* in the background that keeps yet another core active and prevents the package building core(s) from overclocking... Modern processors ? Multiple cores ? I'm using single-processors from somewhere between 4 and 5 years ago ;) May be thats the reason: What about throtteling because of high temperature? Or running *something* in the background forcing task switches? Uwe -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Variability in build times.
On Tue, 19 Oct 2010, Uwe Düffert wrote: I stopped testing binutils anyway. All results were very close, just as I was used to it for years. The difference between the slowest and the fastest run was about 0.6% (3m04.095 vs 3m05.282 real time measured by time), no matter what I was doing in the background (console only, 4850e (dual core), only 1 core compiling). I'll run glibc next, but don't expect much difference. May be we should all test abiword, but I don't usually build it and probably quite a lot of its prerequisites neither... Same with glibc here: The difference between the slowest and the fastest run is just 0.3% (16m53.825 vs 16m57.186). Uwe-- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: GNOME_PREFIX and GNOME_CONFIG rough draft
On Sun, 7 Feb 2010, Bruce Dubbs wrote: You must use bash as your shell for the durration of the installation as ZSH is know to interpret the $GNOME_CONFIG s/know/known/ While we are at it: s/durration/duration/ Uwe -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Recommended Dependencies
Hi, I absolutely agree that it should be explained as to why a dependency is regarded as recommended. That information is very valuable to readers. On Sat, 29 Aug 2009, Randy McMurchy wrote: DJ Lucas wrote these words on 08/29/09 11:20 CST: Recommended: Package looses significant functionality without it or (new) causes issues with other packages if omitted. We see the same on all cases except this one. This is where it has always been Editor's Choice. And I'm not a big fan of that one. To me, there is not that much of a difference between those two points of view. The key is _significant_. I do not want to get yet another feature/packages/dependency recommended just be because the editor likes or uses it. Thats just a candidate for optional. However, as you mentioned yourself, there are cases where it is possible to ommit a certain feature/switch/dependency, it will build and run, but it is not useful. Gimp without jpeg support seems to be a quite simple example. There are more tricky ones. In those cases I want people knowing the package better than me (a.k.a editors ;-]) to recommend me what switches/dependencies to use (like I dont see any usecase for compiling Gimp without jpeg support, so if you want Gimp you almost for sure will want jpeg support for it, even if you did not hear about jpeg before). If I know for sure that I will never ever use jpeg, I can just ignore such a recommendation. After all, a recommendation is just a featured option with an explanation of someone claiming to know it better as to why it is recommended. Uwe -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Reasons why Speex 1.2rc1 should be in BLFS 6.4
On Wed, 11 Feb 2009, William Immendorf wrote: My premission needs to be back. ?!? Oh, no. As I am still reading that shit you unfortunately still have too much of it... Don't like blacklisting people at all, but on the other hand I never met someone as observationally challenged as you before. I Even considered answering and blocking that only personally, but that would solve the problem only for me. So: Please STFU. Regards. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Anduin
On Thu, 27 Nov 2008, Matthew Burgess wrote: On Thu, 27 Nov 2008 12:09:29 +, TheOldFellow [EMAIL PROTECTED] wrote: I can't get to anduin! 12 10ge.ten1-1.wdc-sp2-cor-1.peer1.net (216.187.116.253) 153.570 ms I get the same thing, albeit via a ridiculously long route out of our corporate network here. It goes dead after: 28 351 ms 343 ms 370 ms 1ge-gi3-2.sat-8500v-dis-2.peer1.net [216.187.124.190] Same here: 11 160 ms 160 ms 160 ms 10ge-ten1-3.sat-8500v-cor-2.peer1.net [216.187.124.178] 12 163 ms 160 ms 160 ms 216.187.124.218 13 *** Request timed out. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Various issues with the book
3. Will be removing Cairo as recommended, but leaving the note. A note should be enough. Why? I'm sure most people installing Pango do so simply because it's required by GTK+-2. That's what I thought too: starting with version 2.7 gtk2 insisted on finding a cairo-enabled pango. If that is still the case, then recommending cairo for pango seems appropriate to me. A note saying that if you plan on installing GTK+-2, you should install Cairo before Pango, should be enough. Thats fine too. Although it is not marked that way, that is IMHO even more than just a recommendation, it is one with explanation... Uwe -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: gnucash and gnome
Hi, I think what he was implying the required dependencies (especially gtkhtml) will pull in most of Gnome-1.4. Randy's good about investigating the dependencies, so I would install just what you want from the gnucash dependencies listed on the page. Looking at gtkhtml-1.1.7, it requires GConf and GAL. Looking at those respective pages, it seems you'll have a good portion of Gnome installed by the time you're done. Yeah, I think, that is the whole point: when I started to build GnuCash (some years ago), I did (and still do) not want any GNOME (or KDE) stuff other than absolutely neccessary to build GnuCash, but I ended up installing a good portion of GNOME. Before that experience I wouldn't have trusted anyone saying something similar to just install GNOME. Therefore I think it might be useful to put a kind of initial hint to to the BLFS GnuCash site, that the mentioned dependencies will pull in a lot of GNOME stuff... Just because GnuCash is one of those applications many people without a(nother) need for GNOME or KDE would consider to build... Uwe Düffert -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: gnucash and gnome
Okay in that case, do any of you know which libs I have to install and which parts of Gnome-1.4 I don't have to worry about? My last gnucash build is quite old, but that info might help you nevertheless. Yes I saw deps in gnucash's README file. Do the listed dependencies depend on something else? Yes. At first look the dependencies in the README might look complete, but they are not. Besides the packages listed under dependencies the stuff mentioned under Prior to building GnuCash is required, e.g. libxml1 and a gnome developement system. In particular I had to install (not mentioned in current readme): libcapplet, gail, libgnomeui, gnome-keyring, libbonoboui, libgnomecanvas, libart, libglade, GConf, gnome-mime-data, libIDL. It might be possible to configure some of those away and some dependencies may have changed up to now. The attached script will probably give you a hint what is needed to get a particular package to install. But I doubt that you will be able to install everything in one run without a failing dependency with current package versions. Uwe Düffert gnucash: http://www.gnucash.org/pub/gnucash/sources/stable/ guile:ftp://ftp.gnu.org/pub/gnu/guile/ slib: http://swissnet.ai.mit.edu/ftpdir/scm/ gnome-libs: ftp://ftp.gnome.org/pub/GNOME/sources/gnome-libs/1.4/ gnome-print: ftp://ftp.gnome.org/pub/GNOME/sources/gnome-print/0.37/ gdk-pixbuf: ftp://ftp.gnome.org/pub/GNOME/sources/gdk-pixbuf/0.22/ gtkhtml: ftp://ftp.gnome.org/pub/GNOME/sources/gtkhtml/1.10/ guppi:ftp://ftp.gnome.org/pub/GNOME/sources/Guppi/0.40/ libgal: ftp://ftp.gnome.org/pub/GNOME/sources/gal/0.24 openhbci: http://prdownloads.sourceforge.net/openhbci/ g-wrap: http://www.gnucash.org/pub/g-wrap/source/ gail: ftp://ftp.gnome.org/pub/GNOME/sources/gail/1.5/ libxml(1):ftp://ftp.gnome.org/pub/GNOME/sources/libxml/1.8/ libgnomecanvas: http://ftp.gnome.org/pub/GNOME/sources/libgnomecanvas/2.5/ libglade(1): ftp://ftp.gnome.org/pub/GNOME/sources/libglade/0.17/ libgnomeprint: ftp://ftp.gnome.org/pub/GNOME/sources/libgnomeprint/2.5/ libgnomeprintui: ftp://ftp.gnome.org/pub/GNOME/sources/libgnomeprintui/2.5/ libgnomeui:ftp://ftp.gnome.org/pub/gnome/sources/libgnomeui/2.5/ libgnome: ftp://ftp.gnome.org/pub/gnome/sources/libgnome/2.5/ libbonobo: ftp://ftp.gnome.org/pub/gnome/sources/libbonobo/2.5/ libbonoboui: ftp://ftp.gnome.org/pub/gnome/sources/libbonoboui/2.5/ gnome-vfs: ftp://ftp.gnome.org/pub/gnome/sources/gnome-vfs/2.5/ ORBit2:ftp://ftp.gnome.org/pub/GNOME/sources/ORBit2/2.9/ libIDL:ftp://ftp.gnome.org/pub/gnome/sources/libIDL/0.8/ GConf: ftp://ftp.gnome.org/pub/gnome/sources/GConf/2.5/ gnome-mime-data: ftp://ftp.gnome.org/pub/gnome/sources/gnome-mime-data/2.4/ gnome-keyring: ftp://ftp.gnome.org/pub/gnome/sources/gnome-keyring/0.1/ libghttp: ftp://ftp.gnome.org/pub/gnome/sources/libghttp/1.0/ oaf: ftp://ftp.gnome.org/pub/gnome/sources/oaf/0.6/ libcapplet:ftp://ftp.gnome.org/pub/gnome/sources/libcapplet/1.5/ openhbci-plugin-ddvcard: http://www.rdg.mirror.ac.uk/sites/www.ibiblio.org/gentoo/distfiles/openhbci-plugin-ddvcard-0.3.tar.gz libofx: (???) http://prdownloads.sourceforge.net/libofx/ 111_gnucash.sh Description: Bourne shell script -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
