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
[Fwd: Re: modprobe bug for aliases with regular expressions]
--- Begin Message ---
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: 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
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: 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
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: 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
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
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: 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
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
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
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
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
M.Canales.es wrote: If decided that dependencies info will be removed from packages files and placed only into that new appendix, then the XML tagging for that appendix can be simplified a lot, or to change it to use a diferent type of list, or to use table format or elsewhere. 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 -- 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: 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-devel&m=114460333128844&w=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
El Viernes, 14 de Abril de 2006 16:14, Dan Nicholson escribió: > Fine work as usual, Chris. Anyway, I think the appendix looks great, > and I'd prefer to have the deps pulled from the individual pages. > With the info just in the appendix, you can flesh it out to useful > lengths. What's on the pages now doesn't add much. If decided that dependencies info will be removed from packages files and placed only into that new appendix, then the XML tagging for that appendix can be simplified a lot, or to change it to use a diferent type of list, or to use table format or elsewhere. Say to me if you need a new Appendix C template. -- 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
On 4/13/06, Chris Staub <[EMAIL PROTECTED]> wrote: > Bruce Dubbs wrote: > > > > 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. Fine work as usual, Chris. Anyway, I think the appendix looks great, and I'd prefer to have the deps pulled from the individual pages. With the info just in the appendix, you can flesh it out to useful lengths. What's on the pages now doesn't add much. Chris, if you need any help with anything, say the word. I'd really like to see this Appendix make it into the next release. This kind of info is extremely useful for anyone with more than a passing interest in what's driving the build. -- Dan -- 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: 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: New server specs
On Thu, Apr 13, 2006 at 08:42:48PM -0400, George Boudreau wrote:
>
>
> Randy McMurchy wrote:
> >George Boudreau wrote these words on 04/13/06 18:42 CST:
> >
> >> It is fast enough for me and does a full LFS build in well under 2
> >>hours and can render a book in minutes.
> >
> >I have a 500mhz p3 that every hour looks to see if there are updates
> >to the BLFS and LFS books. If so, it renders. LFS SVN renders in about
> >3 minutes on this box, and it's a 500mhz. Jeez, I'd hope your 3.2ghz
> >machine can also render in just a couple of minutes.
> >
> >Or perhaps did you mean seconds, and accidentally typed minutes? :-)
>
> yes, my mistake, it was seconds.. 1.05 sys, 35.1 real.
>
If we're on a data-collection exercise, my 1.8GHz athlon64 Winchester
('3000+') with 2GB of DDR333 (board is unstable at DDR200 if fully
populated), running as pure64 with ondemand cpufreq renders the LFS
trunk html in 41.1 seconds real (system is only lightly loaded).
I think any recent processor will be good enough for the moment.
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
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
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-devel&m=114460333128844&w=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: 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
