Re: A few notes on the book
Dan Nicholson wrote: > On 7/11/07, Chris Staub <[EMAIL PROTECTED]> wrote: >> 3. There is a redundancy in Freetype instructions for unpacking the >> freetype-docs tarball. It says to do "--strip-components=2 -C docs", but >> it unpacks into the "docs" dir in the freetype source tree by default >> anyway. This can be changed to just "--strip-components=1" without the >> "-C", or alternatively a note saying that the freetype-docs tarball can >> be unpacked from the same place as the freetype source tarball, and will >> unpack into the same freetype-[version] dir. > > OK. There is an inherent (documented in LFS Section 5.1) assumption made for every package that the instructions given assume that you have done: tar -xf cd Your first suggestion would be a good approach, but the second is a deviation form the norm. I would recommend the first alternative. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Xorg wget download links
Randy McMurchy wrote: > Dan Nicholson wrote these words on 07/12/07 13:27 CST: > >> What about in Additional Downloads vs. part of Package Information? > > Because it is not an upstream file, I think it is probably best in > the "Additional Downloads" section. But that's just my take, perhaps > Bruce and others have comment as well. It looks fine to me, but you may want to review/update the general explanation in the Introduction to Xorg-7.2. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Gnome-2.18: Ejecting CD/DVD ROMs
Dan Nicholson wrote: > On 7/25/07, Randy McMurchy <[EMAIL PROTECTED]> wrote: >> However, it won't properly eject the CD/DVDs. Choosing 'Eject' from the >> volume manager panel applet gives an error. >> >> Gnome-volume-manager and gnome-mount are installed. There is no 'eject' >> program installed. Any clues? > > I think you actually need the `eject' program. It's a runtime dep for > HAL on Linux. It's called by /usr/lib/hal/hal-storage-eject, which is > used by the Eject method. Where is the `eject' program located? It is not in BLFS; at least it is not in the index. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: extra-prompt.sh
David Jensen wrote:
> Moving to dev.
> Ag. D. Hatzimanikas wrote:
>> Does this prompt (in /etc/profile) looks good to you? (it was suggested by
>> David Jensen)
>>
>> if [[ ${EUID} == 0 ]] ; then
>> PS1='\[\e[1;31m\]\u [ \[\e[00m\]\w \[\e[1;31m\]]\$ \[\e[00m\]'
>> else
>> PS1='\[\e[1;32m\]\u [ \[\e[00m\]\w \[\e[1;32m\]]\$ \[\e[00m\]'
>> fi
This is too cryptic. Use:
NORMAL="\[\033[0;39m\]"
RED="\[\033[1;31m\]"
GREEN="\[\033[1;32m\]"
if [[ ${EUID} == 0 ]] ; then
PS1="$RED\u [ $NORMAL\w$RED ]\$ $NORMAL"
else
PS1="$GREEN\u [ $NORMAL\w$GREEN ]\$ $NORMAL"
fi
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: extra-prompt.sh
taipan67 wrote:
> Bruce Dubbs wrote:
>> David Jensen wrote:
>>
>>> Moving to dev.
>>>
>>
>>> Ag. D. Hatzimanikas wrote:
>>>
>>>> Does this prompt (in /etc/profile) looks good to you? (it was suggested by
>>>> David Jensen)
>>>>
>>>> if [[ ${EUID} == 0 ]] ; then
>>>>PS1='\[\e[1;31m\]\u [ \[\e[00m\]\w \[\e[1;31m\]]\$ \[\e[00m\]'
>>>> else
>>>>PS1='\[\e[1;32m\]\u [ \[\e[00m\]\w \[\e[1;32m\]]\$ \[\e[00m\]'
>>>> fi
>>>>
>> This is too cryptic. Use:
>>
>> NORMAL="\[\033[0;39m\]"
>> RED="\[\033[1;31m\]"
>> GREEN="\[\033[1;32m\]"
>>
>> if [[ ${EUID} == 0 ]] ; then
>> PS1="$RED\u [ $NORMAL\w$RED ]\$ $NORMAL"
>> else
>> PS1="$GREEN\u [ $NORMAL\w$GREEN ]\$ $NORMAL"
>> fi
>>
>> -- Bruce
>>
> I've also stolen coloured PS1 values from my current Gentoo-box, & they
> use the '\033' escape-sequence listed above, but in full, not through
> variable-names. They also define 'normal' as "\[\033[00m\]" (not sure of
> the difference).
\e and \033 are the same thing. They are the ASCII escape chararacter,
ESC, decimal 27, octal 33, hex 1b.
> However, Gentoo define them in /etc/bashrc, & have the line ".
> /etc/bashrc" (that's 'full-stop' 'space' 'filename') in /etc/profile,
> instead of a PS1 declaration. I found this to be necessary when booting
> into my LFS system. I also have a third colour defined for
> package-users, but that had to go in the pkgusr ~/.bashrc to work,
> presumably because they never boot the system, they are only su'd to by
> root.
/etc/bashrc is not a standard bash file. It is only used if another
configuration file, e,g, /etc/profile, calls it. BLFS follows that
convention by sourceing it from ~/.bashrc. The dot operator in bash is
a somewhat cryptic shortcut for the bash 'source' command. It exists
primarily for compatibility with sh.
PS1 is required by every new invocation of an interactive bash session,
so it needs to be called by ~/.bashrc or a file sourced from that.
> There are additional pre-checks for the existence of /etc/dircolors &
> that the terminal in use supports colour. For future builds, it's my
> intention to incorporate this into my base LFS-build, as dircolors is
> installed by coreutils fairly early in both chapters 5 & 6 - i haven't
> worked out the details yet...
The initialization files in BLFS are intended as starting points for you
to customize as you desire.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: extra-prompt.sh
David Jensen wrote:
> taipan67 wrote:
> if [[ ${EUID} == 0 ]] ; then
> PS1='\[\e[1;31m\]\u [ \[\e[00m\]\w \[\e[1;31m\]]\$ \[\e[00m\]'
> else
> PS1='\[\e[1;32m\]\u [ \[\e[00m\]\w \[\e[1;32m\]]\$ \[\e[00m\]'
> fi
>
>
>>> This is too cryptic. Use:
>>>
>>> NORMAL="\[\033[0;39m\]"
>>> RED="\[\033[1;31m\]"
>>> GREEN="\[\033[1;32m\]"
>>>
> I don't see \033 as preferable to \e, otherwise it looks OK.
> Perhaps the bold/bright, '1' could be dropped, most others likely don't
> use a white on black xterm as I do.
>
> thus:
> NORMAL="\[\e[0m\]"
> RED="\[\e[31m\]"
> GREEN="\[\e[32m\]"
>
> Maybe single quotes, though there is nothing, as is, that bash will mangle.
The single quote acts differently. From the man page:
"Enclosing characters in single quotes preserves the literal value of
each character within the quotes. A single quote may not occur between
single quotes, even when preceded by a backslash."
"Enclosing characters in double quotes preserves the literal value of
all characters within the quotes, with the exception of $, `, and \."
In this case, using single quotes may not be a problem because the
backslashes will then be interpreted when PS1 is evaluated.
> Does anyone know why the escaped bracketing is required, it is.
> It seems "\e[1;31m" should work but the cursor position and scrolling
> get fouled.
The bash man page again has the answer. Under PROMPTING:
" \[ begin a sequence of non-printing characters, which could
be used toembed a terminal control sequence into the prompt
\] end a sequence of non-printing characters"
I believe this is needed to tell bash not to count these characters when
determining when to wrap a line.
>> They also define 'normal' as "\[\033[00m\]" (not sure of
>> the difference).
> This seems incorrect to me, 00m is default mode, not a color. It does
> however, set the default color and attribute. Either '\e[00m' or
> '\e[0;39m' seem correct.
The sequence "\e[m" could also be used. The usual sequence I've seen is
"\e[00m". I believe "\e[0;39m" would only reset the foreground color and
not the background color.
> Reviewing this thread
> http://linuxfromscratch.org/pipermail/blfs-dev/2007-March/016818.html
> it seems PS1 should not be exported, no decision was reached
It should not be exported because it does no good. PS1 is reset for
each invocation. From the bash man page:
"An interactive shell is one started without non-option arguments and
without the -c option whose standard input and error are both connected
to terminals (as determined by isatty(3)), or one started with the
-i option. PS1 is set and $- includes i if bash is interactive,
allowing a shell script or a startup file to test this state."
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: X.sh in profile.xml
Randy McMurchy wrote: > Dan Nicholson wrote: > >> I like the text you've added, but I'm not sure about /usr/X11R7 yet. > > I also do not think we should hard-code /usr/X11R7. It should perhaps > be suggested, but inside replaceable tags. I am in favor of /usr/X11 as a generic location with compatibility symlinks as necessary. As far as the FHS standard goes, I looked around a bit to see if there is any discussion about he topic. The latest version of FHS was released January 29, 2004. That's 3.5 years ago. The so-called mailing list is nothing but spam. Is the effort still alive? Under these circumstances, I feel slavish adherence to FHS is not appropriate. We can use it for input, but well reasoned variances should not be a cause for concern. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: X11R6 compatibility symlink
Ken Moffat wrote: > On Sat, Aug 11, 2007 at 06:49:34PM -0500, Randy McMurchy wrote: >> And this is the 'blanket' file that goes on broken packages pages: >> >> +This package (unfortunately) expects the X >> +Window system to be installed in the >> +/usr/X11R6 directory. If you're >> +using a recent version of Xorg and it is >> +installed in any other location, ensure you have >> +followed the instructions in the >> +section. >> > Nice restrained text - if it was me, I'd probably use > 'inappropriate' language about packages whose developers don't keep > up to date with changes. But one quibble - unless blfs has got rid > of XFree86 (and I wouldn't argue with that), doesn't the choice of > where to install also apply to XFree86 (e.g. the book currently has > #define ProjectRoot /usr). > > So maybe s/Xorg/xwindows/ (without capitalisation) ? It is never xwindows. It is the 'X Window System'. It has the well know shorthand notation 'X'. Personally I think I'd say: This package expects the X Window system to be installed in the /usr/X11R6 directory. If you have installed X in any other location, ensure you have created a compatibility symbolic link as described in the section. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: LFS-6.3-rc2 has been generated
Randy McMurchy wrote: > Dan Nicholson wrote these words on 08/13/07 13:02 CST: > >> Right, but where is that mirroring from? The canonical download >> address comes from the LFS book and is picked up in the anduin sources >> repo. You can't mirror yourself. > > Here's a link, but I'm not sure how long it would be valid for. > http://fresh.t-systems-sfr.com/linux/src/shadow-4.0.18.1.tar.gz/ > > Additionally, as you said, we can always find a home on Anduin. If we can't find the developer's canonical location, I'd really prefer anduin where we have complete control. For shadow, it is already there. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Why all these new packages?
Randy McMurchy wrote: > Thoughts from others? Am I wasting my time? No, you are not wasting your time. Your actions are well thought out and I, for one, appreciate your efforts a lot. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Akode and FFmpeg
M.Canales.es wrote: > El Miércoles, 15 de Agosto de 2007 00:18, Randy McMurchy escribió: > >> I thought about this today as well. And if Bruce doesn't have the time >> to update, I've already installed and logged about 1/3 of the KDE >> packages, so it wouldn't be hard to update. I'd like get it done one >> way or the other before we release BLFS-6.3. > > When updating KDE to 3.5.7, take note that there are several security > patches, > at this moment there is 3 for KDE packages and one for Koffice: > > ftp://ftp.kde.org/pub/kde/security_patches If Randy, or anyone else, wants to do KDE 3.5.7, that is fine with me. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: XFS url
david567 wrote: > The XFS link is broken again. Maybe it's time to update. > > I'll try the new xfsprogs_2.9.3-1 at: > ftp://oss.sgi.com/projects/xfs/download/cmd_tars/xfsprogs_2.8.18-1.tar.gz > > If someone has already done so, chime in. I keep my music on a xfs > partition. It would be a nice thing for you to update. I'm curious. Why use xfs for your music partition? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Linux From Scratch Version 6.3 Release Announcement
The LFS team is proud to announce the release of LFS-6.2-pre1, the first pre-release of the upcoming LFS-6.2 book. You can read it online or you can download the book from to read it at http://www.linuxfromscratch.org/lfs/view/6.3/ For a full list of changes, I refer you to the changelog included in the book. This version includes many textual and package upgrades. Current packages include: * Autoconf 2.61 * Automake 1.10 * Bash 3.2 * Berkeley DB 4.5.20 * Binutils 2.17 * Bison 2.3 * Bzip2 1.0.4 * Coreutils 6.9 * E2fsprogs 1.40.2 * File 4.21 * Findutils 4.2.31 * GCC 4.1.2 * Gettext 0.16.1 * Glibc 2.5.1 * Groff 1.18.1.4 * Gzip 1.3.12 * IANA-Etc 2.20 * Inetutils 1.5 * IPRoute2 2.6.20-070313 * Less 406 * LFS-Bootscripts 6.3 * Libtool 1.5.24 * Linux 2.6.22.5 * M4 1.4.10 * Make 3.81 * Man-pages 2.63 * Ncurses 5.6 * Procps 3.2.7 * Psmisc 22.5 * Readline 5.2 * Shadow 4.0.18.1 * Tar 1.18 * TCL 8.4.15 * Texinfo 4.9 * Udev 113 * udev-config-6.3 * Vim 7.1 Comments and feedback to the LFS Development List <[EMAIL PROTECTED]> are appreciated. Registration is required. Bruce Dubbs LFS 6.3 Release Manager -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Corrected Linux From Scratch Version 6.3 Release Announcement
Correcting a typo. Original Message Subject: Linux From Scratch Version 6.3 Release Announcement The LFS team is proud to announce the release of LFS-6.3 You can read it online or you can download the book from to read it at http://www.linuxfromscratch.org/lfs/view/6.3/ For a full list of changes, I refer you to the changelog included in the book. This version includes many textual and package upgrades. Current packages include: * Autoconf 2.61 * Automake 1.10 * Bash 3.2 * Berkeley DB 4.5.20 * Binutils 2.17 * Bison 2.3 * Bzip2 1.0.4 * Coreutils 6.9 * E2fsprogs 1.40.2 * File 4.21 * Findutils 4.2.31 * GCC 4.1.2 * Gettext 0.16.1 * Glibc 2.5.1 * Groff 1.18.1.4 * Gzip 1.3.12 * IANA-Etc 2.20 * Inetutils 1.5 * IPRoute2 2.6.20-070313 * Less 406 * LFS-Bootscripts 6.3 * Libtool 1.5.24 * Linux 2.6.22.5 * M4 1.4.10 * Make 3.81 * Man-pages 2.63 * Ncurses 5.6 * Procps 3.2.7 * Psmisc 22.5 * Readline 5.2 * Shadow 4.0.18.1 * Tar 1.18 * TCL 8.4.15 * Texinfo 4.9 * Udev 113 * udev-config-6.3 * Vim 7.1 Comments and feedback to the LFS Development List <[EMAIL PROTECTED]> are appreciated. Registration is required. Bruce Dubbs LFS 6.3 Release Manager -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: My status.
Ag. D. Hatzimanikas wrote: > With the hope that you will understand my situation, I am wishing the best > to all the friends from Lfs universe. > > We shall meet again. Ag, My heart goes out to you. As always, do what you have to do. We will welcome you back when you are able at whatever level you are comfortable. Take care. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Gimp 2.4
I ran into a problem with gimp. I had 2.2 installed, but the last time I started it up, I did not have any text in the menus. The menus worked and had icons in them, but no text like File, Settings, etc. I then went out and got gimp-2.4. It compiled very nicely and is now a simple CMMI application. Some of the requirements are GTK+ version 2.10.13 or newer GLib (>= 2.12.3) Pango (>= 1.12.2) freetype2 newer than version 2.1.7 fontconfig 2.2.0 or newer I did the configure and make and make check. All tests passed. I then installed the new gimp, but I still have the text problems (No menus). I figure I did something to a setting of some kind, but have no idea what. All my KDE programs are fine. Seamonkey uses gtk+2 and is fine. Running gimp from the command line gives the message: (gimp:5026): Pango-WARNING **: shape engine failure, expect ugly output. the offending font is 'Bitstream Vera Sans Not-Rotated 10' Ideas? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: wvstreams configure fails with "openssl>=0.9.7 required"
Alexander E. Patrakov wrote: > Randy McMurchy wrote: >> Unfortunately, it appears that much of BLFS could soon be >> unsupportable. Nobody other than me has made an update to the >> book in almost two months (a couple of days short of two >> months according to the changelog). >> > > So the book is essentially dead. Maybe it is a good idea to start from > scratch - i.e., create an empty branch and copy there only pages > validated (as in: "copying and pasting the instructions gives the > optimal result") by at least one editor. It may be also a good place for > layout and presentation experiments (e.g., add the information about the > setup actually tested by BLFS developers, so that people know which > dependencies actualy work and which are listed only because the > configure script looks for them). The reports of BLFS' death are exaggerated. Yes it is dormant, but it will make a comeback. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: help with mail to the list
[EMAIL PROTECTED] wrote: > All my mail to the list from my webmail get returned as spam by the > mail at linuxfromscratch.org. I forwarded to the postmaster but got > no answer. This email is send using postfix on lfs 6.3, hope is goes > through. Make sure your web mail is not sending as html. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Pipe Dreams
Hans, Thanks you for your feedback. There are a couple of things you touched on that you might want to consider. 1. Each page of the BLFS has a link to a wiki page. Users are free to add to them, so you can help the community there if you would like. 2. For automation, take a look at Automated LFS, particularly jhalfs. Start on the web page. 3. You comment about dependencies is valid. It is very difficult to determine what is needed, but it is virtually impossible for someone to come up with a way to specify the order of dependencies when we don't know what a user will want to install. LFS is better in this regard than BLFS, but the intent of LFS is to build everything there. In BLFS, the idea is to give users a choice so they don't have a bloated set of packages that they don't need. 4. Finally, remember that LFS and BLFS are not, strictly speaking, a distro but are books that intend to teach how to build a system. From there, you are free to customize as you wish. From your comments, it looks to me like we were successful in your case. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Pipe Dreams
Alan Lord wrote: > There have been other threads similar to this and I wonder if there is > something not quite right about the whole discussion... > > It seems to me that there are many individuals who have learned and > loved the whole LFS/BLFS experience (I count myself in this group BTW). > I have found, and it seems so have others, that there comes a point when > it becomes too hard (or time consuming) to continue living with the pure > LFS/BLFS distro for day-to-day tasks. That's why I use Ubuntu on my > desktop. > > Perhaps - and this is an idea for discussion and a good "Pipe Dream" - > that there should be another member of the *LFS family... Perhaps MLFS > where the M stood for Managed, or PLFS for Packaged LFS. And let's get > the community to somehow use and develop the fantastic work done in the > LFS and BLFS books and create a version that is basically LFS and *your* > BLFS with some kind of package management control. > > Is this a stupid idea? Is this Gentoo? It's either Gentoo or Slackware. I use LFS for my main system and have for years. The main thing is that just about every package can be updated in place with the possible exception of glibc. One reason I put the section about installing kde and qt in /opt into BLFS is to allow building in place with the option of backing up if it is needed. For a useful system, you don't always have to update to the latest and greatest. I still have production servers running LFS basically unchanged from December 2003. The kernel is 2.4.5. glibc is 2.3.2. There is no need to update. # du -sh /bin /dev /etc /lib /opt /root /sbin /usr /var 3.1M/bin 44K /dev 2.9M/etc 3.6M/lib 8.7M/opt 32K /root 3.0M/sbin 362M/usr 385M/var No X, no bloat. Works. Try getting Ubuntu or RedHat or SUsE down to that size. -- Bruce P.S. The system above also boots to the command prompt in about 15 seconds, not that booting is required often. The uptime right now is 245 days. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xfsprogs-2.9.4-1
Christian Wurst wrote: > 1.) Calculating the SBUs for the new package: The time-program reports > 3 different times as I'm sure you know. I think I should use the > "user" time, correct? Yes. You use the ratio of the time for package to the first LFS binutils time. I use: TIMEFORMAT='%1R Elapsed Time - ' $PACKAGENAME > 2.) Is the md5 sum of the package simply calculated by invoking > "md5sum xfsprogs-2.9.4-1.tar.gz"? Yes. > 3.) I've never worked with svn before, so the last question is about > editing the xml-sources of the book: As far as I understand it, in my > case I only would have to edit BOOK/postlfs/filesystems/xfs.xml > (change md5 sum, build size, SBU, etc.) and the BOOK/general.ent file > (update xfsprogs-version). Then I run "svn diff > xfsprogs.patch" and > mail it to the list. Sounds about right. > If I "svn up" the next time my changes would be > overwritten by the current file versions of the server, right? No, svn doesn't overwrite your files. It will either "merge' in any changes or update the files with a "Conflict" with and markers. Check with `svn status` > 4.) Is there anything else I should do before sending in a diff-file? > Maybe there are some tests which are usually done or something else I > don't know... Usually I make install with DESTDIR=/tmp/$PACKAGENAME-install and then evaluate if everything is there. Other mkdir, cp, install, commands are similarly modified. Run any test suites and any other tests that you can think of to ensure the package works properly. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: bind (ticket #2409)
On Dec 17, 2007 11:43 AM, Christian Wurst <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm working on a patch adressing the chmod command in the current bind > installation instructions (ticket #2409). So far I removed the outer > curly brackets, which solves the "no such file or directory" error > reported by Moody. > > He also suggests in the ticket to use /dev/urandom in the rndc-confgen > statement. After reading the urandom man page I'm not sure if this is > a good idea. As far as I understand it this is only an issue if > /dev/random runs out of entropy. I have no idea how likely this is to > happen, even without the random init script from the book which helps > here, as far as I understand it. The man page also states that > /dev/urandom might be vulnerable to cryptography attacks. > > I would like to submit a patch which adresses both, but I need help > with the urandom suggestion. Any thoughts about this, i.e. shall we > use urandom or leave it like it is and use random? Have you checked how distros like Ubuntu and Fedora do it? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
KDE4
I've started to look at KDE4 and wondered if anyone else has started to build it. According to http://techbase.kde.org/Getting_Started/Build/KDE4 it looks like there will be several new packages needed: qt4 libclucene librdf boost cmake as well as some others that I'm not sure about. arts is no longer a part of kde, but I'm not sure yet if it is needed at all. It looks like HAL and dBus will be required. The base kde download is 220M and that doesn't include the i18n packages and several smaller packages that are in the extragear/ directory: extragear-plasma-4.0.0.tar.bz2 kaider-4.0.0.tar.bz2 kcoloredit-4.0.0.tar.bz2 kfax-4.0.0.tar.bz2 kgraphviewer-4.0.0.tar.bz2 kiconedit-4.0.0.tar.bz2 kmldonkey-4.0.0.tar.bz2 kphotoalbum-4.0.0.tar.bz2 kpovmodeler-4.0.0.tar.bz2 ktorrent-4.0.0.tar.bz2 ligature-4.0.0.tar.bz2 rsibreak-4.0.0.tar.bz2 This is going to be a major effort and the learning curve is going to be steep. I'd appreciate any advice that others may have. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: stty sane and xterm
DJ Lucas wrote: > This is a silly little issue that has bugged me for a while now, but it > disappears when I finally install gnome's term, so I've never bothered > to mess with it. Anyway, 'stty sane' breaks the backspace character in > recent xterm. I'm not sure if this is related to utf8 or not, can > anybody verify? Anyway, the 'fix' (xterm -ie) is fairly easy for the > default xinitrc ($XORG_PREFIX/lib/xinit/xinitrc) and I wondered if this > should be added to the book in the configuring xorg page? Better solution? I've never noticed this because I use konsole all the time, but stty sane does indeed break the backspace key for me too. >From the man page, sane is a shortcut for cread -ignbrk brkint -inlcr -igncr icrnl -iutf8 -ixoff -iuclc -ixany imaxbel opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke and "all special characters to their default values". What it does is set erase to ^? (Hex 7F) from ^H (hex 08). You can fix by `stty erase ` No other characters change. Use `stty -a` to see all the settings. The only other parameters that I see change are brkint are imaxbel [-]brkint breaks cause an interrupt signal * [-]imaxbel beep and do not flush a full input buffer on a character -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: KDE4
Robert Daniels wrote: > Thought I'd share my progress on building KDE4 with everyone. I > think the biggest contribution I have is a nearly-complete dependency > list. Thanks Robert. The dependency list will be very helpful. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS 6.3: to be or not to be?
Thomas Trepl wrote: > I would like to say that the KDE3 line should be continued as long as > possible/required since KDE4 actually isn't in the state to be a full > replacement of KDE3. KDE4.0 now is not KDE4, some of the KDE gurus said. I > would suggest to upgrade to 3.5.8 and with this, provide a full-featured KDE > desktop and additionally add KDE4 to the book. There is no need to *replace* > KDE3 by KDE4 because you can (but must not) have both KDE versions installed > in parallel (of course in different dirs). I have always intended to add KDE4 as an additional package to KDE3. At some time in the future, it might be appropriate to drop KDE3, but KDE4 will have a fair bit a maturing to do. > When introducing KDE4 to the BLFS-book you need to add QT4 and cmake etc. > too. > I never understood why QT4 has not managed to be described in the book. > Everyone must have seen that QT4 is (one of) the base of KDE4, so we could > have used the time to the release of KDE4 to become familar with QT4. Now, we > need to have a look on all of those packages at once. The reason I was holding off on Qt4 is because nothing we had used it. I was waiting for KDE4 to add Qt4. Again, I plan on adding Qt4 in addition to and not in place of Qt3. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS 6.3: to be or not to be?
Thomas Trepl wrote: > Btw, my prev mail should never sound like a criticism... I never read it that way. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS Miscellanea
Randy McMurchy wrote: > I've always thought that there should be some reference to the project's > home page for each of the BLFS packages. And for most we do, simply because > the download URL for most of the packages contain a reference to the base > URL. For those packages that the download URL is different than the > package home page, then yes, a reference would be acceptable. This should be pretty easy. I'd suggest: + http://...";> ... Package Information + +Home page: + Download (HTTP): Download (FTP): Download MD5 sum: &ex-md5sum; Download size: &ex-size; Estimated disk space required: &ex-buildsize; Estimated build time: &ex-time; If we just agree to add this as we update a page, it would be beneficial. We don't have to go through all the packages right now and add it for every package. An incremental update would be reasonable. One minor problem would be the situation where a package may not have an individual home page. For instance, I'm pretty sure that not all Gnu packages have a dedicated home page. The issue would be what to use in those cases, if anything. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Attribution for helping the BLFS Book
Randy McMurchy wrote: > This is mostly for the devs, but any input is welcome. > > I'm not a big fan of using some anonymous moniker for attributing > in the changelog or whatever a minor update or note to fix the book. > > I don't think it serves any purpose, and sort of to me distracts from > the professionalism of the book to use these anonymous monikers taken > from a Trac username. > > If someone is using some handle other than their name, then simply > leave off the attribution in the ChangeLog. Of course, in the trac > ticket or mailing list the person should be thanked. I don't understand. I just checked the changelog and there are no such entries. There aren't any in the Acknowledgments section either. There are two handles in the Credits section that could be removed: Arhaic and J_Man. I really don't have a preference if those are removed or not. If you are just establishing new policy, then I can agree with this policy. If you are referring to the latest comment by Ag in the Changelog, then I can agree with your policy there too. We might just want to place a link to the ticket in the changelog. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS Miscellanea
Ag. D. Hatzimanikas wrote: > At least all the LFS developers should set up with commit privileges. All the active LFS devs have BLFS commit privs. That is not true the other way. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Attribution for helping the BLFS Book
Ag. D. Hatzimanikas wrote: > On ΚυÏ, ÎœÎ¬Ï 02, at 02:36 Bruce Dubbs wrote: >> We might just want to place a link to the ticket in the changelog. >> > I asked for this months ago. > > Randy McMurchy wrote: >> On Tue, Jul 31, at 01:21 [EMAIL PROTECTED] wrote: >>>> + ... Fixes Trac ticket #2366. >>> Shall I add an entity in general.ent, as they do in LFS to make an >>> actual link so to be "clickable" from the changelog entry? >>> Like: >>> >>> http://wiki.linuxfromscratch.org/bfs/ticket/";> >>> >> No, I would prefer not. In fact, I don't think we need to >> identify that a Trac ticket is being fixed at all. To me >> it would just be too much clutter having a URL in every >> changelog entry. > > Neither I want to add a link to track when its just a normal > package update; but in all other situations, yes, I find it > quite useful. Randy, I don't see a problem with a short message in each changelog message like. "See ticket ." or "Fixes ticket ." -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS-6.3 status
Ken Moffat wrote: > On Tue, Mar 04, 2008 at 08:21:11AM -0600, Randy McMurchy wrote: >> DJ Lucas wrote these words on 03/04/08 01:20 CST: >>> Is it time to branch and freeze yet or do we want to give it a couple >>> more weeks to get the minor updates done? >> I know I need a few days just to get back into things and sort >> of see where we stand. >> > When we mailed off-list back in whenever, you were going to set out > your plans for 6.3. Am I too late to raise tickets for things that > ought to be in it ? No. > Particularly, libxml2, and I suppose the corresponding version of > libxslt on the grounds that they go together - CVE-2007-6824 - and > perhaps cairo - CVE-2007-5503 (that means rebuilding xorg, since I > use xcb, so I haven't tried it on my 6.3 system). I'd say go for it. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
qt4
I'm looking at what is needed for qt4. It is significantly different from qt3, but I need if for a work application as well as it being a prereq for kde4. The libraries and headers for qt3 and qt4 do not seem to conflict. Most things for qt3 starts with qt* and most things for qt4 start with Qt*. There are some places where there are name conflicts such as qstring.h, but those are in a different directory structure. For example: /opt/qt-3.3.8/include/qstring.h /opt/qt-4.3.4/include/Qt/qstring.h /opt/qt-4.3.4/include/QtCore/qstring.h The last two are both installed as regular files, but are identical. In any case the build instructions are a bit simplier: Full: VERSION=4.3.4 ./configure \ -prefix /opt/qt-$VERSION \ -release && make && sudo make install Time: 27 SBU Space: 1914 MB ! ( 1.5 GB build, 361 MB install ) Essential: ./configure \ -prefix /opt/qt-$VERSION \ -release \ -nomake examples \ -nomake demos\ -no-separate-debug-info && make && sudo make install Time: 13.5 SBU Space: 608 MB There does not seem to be a need to use QTDIR, LD_LIBRARY_PATH, or to modify PATH. The docs and examples are installed by default in PREFIX/doc and PREFIX/examples respectively. I've always put qt into /opt for the flexibility of being able to have multiple versions and to be able to install a new version from kde without stepping on the current install like happens if installing with a /usr prefix. For BLFS, I'm inclined to use the essential configuration above as the default with explanations to modify -prefix, -docdir, -demosdir, and -examplesdir according to the user's preference. There are no man pages. The docs are all html. Thoughts? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: qt4
Robert Daniels wrote: > On Wednesday 05 March 2008 15:12:09 Robert Daniels wrote: >>> There does not seem to be a need to use QTDIR, LD_LIBRARY_PATH, or >>> to modify PATH. The docs and examples are installed by default in >>> PREFIX/doc and PREFIX/examples respectively. >> Either lyx or qjackctl (or maybe both) require at least one of QTDIR >> or PATH to be set in order to find qmake. I don't remember exactly >> how it went, but something needs to be set. I think some things also >> use QT4DIR. Environment variables will have to be looked at in more >> detail. > > OK, checked out a few packages that use qt4. Lyx will work with PATH > and PKG_CONFIG_PATH adjusted, or by using a configure switch. qjackctl > seems to require a configure switch no matter what. Avahi and Poppler > seem to be ok with just PKG_CONFIG_PATH. kde4 only seems to need PATH > set. Setting QTDIR, QT4DIR, or LD_LIBRARY_PATH was unnecessary in all > cases. > > I did a full test build on kdelibs-4.0.1, all the rest are based purely > on output from ./configure, so no guarantees that the resulting > Makefiles are correct. Thanks Robert. I think we can drop those environment variables from the qt4 instructions. If they are needed for other packages, then there needs to be instructions to that effect for those specific packages. Also, we don't have any packages in BLFS yet that need qt4. It is interesting to note that ldd finds the correct qt4 libraries for binaries like assistant, designer, qtdemo, etc even though LD_LIBRARY_PATH is not set and /etc/ld.so.conf has not been modified. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS-6.3 status
Randy McMurchy wrote: >> As a first step, I propose to remove autofs, because it has four >> tickets about its bad state, which confirm that the editors don't use >> this package and can't maintain it: >> >> #2458 (about a woefully incorrect example and a missing >> overview/comparison with HAL-based methods) >> #2250 (about the latest upstream patches not being in the book) >> #2310 (about a year-old typo in the initscript) >> #2416 (version update) I added the package as an example of how to handle multiple users. I'll go ahead and fix the page and take the tickets. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS-6.3 status
Alexander E. Patrakov wrote: > Bruce Dubbs wrote: > >> I added the autofs package as an example of how to handle multiple users. >> I'll go ahead and fix the page and take the tickets. > > Thanks! > > Just out of curiosity, what do you use the package for (floppy, cdrom, flash > drives, network shares, something other)? I did use it for network shares. When a user logs on, the home directory is mounted. I left that organization and don't in fact use it myself any more. I do have access to another system that does use it. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS-6.3 status
Alexander E. Patrakov wrote: > Bruce Dubbs wrote: > >> I did use it for network shares. When a user logs on, the home >> directory is mounted. I left that organization and don't in fact use it >> myself any more. I do have access to another system that does use it. > > Very interesting. So, we have two very different use cases: > > * for mounting home directories from network at login time (no symlinks > needed, because nobody is expected to poke into others' home directories with > a > file manager), and > > * for mounting something normally unmounted, but that should be mounted on > the > first use (when the user browses the parent directory with a file manager, > that's the subject of #2458, symlinks are needed). That's an old-style, but > still valid, way of mounting removable media. > > I think that both should be mentioned, and at least the first one should be > covered by an example. I'm working on that now. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Minor Version increments
Robert Daniels wrote: > On Friday 07 March 2008 10:07:46 Randy McMurchy wrote: >> I'm not a big fan of this as it sort of implies we support (have >> tested) newer versions than what the book has in it. Additionally, >> there are so many minor nuances (Moz packages might be an >> exception as they normally don't require command changes) that >> things could be a bit different (doc creation, test suites, >> installed files, etc.). >> > I am in agreement with this. I believe I said this elsewhere, but I > can't find the message right now. What BLFS provides is instructions > known to work with a specific version of a package. The user is > welcome to try the same instructions on a later version of the package. > It will likely work, but we have not tested it and can therefore make > no guarantees. Well, the new instructions I am working on for autofs will pull an arbitrary number of patches from kernel.org and build with those: Recommended Patches: There are frequent patches issued for autofs. To get the current patches, start in the same directory as the main tar file and run: wget http://ftp.kernel.org/pub/linux/daemons/autofs/v5/patch_order-5.0.3 && sed 's;autofs;http://ftp.kernel.org/pub/linux/daemons/autofs/v5/autofs;' patch_order-5.0.3 > wget-list && wget -i wget-list for f in `cat ../patch_order-5.0.3`; do patch -Np1 -i ../$f done That's the way they distribute patches instead of rolling the version. They've had 15 patches since 14-Jan-2008. Of course when they do roll the version, the book will need to change, but technically, I'm relying on the upstream devs to get the patches right. If they put in a new patch, technically I haven't tested it, but I'll rely on bug reports if there is a problem. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK JRL Source
Randy McMurchy wrote: > DJ Lucas wrote these words on 03/08/08 09:06 CST: >> Hi all, I wanted to see if there were any objections to commenting out >> the JDK source build for now. > > If you think the existing source build is too old, then it looks like > you don't have any choice (remember that we are targeting a rather > old LFS/BLFS system). Myself I'd like to see it stay, but we'll let > the community decide. > > The downside is that you'll have to comment the whole page out. I > don't want it to look like we support binary packages in a stable > BLFS release. I'm not really sure we can be flexible here either. > In fact, just the few seconds I'm thinking about it makes me sort > of lean really heavy of establishing policy of no binary packages > in the book unless it's used to bootstrap a source build. > > Sort of a catch-22, because there are quite a few BLFS packages that > rely on Java so we really need it in the book, but you say it must > go. I would like to add an alternative view. Although having a binary package in the book is not preferable, I think this can be an exception. The text could describe the circumstances why we are making that exception. It could also say that the source installation procedures are expected to be in the next version of the book when OpenJDK is released. The reason I would like to see the binary instructions in the book is that they are not trivial. We do mention Nvidia drivers in the X section, but those have a pretty easy install methodology, so I don't see adding those to the book. The only other binary I use is vmware, but that is well beyond the scope of BLFS. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Close ticket #2388 and #2387
Jeremy Huntwork wrote: > Robert Daniels wrote: >> On Sunday 09 March 2008 14:15:27 [EMAIL PROTECTED] wrote: >>> i cannot close the tickets #2388 and #2387 even i have created them >>> by myself. I only can add a reply to them. Could someone else close >>> the tickets please? At least the nfs-utils ticket, to the portmap >>> ticket spinal84 added a comment which i want to investigate. >>> >>> Or is there a setting somewhere which makes the Action-box >>> diappearing at these tickets? >> I'm having this same problem, I was going to assign a couple tickets to >> myself, but was unable to. I mentioned this to DJ, he said to open a >> new trac account with your LFS email address, and if that doesn't work >> talk to Randy. > > I should be able to fix this up for you guys, let me take a look. I've been working privately to get this fixed. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Command nitpick
Randy McMurchy wrote: > Hi all, > > This is mostly for the Editor team, but comments from anyone would > be great. > > I've noticed (on at least one recent commit) that installation commands > are being changed from (for example). > > install -m644 -v somefile someplace > > to > > install -m644 -v -o root -g root somefile someplace > > The command is already preceded by an instruction to do it as root. > Additionally, if you do it as root, the -o and -g is redundant. If > you don't do it as root, it won't work anyway, regardless of the -o > and -g. > > By feeling is the redundancy looks amateurish. Sure -o and -g has > its place in the informative/instructional side, but probably should > only be used when needed. Agree. I think the -o and -g options are for setting the values to a non-root value. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Book nuances [was: Something from -book]
Randy McMurchy wrote: > Ken Moffat wrote these words on 03/10/08 18:28 CST: > >> Care to spell out your preferences ? To me, blfs has for long >> been somewhat pernickety about specifying sizes and SBUs in decimals. >> (I've always found some variation in my own build times, even for >> repeated builds when the cache should be "hot"). I'm happy to >> attempt to fit in with what I find, but a statement for "how small we >> ought to measure" would be useful. > > "Pernickity" ?? > > I had to look in the dictionary. *And you misspelled it* :-) > My dictionary has "persnickity", which would be the perfect word > in the context you used it. > > (don't you just love it when someone uses a word you haven't a > clue what it means, but they misspell it?) :-) > > Just messing with you, Ken > > > The Editor's Guide says one thing, and I didn't reference it, but > here is what *I* do (not that it is correct or right or the way it > should be or anything else): > > Tarball size: I don't even round it. I use 576kb if it isn't quite > a megabyte. If it is over a megabyte I use the entire integer side > and the first decimal of the fraction (e.g., 3,476,345 is 3.4 MB > in the book). > > Buildsize: I round to the nearest MB. Even if under 10 megabyte. > To me, 6.3 MB is the same as 6 MB. 205.6 is *always* 205. OpenOffice > is its own animal. I don't even know what it is, I don't build it > anymore (well I haven't in a long time, anyway). > > Buildtime: Rounded to the nearest one decimal fraction. No-brainer. > If I recall correctly, the Editor's Guide is the same on this one. > If over 10 SBU's I'd probably like to see it at an integer value, > though I can't guarantee how I've done it in the past. Use your > good judgment. Well directly out of the Editor's guide: Units provided for the download sizes should be kilobytes (1024 bytes) or megabytes (1024 kilobytes). Entries less than a 1000 kilobytes should be specified as whole numbers (e.g., 320 KB); larger sizes should be accurate to one decimal (e.g., 6.9 MB). Build sizes should be rounded to the nearest megabyte and displayed as whole numbers (e.g., 38 MB). SBU entries should be rounded to one decimal. If the value is less than 0.1 SBU, it should be listed as "less than 0.1 SBU". Very long build times (greater than 10 SBUs) should be listed as integer values. What's wrong with that? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Book nuances
Randy McMurchy wrote: > Bruce Dubbs wrote these words on 03/10/08 20:05 CST: > >> Units provided for the download sizes should be kilobytes (1024 bytes) >> or megabytes (1024 kilobytes). Entries less than a 1000 kilobytes should >> be specified as whole numbers (e.g., 320 KB); larger sizes should be >> accurate to one decimal (e.g., 6.9 MB). Build sizes should be rounded to >> the nearest megabyte and displayed as whole numbers (e.g., 38 MB). SBU >> entries should be rounded to one decimal. If the value is less than 0.1 >> SBU, it should be listed as "less than 0.1 SBU". Very long build times >> (greater than 10 SBUs) should be listed as integer values. >> >> What's wrong with that? > > Sounds good to me. Just out of curiosity, how much from what I wrote > varies from the EdGuide? It was essentially the same. I jsut wanted to point out that it has been documented for some time. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: kdebase, kdemultimedia, and k3b
Randy McMurchy wrote: > I'm one that thinks the KDE instructions should individualize the > /etc/ dirs to a version-specific directory. > > I think that every installation should have an independent file > structure. GNOME is that way now. Currently KDE uses /etc/kde which > would be overwritten/added/whatever by new/more current versions. > > My belief is that every version should have its own specific > directory. It's taken a long time, but we're almost there! That's a personal preference. I can live with the book either way, but I prefer /opt/kde. I believe, but haven't checked for sure, that existing config files are not overwritten by an install. > Yes, there's merit in having an /opt/kde-1.1.1/etc dir which > cannot ever be overwritten by another version. But it isn't > the way things have evolved. I've *always* looked in /etc/ for > configuration files, and I felt it to be awkward to have > /opt/kde.xxx/etc files. > > At least they are in /etc/kde now, where they belong. As we go > forward, I'm hoping that we can get to /etc/kde/x.x.x dir for > config stuff. Totally version independent. > > If someone wants to duplicate information she already has, then > great, copy it to the new /etc/ directory. Or, I suppose, create a symlink. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Net-Tools vs. IP-Route
Randy McMurchy wrote: > Randy McMurchy wrote these words on 03/10/08 22:12 CST: > Discussion is welcome. I prefer the ifconfig/route syntax also. I believe that the problem with ip-tools was that it did not handle ipv6. I don't know the status of that right now. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: kdebase, kdemultimedia, and k3b
Randy McMurchy wrote: > Bruce Dubbs wrote these words on 03/10/08 22:23 CST: > >> That's a personal preference. I can live with the book either way, but >> I prefer /opt/kde. I believe, but haven't checked for sure, that >> existing config files are not overwritten by an install. >> >> Or, I suppose, create a symlink. > > I cut much of Bruce's message, but only to summarize his thoughts. > I just think that /opt/kde/etc is in the wrong place, because I've > *always* looked first in /etc/* for config files. Exactly. That's why I put it in /etc/kde: --sysconfdir=/etc/kde > Personal preference, of course. And I respect the fact that you put > the KDE instructions in the book, Bruce. In fact, I'll simply let it > be your call on how we go forward. It is too little of an issue to > have discussion about (or an argument anyway). > > You make the final call, and we'll go with whatever decision you > make. Really. The instructions work either way. I'd prefer to keep it the way it is. If nothing else, it shows an option not used a lot. OTOH, as I said, I can live with it either way. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: kdebase, kdemultimedia, and k3b
Alexander E. Patrakov wrote: > Bruce Dubbs wrote: > >> --sysconfdir=/etc/kde > > Could you please verify that it doesn't introduce bugs similar to > http://wiki.linuxfromscratch.org/blfs/ticket/2227 ? I.e., KDE programs should > be > visible in menus of other desktops, possibly including Xfce (currently > commented > out due to bugs and the fact that I no longer use it). I have no idea if that is a problem or not. Most of the kde customization is in $HOME/.kde, but there are some .menu files in /etc/kde/xdg/menus. They are xml files, e.g. $ cat kde-information.menu http://www.freedesktop.org/standards/menu-spec/1.0/menu.dtd";> Information kde-information.directory X-KDE-information How this is used is a mystery to me. I note that ubuntu has a /etc/kde3 directory. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Qt
Alexander E. Patrakov wrote: > Hello, > > the Qt page contains the following warnings: > > 1) Building Qt in a chroot environment may fail. > > Has anyone investigated the cause or is able to reproduce? It has happened to me in the past. The note is not in the Qt4 version because I did not see a problem. Since it says *may*, it does not really hurt to leave the note. > 2) This package (unfortunately) expects the X Window system to be installed > in > the /usr/X11R6 directory. If you're using a recent version of Xorg and it is > installed in any other location, ensure you have followed the instructions in > the Creating an X11R6 Compatibility Symlink section. > > Not reproducible here on the extracted LiveCD (Xorg in /usr, no compatibility > symlink). And, isn't /usr the only de-facto supported Xorg prefixes in the > book > anyway? No. I never put Qt in /usr. If you try to overwrite Qt while in KDE, there is a great potential for problems. Using /opt allows a user to have multiple versions installed simultaneously and easily switch back an forth. This covers the situation where someone wants to update Qt and/or KDE from within a KDE session. For a one time install, or the situation where absolutely no mistakes are made, installing in /usr will work, but in my opinion, is not a wise approach for LFS users. However, you can use your rules for your own distro. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: NFS-Utils nitpick
Thomas Trepl wrote: > Please have a look to the attached patch on the nfsutils.xml to > address most of Randys points. I don't think we should mention tcpwrappers in the required dependencies section. It is really only a library in this context and, as pointed out, only needed by tcpwrappers. Better would be: tcpwrappers Configuration If you enabled support for tcpwrappers (required by portmap) by creating /etc/hosts.deny, ensure you have an entry in the /etc/hosts.allow file for access from the portmap daemon that overrides any rules in the /etc/hosts.deny file. See the man page in section 5 for hosts_access for details on creating appropriate rules. > The "nfsmount" thing is still open. I think this from the very past > and that program doesn't exist anylonger. The question is, what is > start-statd good for and who calls it? Well, the man page for rpc.statd says: For each NFS client or server machine to be monitored, rpc.statd creates a file in /var/lib/nfs/sm. When starting, it normally runs sm-notify to iterate through these files and notify the peer rpc.statd on those machines. But I will note that on my systems /var/lib/nfs/sm is empty for both the client and server even though I do have an nfs entry mounted. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: NFS-Utils nitpick
Randy McMurchy wrote: > Bruce Dubbs wrote these words on 03/20/08 22:51 CST: >> Thomas Trepl wrote: >> >>> Please have a look to the attached patch on the nfsutils.xml to >>> address most of Randys points. >> I don't think we should mention tcpwrappers in the required dependencies >> section. It is really only a library in this context and, as pointed >> out, only needed by tcpwrappers. > > I think Bruce is confused. At best there are typos in the above > statement that until are fixed, the above cannot be deciphered. OK, my memory was hazy. Indeed, you are right. It should merely be listed as an optional dependency. > Bruce is indeed correct that TCP wrappers should not be a > required dependency, it should be an optional dependency, but > I cannot figure out what Bruce is trying to say. > > >> tcpwrappers Configuration >> >> If you enabled support for tcpwrappers (required by portmap) by creating >> /etc/hosts.deny, ensure you have an entry in the /etc/hosts.allow file >> for access from the portmap daemon that overrides any rules in the >> /etc/hosts.deny file. See the man page in section 5 for hosts_access >> for details on creating appropriate rules. > > This is good, except the "If you enabled support for tcpwrappers > (required by portmap) by creating /etc/hosts.deny" part. I'm starting > to lean to think that Bruce is not aware that NFS-Utils looks for > the libwrap library and links it into the build. I'm thinking he > only looks as libwrap as something Portmap uses. If you remove the "(required by portmap)" part, the rest is correct. If /etc/hosts.deny is missing, then nothing is denied. Perhaps the first sentence should start out: If you installed tcpwrappers before nfs-utils and enabled it by ... -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: NFS-Utils nitpick
Randy McMurchy wrote: > I'm confused with the boot script language. It says on the new > client page for NFS-Utils to only install and run the bootscripts > if you want the *server*, yet on the server page it says the > bootscripts are used for *client tools*. Confusing to me. This is another issue. I think the NFS Utilities-1.1.2 Client page should just be removed and the issues briefly discussed there put in the other page. There may be an issue that the main NFS Utilities page is in the Major servers area, but perhaps it should just be moved to Basic Networking Programs and just replace the Client page. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: SeaMonkey and Enigmail
Randy McMurchy wrote: > Hi all, > > This message is sort of a call for help from anyone who may build and > use SeaMonkey. I updated the package the other day, went to use it and > noticed that it doesn't behave as I expected. I use seamonkey as my primary mail/web client, but I haven't updated since 1.1.3/0.95.2 I'll take a look. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: SeaMonkey and Enigmail
Randy McMurchy wrote: > Hi all, > > This message is sort of a call for help from anyone who may build and > use SeaMonkey. I updated the package the other day, went to use it and > noticed that it doesn't behave as I expected. > > Specifically, Enigmail is the issue and all this could be my fault. > During the SeaMonkey update from 1.1.1 to 1.1.8, I changed some things > (not many, mostly just the build patches). Additionally, I used the > Thunderbird instructions for installing the enigmail.xpi that is > created during the build. I have run the build instructions and am testing before installing. I ran ../seamonkey-build/dist/bin/seamonkey and am sending with that running. My initial impression is that the mail is working properly. All the setting swere picjed up from my home direcotry. I have: OpenPGP provided by Enigmail Running Enigmail version 0.95.6 (20080323) Using gpg executable /usr/bin/gpg to encrypt and decrypt The browser has picked up my bookmarks, but not the home page. I like the "modern" font and that came up as default. IIRC, it had to be changed from "classic" before so either they changed the default or it has picked up my settings. I'll take a look at the install issues next. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: SeaMonkey and Enigmail
Bruce Dubbs wrote: > I'll take a look at the install issues next. Randy McMurchy wrote: > Question 1: Does the make (SomethingOrAnother) install of Enigmail > work as described in the book to make it globally available for > all users? make -C ../seamonkey-build/mailnews/extensions/enigmail install It does as far as I can see. I believe the main file is: # ls -l /usr/lib/seamonkey-1.1.8/xpi_store/ total 840 -rw-r--r-- 1 root root 852341 Mar 23 21:17 enigmail-0.95.6.xpi Also: -rw-r--r-- 1 root root 1842 Mar 23 20:45 ./seamonkey-1.1.8/components/enigmime.xpt -rw-r--r-- 1 root root 4353 Mar 23 20:45 ./seamonkey-1.1.8/components/enigmail.xpt -rw-r--r-- 1 root root 181678 Mar 23 21:30 ./seamonkey-1.1.8/components/enigmail.js -rw-r--r-- 1 root root 4545 Mar 23 21:30 ./seamonkey-1.1.8/components/enigprefs-service.js -rw-rw-r-- 1 root root 902 Mar 23 21:18 ./seamonkey-1.1.8/chrome/enigmime.jar -rw-rw-r-- 1 root root 37485 Mar 23 21:18 ./seamonkey-1.1.8/chrome/enigmail-skin-tbird.jar -rw-rw-r-- 1 root root 820446 Mar 23 21:18 ./seamonkey-1.1.8/chrome/enigmail.jar -rw-rw-r-- 1 root root 91371 Mar 23 21:18 ./seamonkey-1.1.8/chrome/enigmail-en-US.jar -rw-rw-r-- 1 root root 36024 Mar 23 21:18 ./seamonkey-1.1.8/chrome/enigmail-skin.jar -rw-rw-r-- 1 root root 2077883 Mar 23 21:18 ./seamonkey-1.1.8/chrome/enigmail-locale.jar -rw-rw-r-- 1 root root 6312 Mar 23 21:30 ./seamonkey-1.1.8/defaults/pref/enigmail.js However, the README.txt file still says: "Note: If you install in the default directory (which is usually /usr/local/mozilla), or any other directory where only the root user normally has write-access, you must start Mozilla first as root before other users can start the program. Doing so generates a set of files required for later use by other users." I don't know if this is still valid or not. It seems to work for me without doing that, but I have run previous versions as root and I have established settings in ~/.mozilla. > As best as I can tell, there is no way (at least I don't know how) > to install the Enigmail extension by non-root user. I've never tried to do this, but all of the above installs in DESTDIR if that is used in the make, ln, install, and cp commands. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: gdk-pixbuf.loaders, DESTDIR and libgnomeui
Robert Daniels wrote: > On Tuesday 25 March 2008 23:06:28 Alexander E. Patrakov wrote: >> Sukucorp Sukucorp wrote: >>> If you use DESTDIR approach, you are deviating from the book. If >>> you are deviating from the book it is assumed that you know what >>> you are doing. >>> >>> Anyway this point might be moot if LFS starts supporting a package >>> manager of some sort. >> With this "discouraging" attitude, package management will never >> become part of the LFS book. >> > IMO, using DESTDIR is a deviation from the 6.3 book, Yes, strictly speaking, it is. > and is generally discouraged. Only from the point of view that it does not follow the books's instructions verbatim. There is a whole page in LFS discussing Package Management. There are also sever hints that are referenced there that go into a lot more detail. > At the least it is indeed assumed you can deal with any > problems that may crop up. This is the same as with any deviations from the book, but some help can be offered via lfs-support and blfs-support. > That said, I do believe PM is the way forward beyond 6.3. I can't say I > look forward to dealing with these kind of issues when PM is supported, > but I think the books will be better for it in 7.0 or whenever PM is > added. The problem is that there are several package management schemes and they are generally incompatible. They are also targeted towards binary installs. When discussing PM, we first need to agree on the goals. What are we trying to do with it? Install an upgraded package transparently? Keep track of files on an LFS/BLFS system? Uninstall a package? The only practical way I can see for doing any of that is to have a separate application do the work. At that point we are fundamentally not doing it "from Scratch" any more. It may as well be Gentoo. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Anduin mirror from Justin's server
Randy McMurchy wrote: > Thoughts from others? It is useful as long as the packages in the stable book are there. We could probably also create a script to check if the packages in the books are on Anduin and post a list of out-of-date files on blfs-book much the same way the list of patches that are not properly in the patches repository are sent out. From that, the editor that does the package update can log into Anduin and do a wget to put the package in place. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Improper handling of -p ${pidfile} in lfs-bootscripts
DJ Lucas wrote: > DJ Lucas wrote: > >> However, it seems to me that if LFS hasn't released say every (insert a >> responsible value here - 6?) months, if there is errata, a new tiny >> release should be made. It's not like it takes all that much to modify >> a released book from it's own svn branch--I mean all the hard work is >> done already. Proofreading, testing, instruction verification, test >> suite results, SBU timings, etc. should still be good. > > Open mouth, insert foot... That was a totally ignorant response on my > part. My apologies to Bruce, Matt, and all previous release managers > and support staff. Yet again, I've spoken before thinking. What I > should have said is "From an editor's POV, it's almost done." I have > absolutely no idea how much work goes into updating the website, writing > a release announcement, setting up source and patch directories, > subversion tags, mirroring, and all the other fine details that I'm sure > I've missed. I suspect it is difficult (to say the least) to get all of > that work done and not miss anything. Just the number of tasks > alone...jeez. Again, I am very sorry for my short sighted response, > and very much appreciate the hard work from our release > managers/coordinators. LOL. Actually, I don't see any reason to not add errata to the website. Section vii of the stable book says to check for errata. The bootscripts could be added as a new package and referenced in the errata in the website. Just update the LFS devel book's bootscripts reference and I can update the web site's errata page to say to use the more recent bootscripts package. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: svn access: can't commit changes
This thread taken off list. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Anduin files
It looks like we have lost our updates of files on Anduin. The most recent update was Dec 12. We had been doing an rsync from rsync.osuosl.org, but it appears that server is no longer being updated and we will have to do it ourself. All editors should have accounts on Anduin. If I overlooked anyone, let me know off list. I'm going to go through the change log since Dec 12 and update on anduin all the packages that have been added since then. We probably need a script to extract all the files from the xml and check them against the repository nightly with a message to blfs-book of any missing files. This would be similar to the patches check. The extraction of file names would be similar to the command in the LFS Makefile: xsltproc --xinclude --nonet --output $(BASEDIR)/wget-list \ stylesheets/wget-list.xsl chapter03/chapter03.xml but we'll need to create a stylesheets/blfs-file-list.xsl. I'll email Manuel and see if he is willing to do that. If not, I'll try to do that myself. Thoughts? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Anduin files
TheOldFellow wrote: > On Fri, 28 Mar 2008 12:11:55 -0500 > Bruce Dubbs <[EMAIL PROTECTED]> wrote: > >> It looks like we have lost our updates of files on Anduin. The most > >> We probably need a script to extract all the files from the xml and >> check them against the repository nightly with a message to blfs-book of >> any missing files. This would be similar to the patches check. > >> Thoughts? >> >>-- Bruce > > There are also the md5sums. It would be good to check the file against > the editor's stated md5sum extracted from the book. (difficult! I > don't have any idea if it's even possible) Yes, its possible. The easiest way to do the xslt is to modify the xml. For instance, if we have: We could change it to read: we could extract to a file that has lines like: kdeaddons-3.5.9.tar.bz2 eaa3832a25b483d1a9613f75991c3d7b from there it would relatively easy to write a bash script to search for the file on anduin and check the md5sum if found. Then errors could be sent to blfs-book. It would be a fair amount of work to add the attributes to every place that would need it, but if we had several editors working it, we could do it fairly quickly. I don't know how much problem it would be to find and extract the filenames and md5sums without the added attributes. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Anduin files
Bruce Dubbs wrote: > Yes, its possible. The easiest way to do the xslt is to modify the xml. > For instance, if we have: > > > > We could change it to read: > > url="&kdeaddons-download-http;"/> > > we could extract to a file that has lines like: > > kdeaddons-3.5.9.tar.bz2 eaa3832a25b483d1a9613f75991c3d7b > > from there it would relatively easy to write a bash script to search for > the file on anduin and check the md5sum if found. Then errors could be > sent to blfs-book. > > It would be a fair amount of work to add the attributes to every place > that would need it, but if we had several editors working it, we could > do it fairly quickly. Following up to my own post. :) If the above change was made, we can us a relatively simple xsl script: http://www.w3.org/1999/XSL/Transform"; version="1.0"> --- This can be invoked with: xsltproc --xinclude --nonet --output ./test-list \ downloads.xsl index.xml and produces the file test-list with the contents like: http://mirrors.isc.org/pub/kde/stable/3.5.9/src/kdeaddons-3.5.9.tar.bz2 eaa3832a25b483d1a9613f75991c3d7b (all on line line). Then a simple bash routine similar to the following can be used: while read url md5; do echo `basename $url` echo $md5 done < test-list to produce the filenames and md5sums. These can in turn be used to check for the presence of the file on anduin and create the appropriate error message when files are not present or wrong. The question is whether we want to go to the effort of changing all the ulink structures specified for download in all the packages. Feedback welcome. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Anduin files
Randy McMurchy wrote: > Bruce Dubbs wrote these words on 03/28/08 15:21 CST: >> Bruce Dubbs wrote: >> >>> Yes, its possible. The easiest way to do the xslt is to modify the xml. > > There is already a script that parses the XML and gets all the > package tarballs. Creating md5sums from them would probably be > trivial. > > Check the Makefile in trunk, you'll find it. I think that is what > you were looking for. Justin used it, or a modified version of it > to populate his server. I don't know why I missed that. It doesn't give the md5sum, but that's something we can live without. I'll go ahead and see what I can come up with for a script to check for existence on anduin. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Helpful error message
Ken Moffat wrote: > I'm trying to edit xpdf so that it again references an upstream > patch. I uncomment the patch, and change it to match the current > version... > Any suggestions ? Please ? Try looking for a mismatched tag *above* the area you mentioned. If you put the the page on quantum or just send it to me, I'll take a look for you. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Helpful error message
Ken Moffat wrote: > On Mon, Mar 31, 2008 at 03:35:12PM +0100, Ken Moffat wrote: >> I'll take a fresh >> look at the suggestions, and if that fails I'll copy it to Bruce. >> > Found the error: even after I commented out the patch, I got a > similar failure. Looking at index.xml, it was pointing to the gnome > chapter. Odd. Updated, to see if I'd somehow missed something - > Richard's commit meant my changelog was in conflict - when I looked, > the formatting was a little weird and my copy seemed to be missing > the first tag for the day's changes (itemizedlist, I think - before > the para). Reverted my changelog, fixed it up, and I've got it > rendered again. Now I just need to make sure I've got the actual > edit correct. Glad you found it. One of the drawbacks of xml is that the error messages don't specify where a problem lies very well. I've run into the same problem with the changelog before. For some reason it's easy to have the tags out of balance there. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Policy on new packages?
TheOldFellow wrote: > If I update to a2ps-4.14, we need gperf-3.0.3. Is it policy to add it, > or just ref it directly to it's home page? If it is a required dependency, then we need to add that dependency to the book. In some cases, we have incorporated the dependency in the same page, but that doesn't feel right in this case. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Upstream patches
DJ Lucas wrote: > Jeremy Huntwork wrote: >> Randy McMurchy wrote: >>> Upstream is notorious for changing the patch content but not changing >>> the name. And we don't see changes. This can only be a bad thing. >>> There is nothing gained by changing the patch and calling it an LFS >>> patch. This can only be a losing situation (upstream changes it, but >>> we have no way of knowing it). >> As I mentioned in the Trac ticket, if they are in the habit of changing >> the patch without changing the name, and we link directly to them, >> essentially we open ourselves up to a situation where we link to an >> untested (by us) patch. At least if we make a snapshot of what they >> released, and we commit it after testing (as I did with this one) then >> we are working with a known patch. > > That is kind of a disturbing point about the way BLFS handles upstream > patches. I've CC'd blfs-dev too. > > If the replacement patch is created with a different -P option, our > instructions are broken. Also, what about the recent issues? > These kinds of problems disappear if we host the patch in our own > repository, excluding the unlikely event (or rather likely as history > has proven) that an upstream patch is updated--which is just plain wrong > anyway as they should have version numbers attached to them, or at very > least, a date. Additionally, our testing is against a known version of > the source. Another weak argument at best, but all other distributions > maintain their own patch sets in their source packages. > > I also don't think that it would be too difficult to create a job to > download and check existing upstream patches against a previously > recorded md5sum. If this irresponsible patch updating business > continues to occur in the future from upstream, we can easily be covered. I don't have a problem with leaving upstream patches upstream, but we should probably have a copy in patches or at least on anduin and mention an md5 sum. This combination will allow us to offer the patch if the upstream one is no longer available or there is a stealth upgrade (not changing the file name). -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Temp files in SVN repo
On Mon, Apr 7, 2008 at 6:38 PM, Dan Nicholson <[EMAIL PROTECTED]> wrote: > The Makefile in the SVN BOOK directory currently creates its temp > files by default in $HOME/tmp. I would really prefer if it would just > keep the temp files inside the checkout. What I'd like to do: > > - change the temp directory to tmp (i.e., ./tmp in the checkout) > - set svn:ignore on the tmp directory > - add a new clean target which will rmdir the temp directory in > addition to weeding out particular files > > Does anyone have any problems with that? Seems fine to me. I was already doing something similar. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: .info files and the 'dir' file
Randy McMurchy wrote: > Hi all, > > Since my installation script actually looks for a /usr/share/info/dir > file if there are any .info files being installed for a package, I've > discovered that many packages do not update the 'dir' file after > installing .info files. > > In these instances, should BLFS provide instructions to update the > 'dir' file? I think they should for completeness, but I'm not user how useful dir is. On my system, I have to page through about 1700 lines of GNU C library functions and macros from glibc to get to a useful view of the table of contents. Looking at a RedHat distro, they have glibc last, but I don't know how to control setting the order of the entries without a special script. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: r7358 - trunk/BOOK
Ken Moffat wrote: > On Tue, Apr 08, 2008 at 11:11:24AM -0700, Dan Nicholson wrote: >> The drawback is that make will not notice if you've updated something >> besides index.xml or general.ent in the source. To force your target >> to be rebuilt, run `make clean' first. Alternatively, touch index.xml >> or general.ent to update their timestamps. I think this is a fair >> trade off for the amount of time spent watching "Validating the >> book..." when you already have a properly validated blfs-full.xml. >> > Dan, > > Now that I've been bitten by this, I think it's a real PITA. > > Just pulled down what was the current book, and ran make before I > had a go at updating. Unsurprisingly, there were no issues (on > another book I've been bitten in the past). I then updated the > changelog and cups (newer security_fixes patch). > > [EMAIL PROTECTED] ~/repos/BLFS $vim introduction/welcome/changelog.xml > pst/printing/cups.xml > 2 files to edit > [EMAIL PROTECTED] ~/repos/BLFS $make > make: Nothing to be done for `blfs'. > > And yes, I remembered this discussion, and running 'make clean' > allowed me to then make the book, but it's just another aggravation. > Creating the book does take too long, but this change made it even > longer. Whether I would remember 'make clean' if I had the same > situation in a month's time is unlikely. I've run into the same thing, but I can get it to run ok by rmoving tmp/. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: $Date$ and $LastChangedBy$ - should we keep them?
Alexander E. Patrakov wrote: > Hello, > > this is a piece of the IRC log on #svn on irc.freenode.net: > > 09:27:59) patrakov: Hello, our project has $Date$ in some files. However, > Subversion expands this based on the current locale, which is wrong for us. > How > to make it always insert the English representation of date into files of > this > project, without manually changing the locale? > (09:31:35) kfogel: patrakov: I know of no way to do that, without setting > some > env variable temporarily. > (09:31:37) Yanroy: patrakov: why is that the wrong behavior? AFAIK, the > client > expands that tag every time a checkout or update is performed, so it isn't on > the server... > (09:33:18) patrakov: Yanroy: this is wrong because it is intermixed with HTML > that has a specified encoding, you can't just arbitrarily mix it (this is the > "last modified" string in HTML files, and it is user-visible) > (09:33:35) Yanroy: ah, I see > (09:33:55) Yanroy: well, I would hope that it's only an issue on your server, > in > which case I'd suggest changing the server's locale > (09:34:26) patrakov: this is a client issue > (09:35:37) patrakov: the server is in USA If you are referring to the LFS main server, quantum, it is actually in Canada. and can render the pages correctly if > I ssh there and check out the files. But on my computer the result is garbage > until I temporarily set LC_TIME=C > (09:36:19) patrakov: (garbage = Russian representation of dates in English > documents) > (09:41:13) patrakov: if no solution is available, I'll report a bug > (09:42:24) kfogel: patrakov: call it rather a proposed enhancement, not a > bug. > The current behavior is intended; we could add more control, but at the cost > of > a more complex interface. > (09:42:50) Yanroy: could you set up an alias in your shell such that it sets > the > environment variable before invoking svn? > (09:44:06) patrakov: Yanroy: I did just that, but I can't call this a > solution, > because a French project would require the dates to be in French, and so on. > I.e., this really should be a property of the repository > (09:45:32) Yanroy: patrakov: I'd say it's a property of the file, not the repo > (09:46:06) Yanroy: patrakov: also, I can almost guarnatee the response you'll > get on the dev mailing list: don't use keyword expansions, they're only > provided > to be backwards-compatible with CVS > > Thus, we should probably find some other method to extract the date and last > author metadata and put them into the files. Or just drop this. I guess I don't understand the problem. What character set is being used for the Russian dates? Is that what is getting checked in? I haven't seen it. Do they conflict with the html specific characters? <, >, ", ', & The date entries for the book are done in the style sheets. We explicitly use a substring of the date as it has a defined length and position for each character. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
BLFS 6.3 outstanding tickets
There are a few unclaimed 6.3 tickets that we need to address: http://wiki.linuxfromscratch.org/blfs/ticket/2065 : Sane UDEV Looks like this one should be handled by Randy or Alexander - http://wiki.linuxfromscratch.org/blfs/ticket/2395 : /etc/X11/ http://wiki.linuxfromscratch.org/blfs/ticket/2391 : /etc/X11/ These have been discussed by Alexander, DJ, and Ag. It would appear that DJ would have these. - http://wiki.linuxfromscratch.org/blfs/ticket/2476 : xine-lib Discussion is between Randy, Robert, Dan, and Alexander. - http://wiki.linuxfromscratch.org/blfs/ticket/2479 : goffice Reported by Ken - http://wiki.linuxfromscratch.org/blfs/ticket/2512 : k3b dependency Reported by Alexander. I don't know much about this, but I'll investigate and if appropriate take this. If someone else knows more, please take it. - All other 6.3 tickets have been accepted. http://wiki.linuxfromscratch.org/blfs/ticket/2512 : seamonkey - Me http://wiki.linuxfromscratch.org/blfs/ticket/2375 : MPG - David http://wiki.linuxfromscratch.org/blfs/ticket/2155 : compressdoc - Dan http://wiki.linuxfromscratch.org/blfs/ticket/2225 : XOrg patches - Dan http://wiki.linuxfromscratch.org/blfs/ticket/2367 : XKeyboardConfig - Dan http://wiki.linuxfromscratch.org/blfs/ticket/2504 : rsync - Randy We are getting close. We should be able to knock out all these tickets pretty quickly and get a -rc1 released. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Fixes for the compressdoc script
Randy McMurchy wrote: > Dan Nicholson wrote these words on 04/21/08 18:37 CST: >> Today I finally spent some time addressing a few patches people have >> sent in about compressdoc and some other bugs I noticed along the way. > > I appreciate your efforts, though I sort of look at repairing the > compressdoc script akin to fixing an old 386 computer. > > Just my opinion, but it's time to move on and not worry about saving > a few megabytes of disk space. Embedded systems wouldn't have man pages, > so I simply see no need to compress man pages. I agree. My system has 68M of man pages uncompressed. Even If I saved 100%, it wouldn't be noticeable. In the military, we had a saying: measure with a micrometer, mark it with a grease pencil, and cut it with an ax. Somehow that seems appropriate here. On the other hand, it might be relevant if someone was trying to squeeze as much as possible on a CDROM (not DVD). > But I do admire Dan's work. Me too. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
RPM
I would like to add RPM to BLFS because it is required for a system to be compliant with the Linux Standards Base. It doesn't have to be for 6.3, but it is relatively easy. The install issues: Requires beecrypt (CMMI) RPM is basically CMMI, but needs --without-selinux for LFS The install puts one file, rpm, in /bin instead of /usr/bin. This is dumb because it requires libraries in /usr/lib. (Yes, it is that way in RHEL.) I would move it to /usr/bin. I do want to report on the Linux Collaboration Conference I went to a couple of weeks ago, but I haven't had time to write up my notes yet. In any case, I think being LSB compliant would be relatively easy for us. It would just require a few more packages, but I haven't compiled a full list yet. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: RPM
Randy McMurchy wrote: > Bruce Dubbs wrote these words on 04/21/08 22:56 CST: >> I would like to add RPM to BLFS because it is required for a system to be >> compliant with the Linux Standards Base. > > Cool. You're thinking it would be just another package like all the > others? > > What I mean is; that we won't be recommending folks install it or > BLFS itself won't move to be RPM-compliant or anything like that, > right? Right. That would be clear in the text. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: RPM
Alexander E. Patrakov wrote: > Bruce Dubbs wrote: >> I would like to add RPM to BLFS because it is required for a system to be >> compliant with the Linux Standards Base. > > Which version? 4.x and 5.x are completely different beasts. According to www.rpm.org, the current version is 4.4.2.3. > Anyway, LFS contains a severe deviation from LSB (no libncurses.so.5 by > default, only a non-standard wide-character version, but here the standard is > wrong), thus, I don't think that it is a good idea to use this "standard" as > a rationale. That is someting I need to investigate. > Anyway, if you want (B)LFS to be LSB-compliant, you'll need to do a lot more > things: > > 1) ld-lsb.so.3 -> ld-linux.so.2 symlink I know that. > 2) a fake "lsb" RPM, because the standard requires that LSB packages must be > installed without --nodeps I'll have to look at that. > 3) run their binary testsuite and fix all failures, even if this means > downgrading versions and reintroducing other, more severe, bugs. That is something for the user to decide. I just want to provide instructions on how to do it. I do have contacts with the LSB maintainers and may be able to get changes made if they enhance Linux distros in general (not just LFS). See > http://bugs.debian.org/401006 as an example that I would like to avoid. > > As for your proposal to put RPM into BLFS, I think this has to be discussed > in LFS, too. Reason: package management belongs in the next-generation LFS, > and it is an option to have it there, as opposed to BLFS. No, no, no. I am not proposing to *use* RPM for BLFS or LFS. As you say, that needs to be discussed with the LFS and BLFS communities. I just want to add the package. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Update in LSB investigation
I got the initial setup to run the LSB tests. To do that, I installed RPM, and rpm --initdb rpm --install --nodeps lsbsi-lsb-3.2.0-1.i486.rpm From there, a server is run and the interface is via a browser. In the core tests, we did OK: Total tests 148 Total tests expected148 Passed tests132 Quelled problems 7 Failures 9 The failures here were just missing programs on my system: at, batch - GNU, not in BLFS crontab - we use fcron in BLFS. I don't know if a symlink from fcontab to crontab is valid or not. install_initd, remove_initd - I'm not familiar with these. mailx- Heirloom mailx is in BLFS pax - Old GNU or Debian source, not in BLFS. sendmail - several equivalents in BLFS time - Built into bash, but there is a GNU version. Not in BLFS. The quelled problems were due to an LSB trial use module: XDG xdg-desktop-icon xdg-desktop-menu xdg-email xdg-icon-resource xdg-mime xdg-open xdg-screensaver There are some xdg directories in KDE and OpenOffice. The programs seem to be in xdg-utils at http://portland.freedesktop.org/wiki/ -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
BLFS release
We are down to 4 tickets outstanding for 6.3: 2526Inconsistency about Xorg prefix [EMAIL PROTECTED] 2527Xorg - remove lbxproxy and proxymngr [EMAIL PROTECTED] 2518Xorg-7.2 libXfont [EMAIL PROTECTED] 2504rsync-3.0.2 [EMAIL PROTECTED] Is it time to do a freeze/rc1? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS release
Randy McMurchy wrote: > Now I'm going to work on Justin to see if he is around so he'll > fix the main BLFS repo to have a 6.3 repo populated with all the > current SVN packages (as per the current SVN book), then create > symlinks pointing to that named 6.3rc1, 6.3rc2, and 6.3rc3. I did create a script that checks the svn repository on anduin against the book. I could just have that send the results to blfs-book on a daily basis as a nag to get the files updated. Then any editor can update as necessary. Do you want me to do that? The current list of outdated files is attached. -- Bruce Missing blfs-bootscripts-20080326.tar.bz2 Missing autofs-5.0.3.tar.bz2 Missing openssl-0.9.8g.tar.gz Missing cracklib-2.8.12.tar.gz Missing cracklib-words-20080203.gz Missing Linux-PAM-0.99.10.0.tar.bz2 Missing Linux-PAM-0.99.10.0-docs.tar.bz2 Missing gnupg-2.0.8.tar.bz2 Missing tripwire-2.4.1.2-src.tar.bz2 Missing heimdal-1.1.tar.gz Missing stunnel-4.21.tar.gz Missing sudo-1.6.9p12.tar.gz Missing xfsprogs_2.9.7-1.tar.gz Missing nano-2.0.7.tar.gz Missing zsh-4.3.6.tar.bz2 Missing zsh-4.3.6-doc.tar.bz2 Missing ast-ksh.2008-02-02.tgz Missing pcre-7.6.tar.bz2 Missing slang-2.1.3.tar.bz2 Missing gamin-0.1.9.tar.gz Missing libxml2-2.6.31.tar.gz Missing libxslt-1.1.22.tar.gz Missing libgtkhtml-2.11.1.tar.bz2 Missing gmp-4.2.2.tar.bz2 Missing libgsf-1.14.7.tar.bz2 Missing libassuan-1.0.4.tar.bz2 Missing libmowgli-0.6.1.tgz Missing libmcs-0.7.0.tgz Missing libpng-1.2.24.tar.bz2 Missing xterm-231.tgz Missing rxvt-unicode-9.02.tar.bz2 Missing gperf-3.0.3.tar.gz Missing which-2.19.tar.gz Missing unrarsrc-3.7.8.tar.gz Missing junit4.3.1.zip Missing Finance-Quote-1.13.tar.gz Missing Python-2.5.2.tar.bz2 Missing html-2.5.tar.bz2 Missing ruby-1.8.6-p111.tar.bz2 Missing tcl8.4.18-src.tar.gz Missing tk8.4.18-src.tar.gz Missing links-2.1pre33.tar.bz2 Missing links-2.1pre33-utf8.diff.bz2 Missing lynx2.8.6rel.5.tar.bz2 Missing portmap-6.0.tgz Missing whois_4.7.26.tar.gz Missing mutt-1.5.17.tar.gz Missing tin-1.8.3.tar.bz2 Missing httpd-2.2.8.tar.bz2 Missing nfs-utils-1.1.2.tar.gz Missing openssh-4.7p1.tar.gz Missing postfix-2.5.1.tar.gz Missing patch.4.5.20.1 Missing patch.4.5.20.2 Missing dhcp-3.0.6.tar.gz Missing openldap-stable-20071118.tgz Missing rsync-3.0.0.tar.gz Missing xkeyboard-config-1.2.tar.bz2 Missing qt-x11-free-3.3.8b.tar.gz Missing qt-x11-opensource-src-4.3.4.tar.gz Missing cairo-1.4.14.tar.gz Missing goffice-0.6.1.tar.bz2 Missing arts-1.5.9.tar.bz2 Missing kdelibs-3.5.9.tar.bz2 Missing kdebase-3.5.9.tar.bz2 Missing kdeadmin-3.5.9.tar.bz2 Missing kdenetwork-3.5.9.tar.bz2 Missing kdepim-3.5.9.tar.bz2 Missing kdemultimedia-3.5.9.tar.bz2 Missing kdegraphics-3.5.9.tar.bz2 Missing kdeutils-3.5.9.tar.bz2 Missing kdeedu-3.5.9.tar.bz2 Missing kdeaccessibility-3.5.9.tar.bz2 Missing kdetoys-3.5.9.tar.bz2 Missing kdegames-3.5.9.tar.bz2 Missing kdeartwork-3.5.9.tar.bz2 Missing kdeaddons-3.5.9.tar.bz2 Missing kdesdk-3.5.9.tar.bz2 Missing kdevelop-3.5.1.tar.bz2 Missing kdewebdev-3.5.9.tar.bz2 Missing kdebindings-3.5.9.tar.bz2 Missing gnumeric-1.8.2.tar.bz2 Missing gnucash-2.2.4.tar.bz2 Missing koffice-1.6.3.tar.bz2 Missing OOo_2.3.1_src_core.tar.bz2 Missing OOo_2.3.1_src_sdk.tar.bz2 Missing OOo_2.3.1_src_l10n.tar.bz2 Missing OOo_2.3.1_src_binfilter.tar.bz2 Missing seamonkey-1.1.9.source.tar.bz2 Missing enigmail-0.95.6.tar.gz Missing firefox-2.0.0.14-source.tar.bz2 Missing thunderbird-2.0.0.12-source.tar.bz2 Missing enigmail-0.95.6.tar.gz Missing balsa-2.3.22.tar.bz2 Missing faac-1.26.tar.gz Missing faad2-2.6.1.tar.gz Missing flac-1.2.1.tar.gz Missing xine-lib-1.1.12.tar.bz2 Missing mpg123-1.4.2.tar.bz2 Missing vorbis-tools-1.2.0.tar.gz Missing amarok-1.4.8.tar.bz2 Missing xine-ui-0.99.5.tar.gz Missing k3b-1.0.4.tar.bz2 Missing cups-1.2.12-source.tar.bz2 Missing paps-0.6.8.tar.gz -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS release
Randy McMurchy wrote: > Bruce Dubbs wrote these words on 05/08/08 16:39 CST: >> Randy McMurchy wrote: >> >>> Now I'm going to work on Justin to see if he is around so he'll >>> fix the main BLFS repo to have a 6.3 repo populated with all the >>> current SVN packages (as per the current SVN book), then create >>> symlinks pointing to that named 6.3rc1, 6.3rc2, and 6.3rc3. >> I did create a script that checks the svn repository on anduin against the >> book. >> I could just have that send the results to blfs-book on a daily basis as a >> nag >> to get the files updated. Then any editor can update as necessary. >> >> Do you want me to do that? > > No, as best as I remember, and unless things have changed in the > manner Justin does it, anything we add that doesn't exist on the > main repo (Justin's) is wiped out during the next Rsync run on > Anduin. > > That is why I said what I did a month ago about the lack of > updates on Anduin. Unless I'm mistaken, there is *nothing* a > BLFS editor can do, other than prod Justin. No. I disabled the rsync some time ago as the last time the master was updated was sometime in December. If Justin's server gets updated, I can easily re-enable the rsync. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS release
Randy McMurchy wrote: > Bruce Dubbs wrote these words on 05/08/08 17:00 CST: > >> No. I disabled the rsync some time ago as the last time the master was >> updated >> was sometime in December. If Justin's server gets updated, I can easily >> re-enable the rsync. > > Well, I'll be darned. I thought I read in the messages back when this > was an issue, that it was *anduins* Rsync that wasn't working and that > Justin's server was good. Then I thought I remember you saying that > you had *fixed* the issue on Anduin, and we were back syncing again. > > Man, I'm losing it. I'm going to check the archives right now to actually > see what was said. I just thought *for sure* that is what I read. Well, I'm not sure what was said and I didn't check, but the rsync line for BLFS in the fcrontab was commented out on March 28. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS release
Randy McMurchy wrote: > Randy McMurchy wrote these words on 05/08/08 17:05 CST: > >> Man, I'm losing it. I'm going to check the archives right now to actually >> see what was said. I just thought *for sure* that is what I read. > > Well, turns out I'm sorta right, for whatever that is worth. :-) > > On April 1, Justin wrote in to reply to a -Dev thread called > "Anduin files" and said that his repo was up-to-date and that > he's just really busy at work is why the repo isn't updated > on a daily basis. > > Heck, I can live with that. If Justin were to just update > once a week, I think that would be great. > > Then, I see an rsync process running on Anduin. I suppose that is > used for something else and I didn't know it. > > Anyway, can we try to sync up with Justin and see where it stands? Sure. I started rsync manually. rsync -lprt --delete rsync.osuosl.org::blfs /srv/ftp/BLFS It is taking some time. I'll let you know what the results were. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS release
Bruce Dubbs wrote: > Randy McMurchy wrote: > Sure. I started rsync manually. > > rsync -lprt --delete rsync.osuosl.org::blfs /srv/ftp/BLFS > > It is taking some time. I'll let you know what the results were. The list of missing pakages is not much shorter. -- Bruce Missing tripwire-2.4.1.2-src.tar.bz2 Missing sudo-1.6.9p12.tar.gz Missing zsh-4.3.6.tar.bz2 Missing zsh-4.3.6-doc.tar.bz2 Missing ast-ksh.2008-02-02.tgz Missing gperf-3.0.3.tar.gz Missing which-2.19.tar.gz Missing junit4.3.1.zip Missing Finance-Quote-1.13.tar.gz Missing html-2.5.tar.bz2 Missing tcl8.4.18-src.tar.gz Missing tk8.4.18-src.tar.gz Missing whois_4.7.26.tar.gz Missing patch.4.5.20.1 Missing patch.4.5.20.2 Missing dhcp-3.0.6.tar.gz Missing xkeyboard-config-1.2.tar.bz2 Missing qt-x11-free-3.3.8b.tar.gz Missing gnumeric-1.8.2.tar.bz2 Missing seamonkey-1.1.9.source.tar.bz2 Missing firefox-2.0.0.14-source.tar.bz2 Missing xine-lib-1.1.12.tar.bz2 Missing mpg123-1.4.2.tar.bz2 Missing cups-1.2.12-source.tar.bz2 Missing a2ps-4.14.tar.gz -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS release
Bruce Dubbs wrote: > The list of missing pakages is not much shorter. s/not/now/ -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Anduin [was: Re: BLFS release]
Thomas Trepl wrote: > Hi all, > > since I'm new to the editors group (or for any other reason) I may have > missed > something, so don't hit me too hard for the following question(s). > > It seems so that we need to update some directories (files in it) on anduin > in > case of a version update, right? That dir is /srv/ftp/BLFS/ > If i understood this thread right, we need to keep that directories uptodate > since there is no automatism (any longer)? > > Should not be a problem to do so, I just need to know whether I should do... Hold off for right now Thomas. We had one person doing it on another system and were rsyncing to that. If that system will be getting updated on a reasonably regular basis, we should be OK. Thanks for the offer. We may still take you up on that. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS release (?)
Jeremy Huntwork wrote: > Alexander E. Patrakov wrote: >> DJ Lucas wrote: >>> The real problem with it is, if we keep holding for every version >>> increment, we'll never get 6.3 out the door. >> And do we really need to get 6.3 out of the door? Essentially, without an >> errata >> page, without the team tracking security issues and bugs, it will be just a >> snapshot, not a proper distro release. Maybe versionless BLFS (i.e., "always >> use >> svn") is the way to go? > > Personally, I never use a released BLFS book. I can understand why some > feel it is necessary or important, but for me, by the time it is > released, it always feels so dated. Not a fault on any of the devs part, > just a nature of the current setup, I think. Some users, especially new users, will prefer a 'release' version to a svn version. The advantage of BLFS 6.3 is that it is (at least should be) checked against LFS 6.3 and not svn or some hybrid version. By doing a 6.3 release, we can start working BLFS svn against LFS svn. Then when LFS releases, start over again, hopefully with a faster turn around. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Anduin [was: Re: BLFS release]
Randy McMurchy wrote: > Thomas Trepl wrote these words on 05/09/08 01:07 CST: > >> It seems so that we need to update some directories (files in it) on anduin >> in >> case of a version update, right? That dir is /srv/ftp/BLFS/ >> If i understood this thread right, we need to keep that directories uptodate >> since there is no automatism (any longer)? > > Not sure about that. As Bruce mentioned, we just turned the Rsysc > mechanism back on which makes Anduin a slave to Justin's master FTP > server. Any changes we do on Anduin get wiped out on the next > hour/day/whatever's Rsync run. Not exactly. I just ran rsync once last night. It's not yet in the crontab. However, if I run it in with the same switches, changes will get deleted. I'll turn the crontab back on if I get some confirmation that Justin will be updating his system on a somewhat regular basis. -- Bruce BTW, I think if several editors updated the repository as they made changes and I published a nag list of out of date packages, it wouldn't be as bad as the admittedly tedious initial setup. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [BLFS Trac] #2533: Berkeley DB-4.6.21
Moving to blfs=dev... For reference, see http://wiki.linuxfromscratch.org/blfs/ticket/2533 BLFS Trac wrote: > Comment (by [EMAIL PROTECTED]): > > I'm not sure if Bruce has changed his mind, or if he thinks our > policy is dated, or what, but he has turned 180 degrees on this > one. The last time this very same exact issue was discussed, Bruce > opted for the "stable" version. > > Now Bruce is opting for what the OpenLDAP folks say is not their > stable version. Nothing has changed, other than this issue with > Berkeley-DB. Here's the thread: > http://linuxfromscratch.org/pipermail/blfs-dev/2005-August/010927.html LOL. I've slept since then. Anyway, I think circumstances have changed. > I want to be careful that we don't just abandon our very good > policy of using maintainer's stable versions, unless there's > really good reason not to (no stable releases any longer, security > issues, UTF8 compatibility, et all). Agree. If there are no issues, then choose the stable version. When issues come up, discuss, and choose the best course for the current set of circumstances. > I don't want to set precedent (again) with still another package > using other than stable version. However, it very well could be that > OpenLDAP, with it's multiple "production" releases, can truly be > called an exception to the policy. That was my unstated point. > One problem to this approach is the quickness with which OpenLDAP > is released. It is a very fast release-to-release cycle, and I > don't think we can keep up in a timely manner. Using the stable > releases at least afford us to be current for a few months at a > time, instead of a few weeks. We can use the OpenLDAP recommended policy. When the 'stable' version is beyond the version in the book, update to the next 'release' version. I'd modify that to say that before a BLFS release, update to the latest 'release' version to maximize the release lifetime. > This Berkeley-DB dilemma could very well be the turning point > in the decision making process. I don't think so. I think the 'Policy' is to use the stable version unless there are solid reasons to use something else. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Perl Modules type (maybe?)
Ag. D. Hatzimanikas wrote: > On Sat, May 10, at 02:07 Randy McMurchy wrote: >> Hi all, >> >> I see this on the Perl Modules page: >> >> When reinstalling a Perl module, sometimes older versions of the >> module being reinstalled are in other directories specified in @INC. >> To delete all other versions of the module being reinstalled (not >> simply older ones) set the UNINST variable: >> >> make install UNINST=1. >> >> == >> >> My question is: >> >> Is the period (.) at the end of the command a typo or is it supposed >> to be like that? >> > > Judging from the usual programming languages conventions, this seems > like a boolean option (1/0, true/false, etc...), so it looks like it is > safe to bet that the period is a typo. Yes, its a typo that I made. I see that it is already fixed. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS-6.3rc1 in progress
Justin R. Knierim wrote: > Randy McMurchy wrote: >> I was hoping to hear from Justin about the repo situation. I've >> emailed him, as has Bruce, and this message is cc'd to him. I'm >> sure we'll hear from him soon. I don't want to release the SVN >> branch for changes as Justin my need current SVN to do the >> package syncing (he may have scripts that look at SVN on-line >> and pulls from there). >> > I'm really sorry for holding up your release guys, the ftp repo is up to > date for now and I've copied the svn symlinks to a 6.3 branch. I can > change one of the scripts to compare to the 6.3 branch files, so go > ahead and do what you need to do. Thanks Justin. I've re-established the cron job to rsync the files twice a day. I also ran the rsync job just now so things should be up to date. In addition, I have set up a script that runs in the early morning each day that will send a message to blfs-book that has the subject line "Files in BLFS svn missing on anduin" if any files are missing. We'll see if that helps us. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Perl Modules type (maybe?)
Randy McMurchy wrote: > Bruce Dubbs wrote these words on 05/10/08 15:16 CST: > >> I see that it is already fixed. > > You must have seen another Perl Modules commit (I've made a couple in > the last hours), but I just fixed the typo in r7440. I wasn't looking closely enough. I see now that it was after . Thanks for fixing it. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Broken JDK link
DJ Lucas wrote: > http://www.linuxfromscratch.org/patches/downloads/jdk/jdk-Readme.txt is > valid, it's just not in copied to > http://www.linuxfromscratch.org/patches/blfs/svn/jdk-Readme.txt. http://www.linuxfromscratch.org/patches/blfs/svn/ is built nightly from the book. The list of patches comes from: xsltproc --xinclude stylesheets/patcheslist.xsl index.xml > copy-blfs-patches.sh Basically, it is looking for a url that ends with .patch, not .txt. The patches repository is not the right location for a License. It should be on Anduin. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Broken JDK link
DJ Lucas wrote: > The issue is licensing, and the patches repo must hold the license if we > are to keep the patches in the repo. Because we are not dealing with a > typical FOSS license, the patches have to have a readme file in the same > directory (or include the readme in a 'prominent place' with our > sources). We have ftp://anduin.linuxfromscratch.org/BLFS/conglomeration/jdk/jdk-1.5.0.README can't we use that as a 'prominent place'? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS-6.3-rc1 has been released!
Randy McMurchy wrote: > The BLFS Development team is pleased to announce the release of the > 6.3-rc1 version of BLFS. This is a release candidate of the 6.3 version, > due to be released on May 25th. For additional information about the > release, along with download and format options, see > http://www.linuxfromscratch.org/blfs/6.3-release_notes.html Looks good Randy. Thanks for all the hard work. Do you have a schedule for the final release? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS-6.3-rc1 has been released!
Randy McMurchy wrote: > Bruce Dubbs wrote these words on 05/12/08 12:03 CST: > >> Do you have a schedule for the final release? > > I put May 25th on the announcements and Web pages. I'm hoping that > we don't need an rc2, but May 25th gives us almost two weeks. I saw the May 25th date but was wondering if you had any intermediate events planned. > Is that long enough? I'd say that depends on the amount of feedback. If changes needed are relatively small or isolated, yes. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: LFS Future Braindump
Robert Daniels wrote: > We need better descriptions of the packages and why you might want them. Yes, that is true. Some packages need more info than others. > Second, I find that there is an almost total lack of information on how to > make the various pieces work together. This is also true. I did a lot of the original xfree86 description and added a couple of pages that described some issues on how to set it up. Others have since enhanced that, but the same thing does apply to other packages you mention such as ldap, kerberos, etc. The problem is how to determine what is the right amount of explanation. I have a book of over 1000 pages just on sendmail. ldap is about 300 pages. I have books on Qt, vim, xml, bash, subversion, docbook, apache, bind, openssl, samba ... and many others. How much do we put in LFS or BLFS? Obviously more than what we have now would be useful, but we certainly can't incorporate everything in all these books into ours. BLFS is already over 1000 pages. Overall, I'm agreeing with you, but I don't know how to address the problem. Perhaps we need to let the editors scratch their itch to present things that they feel are useful and not try to cover every package or set of related packages at the same level of detail. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS-6.3
Randy McMurchy wrote: > Hi all, > > I can't remember (and I didn't take good notes) anything else that > was mentioned other than the Xorg deprecated stuff and the Shadow > typo (and DJ fixed both) that would prevent us from releasing 6.3. > > The KDE thing reported in -support apparently is not an issue as > it was caused from deviating from the book's commands. > > Are we ready to release 6.3, or should we cut another release > candidate? Did you get my email from yesterday about the licenses we're using? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: LFS Future Braindump
Ag. D. Hatzimanikas wrote: > From now and on, I will encourage people to apply their ideas independently > of the opinions, and for that reason, I will please and ask the community > to give the supplies (e.g., svn access, an LFS account and the > permission to create a personal branch) to those people (with plans or a > simple desire) to work on their ideas. You really don't need permission to create a personal branch. All you need is access to *some* web server. Anyone can check out the sources and make whatever changes they want and send a link to the list. For those that have accounts on quantum, you only need to place the html in ~/public_html/. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS-6.3
Dan Nicholson wrote: > On Wed, May 28, 2008 at 11:14 AM, Juergen Beisert > <[EMAIL PROTECTED]> wrote: >> How "--enable-final" works: >> "It's just another way of compiling (it cats all the source and headers into >> one file and compiles that (hence the .all_cpp file in the error)). Usually >> it compiles a bit faster." > > FWIW, the kdebindings page has commands to undo this because it had > the exact opposite effect: concatenating all the sources made the > build much, much slower. This was due to a bug in g++. I don't know if > the GCC used for 6.3 has this fixed or not. I'd have to dig up the > emails. If the source got too big, there would be a potential for swapping on systems with relatively low memory and that would slow things down a lot. It would be useful if someone could do some timing tests with and without the switch to quantify the time savings or cost. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: X.Org scripted installation / Proprietary ATI driver
Philipp Christian Loewner wrote: I don't have time now for an in depth analysis of your comments, but we will. Thanks for the feedback. > OK, now to my question: Are there any intentions to add > the proprietary drivers of ATI / NVIDIA to BLFS? No. I don't ever see us adding anything about proprietary drivers, other than a potential comment that they exist, to BLFS. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS 6.3 Timeline?
Randy McMurchy wrote: > Zach Milton wrote: > >> If you don't mind me asking, is there a revised timeline for the release >> of BLFS 6.3 Stable? I have been seeing the message for 6.3rc2 for a >> while on the BLFS download page, and I was just wondering when BLFS 6.3 >> Stable is slated for release, as the May 25th release forcast seems to >> have come and gone. > > There have been quite a few issues identified that need to be > fixed, but they have not been addressed yet. I'll try to get > some of them fixed up and cut an RC3 version soon. It seems > development has almost come to a halt. I'm ready to tackle some tickets, but I was waiting for 6.3. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
