Re: [leaf-devel] rsync.leaf-project.org::leaf-cvs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: | On Mon, 2005-03-14 at 13:32, Charles Steinkuehler wrote: | Mike Noyes wrote: | | Is the rsync leaf-cvs archive still updating? It doesn't seem to be | | current. Is it a problem with the nightly tarball created by SF? | | | | Example: | | leaf-cvs/leaf/src/bering-uclibc/buildtool/buildpacket.pl | | 37703 2004-07-24 10:51 buildpacket.pl,v | | | | | http://cvs.sourceforge.net/viewcvs.py/leaf/src/bering-uclibc/buildtool/ | | It looks like it's at least trying to work...I'm downloading the following URL: | | http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2 | | ...is that the right one? | | Charles, | Yes, that's the correct file. If it's a problem with the nightly tarball | creation on SF, I'll open a SR with them. I downloaded the tarball and tried to de-compress it, and got the following: bunzip2: Compressed file ends unexpectedly; ~perhaps it is corrupted? *Possible* reason follows. bunzip2: No such file or directory ~Input file = leaf-cvsroot.tar.bz2, output file = leaf-cvsroot.tar It is possible that the compressed file(s) have become corrupted. You can use the -tvv option to test integrity of such files. You can use the `bzip2recover' program to *attempt* to recover data from undamaged sections of corrupted files. bunzip2: Deleting output file leaf-cvsroot.tar, if it exists. I'd say it looks like there's a problem with the tarball, but I'm going to try again to make sure. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCNs/kLywbqEHdNFwRAt9AAJ4r7PpGwNpKAk2J7SRg1cQhL4WvjQCeORGz nJE0rJ09+vLLHDicweTScY4= =8jTh -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync.leaf-project.org::leaf-cvs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Steinkuehler wrote: | Mike Noyes wrote: | | | On Mon, 2005-03-14 at 13:32, Charles Steinkuehler wrote: | | Mike Noyes wrote: | | | Is the rsync leaf-cvs archive still updating? It doesn't seem to be | | | current. Is it a problem with the nightly tarball created by SF? | | | | | | Example: | | | leaf-cvs/leaf/src/bering-uclibc/buildtool/buildpacket.pl | | | 37703 2004-07-24 10:51 buildpacket.pl,v | | | | | | | | http://cvs.sourceforge.net/viewcvs.py/leaf/src/bering-uclibc/buildtool/ | | | | It looks like it's at least trying to work...I'm downloading the | following URL: | | | | http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2 | | | | ...is that the right one? | | | | Charles, | | Yes, that's the correct file. If it's a problem with the nightly tarball | | creation on SF, I'll open a SR with them. | | I downloaded the tarball and tried to de-compress it, and got the following: | | bunzip2: Compressed file ends unexpectedly; | ~perhaps it is corrupted? *Possible* reason follows. | bunzip2: No such file or directory | ~Input file = leaf-cvsroot.tar.bz2, output file = leaf-cvsroot.tar | | It is possible that the compressed file(s) have become corrupted. | You can use the -tvv option to test integrity of such files. | | You can use the `bzip2recover' program to *attempt* to recover | data from undamaged sections of corrupted files. | | bunzip2: Deleting output file leaf-cvsroot.tar, if it exists. | | I'd say it looks like there's a problem with the tarball, but I'm going to | try again to make sure. OK, I tried again and get the same error. Extrating the filenames from the uncompressed partial tarball yeilds 1544 filenames, ending with: - -r--r--r-- 91103/14751 7326801 2003-01-30 23:47:21 leaf/devel/ccarr/devel/bering/dist/Bering_1.0-stable_modules_2.4.20.tar.gz,v Anything after this isn't getting updated. Note that the SF tarball is getting created and updated, as evidenced by some files with recent dates, ie: - -rwxrwxr-x 99/147512189750 2005-03-14 16:33:14 leaf/CVSROOT/history Sounds like we need to make a support request to SF. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCNtfMLywbqEHdNFwRAsxbAJsH42RwuW4Reb3Jb3CFf+75Q0L6bQCcD4cd oiRch/38mO6l4IYWmFVC24U= =8cRv -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] package libcxx: buildtool.cfg filenames
Martin Hejl [EMAIL PROTECTED] writes: But if someone wants to fix the current regexp based buildpacket.pl code, the proposed workaround should point to the bug quite directly. correction - I found the issue you're seeing. It wasn't triggered when I tried, because I didn't fully specify the Filename part of the file definition. I've updated buildpacket.pl in CVS, please give it a try. It works now. I have thus removed the workaround from apps/libgcc/buildtool.cfg. Uli --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync.leaf-project.org::leaf-cvs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Steinkuehler wrote: | Sounds like we need to make a support request to SF. Hold off on this for now...both times I tried downloading with links. I'm now using curl, and it looks like I'm going to wind up with a different (larger) sized file. I'll post the results when finished. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCNv6tLywbqEHdNFwRAnFPAKDVzyvq/2h+47PWN7VDcRBRzjFgCACdH2/b +GxyGa3LDN4EEog+xPs9YWI= =IOUK -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync.leaf-project.org::leaf-cvs
On Tue, 2005-03-15 at 07:26, Charles Steinkuehler wrote: Charles Steinkuehler wrote: | Sounds like we need to make a support request to SF. Hold off on this for now...both times I tried downloading with links. I'm now using curl, and it looks like I'm going to wind up with a different (larger) sized file. Charles, Will do. I'll post the results when finished. Thanks. :-) BTW, are you using --delete when updating the rsync server? I noticed some errant commits, that were removed by the SF staff, present in the leaf-cvs module. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync.leaf-project.org::leaf-cvs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: | On Tue, 2005-03-15 at 07:26, Charles Steinkuehler wrote: | Charles Steinkuehler wrote: | | | Sounds like we need to make a support request to SF. | | Hold off on this for now...both times I tried downloading with links. I'm | now using curl, and it looks like I'm going to wind up with a different | (larger) sized file. | | Charles, | Will do. | | I'll post the results when finished. | | Thanks. :-) OK, I think I've figured out what's going on. For some reason, the SF server is disconnecting the client before the entire CVS tarball gets downloaded. Using curl's resume capability, I was able to download the entire archive, but it took several successive tries. Each attempt would fail after about 7-8 minutes or apx 200-300 MB of data: multiple curl commands output edited for readability [EMAIL PROTECTED] charles]$ curl -OC - 'http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2' ~ % Total% Received % Xferd Average Speed Time ~ Dload Upload TotalCurrent Left ~ 25 1056M 25 266M0 0 545k 0 0:33:01 0:08:20 0:24:41 curl: (18) transfer closed with 827527107 bytes remaining to read ~ 29 789M 29 233M0 0 487k 0 0:27:36 0:08:10 0:19:26 curl: (18) transfer closed with 582198011 bytes remaining to read ~ 39 555M 39 218M0 0 530k 0 0:17:50 0:07:00 0:10:50 curl: (18) transfer closed with 353273803 bytes remaining to read ~ 89 336M 89 300M0 0 528k 0 0:10:53 0:09:43 0:01:10 curl: (18) transfer closed with 37835243 bytes remaining to read 100 36.1M 100 36.1M0 0 451k 0 0:01:21 0:01:21 0:00:00 So...I'm not sure *WHY* the SF server is disconnecting, but that definately seems to be what's happening. Can someone with good bandwidth try downloading the tarball with a normal web-browser like Mozilla or IE? I've tested with curl and links, but don't have a GUI running on a machine with a fat upstream link. Currently, it looks like I'm going to have to script the grab of the CVS tarball (it's currently a 'one-liner' in cron) and loop until curl exits with an error other than 18. | BTW, are you using --delete when updating the rsync server? I noticed | some errant commits, that were removed by the SF staff, present in the | leaf-cvs module. Um...I can't rsync directly to the CVS archive. I'm basically grabbing the tarball and 'exploding' it in place on my CoLo system, then rsync'ing from that system to basic.steinkuehler.net. That means there's nothing in place to delete files that may have existed in the CVS archive at one time, but don't any more. If you want, I can wipe the output directory prior to untaring the downloaded file, which should clear out any cruft. MIKE: I've manually updated the CVS archive on the CoLo system (rsync.steinkuehler.net), and basic should update soon. It looks to me like everything's OK, but you might want to check. Note that it might be until sometime tomorrow before basic has a fully updated archive (I think there will be a *LOT* of stuff to rsync, and I don't off-hand recall when the sync occurs, except I think it's late-night/early-AM). - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCNzqpLywbqEHdNFwRAhA1AJ4gbLzP8SABYMwqAZAgDuVHumYMuwCfcqSt YMD4/Lo0VIlDKuyeaj36qpg= =C0Jc -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync.leaf-project.org::leaf-cvs
On Tue, 2005-03-15 at 11:42, Charles Steinkuehler wrote: Mike Noyes wrote: | On Tue, 2005-03-15 at 07:26, Charles Steinkuehler wrote: | Charles Steinkuehler wrote: | | | Sounds like we need to make a support request to SF. | | Hold off on this for now...both times I tried downloading with links. I'm | now using curl, and it looks like I'm going to wind up with a different | (larger) sized file. | | Charles, | Will do. | | I'll post the results when finished. | | Thanks. :-) OK, I think I've figured out what's going on. For some reason, the SF server is disconnecting the client before the entire CVS tarball gets downloaded. Using curl's resume capability, I was able to download the entire archive, but it took several successive tries. Each attempt would fail after about 7-8 minutes or apx 200-300 MB of data: Charles, Yep. That looks like the issue. I got a similar recommendation from burley in #sourceforge on irc.SlashNET.org. wget -c --waitretry=60 http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2 -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync.leaf-project.org::leaf-cvs
On Tue, 2005-03-15 at 11:42, Charles Steinkuehler wrote: Mike Noyes wrote: | BTW, are you using --delete when updating the rsync server? I noticed | some errant commits, that were removed by the SF staff, present in the | leaf-cvs module. Um...I can't rsync directly to the CVS archive. I'm basically grabbing the tarball and 'exploding' it in place on my CoLo system, then rsync'ing from that system to basic.steinkuehler.net. That means there's nothing in place to delete files that may have existed in the CVS archive at one time, but don't any more. If you want, I can wipe the output directory prior to untaring the downloaded file, which should clear out any cruft. Charles, Sorry. I mistakenly thought you were untaring the download in a temp directory, and syncing that to the rsync module. MIKE: I've manually updated the CVS archive on the CoLo system (rsync.steinkuehler.net), and basic should update soon. It looks to me like everything's OK, but you might want to check. Note that it might be until sometime tomorrow before basic has a fully updated archive (I think there will be a *LOT* of stuff to rsync, and I don't off-hand recall when the sync occurs, except I think it's late-night/early-AM). Thanks. I'll rsync tomorrow. It'll probably take me a while. Sorry I didn't notice this problem earlier. :-( -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] possible bug in linuxrc
Hi
There is a possible bug in linuxrc (at least with the busybox of Bering)
when trying to create and mount the /tmp filesystem.
Here is the output from /linuxrc.err
mount -t tmpfs tmpfs /tmp -o size=20M
mount: Mounting tmpfs on /tmp failed: Invalid argument
mount -t tmpfs tmpfs /tmp -o size=20M
I extended linuxrc a little to get the debug info. It appears as if the
tmpfs mount does not like the parameter substitution used for tmp_size
here is the relevant code
[ $VERBOSE ] Lecho Generating /tmp /var/log partitions ...
echo mount -t tmpfs tmpfs /tmp ${tmp_size:+-o size=$tmp_size}
/linuxrc.err
qt mount -t tmpfs tmpfs /tmp ${tmp_size:+-o size=$tmp_size}
echo mount -t tmpfs tmpfs /tmp -o size=$tmp_size /linuxrc.err
qt mount -t tmpfs tmpfs /tmp -o size=$tmp_size
as you can see, the second mount appears to work, this is with tmp_size
set to 20M in leaf.cfg
When not setting tmp_size in leaf.cfg the following results appear
mount -t tmpfs tmpfs /tmp
mount -t tmpfs tmpfs /tmp -o size=
Of course my debug code fails, but apparently the original code works
now this is the code which appears to work in both circumstances, it
lacks the elegance of the substitution, but helas...
[ $VERBOSE ] Lecho Generating /tmp /var/log partitions ...
[ $tmp_size ] qt mount -t tmpfs tmpfs /tmp -o size=$tmp_size
[ ! $tmp_size ] qt mount -t tmpfs tmpfs /tmp
cheers
Erich
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
