Re: Surprise! (Re: HEADS UP: Port recompiles needed (Re: Unknown symbol __sF))
On Tue, Oct 15, 2002 at 11:14:49PM +0200, Hellmuth Michaelis wrote: I am really, really astonished: all went smoothly! XFree86-4, the complete kde3 (i never managed to compile kde on stable or current before without the need to adjust something !), Staroffice52 and vmware all compiled out of the box and ran out of the box (just vmware2, i had to relink /compat/linux/dev/vmnet1 to /dev/vmnet1). The rest is not worth to mention, i did not noticed _any_ showstopper yet! This is cool! I'd like to thank everyone involved for the good work! Excellent, thanks for the valuable datapoint! Kris msg44736/pgp0.pgp Description: PGP signature
Unknown symbol __sF
Had a very bad night after upgrading my main machine from a September-based current to a -current as of yesterday, for many, many of the programs running on that machine i got an error message like /usr/libexec/ld-elf.so.1: . Unknown symbol __sF which somehow came from this ancient library in /usr/lib: lrwxrwxrwx 1 root wheel 11 Mar 29 2002 libgcc.so - libgcc.so.2 -r--r--r-- 1 root wheel 21343 Apr 4 1999 libgcc.so.2 moving the libraries out of the way just gave an error about not finding libgcc.so.2. One of the affected programs was postfix. After nothing helped, i installed a complete fresh ports tree and recompiled postfix-current, but when make installing it, even there it complained about Unknown symbol __sF and i was not able to install it. Luckily i had saved the /usr/obj and /usr/src, downgrading to the old current stopped the nightmare and i'm writing this again from the September-based current. Is there help in sight or do i have to do a complete, fresh reinstall on this machine (Oh no ;-) ) ? tired, hellmuth -- Hellmuth MichaelisHamburg, Europe[EMAIL PROTECTED]www.kts.org There is a difference between an open mind and a hole in the head. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: Port recompiles needed (Re: Unknown symbol __sF)
On Sun, Oct 13, 2002 at 10:22:48AM +0200, Hellmuth Michaelis wrote: Had a very bad night after upgrading my main machine from a September-based current to a -current as of yesterday, for many, many of the programs running on that machine i got an error message like Peter removed the stdio transitional aid for older -current systems. This means that older 5.0 libraries are no longer compatible with the new 5.0 libc, and you will need to recompile everything that depends on them. 4.x applications (i.e. things that link with libc.so.4) should be unaffected. This is a required change for 5.0-RELEASE. Doing a 'make world' followed by 'portupgrade -a -f' should be sufficient to rebuild everything correctly. Alternatively, I'll have new packages built in a few days, and you could just reinstall your packages with those. Kris msg45294/pgp0.pgp Description: PGP signature
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
On Sun, Oct 13, 2002 at 01:38:12AM -0700, Kris Kennaway wrote: On Sun, Oct 13, 2002 at 10:22:48AM +0200, Hellmuth Michaelis wrote: Had a very bad night after upgrading my main machine from a September-based current to a -current as of yesterday, for many, many of the programs running on that machine i got an error message like Peter removed the stdio transitional aid for older -current systems. This means that older 5.0 libraries are no longer compatible with the new 5.0 libc, and you will need to recompile everything that depends on them. 4.x applications (i.e. things that link with libc.so.4) should be unaffected. This is a required change for 5.0-RELEASE. Doing a 'make world' followed by 'portupgrade -a -f' should be sufficient to rebuild everything correctly. Alternatively, I'll have new packages built in a few days, and you could just reinstall your packages with those. Actually, this should only be required for old ports (older than some date which I don't know off-hand). It might be easier to just rebuild everything though. Kris msg45295/pgp0.pgp Description: PGP signature
Re: HEADS UP: Port recompiles needed (Re: Unknown symbol __sF)
Kris Kennaway wrote: On Sun, Oct 13, 2002 at 10:22:48AM +0200, Hellmuth Michaelis wrote: Had a very bad night after upgrading my main machine from a September-based current to a -current as of yesterday, for many, many of the programs running on that machine i got an error message like Peter removed the stdio transitional aid for older -current systems. This means that older 5.0 libraries are no longer compatible with the new 5.0 libc, and you will need to recompile everything that depends on them. 4.x applications (i.e. things that link with libc.so.4) should be unaffected. The resize program and other X11 programs break because of the changes in this area: % resize /usr/libexec/ld-elf.so.1: /usr/lib/libncurses.so.5: \ Undefined symbol __stdoutp This is a required change for 5.0-RELEASE. So's the bumping of the version numbers on the libraries whose interfaces have been changed -- both producer (libc) and consumer (libncurses). This also means libncurses needs to be part of the compat4.x that comes with 5.x. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
On Sun, 13 Oct 2002, Terry Lambert wrote: Kris Kennaway wrote: Actually, this should only be required for old ports (older than some date which I don't know off-hand). It might be easier to just rebuild everything though. This would be OK, if the X11 package came from the FreeBSD source tree, instead of just as a binary on the CDROM (I hate that upgrading a box breaks things... it should *never* break things, as long as you don't tell it to remove old libraries). Not to mention it's easier said than done to recompile all packages since I have a hard enough time trying to figure out and keep track of all ports than have been updated or has changes committed. It would be easy if it was a dozen packages or the entire ports collection but if it's only 1,000 packages, recompiling them will take forever assuming you ever know which packages are installed. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
On Sun, Oct 13, 2002 at 04:01:53AM -0700, Terry Lambert wrote: Kris Kennaway wrote: Actually, this should only be required for old ports (older than some date which I don't know off-hand). It might be easier to just rebuild everything though. This would be OK, if the X11 package came from the FreeBSD source tree, instead of just as a binary on the CDROM (I hate that upgrading a box breaks things... it should *never* break things, as long as you don't tell it to remove old libraries). If you can't deal with having to recompile things over the -current development cycle then don't run it. Kris msg45302/pgp0.pgp Description: PGP signature
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
Kris Kennaway wrote: On Sun, Oct 13, 2002 at 04:01:53AM -0700, Terry Lambert wrote: Kris Kennaway wrote: Actually, this should only be required for old ports (older than some date which I don't know off-hand). It might be easier to just rebuild everything though. This would be OK, if the X11 package came from the FreeBSD source tree, instead of just as a binary on the CDROM (I hate that upgrading a box breaks things... it should *never* break things, as long as you don't tell it to remove old libraries). If you can't deal with having to recompile things over the -current development cycle then don't run it. Uh, the issue was the upcoming 5.0 release, which will cause these same problems for people. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
On Sun, Oct 13, 2002 at 04:27:27AM -0700, Terry Lambert wrote: Kris Kennaway wrote: On Sun, Oct 13, 2002 at 04:01:53AM -0700, Terry Lambert wrote: Kris Kennaway wrote: Actually, this should only be required for old ports (older than some date which I don't know off-hand). It might be easier to just rebuild everything though. This would be OK, if the X11 package came from the FreeBSD source tree, instead of just as a binary on the CDROM (I hate that upgrading a box breaks things... it should *never* break things, as long as you don't tell it to remove old libraries). If you can't deal with having to recompile things over the -current development cycle then don't run it. Uh, the issue was the upcoming 5.0 release, which will cause these same problems for people. As Kris already mentioned in the unquoted part of his original email, this does not affect RELENG_4 binaries. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45306/pgp0.pgp Description: PGP signature
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
On Sun, Oct 13, 2002 at 03:32:14PM +0300, Ruslan Ermilov wrote: On Sun, Oct 13, 2002 at 04:27:27AM -0700, Terry Lambert wrote: Kris Kennaway wrote: On Sun, Oct 13, 2002 at 04:01:53AM -0700, Terry Lambert wrote: Kris Kennaway wrote: Actually, this should only be required for old ports (older than some date which I don't know off-hand). It might be easier to just rebuild everything though. This would be OK, if the X11 package came from the FreeBSD source tree, instead of just as a binary on the CDROM (I hate that upgrading a box breaks things... it should *never* break things, as long as you don't tell it to remove old libraries). If you can't deal with having to recompile things over the -current development cycle then don't run it. Uh, the issue was the upcoming 5.0 release, which will cause these same problems for people. As Kris already mentioned in the unquoted part of his original email, this does not affect RELENG_4 binaries. Yes, it can. See yesterday's thread Revision 1.48 of stdio.h breaks 3rd party software. Luckily, Peter helps me find a work-around. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
Kris Kennaway wrote: On Sun, Oct 13, 2002 at 01:38:12AM -0700, Kris Kennaway wrote: On Sun, Oct 13, 2002 at 10:22:48AM +0200, Hellmuth Michaelis wrote: =20 Had a very bad night after upgrading my main machine from a September-b= ased current to a -current as of yesterday, for many, many of the programs running on that machine i got an error message like =20 Peter removed the stdio transitional aid for older -current systems. This means that older 5.0 libraries are no longer compatible with the new 5.0 libc, and you will need to recompile everything that depends on them. 4.x applications (i.e. things that link with libc.so.4) should be unaffected. =20 This is a required change for 5.0-RELEASE. =20 Doing a 'make world' followed by 'portupgrade -a -f' should be sufficient to rebuild everything correctly. Alternatively, I'll have new packages built in a few days, and you could just reinstall your packages with those. Actually, this should only be required for old ports (older than some date which I don't know off-hand). It might be easier to just rebuild everything though. Anything older than August 13th, 2001. It also appears that gcc has been miscompiling some binaries if you have got /usr/lib/libgcc.so* present. I've seen one report where an ancient 3.x libgcc.so was hanging around and was being used by the -current gcc compiler with -current binaries. Not Good. Here's what I do personally: make buildworld rm -rf /usr/include.old mv /usr/include /usr/include.old chflags -R noschg /usr/lib [mkdir /usr/lib/old] mv /usr/lib/lib*.so.* /usr/lib/compat mv /usr/lib/*.o /usr/lib/lib*.a /usr/lib/lib*.so /usr/lib/old make installworld This guarantees a clean /usr/include and /usr/lib after finishing. Dynamic binaries keep running because they find their libraries in /usr/lib/compat. But ld(1) will not find them there for *new* binaries. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
Ruslan Ermilov wrote: On Sun, Oct 13, 2002 at 04:27:27AM -0700, Terry Lambert wrote: Kris Kennaway wrote: If you can't deal with having to recompile things over the -current development cycle then don't run it. Uh, the issue was the upcoming 5.0 release, which will cause these same problems for people. As Kris already mentioned in the unquoted part of his original email, this does not affect RELENG_4 binaries. As I mentioned, it does for 4.6-RELEASE binaries: % resize /usr/libexec/ld-elf.so.1: /usr/lib/libncurses.so.5: \ Undefined symbol __stdoutp ...are people going to be upgrading to 5.0-RELEASE from RELENG4, or are they going to be upgrading from 4.6-RELEASE and 4.7-RELEASE? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
Terry Lambert wrote: Ruslan Ermilov wrote: On Sun, Oct 13, 2002 at 04:27:27AM -0700, Terry Lambert wrote: Kris Kennaway wrote: If you can't deal with having to recompile things over the -current development cycle then don't run it. Uh, the issue was the upcoming 5.0 release, which will cause these same problems for people. As Kris already mentioned in the unquoted part of his original email, this does not affect RELENG_4 binaries. As I mentioned, it does for 4.6-RELEASE binaries: % resize /usr/libexec/ld-elf.so.1: /usr/lib/libncurses.so.5: \ Undefined symbol __stdoutp ...are people going to be upgrading to 5.0-RELEASE from RELENG4, or are they going to be upgrading from 4.6-RELEASE and 4.7-RELEASE? Add COMPAT4X=true to your make.conf. We added __stdoutp etc to RELENG_4 and included it in the last two releases. -current's COMPAT4X stuff has the updated libc.so.4 with these symbols. If you want to run 4.x binaries, you need COMPAT4X=true so that we can update the 4.x compatability libraries over time. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
Peter Wemm wrote: Add COMPAT4X=true to your make.conf. We added __stdoutp etc to RELENG_4 and included it in the last two releases. -current's COMPAT4X stuff has the updated libc.so.4 with these symbols. If you want to run 4.x binaries, you need COMPAT4X=true so that we can update the 4.x compatability libraries over time. I guess if I just rebuild from CVS source with this flag set, you're saying I'll be all right? Thanks for the info... I'll give it a try. I had upgraded the machine with a snapshot from the Japan snapshot image server; apparently, no one ever thinks of compressiong ISO's, so that was at the limit of what I could download. 8-(. It may be a good idea to put this flag in by default, at least until 5.0-RELEASE, so that it will be there on the snapshots. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
On 2002-10-13 13:36, Terry Lambert [EMAIL PROTECTED] wrote: I had upgraded the machine with a snapshot from the Japan snapshot image server; apparently, no one ever thinks of compressiong ISO's, so that was at the limit of what I could download. 8-(. It may be a good idea to put this flag in by default, at least until 5.0-RELEASE, so that it will be there on the snapshots. That's a commonly asked question, and a very good answer is in the FAQ :P There are good reasons why the overworked snapshot servers do not attempt to compress the ISO images, which btw contain mostly .tgz files. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
Giorgos Keramidas wrote: On 2002-10-13 13:36, Terry Lambert [EMAIL PROTECTED] wrote: I had upgraded the machine with a snapshot from the Japan snapshot image server; apparently, no one ever thinks of compressiong ISO's, so that was at the limit of what I could download. 8-(. It may be a good idea to put this flag in by default, at least until 5.0-RELEASE, so that it will be there on the snapshots. That's a commonly asked question, and a very good answer is in the FAQ :P There are good reasons why the overworked snapshot servers do not attempt to compress the ISO images, which btw contain mostly .tgz files. Alternately, instead of believing someone's opinion, we could ask the data in question: % ls -l 248643584 Sep 17 00:03 5.0-CURRENT-20020917-JPSNAP.iso 212988130 Oct 13 10:39 5.0-CURRENT-20020917-JPSNAP.iso.gz Compression gets rid of about 36MB. That's 3.4 hours saved on a 28.8K modem download time, overall... a 14% reduction in size. I guess it's no wonder it's a frequently asked question. Too bad it's not answered correctly in the FAQ. I think the correct answer is maybe because the FAQ maintainers have broadband connections... PS: If the server is overworked, all you need to do is store the compressed version of the image on the server; I have no idea why you seem to believe that it needs to be compressed more than once, so whether or not the server is overworked is irrelevent to the compression, I think. PPS: If the server is overworked, think what reducing the number of bytes per download by 14% would do for it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
: On 2002-10-13 13:36, Terry Lambert [EMAIL PROTECTED] wrote: : I had upgraded the machine with a snapshot from the Japan snapshot : image server; apparently, no one ever thinks of compressiong ISO's, : so that was at the limit of what I could download. 8-(. : : It may be a good idea to put this flag in by default, at least until : 5.0-RELEASE, so that it will be there on the snapshots. : : That's a commonly asked question, and a very good answer is in the FAQ :P : There are good reasons why the overworked snapshot servers do not : attempt to compress the ISO images, which btw contain mostly .tgz files. : :Alternately, instead of believing someone's opinion, we could ask :the data in question: : :% ls -l :248643584 Sep 17 00:03 5.0-CURRENT-20020917-JPSNAP.iso :212988130 Oct 13 10:39 5.0-CURRENT-20020917-JPSNAP.iso.gz : :Compression gets rid of about 36MB. : :That's 3.4 hours saved on a 28.8K modem download time, overall... :a 14% reduction in size. Well, ok, but on a percentage basis you don't get much out of it. If someone is downloading via a modem they're probably doing it overnight anyway. bzip2 does even worse then gz in this instance, so no magic there either. -rw-r--r-- 1 dillon wheel 179985801 Oct 13 15:00 bzip2.bz2 (bzip2 -9) -rw-r--r-- 1 dillon wheel 178963831 Oct 13 14:56 gzip9.gz(gzip -9) -rw-r--r-- 1 dillon wheel 187006976 Jun 8 00:04 miniinst-RC4-8Jun2002.iso -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
On 2002-10-13 14:49, Terry Lambert [EMAIL PROTECTED] wrote: Giorgos Keramidas wrote: That's a commonly asked question, and a very good answer is in the FAQ :P There are good reasons why the overworked snapshot servers do not attempt to compress the ISO images, which btw contain mostly .tgz files. Alternately, instead of believing someone's opinion, we could ask the data in question: % ls -l 248643584 Sep 17 00:03 5.0-CURRENT-20020917-JPSNAP.iso 212988130 Oct 13 10:39 5.0-CURRENT-20020917-JPSNAP.iso.gz Compression gets rid of about 36MB. How long did that take to compress though? What load did the machine that did the compression have? Currently, the snapshots.jp.freebsd.org machines build releases every 24 hours which last 4-9 hours. I'm not sure if the same machines could spare some cycles to compress the ISO images, or the disk space to store almost duplicate copies of the same ISO images twice (compressed, and uncompressed). The best people to ask about things like these are the jp.freebsd.org admins and not a local compression program imho. That's 3.4 hours saved on a 28.8K modem download time, overall... a 14% reduction in size. I guess it's no wonder it's a frequently asked question. Too bad it's not answered correctly in the FAQ. I think the correct answer is maybe because the FAQ maintainers have broadband connections... No we don't. My ultrafast connection is in fact a 28.8 Kbit/sec dialup connection. This is why I don't download entire ISO images, but instead do FTP-installs. So, there you go ;) PS: If the server is overworked, all you need to do is store the compressed version of the image on the server; I have no idea why you seem to believe that it needs to be compressed more than once, so whether or not the server is overworked is irrelevent to the compression, I think. Not very irrelevant, as it might seem at first. Because I'm not talking about the FTP server that delivers the files, but about the server that 'builds the snapshots'. The donations list of freebsd.org lists requests for better, faster release building machines for the Japan cluster. If you really think that you can help, I'd be glad to be proven wrong by a generous donation to the guys who have saved my -current installation at home a dozen times with their snapshots. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
Matthew Dillon wrote: :% ls -l :248643584 Sep 17 00:03 5.0-CURRENT-20020917-JPSNAP.iso :212988130 Oct 13 10:39 5.0-CURRENT-20020917-JPSNAP.iso.gz : :Compression gets rid of about 36MB. : :That's 3.4 hours saved on a 28.8K modem download time, overall... :a 14% reduction in size. Well, ok, but on a percentage basis you don't get much out of it. If someone is downloading via a modem they're probably doing it overnight anyway. And that's OK, because we all live in countries that don't charge time or message units for phone calls, right? 8-) 8-). bzip2 does even worse then gz in this instance, so no magic there either. Bzip sucks. It was invented to get out from under a patent that is now expired. -rw-r--r-- 1 dillon wheel 179985801 Oct 13 15:00 bzip2.bz2 (bzip2 -9) -rw-r--r-- 1 dillon wheel 178963831 Oct 13 14:56 gzip9.gz(gzip -9) -rw-r--r-- 1 dillon wheel 187006976 Jun 8 00:04 miniinst-RC4-8Jun2002.iso The gzip number I gave was for the default (-6), not -9. The -9 only dropped 600K more out; every little bit helps, though. I gave the default number to make it repeatable, and to give a valid baseline vs. all the compressed data, which was uncompressible because it was otself -6. A lot of things in the less minimal distributions are more compressible. The ISO for the live FS image is *immensely* compressible. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
Giorgos Keramidas wrote: Compression gets rid of about 36MB. How long did that take to compress though? 2 minutes on a P3-800 with 128M of RAM and one IDE disk. Doesn't matter, because all it really adds is latency. What load did the machine that did the compression have? Currently, the snapshots.jp.freebsd.org machines build releases every 24 hours which last 4-9 hours. I'm not sure if the same machines could spare some cycles to compress the ISO images, or the disk space to store almost duplicate copies of the same ISO images twice (compressed, and uncompressed). The best people to ask about things like these are the jp.freebsd.org admins and not a local compression program imho. The space argument may be valid; though, in that case, you'd expect that compressed images would be the only images that would be there. 8-). I think the correct answer is maybe because the FAQ maintainers have broadband connections... No we don't. My ultrafast connection is in fact a 28.8 Kbit/sec dialup connection. This is why I don't download entire ISO images, but instead do FTP-installs. So, there you go ;) It's *incredibly* hard to get a -current machine initially installed from sources corectly. It's easier to use the ISO's, even if they take a very long time to download. It's either that, or don't start following -current. Not very irrelevant, as it might seem at first. Because I'm not talking about the FTP server that delivers the files, but about the server that 'builds the snapshots'. The donations list of freebsd.org lists requests for better, faster release building machines for the Japan cluster. If you really think that you can help, I'd be glad to be proven wrong by a generous donation to the guys who have saved my -current installation at home a dozen times with their snapshots. 3.5 hours worth of additional FTP downloading time per download, vs. two minutes of compression time... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
On Mon, Oct 14, 2002 at 11:43:20AM +0900, Makoto Matsushita wrote: tlambert2 That's 3.4 hours saved on a 28.8K modem download time, tlambert2 overall... a 14% reduction in size. The percentage doesn't matter. If ISO image is compressed, user who downloads the image may de-compress that image to burn (I don't know any about the burner softwares which support compressed ISO image). What's happen if there is no space to make de-compressed image on a HDD? I do not follow this. If the user can not fit a non-compressed image on their drive then they certainly will not be downloading a non- compressed image nor a compressed image hence rendering this whole discussion moot for that user...it seems so to me at least. Maybe I am not seeing something? 3.4 hours is a lot of time on a dial-up connection (granted it is not a one size fits all period of time). Also, the image size is still over 200MB; it is too large to fetch via 28.8k link IMHO (saving 3.4hours doesn't help either). There are lots of broadband connection services we can temporary buy (at airport, starbucks, etc), so why not use it for large file downloads :-) I disagree with the first sentence; see my reply above. I simply disagree that 3.4 hours is not helpful. Whether we think the size is too large for dial-up or not people will still download it. And 200MB is absolutely nothing compared to what people put up with for full-size distribution ISOs. You could argue that not everyone has gzip (I would assume primarily a Windows user). As far as I know there is a DOS version of gzip. This would be where you might need both types of images (compressed and not compressed), and that is something up to the snapshots people. One might argue that Mr. Lambert is simply speculating that anyone has a 28.8k connection anymore. What are the odds that everyone fits this: a: they live close enough to a provider to get broadband (see 'b'), b: they can afford broadband, c: they live close enough to a Starbucks and/or airport, and d: is going to put out that kind of effort to do a-c when they can just as well hope that the snapshot server(s) have the space and power to compress an image so that they can stay in the comfort of their home with their 28.8k Internet connection? I think more than maybe is accounted for. I liken it to simply forgetting about the others...sort of like for a long time the blind, deaf, et cetera were left out of most people's thoughts when it came to accessibility (whether that is with computers or physical access to something). I think the FTP installation should be just fine for people with a dial-up connection if they really really really want to have -CURRENT. I've used it a few times for getting snapshots with no harm done. If the snapshot server(s) are not up to task then all of this is useless discussion. Someone ``in the know'' should simply get up and say hey, our servers can not handle this; end of story instead of speculating. No one has said that yet that I am aware of. As you might be able to tell I have no idea who actually runs the snapshot server(s) nor am I aware of how many, if there are more than one, there are. Sorry. Of course that's all just my opinion; I could be wrong. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
On Sun, Oct 13, 2002 at 11:29:32PM -0400, Carl Schmidt wrote: On Mon, Oct 14, 2002 at 11:43:20AM +0900, Makoto Matsushita wrote: tlambert2 That's 3.4 hours saved on a 28.8K modem download time, tlambert2 overall... a 14% reduction in size. The percentage doesn't matter. If ISO image is compressed, user who downloads the image may de-compress that image to burn (I don't know any about the burner softwares which support compressed ISO image). What's happen if there is no space to make de-compressed image on a HDD? I do not follow this. If the user can not fit a non-compressed image on their drive then they certainly will not be downloading a non- compressed image nor a compressed image hence rendering this whole discussion moot for that user...it seems so to me at least. Maybe I am not seeing something? The temporary space required to do the decompression is what I am assuming is being reference, although I'm not sure how accurate that argument is. Whether we think the size is too large for dial-up or not people will still download it. And 200MB is absolutely nothing compared to what people put up with for full-size distribution ISOs. You could argue that not everyone has gzip (I would assume primarily a Windows user). As far as I know there is a DOS version of gzip. This would be where you might need both types of images (compressed and not compressed), and that is something up to the snapshots people. Winzip supports tar and gz, winrar supports bzip2 One might argue that Mr. Lambert is simply speculating that anyone has a 28.8k connection anymore. What are the odds that everyone fits this: a: they live close enough to a provider to get broadband (see 'b'), I did not think distance was a requirement for cable modem, but I do agree with your logic that not everyone has broadband. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
* De: Makoto Matsushita [EMAIL PROTECTED] [ Data: 2002-10-13 ] [ Subjecte: Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF) ] carl 3.4 hours is a lot of time on a dial-up connection (granted it carl is not a one size fits all period of time). You forget that you still compressed image with about 30 hours (at least, full 1 day or more), and it is not helpful for ordinal users, not you. Again, reducing hours/percentages with compressed image doesn't matter; please focus total download time which is actually needed for all users. Missing the point is not helpful for the discussion. I've done recent FreeBSD installs over 14.4k modems. The trick is to do a network install over ppp. If one needs to do multiple local installs, then bootstrapping one box this way is best, then slowly pull things over cvsup(1), and build one release locally. Less error- prone to do things this way. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
On Sun, Oct 13, 2002 at 10:40:20PM -0500, David W. Chapman Jr. wrote: On Sun, Oct 13, 2002 at 11:29:32PM -0400, Carl Schmidt wrote: On Mon, Oct 14, 2002 at 11:43:20AM +0900, Makoto Matsushita wrote: tlambert2 That's 3.4 hours saved on a 28.8K modem download time, tlambert2 overall... a 14% reduction in size. The percentage doesn't matter. If ISO image is compressed, user who downloads the image may de-compress that image to burn (I don't know any about the burner softwares which support compressed ISO image). What's happen if there is no space to make de-compressed image on a HDD? I do not follow this. If the user can not fit a non-compressed image on their drive then they certainly will not be downloading a non- compressed image nor a compressed image hence rendering this whole discussion moot for that user...it seems so to me at least. Maybe I am not seeing something? The temporary space required to do the decompression is what I am assuming is being reference, although I'm not sure how accurate that argument is. I did a little test to see how that works. If you gzip a file and gunzip it and follow the sizes of each file it seems that the file being de-compressed decreases in size while the new file increases in size. I think it is safe to say that gzip does not require temporary space, except an extra inode for de-compression. I could be wrong though. Whether we think the size is too large for dial-up or not people will still download it. And 200MB is absolutely nothing compared to what people put up with for full-size distribution ISOs. You could argue that not everyone has gzip (I would assume primarily a Windows user). As far as I know there is a DOS version of gzip. This would be where you might need both types of images (compressed and not compressed), and that is something up to the snapshots people. Winzip supports tar and gz, winrar supports bzip2 One might argue that Mr. Lambert is simply speculating that anyone has a 28.8k connection anymore. What are the odds that everyone fits this: a: they live close enough to a provider to get broadband (see 'b'), I did not think distance was a requirement for cable modem, but I do agree with your logic that not everyone has broadband. The distance argument is probably not relevant. I remember a long time ago some person from the UK complaining about having to use ISDN because NTL did not provide cable at that distance, or something. I honestly do not know about that. From Qwest: EOD Technical Specs for DOCSIS Cable Modem: [...] * Supports round trip distances of up to 200 miles EOD Finally, I am sorry that this seems to be completely un-related to the original topic. I did not follow it thoroughly. -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol __sF)
On Mon, Oct 14, 2002 at 12:45:41PM +0900, Makoto Matsushita wrote: carl 3.4 hours is a lot of time on a dial-up connection (granted it carl is not a one size fits all period of time). You forget that you still compressed image with about 30 hours (at least, full 1 day or more), and it is not helpful for ordinal users, not you. I fail to see how a reduction of hours (even just one) is insignificant to someone on a dial-up connection. Time is money for some people; even a meager three hours. Again, reducing hours/percentages with compressed image doesn't matter; please focus total download time which is actually needed for all users. Missing the point is not helpful for the discussion. Again, I fail to see how a reduction in download time for -anyone- is insignificant. Can you explain how I am missing the point? I think it would be better to focus on whether or not the snapshot machine can even handle such a task, and, more importantly, whether the administrator even wants to do it. I e-mailed [EMAIL PROTECTED] about the task. If that is you I hope you'll forward your response to the freebsd-current list. -- Carl Schmidt [Random Quote] Be careful of reading health books, you might die of a misprint. -- Mark Twain To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
