[lfs-dev] Mailing list moves
Hi guys, A bit of a long email ahead. Please do read. Important information ahead to give you a head's up on what to expect today. A quick note on memberships: I haven't found an easy way to maintain people's passwords and their digest enabled/disabled flag. I don't want to spend a great deal more time in trying to make this work. So, in short, everybody who is currently subscribed will be moved over. You'll have to set your passwords again and turn digest modes back on if desired. There aren't too many people who use digest mode so I hope the global inconvenience isn't too great. That said, I'm moving the mailing lists today. I'll be starting this process shortly. In an attempt to prevent de-synchronizations (and subsequently extra work) I'm going to follow this process. I'm not going to send yet another email to all the lists after having sent so many already so this will serve as the head's up that downtime is imminent. Once this email is sent out and the email queue is empty (ie. everybody has received this email) I'll give some time to read it and make your final commits and posts. It's 9:45 AM CST right now. I'll start with the process outlined below (resulting in downtime) in approximately an hour. The process in a nutshell will be as follows: * Set every list to moderate all mode on old and new servers to prevent new messages from being delivered. This ensures the archives remain unchanged while they are uploaded to the new server. There's about 6 GB to upload, spanning 14 years. This will take some time. * Turn off Mailman services on both servers * Forward every Mailman related email address from old to new server. At this point any post attempts will end held in the new server's queue. They will remain there until all the archives and membership databases are imported. After the files are copied over I'll turn on Mailman services back (new server only) so databases can be imported. Moderate all mode will remain on for a while longer. After testing I'll turn the modes off on a per-list basis one at a time and send an all clear email to the list. In theory, no posts will get lost -- they just end up queued up for later delivery. However, I can't make guarantees that I won't have to flush a queue to fix problems that crop up. It would probably be best if you guys all avoid posting too much (or anything at all). You can of course try but you may end up having to re-send an email or two that gets lost. Website URLs to mailing list info and archive pages will be updated afterwards at some point as well. I don't have an ETA on all this. Please anticipate this taking the better part of the day. Thanks guys, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Apologies - the unsubscribe notification is false
Hi guys, If you just received an unsubscribe notification for this list, ignore it please and my apologies for it to begin with. This action took place as part of an import/export on the new server in preparation of moving things. You weren't actually unsubscribed -- I was just running some tests. By the time I realized my mistake the mail queue was already empty. Thanks, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Mailinglist Migration
Hi guys, This weekend I'm going to spend some time migrating the LFS mailinglists over to the new server. Along with the migration will be changes to the posting address and hostname for list management. All mailinglists will be moved over to @lists.linuxfromscratch.org instead of @linuxfromscratch.org. As a consequence the post address will change along with it. For example, lfs-dev is currently lfs-dev@linuxfromscratch.org and will become lfs-...@lists.linuxfromscratch.org I'll setup aliases to maintain backwards compatibility for some time. I'll import the membership database for each list so you don't need to re-subscribe. I'll try not to cause a flood of emails again next time. :-) Once done, I'll email each list after migration so you guys know it's finished. I did notice one potential issue: filters. Some of you, and myself included, might be filtering on the List-Id header. Its current value is lfs-dev.linuxfromscratch.org and the default new value is lfs-dev.lists.linuxfromscratch.org I'm going to try and change this so the old List-Id remains in place to avoid people's inboxes suddenly flooding when filters fail. In the event Mailman won't (easily) let me do this, consider this a head's up. Perhaps it's not a bad idea to modify filters to include a wildcard so it'll match both versions. Thanks, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Mailinglist Migration
On 2014-04-25 14:14, Gerard Beekmans wrote: This weekend I'm going to spend some time migrating the LFS mailinglists I forgot to mention: the archives will be re-instated. New server hosting allows 16 TB/month transfer (old host only 100 GB/month which is why we took the archives offline). Thanks, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [blfs-dev] Mailinglist Migration
On 2014-04-25 14:16, Gerard Beekmans wrote: On 2014-04-25 14:14, Gerard Beekmans wrote: This weekend I'm going to spend some time migrating the LFS mailinglists I forgot to mention: the archives will be re-instated. New server hosting allows 16 TB/month transfer (old host only 100 GB/month which is why we took the archives offline). Thanks, Gerard Past this message I'm going to send further follow-ups to the lfs-dev list to limit the amount of cross-posting. If anybody wants to reply, please do so on lfs-dev. Thanks, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [blfs-dev] Pending LFS Server Outage
On 2014-04-23 15:53, Gerard Beekmans wrote: Hosting company (Linode) has changed price plans and how offers additional resources for same monthly cost. This upgrade for us includes: * RAM from 8 GB to 16 GB * Shared outgoing bandwidth from 250 Mbps to 2 Gbps I'll follow-up later with the plan of attack. Downtime will be a few hours so have to schedule around this. Gerard Short notice - I'm doing the upgrade right now. The datacentre is idle and it's early that nobody is likely to use the server right now. Total downtime should be less than 3 hours. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [blfs-dev] Pending LFS Server Outage
On 2014-04-24 07:15, Gerard Beekmans wrote: On 2014-04-23 15:53, Gerard Beekmans wrote: Hosting company (Linode) has changed price plans and how offers additional resources for same monthly cost. This upgrade for us includes: * RAM from 8 GB to 16 GB * Shared outgoing bandwidth from 250 Mbps to 2 Gbps I'll follow-up later with the plan of attack. Downtime will be a few hours so have to schedule around this. Gerard Short notice - I'm doing the upgrade right now. The datacentre is idle and it's early that nobody is likely to use the server right now. Total downtime should be less than 3 hours. Gerard Server is back online. Only took 1.5 hours in the end. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Pending LFS Server Outage
Hosting company (Linode) has changed price plans and how offers additional resources for same monthly cost. This upgrade for us includes: * RAM from 8 GB to 16 GB * Shared outgoing bandwidth from 250 Mbps to 2 Gbps I'll follow-up later with the plan of attack. Downtime will be a few hours so have to schedule around this. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Server Shutdown for Maintenance
On 2013-11-27 21:54, Gerard Beekmans wrote: Hi, I'm preparing to shut the (new) LFS server down for maintenance Friday evening to take advantage of a free upgrade to double our disk space to 384 GB. The upgrade requires a storage migration and estimates say it may take approximately three hours to complete. I plan to start this close to midnight CST (give or take 1-2 hours) so the impact should be relatively minor. Thanks, Gerard I have started a little earlier to fit scheduling. At the rate it's going it should finish within the hour instead of the projected three hours (assuming the load on the host doesn't negatively affect the disk speed). Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Server Shutdown for Maintenance
On 2013-11-29 22:31, Gerard Beekmans wrote: On 2013-11-27 21:54, Gerard Beekmans wrote: Hi, I'm preparing to shut the (new) LFS server down for maintenance Friday evening to take advantage of a free upgrade to double our disk space to 384 GB. The upgrade requires a storage migration and estimates say it may take approximately three hours to complete. I plan to start this close to midnight CST (give or take 1-2 hours) so the impact should be relatively minor. Thanks, Gerard I have started a little earlier to fit scheduling. At the rate it's going it should finish within the hour instead of the projected three hours (assuming the load on the host doesn't negatively affect the disk speed). Gerard The server has finished upgrading and is booted back up. I'm verifying all services are running and doing general housekeeping. Any glitches that may exist won't exist long (and if they do, please let me know). G -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS Server Shutdown for Maintenance
Hi, I'm preparing to shut the (new) LFS server down for maintenance Friday evening to take advantage of a free upgrade to double our disk space to 384 GB. The upgrade requires a storage migration and estimates say it may take approximately three hours to complete. I plan to start this close to midnight CST (give or take 1-2 hours) so the impact should be relatively minor. Thanks, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Server Outage Saturday 10:00 PM - 02:00 AM MST
On 2013-11-02 22:47, Gerard Beekmans wrote: On 2013-11-02 22:29, Gerard Beekmans wrote: I decided on an early shutdown. It's currently half an hour before actual planned shutdown. Going to reboot Quantum to see if it'll come back online as it should. If it does, then I won't be up at 3:00 AM local time to wait for it to come back. If it doesn't come back online then it's still early enough/now/ to make arrangements to have somebody repair it in the morning. As soon as the mail queue on Quantum is emptied after sending this messages it'll go offline. Server came back online with all services seemingly up and running. Final shutdown will take place in about 10 minutes. It should come back online by itself without problems. I'll check in the morning and fix if anything didn't come back properly. Ciao, Gerard And that completes the outage. Server is back online and (important) services are back online. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Server Outage Saturday 10:00 PM - 02:00 AM MST
On 2013-11-02 20:57, Gerard Beekmans wrote: started on it. Quantum has not been rebooted in a long time so we're not entirely sure how it'll behave on the first attempt. I decided on an early shutdown. It's currently half an hour before actual planned shutdown. Going to reboot Quantum to see if it'll come back online as it should. If it does, then I won't be up at 3:00 AM local time to wait for it to come back. If it doesn't come back online then it's still early enough/now/ to make arrangements to have somebody repair it in the morning. As soon as the mail queue on Quantum is emptied after sending this messages it'll go offline. Sorry for short notice. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Server Outage Saturday 10:00 PM - 02:00 AM MST
On 2013-11-02 22:29, Gerard Beekmans wrote: I decided on an early shutdown. It's currently half an hour before actual planned shutdown. Going to reboot Quantum to see if it'll come back online as it should. If it does, then I won't be up at 3:00 AM local time to wait for it to come back. If it doesn't come back online then it's still early enough/now/ to make arrangements to have somebody repair it in the morning. As soon as the mail queue on Quantum is emptied after sending this messages it'll go offline. Server came back online with all services seemingly up and running. Final shutdown will take place in about 10 minutes. It should come back online by itself without problems. I'll check in the morning and fix if anything didn't come back properly. Ciao, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS Server Outage Saturday 10:00 PM - 02:00 AM MST
Hi guys, Quantum (old'ish server, the one running email) will be shutdown tomorrow just prior to 10:00 PM MST. The datacentre it's hosted in is shutting down power for electrical maintenance (new UPS among other things). Restart time is expected around 2:00 AM MST which means 3:00 my timezone. I may or may not be awake still at that time to check on services so it may defer until morning time. Thanks, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Server Upgrade
On 2013-05-22 12:30, Gerard Beekmans wrote: Stay tuned for more details coming soon. I had to leave town on business and did not have enough time while away to take care of this so it's come down to the wire. The maintenance window is happening tomorrow starting at 8:00 PM PDT (server's local time). This is not ideal. If I initiate the upgrade tonight we will get the free RAM upgrade and a shorter outage window. The virtual server migration is estimated to take 3 hours once it starts. I'm going to start this process around 9:00 PM PDT (which is around 11:00 PM my own time) so it'll complete overnight. LFS email shouldn't be affected (backup DNS still runs on the current mail server) but websites will be unavailable. I'll send more info tonight when getting closer to pulling the trigger on the upgrade. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Server Upgrade
On 2013-06-04 11:40, Gerard Beekmans wrote: I'll send more info tonight when getting closer to pulling the trigger on the upgrade. Still planned to start around 9:00 PM PDT (approx two hours after sending this email). Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Server Upgrade
On 2013-06-04 21:15, Gerard Beekmans wrote: Still planned to start around 9:00 PM PDT (approx two hours after sending this email). Gerard Migration is well underway. If the transfer speed doesn't drop from its current 93 MB/sec this should be done in about an hour. Fingers crossed. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Server Upgrade
On 2013-06-05 00:03, Gerard Beekmans wrote: On 2013-06-04 21:15, Gerard Beekmans wrote: Still planned to start around 9:00 PM PDT (approx two hours after sending this email). Gerard Migration is well underway. If the transfer speed doesn't drop from its current 93 MB/sec this should be done in about an hour. Fingers crossed. Gerard It's back online with double the RAM (8 GB now). Checking services and all that to make sure it's running properly. G -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS Server Upgrade
Hi guys, The hosting company where the new server is located is going through a round of upgrades including physical hardware relocation to their new facility. This means our server will need to be powered down for a while (estimated two hours or less but their total maintenance window is 8 hours). The outage window itself is June 5, 2013 between 8:00 PM and 4:00 AM PDT. Our account is also eligible for a free upgrade which also will shut the machine down and migrate to their new facility. This combined upgrade relocation will take an estimated 3 hours but if it's done before June 5, we are in control exactly when it happens and not have to deal with an entire 8 hour window. I plan to take advantage of this upgrade and initiate it some time late at night when the server usage is at its average lowest point (starting at around midnight PDT). A likely day will be on a weekend day. I will confirm the exact time of this happening. I have to prepare ahead of time to ensure no DNS outages will occur, etc. The upgrade itself will double the amount of RAM (from 4 GB to 8 GB). Disk space and monthly bandwidth remain unchanged but they are more than sufficient for our purposes already. Stay tuned for more details coming soon. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Fwd: Re: [blfs-dev] LFS Server Upgrade
Original Message Subject:Re: [blfs-dev] LFS Server Upgrade Date: Wed, 22 May 2013 15:47:49 -0500 From: Gerard Beekmans ger...@linuxfromscratch.org Reply-To: BLFS Development List blfs-...@linuxfromscratch.org To: BLFS Development List blfs-...@linuxfromscratch.org CC: Bruce Dubbs bruce.du...@gmail.com On 2013-05-22 12:48, Bruce Dubbs wrote: Stay tuned for more details coming soon. That sounds fine. I think we need a couple of additional notifications as we get closer to June 5 would be appropriate. Also, there are a few questions. Will the IP address change? Will you start up rsyncd for the mirrors to resync? Will we transition email/mailman to higgs and allow search of email? I hope to do this before June 5. It can be done any time now effective immediately so I may opt for this weekend or the one following. That way it's done on our terms with a reboot scheduled when we want vs it just happening randomly and having to check for running services at an unknown hour later on. Nothing will change. The server will just got offline for a few hours during which websites won't be available, then back up and resume business as usual. After this migration I'll fix up rsync as well. Email can begin transitioning as well, get SpamAssassin going on auto-updates and all that stuff. Gerard -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] DistroWatch donation to LFS
Hi guys, If you haven't already read this posting yet (it was also referred to in a blfs-dev post today): http://distrowatch.com/weekly.php?issue=20130304#donation I spoke with Ladislav (the founder of that site) to get some more details on what prompted all this and, well, the write up there explains it all. The roots go a bit deeper. For those who aren't aware (or have forgotten over the years), when distrowatch first started, we provided them with website hosting for a few months (a couple of server incarnations ago). It's nice to see everything come full circle in a way like this. (Any funds donated to the LFS project are always put toward the monthly server hosting fees) Ciao, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Shutting Trac down for move
I'm making the final DNS change to move Trac to the new server. It will be offline for about half an hour or so while I wait for DNS to propagate. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Shutting Trac down for move
On 2013-02-27 10:23, Gerard Beekmans wrote: I'm making the final DNS change to move Trac to the new server. It will be offline for about half an hour or so while I wait for DNS to propagate. Gerard Move completed and tested. All seems well. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [blfs-dev] Shutting Trac down for move
On 2013-02-27 10:23, Gerard Beekmans wrote: I'm making the final DNS change to move Trac to the new server. It will be offline for about half an hour or so while I wait for DNS to propagate. Gerard Move completed and tested. All seems well. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-dev] SVN and Trac freeze
On 2013-01-23 00:03, Bruce Dubbs wrote: Gerard Beekmans wrote: I am continuing the final testing and migration into the morning after taking a break for the night. I've taken the latest backup files so please don't make changes. I may not end up syncing them to the new server as the data I have right now is properly cleaned up and converted for the newer software versions. The migration should be done in principle now, barring any typos on my part that testing hasn't shown yet. For those with write access: find svn.linuxfromscratch.org in your ~/.ssh/known_hosts and remove it. The new server has new keys so SSH will fail and svn along with it. Please test it out, try a test commit or two to ensure it's working correctly and your account on the new server is also still working. When this is verified to work we'll do a round of tests on Trac and call it a day. svn, trac, and mail seem to work. The list archives still need to be made available. -- Bruce I need to re-import Trac again as the data there wasn't synced up properly from Quantum. Might be missing a few tickets. I tried to import on top and must have messed up a permission somewhere causing some files not to overwrite. I'll blow it away and try again from scratch. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] higgs and the book list
On 2013-01-23 10:56, Bruce Dubbs wrote: Ken Moffat wrote: Just checked I can access LFS on svn. r10101 and r10102 to add a testfile and then delete it. Seemed fine, but I got two mails like this - guess I'd better hold off testing that BLFS still works. ĸen Date: Wed, 23 Jan 2013 07:46:51 -0700 From: lfs-book-boun...@linuxfromscratch.org To: k...@higgs.linuxfromscratch.org ^ Subject: Your message to lfs-book awaits moderator approval Your mail to 'lfs-book' with the subject r10101 - trunk/BOOK Is being held until the list moderator can review it for approval. Right. I added you to the list of automatic accecpts for the list. We may need to look at this for a while. -- Bruce Right. That's a side-effect of it not being responsible for linuxfromscratch.org yet (that MX record points to Quantum). I'll see if we can force a domain name in SVN config setting. I think I saw an option for that. I'll figure it out. G -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] SVN and Trac freeze
I am continuing the final testing and migration into the morning after taking a break for the night. I've taken the latest backup files so please don't make changes. I may not end up syncing them to the new server as the data I have right now is properly cleaned up and converted for the newer software versions. The migration should be done in principle now, barring any typos on my part that testing hasn't shown yet. For those with write access: find svn.linuxfromscratch.org in your ~/.ssh/known_hosts and remove it. The new server has new keys so SSH will fail and svn along with it. Please test it out, try a test commit or two to ensure it's working correctly and your account on the new server is also still working. When this is verified to work we'll do a round of tests on Trac and call it a day. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] SVN and Trac freeze
Hi guys, I'd like to call a freeze to SVN and Trac for all LFS related activities (LFS, BLFS and everything else). I plan to finish its migration to the new server between late tonight and tomorrow morning depending when activity ceases (ie. when you guys have had a chance to read this email). If you want to commit a few final changes, please do so as soon as you can. If you'd like a little more time and get things done, email me and we can figure out what your timeline is vs. my own. I'll send a follow-up email with a more exact starting time. I'm aiming for a start time mid to late evening: between 9:00 PM (21:00) and 11:00 PM (23:00) CST. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Migrating websites
Hi guys, I'm going to start the process of moving over the websites now. I have disabled all cron jobs that render books and update the website in some way. These will remain disabled until everything is done which may be longer than just today. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Migrating websites
On 2013-01-08 09:27, Gerard Beekmans wrote: Hi guys, I'm going to start the process of moving over the websites now. I have disabled all cron jobs that render books and update the website in some way. These will remain disabled until everything is done which may be longer than just today. Gerard Websites have been moved over with the exception of: svn.linuxfromscratch.org wiki.linuxfromscratch.org webmail.linuxfromscratch.org Those components will come later. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Server Migration - websites, home directories, trac, svn and related
Hi guys, The next major portion of migration will involve the websites and home directories of active users. I have done an initial rsync already to make the final cut-over as fast as possible. Due to the fact all this is happening in spare time I can't give an exact time nor can I give a lot of advance notice when it will start and finish due to prior commitments with day job and family. I would like to cut-over all the websites today with a caveat regarding Trac. I'm not sure it will be done today as well. The current version of Trac needs to be more carefully validated to ensure it will work with our current data. If it can be tested and imported today then it will move over. Otherwise it will wait a bit. SVN will be migrated after the websites are done and likely after the entire email setup has been migrated also. It also needs similar validation like Trac. Shouldn't be a problem but better safe than sorry. Until all that is completed, book render scripts will be disabled on the current/old server when I start the process of moving the websites. You can still use SVN to commit changes for now but they aren't going to be live for a little while. I'll email when I'm ready for SVN to move over and ask for a freeze so as to not cause any issues. Please keep watching the lfs-dev and/or blfs-dev list. I'll email progress updates and will try to give notice when I can. Like I said, there may not be much notice at all due to the fact I'll jump on every bit of free time I end up with. I won't have much advance notice myself. Thanks, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Server's User Account Cleanup
Hi guys, I'm starting the process of backing up and removing old user accounts that have been deemed inactive. Now there is a slight chance too many accounts are being affected. We've based our list on last known and seen activity (roughly one year if we don't know for sure). Backups are taken before anything is de-activated so if you do inadvertently find your user account is no longer working, our apologies in advance and we'll chalk it up to happy trigger fingers. Please contact me directly and we'll get things fixed up right away. Thanks, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Temporary wget block
On 2013-01-01 13:21, Gerard Beekmans wrote: Hi guys, After reviewing logs I ended up having to block the wget user agent in Apache for the time being. Pages such as http://www.linuxfromscratch.org/lfs/downloads/stable/ are causing issues with wget. The block has been lifted and the website has been redirected to Bruce's server Anduin for the time being until after the migration. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS website redirected
Hi guys, www.linuxfromscratch.org has temporarily been redirected to lfsbook.linuxfromscratch.org to help facilitate in the sever migration. lfsbook is hosted on Anduin (by way of Bruce). Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Temporary wget block
Hi guys, After reviewing logs I ended up having to block the wget user agent in Apache for the time being. Pages such as http://www.linuxfromscratch.org/lfs/downloads/stable/ are causing issues with wget. The name, last modified, size and description headers are clickable links to change the sorting of the page. This tricks wget's recursive mode into thinking they are different pages. Each page ends up with 8 copies and each file is downloading at least 8 times. Looking back over previous months this is causing a lot of wasted bandwidth toward our monthly cap. The above page is just one example of a few areas where this occurs. The automated dowloads also increase the per-unit of time hit so by not letting that go on for now means the bandwidth load is spread over longer periods of time. This is just another stop-gap while the migration is under way. The new provider offers 1.6 TB/month with a soft cap so a few GB over here and there won't cause problems. We'll have more breathing room. Until then, this will cause some issues with the wget-list file provided for easy patch downloads. Hopefully not too many people will find themselves stranded. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Temporary wget block
Would an appropriate /robots.txt help things out? Doesn't look like it. The guilty hosts never attempted to download robots.txt files. Bots like Google do request those files and behave properly but those aren't the ones causing issues or dowloading duplicate files. Nor do they show up as wget/x.yy user agents in Apache logs. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Temporary wget block
Is this something we can change in the future, somewhere in the xml, or is it another of those we miss Manuel moments ? For the content of that page, I have difficulty understanding what use the alternate orders provide - there are only six links plus the parent directory, and for previous versions the maximum seems to be eight links. Even in lynx on an 80x24 screen those few linkages will always be present without scrolling. Yep it can be changed. It's an Apache config not XML in this case (the dir listings are shown when no index.html or index.php files are present). It can be turned off but have to see if it can be nicely done on a case by case basis. In other areas on the server those directory listings are a lot longer and some form of sorting might be desired (although I doubt it, it bears investigation). In the link I mentioned in my original email, there is no use for alternate orders. I just used it as an example. There are other areas (such as in archives.linuxfromscratch.org) where it makes a difference. Nothing beats a nicely rendered HTML page. It's just convenient to dump in new files and not have to worry about updating HTML files after the fact. All this will be a moot point before this month (January) is out. Later today I will try an experiment to reconfigure Apache to turn off the sorting headers and allow wget again and monitor usage and make a final determination. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Temporary wget block
Nope, that page is served out by Apache using its autoindex module. Gerard, we could just configure Apache to use 'SuppressColumnSorting' (http://httpd.apache.org/docs/2.2/mod/mod_autoindex.html#indexoptions) - it won't stop bots from downloading masses of data if that's what they're intent on doing, but for otherwise innocent scripts that are being tripped up by the column sorting hyperlinks, it'll prevent them getting multiple copies of everything. You beat me to it. That will fix the recursive wget issue but not entirely the acts like a bot, downloads the entire website, but won't honour robots.txt that Bruce alluded to as well. Just over the last two days alone there have quite a few unique IP addresses that use wget to download almost all of www.linuxfromscratch.org (682 MB) and before I disabled it, the mailinglist archives as well. The total impact of most recursive downloads was a few GB per IP address. Multiple that over a full day then over a full month and that's a few hundred GB. What we really need is a proper packet shaper; let everybody download what they want but up to a maximum rate (Mbps) and amount (MB) per time unit. We'll have that capability on the new server. Not on the current one without spending more time and effort than is worth seeing we're moving off of it regardless. I'm more interested in simple stop-gap measures while we're preparing the migration. That process won't take more than a few days to complete once it's in full swing. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Pipermail
On 2012-12-31 11:29, Bruce Dubbs wrote: BLFS Trac wrote: Also, someone broke pipermail ... Unfortunately that was done on purpose. Gerard had 500 GB over his normal download limit last month and got hit with a huge change. Most of it seemed to be downloading all of pipermail by multiple entities. We'll try to get it back when we can come up with a solution. A few things need to happen all at once to fix the underlying problem (which is: we need more bandwidth in general). The mailinglist downloads were only part of the problem. A DNS Amplification DDoS attack was another. Both have been taken care of for now to buy some time. I will post details shortly but in short it involves moving hosting providers. This process was started a while ago but I had to abandon it due to issues with the originally selected provider. A lot of change on the horizon. All good, too. Just a few growing pains along the way until it's all done. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Happy 13th
Hey guys, 13 years ago LFS 1.0 was released (Dec 16, 1999). Still continuing on today. Reading an old article from 3 years ago (http://news.cnet.com/8301-13505_3-10413589-16.html) sparked this email. The first sentence in that article reads Quick, what were you doing on December 9, 1999? If you actually remember, then there's a good chance that you're an old-school Linux type. Well, as a matter of fact, on that evening I was laying the finishing touches to LFS 1.0 and fixing the last few glitches in compiling GCC-2.7.2.3 and Glibc-2.0.7. Does anybody remember those early days? Up hill. Both ways comes to mind from that early era. Tons of fun, though! Well, here's to another 13 years of LFS. Ciao, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Andy Benton
On 31/07/2012 16:25, Bruce Dubbs wrote: With great sadness, I have to report the passing of Andy Benton. I never had the opportunity to meet Andy in person, but after several thousand posts to the lists, I think I knew him. His first post was in March 2004. Since that time he made many, many contributions to LFS and BLFS. Andy was from Prenton in northwest England and educated as an Astrophysicist in Edinburgh. His son tells me that two things made him happy: playing Team Fortress 2 and his work on LFS. Andy was 47 years old. He is survived by his Mother, Father, three sisters, wife Angie, his son Eddie, and daughter Rusti. He will be missed. A lot. -- Bruce Hi, Our hearts go out to the Benton family during this very difficult and sad time. Some of you guys have been working with me on LFS since its inception 13 years ago and Andy joining us 8 years ago has made him a permanent fixture for a very long time. We have seen each other go through life's ups and downs; marriages, birth of children, moving to other cities, starting new careers, immigrations, leaving the LFS project to pursue other goals and later on coming back to the LFS project... With everything we've been through as a team, I never once paused to think that this may come to pass as well. It took me by total surprise as it did all of you as well I'm sure. Bruce mentioned in his post that he didn't have the opportunity to meet Andy in person. I think most of us haven't had the chance to meet each other yet we all spend so much time together. It's sometimes easy to forget that all of us have lives outside of LFS and we don't know each other nearly well enough. When Eddie shared a little of Andy's life it really drove the point home. I had no idea he was educated in Astrophysics which is something I'm working towards myself as well. I would have loved the chance to sit down with him and talk about our shared passion over a cup of coffee, had we only known it was a shared passion. Andy will be missed a great deal. -- Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Server outage tonight and tomorrow night
On 29/02/2012 12:45, Gerard Beekmans wrote: Hi guys, I completely forgot to send along this notification sooner. My apologies. The LFS server will be powered off tonight around 11:00 PM CST until 4:00 AM CST and again tomorrow during the same window. The data centre we're colocated with is shutting down power to upgrade electrical grids including work on the UPS. The guys on-site will restore power once the work is completed and I'll verify connectivity in the morning. The scheduled outage for tonight has been cancelled as the data centre completed all the work last night. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Server outage tonight and tomorrow night
Hi guys, I completely forgot to send along this notification sooner. My apologies. The LFS server will be powered off tonight around 11:00 PM CST until 4:00 AM CST and again tomorrow during the same window. The data centre we're colocated with is shutting down power to upgrade electrical grids including work on the UPS. The guys on-site will restore power once the work is completed and I'll verify connectivity in the morning. -- Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Latest Changes
On 02/02/2012 03:44, Bruce Dubbs wrote: I built LFS tonight on a kvm VM. Here are a couple of comments: The total build time was 6.3 hours. The last build (LFS 7.0) on the same machine, but on the HW was 4.1 hours. That's a 50% increase in time. I'm not sure why. First thing I personally look at when VMs are slower is disk slowdowns. It's always been the bottleneck on my machines. Writing to a massive file on the host's file system is going to incur overhead and slowdown. Having a separate drive available that can be directly accessed by the VM helps. Using solid state drives has also dramatically improved performance for me; it negated the performance hit. -- Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] fedora
On 02/02/2012 15:25, Bruce Dubbs wrote: I have another reason to dislike fedora. I wanted to look at what environment variables were used and did a simple 'set' command. I got a bunch of garbage. Upon investigating, I got about 70 lines of variables and about 9600! lines of functions that could easily be in a script. Blech. -- Bruce I can one-up that. On a Ubuntu Server installation I ran 'set' and got over 10K lines back. Mostly functions. I suppose one could argue functions are less expensive than scripts. Fewer bash (or whichever shell) processes to run and less disk IO. Readability is out of the window of course if you're looking for something. I find scripts cleaner, personally. -- Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] No IRC on the new server
Hi, Unfortunately the new data centre does not allow us to run IRC of any kind (both clients and servers) and would be considered going against their AUP. If the LFS IRC channels are to continue a new home will need to be found for them. I'd like the current channel admins to give this some thought. Let me know if you have any suggestions you would like to see implemented. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS-8.0
What I wish more of the experienced folks would do is reveal the decisions they made as they built their latest system. It could be an excellent education for those of us looking for well thought out designs. Entire book can be written on such subjects. The ensuing wall of text on a mailinglist would be overwhelming but you're always free to ask questions for people to elaborate. As for myself, I never mind typing long emails if people don't mind reading them. -- Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] No IRC on the new server
On 31/01/2012 09:51, Alan Lord (News) wrote: On 31/01/12 14:37, Gerard Beekmans wrote: If the LFS IRC channels are to continue a new home will need to be found for them. I'd like the current channel admins to give this some thought. Let me know if you have any suggestions you would like to see implemented. Freenode seems to be where everyone else hangs out; and I'm sure they'd host the LFS project. Freenode provides discussion facilities for the Free and Open Source Software communities, for not-for-profit organizations and for related communities and organizations. http://freenode.net/ Al Freenode is already at the top of my list of possible locations. I'm also pursuing other options (LFS members from this list who have offered to help out). Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] No IRC on the new server
What's the delay of migration? Will we have some warning before definitive process? To inform users (especially IRC)? I'd say a month at the very least before I'd even think of turning the current/old server off. I first need to get the new server up and ready. It was pre-loaded with a CentOS version that needs to be modified and replaced with LFS. It may even be two months. It's a bit too early to tell. -- Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Server migration
Hi guys, Just a head's up that we're moving forward with the LFS server migration. Current hardware is getting old and I'm taking pro-active action to change to a newer server while we have the luxury of time before hardware failures. The server will also be moved to a data centre in the US that is giving us a much higher monthly bandwidth allowance. The migration itself will be carefully planned out so as to not cause any service disruptions. I'm in the final stages of reviewing agreements and policies. Once everything is set in stone I'll begin the process and communicate the plans of attack. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS-8.0
I think this concept is one of all/most the old farts are moving on...to be taken over by the youngens who are now thinking that they are the masters when thye haven't a clue for history. I will take the ways of unix from the 70's, It is that way for many _good_ reasons. Yes, you're right, certain things from the 70s were like that for many good reasons but some of them have become bad reasons as technology has evolved. What follows is a devil's advocate point of view in an attempt to keep an open mind and consider all sides equally. 40 years ago hardware and software were extremely limited compared to today's standards. If we never changed anything, we'd still be on 8-bit systems today with little RAM and HDD. A lot of people disliked the recent 64-bit change as well. In some ways it was a royal headache to deal with. Now we all but live breathe it and are (mostly?) happy for 64-bit architectures because it allows us to address a lot more RAM and HDD. All that additional RAM and HDD allows us to virtualize systems on just about any system and save a lot of money. LFS development is faster cheaper this way. 10 years ago it wasn't as easy of efficient having multiple computers around my desk so I could test instructions on one machine while writing the book on another. There is a fine line between following a tried, tested true method with philosophies such as why break what wasn't broken in the first place and being at the far end of that spectrum called stuck in the past. Change is sometimes painful but not all change is ultimately bad. I think it's important for everybody to at least keep an open mind. Another example is that nobody wants the Internet of the old days back when 2400 baud and slower modems were around. It wasn't necessarily broken; it worked fine, just slow. Now we have GigE Internet readily available. Progress comes at the price of adopting paradigm shifts and letting go of old and outdated ways. When we arrive on the other side, we sometimes are better off for it. Now a lot of people wouldn't dream of going back to a simpler time of 2400 baud, 8-bit computers and a couple of kilobyte of RAM. Sometimes simpler times are also the thing that hold you back from beneficial improvements. As for systemd specifically, I have to agree it feels messy and less than ideal. I wouldn't be overly happy if I were to be forced into using it. Some of its benefits do make sense even if the implementation is rough around the edges. I'm trying to at least see past that and keep an open mind for the time being. Perhaps its final implementation down the road won't be so bad. If nothing else, it's something new to play with. Whether it makes it into the LFS book is a whole different matter. There are valid plus sides to the merging /usr debate. I can't remember if this was mentioned on the freedesktop.org page linked by Bruce. If everything OS provided is together in one top level directory, it would make a lot of things simply more elegant. Backups being one of them. Sure, all those separate mount points existed for a number of very good reasons. Those reasons evolved over the decades and maybe we're truly coming to a point where they can be considered obsolete. One of those reasons was due to hard drive capacity problems. There wasn't always enough room to store all of /, /usr, /var, /tmp, /home and others on the same drive when all you had was 100-300 MB per physical drive. Having a few tools in /bin and /sbin was by some considered a work-around/hack so you could boot a mini system with enough tools to repair bring up all the other partitions into a full system that may have spanned half a dozen drives. Now that we don't have that hard drive size problem and more intelligent file systems that are harder and harder to corrupt, do we still need to stick with those work-arounds? The work-arounds have become common practice and we've adopted them as the only true way of doing things. But they were considered work-arounds by some, and eventually a work-around is removed when the original issue no longer exists or has been fixed by other means. Nowadays with multi-TB size drives space at least is no longer a concern. There were other good reasons to have separate partitions. For example, if /home filled up it wouldn't necessarily crash the system as /var wouldn't fill up. Subsystems such as email would continue to work. That concept still applies today in my opinion but we also have other ways of accomplishing that with, for example, file system quotas. It was a real nuisance in the old days when one partition ran out of space but you had tons of space on another partition. Ugly work-arounds to work around other work-arounds came to be such as symlinking across partitions so you could use a portion of /var inside /home/someuser. LVM addresses some of that where you can resize partitions dynamically without danger of data loss
Re: [lfs-dev] LFS-8.0
Just don't fall into change for the sake of change. Good point. Lookup the bumblebee fiasco on google, The bumble devs had a line rm -rf /usr /libwhat ever in a install script so you installed the app and your /usr was gone. Do you really want everything in /usr? A typo is a typo. Say you wanted everything in /usr/local/lib/googlestuff A typo could easily be rm -rf / usr/local/lib/googlestuff - I've made that mistake once in my life. It doesn't matter where you put stuff in the end. It won't be safe from a typo. Everybody can purse the change if that is what they want, just leave enough of the old for me. That's why when change happens slowly it's often better. It gives everybody a sense of being able to keep up and not feel the rug is pulled out from under them every 6 months. There are days I like pulling the rub out from under me just so learn something new. Other days I'd like things to stay the same so I can take a breather once in a while and not be out of date within a few months. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Adding LVM/RAID/initfamfs
On my system I don't always get the same device at /dev/sda. Rebooting can change my /dev/sda to /dev/sdg, or any other device letter, without any physical change in the underlying disks or cabling. This is not a problem in the eyes of the kernel devs, and will never be fixed, because there's no general way to guarantee consistent naming short of a configurable system like udev (which obviously isn't available at the time root is mounted by the kernel). Another way to work around that issue is not using static device node names if they don't end up being statically assigned. You can use a partition's Label or UUID and reference them in /etc/fstab. Running blkid will obtain the values you'll need. This makes the partitions persistent in terms of mount point even if the underlying drive gets a new name. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Adding LVM/RAID/initfamfs
Another way to work around that issue is not using static device node names if they don't end up being statically assigned. You can use a partition's Label or UUID and reference them in /etc/fstab. Running blkid will obtain the values you'll need. This makes the partitions persistent in terms of mount point even if the underlying drive gets a new name. If it wasn't entirely clear from other posts, Grub can also use those same UUIDs for its 'linux', 'linuxrd' and 'root' options. I'm not sure off the top of my head if it supports labels. I've always used the UUIDs because every partition is guaranteed to have one even if they read a bit awkward. It's also not likely to change as the years go by as opposed to labels. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Adding LVM/RAID/initfamfs
To me, the biggest reason to use initiramfs is if you want to have the root fs on a sw raid device, e.g. md0. All the other reasons are fairly exotic. root on lvm? why? On nfs? Maybe, but still exotic. Encrypted? Data, yes, but why the root fs? We have to be careful here. What seems exotic to us may be mandatory to somebody else even if we don't agree with it. It's not really up to us to judge that one way or another. I like the educational information that is presented even if it goes into a hint vs. straight into the book. Even if making the root partition part of NFS or LVM is a bad idea to some, we can make our personal opinions known but that's it; only so somebody can make an educated decision themselves vs. us making one for them. A case in point: I have Linux servers at work that are a form of thin client. The servers themselves are virtualized and don't have a significant virtual harddrive attached to them. They have a tiny amount of storage presented to them by the hypervisor node they are on - enough to hold a couple of kernel images. The kernel loads an initramfs which in turn setups networking and runs an iscsi daemon to make an iSCSI connection to the SAN where it receives its network drives from including root. Technically speaking my root partitions aren't on NFS but on a SAN which, for this discussion's purpose, might as well be the same thing. Whether it's a good or bad thing to do it this way depends on whom you ask in the end. There seems to be a trend in Linux to embrace the complex when simple solutions will suffice for most people. The first exhibit is systemd. There is a balancing act, always has been and always will be, to how much complexity we expose our users to via the book. Anything above and beyond can always be added to supplementary information (and is always encouraged). Somebody else made an emergency shell comment which is another good benefit even if some people never use it. A local harddisk user can do init=/bin/bash and have his emergency shell. When you deal with servers that are setup as thin clients like mine, a shell offered by initramfs is virtually indispensable. From our book's point of view I still like the idea of exposing a basic initramfs. Just enough to give a shell and some useful utilities if decided upon. We can leave it to hints user's own imagination to add RAID, LVM, iSCSI and other such capabilities. If we give a starting point, the community will run with it and find interesting new ways of doing things. Innovation is good. :) Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Adding LVM/RAID/initfamfs
I believe they still are. I don't think the kernel recognizes UUIDs, so an initrd (initramfs) is still needed to implement UUIDs and labels. You're right, I stand corrected. I haven't booted Linux w/o an init ram disk in so long... There is no 'linuxrd' command in GRUB2, only 'linux', 'linux16', 'search', 'initrd', and 'initrd16' with respect to this discussion. That was a typo on my part. I even opened up my grub.cfg file to make sure and still managed by combine the linux and initrd lines into linuxrd. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Direction
Learning needs to be an incremental process. Once you learn the basics, you can go on to more advanced topics. Absolutely. No argument on that one. On the other hand, setting up a initramfs may require a lot more. There have been mentions of RAID, encrypted filesystems, LVM, and networked FS. We could leave something out, but some have said they want something that will work anywhere. As we've learned in LFS' 12 years of history, there's always somebody who wants something that we're not doing. The adage you can't please everybody applies. If we decide to go through with this, we'll need to reach a compromise of course. Just about everybody can implement LVM. Not everybody has the hardware to implement RAID. That might become a driving force for making certain choices. But we don't need to completely ignore a RAID setup in the LFS book, even if we just make a reference to it and include links to other documentation (BLFS, hints or otherwise) that people can side-step into to then return to the LFS book once completed. It might actually be an eye opener to people that there is more than simple static partitions. At the point where we create the LFS partition (Section 2.2) we might as well make mention of other options. I am convinced this will make the LFS process seem more well rounded. There will be even more information available to make informed decisions and allow for more experimentation. I'd even want to go as far as considering adding a few options to Chapter 2. We already have the single partition model and mentioning the extra partitions (/home, /usr, etc). Would it be a bad idea to provide a full LVM2 example there too? Yes, it'll potentially increase the load on support but I feel it's worth exploring. For those that end up deciding against LVM for their build, the appropriate packages in the book can then be skipped. This means the LFS book will start to include more optional packages as a result and not everybody is likely to install all of them anymore. I don't feel that's a deal breaker. In the end it'll take more work to maintain the book and more work to test the various scenarios we officially provide. It'll make the book a bit more complex as choices have to be made when it comes to installing packages. The added value all that provides is well worth the extra work in my opinion. starting to build Chapter 5. This IMO is not From Scratch. I suppose that the argument can be made that running fdisk from the host is not From Scratch either, but it feels much closer to me. That's one of those compromises we'd have to decide on. There's always a downside to every good idea I suppose. There are others. Clearly we don't have to build everything, but the first decision is what to omit. Do we ask the user to build a subset just for an initramfs and then go back later if a full installation is desired? If an initramfs shell is created already, then adding more to it is easier than trying to add an entire initramfs well after the fact. The list I snipped is extensive and seems a little much at first glance. Definitely some decisions will need to be made. My overall impression is that BLFS is the right place for this with links to the appropriate packages that need to be built. Forward references in Chapter 2 and 8.3 (Kernel) and 8.4 (Grub Config) would be appropriate. My gut feeling says that a combination of LFS changes along with forward references to BLFS for other/more detailed/exotic options would be the best of both worlds. You can't put everything in LFS. I think everybody will agree on that. Adding more of what has become common these days on many systems to LFS would be worth exploring. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Direction
No objections to choice, and therefore optional packages, but it might be the thin end of the wedge - e.g. some people think autotools could be skipped, and *most* of the time the LFS book doesn't need them (unlike BLFS, which needs them a lot of times when things in the base system have changed). That issue has existed since day #1. Some people prefer to be LFS as minimalistic as possible whereas others prefer to have a well-rounded LFS system that has the parts you need for future changes. Whereas you might not need autotools during an LFS build, you are more likely than not going to need them very soon after LFS. You might never in LFS' life run fdisk after you first get LFS going but you still install them as part of the well rounded philosophy. There are countless programs and packages that fall under that category. Some are more clear-cut than others (autotools vs util-linux components). Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Direction
Putting those packages in LFS leaves them unused unless we tell the user to build them in Chapter 5, repartition, and then start over. I don't like that approach. I'm not sure I'm following that one. Which packages will be left unused and why would you need to repartition (presumably you're referring to the LFS partition created in Chapter 2) in Chapter 5? Have you looked at section iv recently? The Appendices, sure. What are you getting at? Put LVM/RAID/etc information in an appendix with a forward-reference in Chapter 2 for those users interested? -- Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Direction
On 14/01/2012 07:14, Andrew Benton wrote: On Sat, 14 Jan 2012 01:22:45 -0800 Zachary Kotlarekz...@kotlarek.com wrote: But yes, if you want to do a modules-only build you do need to rebuild the initramfs when you change kernels. Or at least the /lib/modules bit of it. My point was just that, since the current direct-boot method is you must be able to mount root from the monolithic kernel the initramfs does need to be rebuilt just to change kernels. I think that initramfs/LVM sounds very interesting but I don't think it should go in LFS (at least, not straight away). Perhaps a section of BLFS could be made describing what is needed? One of the downsides with putting those things in BLFS is that people then find out about them too late. If you want to setup a system with initramfs and LVM configurations, that needs to be done early on in the LFS book. If you find out after the fact you end up having to re-do the LFS installation again. A compromise solution would be to still do a write-up about the various options in the LFS book. Explain what it's all about, the pros and cons but if it's decided to be out of LFS' scope then refer to the appropriate sections elsewhere. This keeps the work flow intact: make a sound and informed decision on how to partition your system early on. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Direction
Hi guys, I'd like to discuss the direction of LFS with respect to where upstream developers appear to be going. I've read the comments posted by other everybody else to date and there are good reasons both for and against changing certain aspects such as the initramfs vs. non-initramfs camps. Even if there are very good reasons not to add it to the book, mostly for simplicity reasons, I say make the changes anyway for the following reasons: 1) Simplifying too much does not illustrate what has become a very common setup on almost every system you encounter these days. The idea of LFS has always been to educate as to what is going on. If a just finished LFS system can't begin to explain how a regular distribution works, what the deal is with their initramfs setups and so on, then LFS has missed the mark, its primary purpose. It makes it less relevant in today's climate. 2) Adding complexity to the book is not something to necessary shy away from. Rather, it makes the experience more dynamic and it illustrates all the major choices you have (initramfs or not, LVM2 or not and so on) these days. LVM2 is a wonderful tool when you get past the learning curve. The LFS server itself was built on top of LVM2 and it has come in very handy over the years re-arranging things. The book often focuses on one way of doing things to simplify support. If there is only one right answer to be had (and I double-quoted the word right there on purpose) then it's easier to support them. That is a valid point but being too rigid is not good either. Offering more options make people feel less like they are following a recipe and feel more like they had a chance early on to customize their system. We all hear comments I wish I had seen this hint sooner or read a section in BLFS sooner; now I have to redo all/most of the LFS system from scratch, again. There is great value in rebuilding an LFS system many times if you want to. Being forced to do so is nothing but tedious and not always enjoyable. That affects the user's experience. -- Gerard Beekmans -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Happy New Year
Good afternoon guys, I'd like to wish you all a Happy New Year. Hopefully you all are well on your way to recover from last night's partying. Ciao, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS' future server plans
Hi guys, The LFS server recently passed its five year mark. While there are still no indications yet of hardware problems or degraded performance due to aging components yet, I've started to pro-actively look at options to replace the server. After all, it's better to be pro-active than reactive in these cases. A second reason for doing this is that the server is currently co-located in Calgary, AB, Canada but I myself don't live near Calgary anymore. A couple of months ago I moved to Winnipeg, MB. If anything were to happen to the server now, I'd have to fly out to Calgary to deal with it. I'm sure I don't have to explain the issues with that. I'm looking at two ways of dealing with the LFS server: 1) Acquire a new server and co-locate it here in Winnipeg. 2) Turn the LFS server into a Virtual Private Server (VPS) with some company which won't be restricted to Winnipeg in that situation because we wouldn't be responsible for the hardware. I'm awaiting responses from a couple of companies in Winnipeg that offer co-location services. When I have all the numbers I'll put together a financial picture for both options and go from there. Regardless of the option chosen, there will be a period of migration where we move services from the current server to the new one. It shouldn't cause too many headaches in terms of outages and extended downtime. It won't be 100% unavoidable either so this will just serve as a head's up that it'll be coming down the pipe soon. This period of time where we discuss migrations would be a good time for us to discuss any wholesome changes we might like to implement. We can start off with a new server and a clean slate instead of blindly replicating the current setup and methods without any thought to it. As always I'm open to any and all suggestions regarding both the server itself and the aforementioned potential changes that could be implemented. -- Gerard Beekmans -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS' future server plans
On 11/09/2011 14:20, Bruce Dubbs wrote: Gerard Beekmans wrote: Hi guys, The LFS server recently passed its five year mark. While there are still no indications yet of hardware problems or degraded performance due to aging components yet, I've started to pro-actively look at options to replace the server. After all, it's better to be pro-active than reactive in these cases. A second reason for doing this is that the server is currently co-located in Calgary, AB, Canada but I myself don't live near Calgary anymore. A couple of months ago I moved to Winnipeg, MB. If anything were to happen to the server now, I'd have to fly out to Calgary to deal with it. I'm sure I don't have to explain the issues with that. I'm looking at two ways of dealing with the LFS server: 1) Acquire a new server and co-locate it here in Winnipeg. 2) Turn the LFS server into a Virtual Private Server (VPS) with some company which won't be restricted to Winnipeg in that situation because we wouldn't be responsible for the hardware. I'm awaiting responses from a couple of companies in Winnipeg that offer co-location services. When I have all the numbers I'll put together a financial picture for both options and go from there. Regardless of the option chosen, there will be a period of migration where we move services from the current server to the new one. It shouldn't cause too many headaches in terms of outages and extended downtime. It won't be 100% unavoidable either so this will just serve as a head's up that it'll be coming down the pipe soon. This period of time where we discuss migrations would be a good time for us to discuss any wholesome changes we might like to implement. We can start off with a new server and a clean slate instead of blindly replicating the current setup and methods without any thought to it. As always I'm open to any and all suggestions regarding both the server itself and the aforementioned potential changes that could be implemented. anduin.linuxfromscratch.org is hosted by Server Beach. I did get a special deal so it costs about $50/month, but I never have to physically touch it. The tricky part of a remote system is building a LFS system remotely and then being able to boot into it. They do have a way to get to a virtual system where an arbitrary partition can be mounted and corrections made to fix a boot problem. I have some contacts with Rackspace too. They are headquartered here in San Antonio and they host the SATLUG server (www.satlug.org) for free. That system is physically in Dallas and I never touch it either. I could make some inquiries to see if LFS could get the same deal. -- Bruce Thanks for looking into that, Bruce. I'd love to get additional options. A server not being close by physically won't have to be a problem as long as there are arrangements made for hardware maintenance and replacements so we're not left high and dry should something crash. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS' future server plans
On 11/09/2011 18:09, Ken Moffat wrote: On Sun, Sep 11, 2011 at 01:40:27PM -0500, Gerard Beekmans wrote: This period of time where we discuss migrations would be a good time for us to discuss any wholesome changes we might like to implement. We can start off with a new server and a clean slate instead of blindly replicating the current setup and methods without any thought to it. Maybe, moving to git instead of svn ? Git is a bitch to become comfortable with [ I dropped out of clfs when they moved to it ] but it does make branching easy. Perhaps that isn't an issue in LFS, in which case feel free to ignore this suggestion. Also, can we do anything about getting list emails out quicker - for a long time now, my posts and replies to the lfs lists seem to take two or three hours to come back to my inbox ? ĸen I agree on the issue with Git and that it appears to be overkill for what LFS needs. But, seeing you raised it, let's at least give it an honest discussion before summarily dismissing it. As for the email delays; that appears to be a Mailman problem. When there are a lot of bounce messages in Mailman's queue (in its qfiles/retry and qfiles/out directories) it can significantly delay the processing of new emails if there are a number of retries ahead of a new message in the queue. Deploying a new server will automatically fix that problem due to a newer version of Mailman that has addressed this issue. Speaking of mailing lists. I wasn't going to bring it up yet but I have toyed with the idea for several years now of moving away from the idea of email based mailing lists and moving to a forum based system. Before all us old timers (myself included) have a virtual aneurysm, just think about it for a while and get at it from different angles. As an example why to even consider this: as time goes by and technology advances, I am spending less and less time at a computer that has my email programs installed and more time on mobile devices (phones and tablets). Accessing emails to read mailing lists in that way is an exercise in frustration so I've stopped trying. A web based forum would solve that problem. Sure, I could filter email on the server and access via a decent IMAP program and call it a day. But I don't and it's besides the point. Not everybody has that option and needs to download email to their computer before it can be sorted, managed and read efficiently. I think in the end it just comes down to: email based lists made sense 12 years ago when LFS started. It's how things were done back then. I think it's valid to think about a paradigm shift and move to a more efficient technology so we can more easily access LFS from myriad of our computers, mobile devices, tablets and so forth. Some food for thought. Think about it. Comment on it. As always, opinions count. I'd love to hear arguments for both ideas. -- Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS' future server plans
and, weirdly, this came back to me quickly - my recent posts to -support, where speed might be more important, were a lot slower. See previous email I sent just before this one. I cleared the backlog and queue in Mailman. It should be speedier across all lists now. Until it bogs down again. -- Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS' future server plans
On 11/09/2011 21:13, William Tracy wrote: This may not advance this particular discussion very much, but: What I would love to see, and what I'm actually surprised that nobody in the FOSS community has built yet, is a discussion board system with a separated back-end that can be attached to multiple front-ends. The same install could have a web-based front-end and an email front-end, and both would be first-class citizens. (Bonus points if the different front-ends can share account information, so you can post the email interface from home, and the web interface on a public computer somewhere, and the system will understand that both messages come from the same account.) From there, you could extend the system with an arbitrary number of front-ends: A client that pushes new thread notifications to Twitter? Sure. A bot that pushes new post information to IRC? Sure. A client that automatically generates a new post with every push to revision control? Sure. Multiple web front-ends, because someone wants an app written in PHP, and someone else wants an app built with Ruby on Rails? Sure. I already have enough projects on my plate, but if anyone out there wants to build this, I might be able to pitch in. :-) William Tracy afishion...@gmail.com mailto:afishion...@gmail.com Cell phone: (805) 704-0917 Internet phone: (707) 206-6441 I definitely like where you're going with that idea. It's ambitious but luckily bits and pieces already exist and could be leveraged. I'm not sure this is something we can just slap together for the new LFS server during its initial launch due to the time involved. But I do like it. -- Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ticket 2412 - Toolchain Technical Notes
An example of how the host can corrupt the temporary libraries when you don't cross-compile would be very educational as well. It helps in proving that cross-compiling really is recommended. I don't think the above is applicable. If it's not applicable then that note should be removed from the book. I copy and pasted from that page that says corruption could become an issue I don't recall explicit problems, but I didn't run the ICA analyses. If true, then that ties in with my previous comments. The notes as they appear in the book right now hint toward issues if we don't build a cross-compiler (even if it's only a cross-compiler that compiles for itself as we only change the vendor portion of the TGT, not the fundamental architecture itself). Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ticket 2412 - Toolchain Technical Notes
You are arguing because of an implication that, quite honestly, I don't see. I'm not trying to be argumentative. To me it's just seeing a technical explanation that feels incomplete. Some claims are made that then aren't further explained. I'll have to admit that I don't remember all the nuances right now either to come up with a replacement explanation on the fly. Some explanation is always better than not at all. This'll have to be fleshed out more. I'd like to keep this ticket open but lower priority for now. It's not going to have a be a show-stopper but something just doesn't feel right about leaving this the way it is. Or close it for now if you prefer. It can always be re-opened again in the future as part of a bigger overhaul. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ticket 2412 - Toolchain Technical Notes
I agree but I still don't see what is not explained. I've re-read your post from yesterday several times. Are you saying that we should explain the process of cross-compilation? To me it is reasonably obvious that if you use cross-compilation techniques then the system can't use resources from the host architecture. That one word can't actually makes the difference. When you put it that way it makes perfect sense why LFS would do something like that. We don't ask that our users be programmers, but trying to explain *how* cross-compilation removes all dependency on the host system seems to be beyond the scope of the book. To really understand the cross-compilation process, I think you need to be a programmer who understands compiler construction. True, but only to a point. I think we should make an effort to at least explain the basics. It's a great topic to teach somebody. I know the book's scope would preclude us from going into all the nitty gritty detail because it would probably become a book onto itself. But that doesn't mean we can't add some. The how is too in depth. But the why is more important. The temporary libraries are cross-compiled. Because a cross-compiler cannot rely on anything from the host system, this removes any potential contamination of the target system by lessening the chance of headers or libraries from the host being incorporated into the new tools. Cross-compilation also allows for the possibility of building both 32-bit and 64-bit libraries on 64-bit capable hardware. Just about does it. How about the following to really drive the point home (and to explain that it's the way it is, not because we decided it): As a cross-compiler by its nature cannot rely on anything from its/the* host system, this method removes any potential contamination... * pick the better of the two words. I'm not sure which one is semantically more correct. It likely doesn't even matter much. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
RE: Ticket 2412 - Toolchain Technical Notes
What more do we need to add? Or can we just close the ticket? I think it was addressed in the updates Matt made about four months ago and about 2 months after ticket 2412 was opened. I'm happy to close that ticket off, I don't think it needs any more explanation but am open to suggestions. I'll close the ticket on Monday if we've had no further comments, if that's OK? I think it can use a bit more refining. I'm writing this email without relying on existing knowledge. If I read the page as-is without having any additional knowledge in the area of cross-compiling, it doesn't quite make sense yet. There are the three bullets that explain three key technical points. Comments on the first two: 1) Slightly adjusting the name of the working platform, by changing the vendor field target triplet by way of the LFS_TGT variable, ensures that the first build of Binutils and GCC produces a compatible cross-linker and cross-compiler. Instead of producing binaries for another architecture, the cross-linker and cross-compiler will produce binaries compatible with the current hardware. 2) The temporary libraries are cross-compiled. This removes all dependency on the host system, lessens the chance of headers or libraries from the host corrupting the new tools and allows for the possibility of building both 32-bit and 64-bit libraries on 64-bit capable hardware. We should add why cross-compiling removes all dependency on the host system. The statement as-is implies that regular compiling does not yield the same result. That has to be explained rather than just taking the statement at face value. Providing an example would go a long way to illustrate the problem. An example of how the host can corrupt the temporary libraries when you don't cross-compile would be very educational as well. It helps in proving that cross-compiling really is recommended. This whole portion of the build process plays a very important role. Right now that one page doesn't explain the many issues that cross-compiling overcomes. One of the questions that may come up is why we didn't cross-compile in older versions of the book. We obviously encountered problems and changed the process in the book. But the rationale behind that is still missing and not clearly explained. Please keep in mind the above comments are written by ignoring any knowledge that somebody might actually have. Put yourself in a reader's shoes who is pretty new to this compiling thing and in particular cross-compiling. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-BOOK PDF generation
Alright. I've enabled the PDF section in the nightly LFS render script. I'm running it through cron ahead of schedule in a few minutes to make sure it's able to find all the JDK, FOP and FAI stuff. That seems to work properly now. PDF is added to the nightly generated files. While I was at it, I rescheduled the cron job to generate the nightly files at 1:00 AM rather than 4:15 AM it used to be. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Next time somebody arrives at Chapter 5 - GCC Pass 2, please try the following...
Hiya, Next time somebody arrives at Chapter 5 - GCC Pass 2, can you deviate slightly from the book and try out the change mentioned in Ticket #2413 at http://wiki.linuxfromscratch.org/lfs/ticket/2413 I just deleted my Chapter 5 so I was wondering if one of you guys is already in the process of running a test. If so, it'd be appreciated if you can try out the suggested change in that ticket. Its milestone is currently 7.0 but I think it makes a fine 6.5 candidate as it's a quick easy one. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
More frequent snapshots of SVN
Hi, Currently http://www.linuxfromscratch.org/lfs/downloads/development/ refreshes once a day. Seeing it only takes about 1.5 to 2 minutes to generate those files, there isn't any problem updating those files more frequently. Once an hour seems reasonable. On the other hand, it'd be a waste of resources to keep regenerating the same book version over and over again when no changes have been made. I considered making it a live update--as soon as something is committed to SVN, update the downloadable files. The downside of that one is if there's a flurry of activity, it could end up regenerating the book several times in a row for no added benefit. Perhaps a good compromise is to attempt an hourly regeneration of files unless it detects no SVN changes have been made since the last time. I'm going to look at the latter option (conditional regeneration) to see how we might go about this. Any comments are welcome. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Next time somebody arrives at Chapter 5 - GCC Pass 2, please try the following...
Trent, for file in gcc/config/linux64.h gcc/config/linux.h gcc/config/sysv4.h; Right, I totally forgot about the other architecture subdirectories. I briefly considered just now modifying that to for file in gcc/config/*/file.h but then it won't match files in the gcc/config directory and only looks in sub-directories. Right now that'll drop at least one file that I know of (gcc/config/linux.h). This ticket will be closed wontfix. The current way of doing it is the easiest to type and least amount of code. Thanks for that, Trent. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: More frequent snapshots of SVN
Changes more than once a day may be confusing. The book is now identified by a date. If there are different versions with the same date, it could cause a new user a problem. Developers, on the other hand, build in their own sandbox and don't need the site to do it. I'd recommend leaving things as they are and render once or at most twice a day. Points well made. An additional side-effect that I just realized: we might have people reading the dev book online and suddenly they go to the next page and the page either doesn't exist (anymore) or it was recently modified and their chapter 5 or chapter 6 builds are suddenly at risk (say an important change was committed right between the reader's binutils or gcc passes). This could potentially also happen if they start one day and finish the next day (as the book re-generated during that time) but it being a 24 hour window, the risk is a reduced one at least. I'll leave status quo for the time being and sit on this for a while. Maybe we'll revisit it at a later time. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.5 Status
Hi Emmanuel, It seems that the attachement has been remove. So here is the patch. Patch came through properly the first time around, at least on my end. I have added the patch to the corresponding Trac ticket. The suggested edits seem pretty straight-forward and I don't think there are any issues to accept them as-is. Thanks, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.5 Status
#2326 Modifications to Preface gerard Some changes have been made. Waiting for final review to close. #2092 Switch all text back from third person to second person pronouns gerard Some fixes have been made. We can probably promote this to 6.5 Agreed on #2092. It's set to Milestone 6.5 now. I think I caught the bulk of the 3rd person edits. A few extra pairs of eyes are always appreciated. The Preface is about done I think, but any additional suggestions are welcome. If nothing else, a grammar check is welcome (ESL and all). I'll assign that From Power Up To Bash Prompt ticket to myself as it fits within the scope of the Preface. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS-BOOK PDF generation
Hi, I just installed the missing pieces on the server to allow PDF generation again (JDK, FOP and FAI). First attempt to render the PDF seems to have successful minus a few warnings regarding missing fonts and an overflow problem in a paragraph. Generated PDF is here: http://www.linuxfromscratch.org/~gerard/LFS-BOOK-20090526.pdf Have a look, see if you can spot any obvious issues. If it appears decent the daily snapshots can include PDFs again. The warnings mentioned earlier on this first attempt are as follows. May 26, 2009 8:03:58 PM org.apache.fop.fonts.FontInfo notifyFontReplacement WARNING: Font 'Symbol,normal,700' not found. Substituting with 'Symbol,normal,400'. May 26, 2009 8:03:58 PM org.apache.fop.fonts.FontInfo notifyFontReplacement WARNING: Font 'ZapfDingbats,normal,700' not found. Substituting with 'ZapfDingbats,normal,400'. May 26, 2009 8:03:59 PM org.apache.fop.fonts.FontInfo notifyFontReplacement WARNING: Font 'ZapfDingbats,italic,400' not found. Substituting with 'ZapfDingbats,normal,400'. May 26, 2009 8:04:04 PM org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm updateData2 WARNING: Line 2 of a paragraph overflows the available area by 43200mpt. (fo:block, location: 1824/2298) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Book's Makefile leaves temporary files behind
Hiya, I can't remember if there was an ulterior motive for this or not. After generating the book, a few temporary files were left behind: - lfs-full.xml - lfs-html.xml - lfs-pdf.fo - lfs-pdf.xml These files are all removed by the 'tmpdir' target that runs just before 'validxml' so it's not a big deal. Except it's clutter *after* generation unless there's a reason to keep those files around? Besides for debugging purposes that is. For that we could easily introduce a variable to switch on/off that behaviour. Comments? Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-BOOK PDF generation
I looked for the overflow, but couldn't find it. I would have thought it might have been one of the boot or udev scripts, but I didn't spot the problem. You might look at the lfs-pdf.fo and see if you can get to block 1824. I think that 1pt == 1000mpt == 1/72 inch so we are looking at 43.2 pts or about a half inch. The blocks don't seem to be numbered nor one block per line. Anybody feel like counting? It seems to me this issue is too long of a line in a literal output type section. I'm not going to worry about it too much right now. Maybe there ends up being an easy to way to track down the exact location in an easy way. I'm sure there's a way. I just don't know it yet. :) Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.5 Status
Gerard, I took the liberty of making several grammar/wording changes in the preface. If you are OK with them, I think you can close #2326. I've been going over the book for a couple of days now and no 3rd person text jumped out to me. We may be OK with #2092 also. We can always make quick changes as they get identified. I'll close both. I'm sure future adjustments will take place, but no need to keep a dedicated ticket open for those. Thanks, Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-BOOK PDF generation
I tried running make pdf on quantum, but got: /bin/sh: fop: command not found I didn't add the JDK and FOP directories to the global $PATH yet. Add the appropriate lines to your .bash_profile or .bashrc: PATH=$PATH:/usr/fop export JAVA_HOME=/opt/jdk export ANT_HOME=/opt/ant and to .foprc FOP_HOME=/opt/fop FOP_OPTS=-Xmx2024m (The last line per BLFS instructions and I just took the RAM amount as per free -m output to get started). -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-BOOK PDF generation
I think I found it. In the very last page of the index:
# /usr/include/{asm{,-generic},drm,linux,mtd, rdma,sound,video}/*.h:
Linux-2.6.29.4 API Headers
While I appreciate the way that's written, it's hardly readable and it
does take a few careful looks to actually construct the final list of
files in your head.
Let's break that up into the individual components. It'll mean a few
extra lines of text, but it will greatly enhance readability.
Do you want to work on that Bruce or shall I? If you've already started
work on reformatting it, I'll let you finish it off otherwise I'll
tackle it tonight.
Let me know.
Gerard
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LFS-BOOK PDF generation
Go for it. I've gost several other items working. Working on it right now. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-BOOK PDF generation
Some lines are wrapped, but one or more of the 3 lines that have:
/usr/include/{asm{,-generic},drm,linux,mtd,rdma,sound,video}/*.h
are causing the problem. We can probably fix it by breaking that up into
multiple entries in the seglist item and multiple varlistentry items.
That line would translate into the following individual entries
(alphabetized):
/usr/include/asm/*.h
/usr/include/asm-generic/*.h
/usr/include/drm/*.h
/usr/include/linux/*.h
/usr/include/mtd/*.h
/usr/include/rdma/*.h
/usr/include/sound/*.h
/usr/include/video/*.h
I'll start on splitting up the list, creating extra index, term, etc
tags using the above list.
G
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LFS-BOOK PDF generation
The line overflow has been fixed by creating individual index entries rather than one long one in shell-syntax presentation. Makes it easier to read as well as discussed elsewhere in this thread. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-BOOK PDF generation
Looking at the dingbats, http://en.wikipedia.org/wiki/Dingbat, I don't see where italic or bold dingbats make sense. We can just ignore these warnings. Alright. I've enabled the PDF section in the nightly LFS render script. I'm running it through cron ahead of schedule in a few minutes to make sure it's able to find all the JDK, FOP and FAI stuff. G -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Server outage
Hi, I'm sure some of you will have noticed a server outage earlier this morning. The problem is corrected and I will be monitoring the hardware to make sure it stays that way. There are no clear indications what went wrong and I didn't take the time to drive to the data center to take a look at it. I had an on-site tech restart the server instead and things appear to be fine now. If you notice something not working right, just let me know. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: A new year with a lot of memories
Hey Enrique, snip Thanks for your encouraging feedback. It's always nice to hear such reports PS: My only gripe is that I used to bring people to the LFS page and show them how the different penguin icons matched the different stages of the book. It ripped lots of smiles. Pleasure gone... :( lol yeah I do think it might be time for a new logo one of these days. It's getting a little dated, eh? Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
A new year with a lot of memories
Hi guys, You all know that saying time flies when you're having fun, right? The idea behind LFS first came to be in the first few months of 1999. The exact date has since been lost so I've taken to assume January for convenience reasons. This means that with a 2-3 month margin of error we have just launched into our 11th year. I think that's pretty note-worthy in and of itself. Anyways, just wanted to share that. That realization came with a lot of memories. Good job guys and there's to 10 more years! :) Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Mailing lists archives
Any (easy) way to to remove the Downloadable version from the archive list overview? I imagine it's easy. I mean, we got the source code, right :) I'll have to looking into the Python source. I didn't see a configuration item to turn that on or off at will. Granted, I admit I didn't look very hard either so I'll give it another shot and perhaps RTFM while I'm at it...such an add concept. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Mailing lists archives
Or compress them. Maybe make them only available to subscribed members. I wanted to grab the last two months of the blfs-support mailing list archive. Maybe someone can email me the files. Compressing is an option but would also require some Mailman modifications, or a helper script running through cron - the various files that make up an archive are automatically updated each time an email arrives (ie email contents is appended to an mbox and txt file). We don't want to run bzip2 on the mbox or monthly txt files each time an email arrives. The compress operation would take a while and a half dozen more emails could arrive, making that a never ending cycle. A nightly or weekly snapshot would be a compromise there. In the mean time I'll send you the last two months of blfs-support to your email address in a few minutes when I have it tar'ed up for you. G -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Mailing lists archives
I'll have to looking into the Python source. I didn't see a configuration item to turn that on or off at will. Granted, I admit I That should be taken care of now. The archive pages will re-generate themselves when new messages to the lists start to arrive. The template was updated to not show download links anymore for the archives. I will re-evaluate this again soon to see if it can be turned back on, compressed, or something else. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: PDF files in */downloads/ compressed - removed uncompressed versions
Thanks for informing us that there is a demand for PDF versions. Is it possible to have some figures about the bandwidth consumed by HTML versions of LFS and BLFS books (preferably separate for stable development versions), artwork, stuff in public_html, and PDFs, just to compare? I'm working on tweaking the Webalizer output to show all that stuff. The default settings right now only show the top 10 or so in categories. Need to change those settings to show the actual specific files we want, even if they aren't in a Top 10. The default stats are here: http://quantum.linuxfromscratch.org/webalizer/www.linuxfromscratch.org/usage_200806.html If you go up a level there are other web sites that can be checked (archives.linuxfromscratch.org and other old no-longer-in-use ones but are still in apache's vhosts). I put some additional settings in place that hide things like RSS, CSS and graphic files. Though in retrospect it'd be nice to have RSS stats as well. These stats started on June 15 so not much to go by yet, but already quite a bit of data uploaded in such a short time. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
PDF files in */downloads/ compressed - removed uncompressed versions
In an effort to save a large amount of bandwidth I've compressed the PDF files that haven't been compressed yet and removed the uncompressed files in the download sections. This'll conserve some bandwidth and associated charges that go along with it. In the last few days alone the server has uploaded several gigabytes worth of LFS and BLFS PDF files. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Moving 'setclock' to earlier in the boot sequence
I think it's always the right thing to get the kernel file systems mounted, modules loaded and devices created as soon as possible. I don't believe the cleanfs issue is important enough to merit wedging the setclock script in front of those steps. I'd personally rather change cleanfs to operate in a different way that's independent of those 3 services. Look at it this way as well. If you wanted to keep track of boot logs and whatnot with timestamps, they are pretty useless if the time is wrong. Of course there's the argument that you then will want to sync with an NTP server as well while you're at it. However, to at least set the CMOS clock to proper time (with timezone conversion if needed), is a step up to get the boot logging a bit more accurate. G -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Future Braindump
packages included in the book would be included, equivalent to the current index of the BLFS book. If there is interest, I can try to hack up a quick version of this idea. A visual representation of those ideas is most always the quickest way for people to truly understand what you're trying to accomplish and convey. I'd be interested to see how similar or different your ideas are from other people's suggestions. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Moving 'setclock' to earlier in the boot sequence
Please see http://wiki.linuxfromscratch.org/lfs/ticket/2160 The ticket is about a potential issue with bootscripts and from it came a suggestion to move the setclock call to earlier in the sequence. It would help to address the issue but also having the system clock set accurately earlier is good for other things. Is there any reason why we wouldn't want the system clock set properly using the 'setclock' script right after modules are loaded and udev is setup? If there are no technical objections this will become a new Trac ticket. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
