Re: Build order rationale page
Bruce Dubbs wrote: I'm not sure what I'm supposed to be seeing on the installation pages for Autoconf and Automake. Perhaps the Test Suite depends? Yeah. The appendix looks good. I do think that the dependencies should be pulled out of the individual packages. No need to duplicate it in Chapter 5 and Chapter 6. Yeah, I'm starting to think that too. However, the notes similar to 'Also note that the destdir test will always be skipped, because it only works for non-root users, and several other tests will be skipped as they depend on packages not installed in LFS' should go in the package sections and not in the dependencies section. I agree there, although I think that is only in the deps. page because Manuel, in creating the patch, was simply copying-and-pasting my comments about dependencies I had made in the ticket. Those notes certainly should go into the installation pages. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscripts contrib cleanup
On Thu, Apr 13, 2006 at 09:53:26PM -0500, DJ Lucas wrote: The enhanced rc/functions aren't completely current, but can be made so if anyone speaks up that still wants it, else I'm pulling it. I use the enhanced, but only for boot logging. If you pull it, will you be making incompatible changes to the main bootscripts? If not, I can just keep a personal patch of it until the lsb-v3 scripts arrive. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Build order rationale page
El Viernes, 14 de Abril de 2006 07:58, Chris Staub escribió: I agree there, although I think that is only in the deps. page because Manuel, in creating the patch, was simply copying-and-pasting my comments about dependencies I had made in the ticket. Those notes certainly should go into the installation pages. Right. Remember that the patch is only a POC. All can be modified if needed. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev branch. package udev.
Archaic wrote:
On Wed, Apr 05, 2006 at 01:57:12PM +0100, William Zhou wrote:
Create some rules that work around broken sysfs attribute creation
timing in linux-2.6.15:
This is still in. Either it needs to be pulled, or the version needs to
refer to the entity. Alex?
It needs to be pulled, but there's another breakage reported:
http://marc.theaimsgroup.com/?l=linux-hotplug-develm=114460333128844w=2
Apply this kernel patch:
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;h=2731570eba5b35a21c311dd587057c39805082f1;hp=dfb62998866ae2e298139164a85ec0757b7f3fc7;hb=9469d458b90bfb9117cbb488cfa645d94c3921b1;f=net/core/dev.c
The patch is also pasted below just in case if the URL is too long:
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3042,11 +3042,11 @@ void netdev_run_todo(void)
switch(dev-reg_state) {
case NETREG_REGISTERING:
+ dev-reg_state = NETREG_REGISTERED;
err = netdev_register_sysfs(dev);
if (err)
printk(KERN_ERR %s: failed sysfs registration
(%d)\n,
dev-name, err);
- dev-reg_state = NETREG_REGISTERED;
break;
case NETREG_UNREGISTERING:
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Typography Convertions
El Lunes, 10 de Abril de 2006 07:06, Bruce Dubbs escribió: OK, here it is. I also updated the chapter07/hosts.xml file as discussed earlier. Applied, many thanks. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Notification de l'état de remise
Ce rapport fait référence à un message envoyé avec les champs d'en-tête suivants : Message-id: [EMAIL PROTECTED] Date: Fri, 14 Apr 2006 15:59:11 +0200 From: lfs-dev@linuxfromscratch.org To: [EMAIL PROTECTED] Subject: Returned mail: see transcript for details Le message ne peut pas être remis aux destinataires suivants : Adresse du destinataire : [EMAIL PROTECTED] Raison : SMTP transmission failure has occurred Code de diagnostic : smtp;554 5.7.1 virus Worm.Mydoom.M detected by ClamAV - http://www.clamav.net Système distant : dns;castore.unimo.it (TCP|84.96.92.60|35538|155.185.1.150|25) (castore.unimo.it ESMTP Sendmail 8.12.11/8.12.11; Fri, 14 Apr 2006 16:11:11 +0200) Reporting-MTA: dns;sp604001mt.gpm.neuf.ld (tcp-daemon) Original-recipient: rfc822;biblioteca.reggio@unimore.it Final-recipient: rfc822;biblioteca.reggio@unimore.it Action: failed Status: 5.7.1 (SMTP transmission failure has occurred) Remote-MTA: dns;castore.unimo.it (TCP|84.96.92.60|35538|155.185.1.150|25) (castore.unimo.it ESMTP Sendmail 8.12.11/8.12.11; Fri, 14 Apr 2006 16:11:11 +0200) Diagnostic-code: smtp;554 5.7.1 virus Worm.Mydoom.M detected by ClamAV - http://www.clamav.net Return-path: lfs-dev@linuxfromscratch.org Received: from tcp-daemon.sp604001mt.gpm.neuf.ld by sp604001mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006)) id [EMAIL PROTECTED]; Fri, 14 Apr 2006 16:08:48 +0200 (CEST) Received: from linuxfromscratch.org ([84.7.87.25]) by sp604001mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006)) with ESMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Fri, 14 Apr 2006 16:01:00 +0200 (CEST) Date: Fri, 14 Apr 2006 15:59:11 +0200 From: lfs-dev@linuxfromscratch.org Subject: Returned mail: see transcript for details To: [EMAIL PROTECTED] Message-id: [EMAIL PROTECTED] MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. X-Mailer: Microsoft Outlook Express 6.00.2600. Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev branch. package udev.
Alexander E. Patrakov wrote:
Archaic wrote:
On Wed, Apr 05, 2006 at 01:57:12PM +0100, William Zhou wrote:
Create some rules that work around broken sysfs attribute creation
timing in linux-2.6.15:
This is still in. Either it needs to be pulled, or the version needs to
refer to the entity. Alex?
It needs to be pulled, but there's another breakage reported:
http://marc.theaimsgroup.com/?l=linux-hotplug-develm=114460333128844w=2
Apply this kernel patch:
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;h=2731570eba5b35a21c311dd587057c39805082f1;hp=dfb62998866ae2e298139164a85ec0757b7f3fc7;hb=9469d458b90bfb9117cbb488cfa645d94c3921b1;f=net/core/dev.c
[snip]
Rediffed against linux-2.6.16.5.
--- orig/net/core/dev.c
+++ new/net/core/dev.c
@@ -2932,11 +2932,11 @@
switch(dev-reg_state) {
case NETREG_REGISTERING:
+ dev-reg_state = NETREG_REGISTERED;
err = netdev_register_sysfs(dev);
if (err)
printk(KERN_ERR %s: failed sysfs registration
(%d)\n,
dev-name, err);
- dev-reg_state = NETREG_REGISTERED;
break;
case NETREG_UNREGISTERING:
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Build order rationale page
On Fri, Apr 14, 2006 at 04:28:16PM +0200, M.Canales.es wrote: Say to me if you need a new Appendix C template. Manuel, so far everyone has been in agreement that they like the look of it. The only thing mentioned was taking out stuff like notes about being non-root user. As far as the software dependencies and build order notes, I'd say you've already got a winner. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Build order rationale page
On Fri, Apr 14, 2006 at 10:58:08AM -0400, Jeremy Huntwork wrote: Yes, I think that's the way to go. Have the dependency info only in the appendix and then each package page pulls the info in. Actually, I was thinking that pulling anything in was rather wasted effort. Why should the individual packages list their deps when the exact same info is in the Appendix? -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Build order rationale page
Archaic wrote: On Fri, Apr 14, 2006 at 10:58:08AM -0400, Jeremy Huntwork wrote: Yes, I think that's the way to go. Have the dependency info only in the appendix and then each package page pulls the info in. Actually, I was thinking that pulling anything in was rather wasted effort. Why should the individual packages list their deps when the exact same info is in the Appendix? Well, doesn't matter to me. I just don't want the actual information appearing in the XML sources in more than one place, so if we do want that information in the rendered book in more than one spot, do some includes. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Build order rationale page
Jeremy Huntwork wrote: Yes, I think that's the way to go. Have the dependency info only in the appendix and then each package page pulls the info in. Agreed with everything else so far. -- JH That's the way Manuel's patch is now. What he is saying is to change it and *remove* that info entirely from each individual package page. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Build order rationale page
M.Canales.es wrote: Right. Remember that the patch is only a POC. All can be modified if needed. I just now realized what POC means. I feel stupid... :p -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Build order rationale page
Chris Staub wrote: That's the way Manuel's patch is now. What he is saying is to change it and *remove* that info entirely from each individual package page. Gotcha. Sounds fine to me. :) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Build order rationale page
El Viernes, 14 de Abril de 2006 17:05, Archaic escribió:
Actually, I was thinking that pulling anything in was rather wasted
effort. Why should the individual packages list their deps when the
exact same info is in the Appendix?
That is wy I'm ofering a new template.
If that is done, the special tagging in Appendix C required to can point the
package filies XIncludes to the proper place inside Appendix C isn't needed.
We could take away of that {formalpara}s and emty {para}s.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Build order rationale page
Chris Staub wrote: I just now realized what POC means. I feel stupid... :p Hehe, did you think he meant something like 'piece of crap'? ;D -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Build order rationale page
Jeremy Huntwork wrote: Hehe, did you think he meant something like 'piece of crap'? ;D -- JH *cough*of course not*cough* -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
udev-089 moves some things around
Moved: /sbin/ata_idto /lib/udev/ata_id /sbin/cdrom_id to /lib/udev/cdrom_id /sbin/edd_idto /lib/udev/edd_id /sbin/usb_idto /lib/udev/usb_id /sbin/vol_idto /lib/udev/vol_id Added: /lib/udev/scsi_id /lib/libvolume_id.so.0 /lib/libvolume_id.so.0.61.0 /usr/include/libvolume_id.h /usr/lib/libvolume_id.a /usr/lib/libvolume_id.so /usr/lib/pkgconfig/libvolume_id.pc Since the book doesn't currently use any of these helpers, I'm going to make the update. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev-089 moves some things around
On Fri, Apr 14, 2006 at 09:59:48AM -0600, Archaic wrote: Moved: /sbin/ata_idto /lib/udev/ata_id /sbin/cdrom_id to /lib/udev/cdrom_id /sbin/edd_idto /lib/udev/edd_id /sbin/usb_idto /lib/udev/usb_id /sbin/vol_idto /lib/udev/vol_id Added: /lib/udev/scsi_id /lib/libvolume_id.so.0 /lib/libvolume_id.so.0.61.0 /usr/include/libvolume_id.h /usr/lib/libvolume_id.a /usr/lib/libvolume_id.so /usr/lib/pkgconfig/libvolume_id.pc Note also that the extras/ directory contained a path_id shell script. The etc/udev/60-persistent-storage.rules file contains rules to run this script (in udev-088, it ran the script from /sbin, and -089 runs it from /lib/udev) and create /dev/disk/by-path/* symlinks so you can refer to a disk or partition by its shortest physical path. We don't have an equivalent to anything in this persistent-storage rules file, but we do install all of the helpers -- except, in udev-088, path_id. path_id didn't have its own subdirectory under extras/ in udev-088, and it didn't have its own Makefile either, so there was no way to install it using udev's own build process. But in -089, it does have both of these. So when the book upgrades to -089, I think we should add extras/path_id to the EXTRAS variable in the build and install commands, so we have this script installed. I also personally think we should install the sample persistent storage rules file, so that these helpers get used and stable symlinks get created (in my own builds, I will definitely install it). But that may not be deemed necessary for a base system. pgpelvSsJWSuS.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev-089 moves some things around
On Fri, Apr 14, 2006 at 12:56:26PM -0400, Bryan Kadzban wrote: So when the book upgrades to -089, I think we should add extras/path_id to the EXTRAS variable in the build and install commands, so we have this script installed. Indeed. I also personally think we should install the sample persistent storage rules file, so that these helpers get used and stable symlinks get created (in my own builds, I will definitely install it). But that may not be deemed necessary for a base system. How be to create persistant symlinks is still a matter of debate. I've yet to investigate pros and cons, I just know there is stuff in Trac, CLFS, the udev tarball, and Alex pointed to a link to another. Some of these may indeed be the same method (or overlap considerably) but I just haven't had time to look into it and no one seems to agree how it should be done. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Unticketed tasks to be completed
On 4/13/06, Archaic [EMAIL PROTECTED] wrote:
Chapter 6 gcc says to repeat previous sanity checks, but that doesn't
quite work. Dan has made a proposal here (which included other sanity
test changes):
http://linuxfromscratch.org/pipermail/lfs-dev/2006-March/056423.html
We need to discuss if this is effective enough, overkill, or just right.
Assuming that everyone's silence from my original post means they
think the added sanity checks are overkill, I will just mention the
one necessary change. If anyone wants to hear rationale for more
sanity checks, I will go into it.
We now check that the glibc start files (crt{i,1,n}.o) are found in
/usr/lib instead of /tools/lib during the Re-Adjusting phase. The
current check looks like this:
grep /usr/lib/crt.* dummy.log
When *startfile_prefix_spec is in effect, this is accurate. However,
after the final GCC is installed, the path is relative to the GCC
searchdirs. So, that check bombs. The glibc startfiles will be shown
to be here (on an i686-pc-linux-gnu build):
attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crt1.o succeeded
This command will continue to find the glibc start files after GCC is installed:
$ grep '/usr/lib.*crt.* ' dummy.log
attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crt1.o succeeded
attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crti.o succeeded
attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/crtbegin.o succeeded
attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/crtend.o succeeded
attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crtn.o succeeded
The only drawback here is that grep is also finding the GCC startfiles
(crtend.o, crtbegin.o) and this may confuse people since they wouldn't
be found during Re-Adjusting. Another option is to just pick one
glibc startfile or specify them all:
$ grep '/usr/lib.*crt1.* ' dummy.log
attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crt1.o succeeded
$ grep '/usr/lib.*crt[1in].* ' dummy.log
attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crt1.o succeeded
attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crti.o succeeded
attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crtn.o succeeded
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
[Fwd: Re: modprobe bug for aliases with regular expressions]
---BeginMessage---
On Fri, Apr 14, 2006 at 02:59:30PM +1000, Rusty Russell wrote:
On Thu, 2006-04-13 at 16:35 -0700, Greg KH wrote:
Recently it's been pointed out to me that the modprobe functionality
with aliases doesn't quite work properly for some USB modules.
Sorry, my bad. I got a patch for this a while ago from Sam Morris.
Originally noone was using ranges in [].
This is fixed in 3.3-pre1. I should release 3.3 proper sometime this
weekend.
So, the patch that fixes it is the patch below? (needed for distros that
don't want to rev the whole package...)
thanks,
greg k-h
diff -Naur module-init-tools-3.2.2/modprobe.c
module-init-tools-3.3-pre1/modprobe.c
--- module-init-tools-3.2.2/modprobe.c 2005-12-01 15:42:09.0 -0800
+++ module-init-tools-3.3-pre1/modprobe.c 2006-02-04 15:18:07.0
-0800
@@ -990,13 +990,27 @@
return ret;
}
+/* Careful! Don't munge - in [ ] as per Debian Bug#350915 */
static char *underscores(char *string)
{
if (string) {
unsigned int i;
- for (i = 0; string[i]; i++)
- if (string[i] == '-')
- string[i] = '_';
+ int inbracket = 0;
+ for (i = 0; string[i]; i++) {
+ switch (string[i]) {
+ case '[':
+ inbracket++;
+ break;
+ case ']':
+ inbracket--;
+ break;
+ case '-':
+ if (!inbracket)
+ string[i] = '_';
+ }
+ }
+ if (inbracket)
+ warn(Unmatched bracket in %s\n, string);
}
return string;
}
---End Message---
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Build order rationale page
M.Canales.es wrote:
That is wy I'm ofering a new template.
If that is done, the special tagging in Appendix C required to can point the
package filies XIncludes to the proper place inside Appendix C isn't needed.
We could take away of that {formalpara}s and emty {para}s.
Yeah, I also agree it would be good to eliminate that stuff from the
package installation page, and just put it all in one place. The
dependency info is useful and important, but it just isn't needed at the
time a package is being built.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
