Re: Perl 5.10 stabilization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Reini Urban wrote: | Current changes from -3 to -4: | No API changes, just one added DynaLoader.o in libperl and added one | missing Win32CORE.a, so your packages will be fine. I'll admit that I know nothing of Perl internals, but could Win32CORE.a be added to libperl as well? As I mentioned on the list, EU::Embed creates dependencies on both DynaLoader and Win32CORE, and linking a shared library/module against Win32CORE.a (or DynaLoader.a) doesn't work OOTB when using libtool. This would be helpful if it's possible. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgg4AYACgkQpiWmPGlmQSNDQQCgh/9Fnkms7ANR4oKF646r0dAV otUAni9uQrhuEKYmpsXDDw4/adWY0PrO =0E0o -END PGP SIGNATURE-
Re: setup.exe: Invalid or unsupported tar format
Christopher Faylor wrote: > Yes, I'm confused by this. I did replace all of the zero length tar files > with the 46 byte versions. That's what I've always done when creating an > empty package. Here is a summary of the situation: The current stable/release version of setup will never warn if it can't understand a package, it will just silently skip it. Mostly, this is what you want, as it means it will cope just fine with both the 14b and 46b packages. However a while ago someone reported that a package wasn't installing and after investigation it was because the maintainer had used something like cmake with its own libtar implementation that used an incompatible magic. Setup was silently refusing to install the package even though everything indicated that it was to be installed -- very confusing. I added support for this new magic value and rewrote the tar checking code to explicitly warn if it cannot grok a package. This change existed only in testing/snapshot versions so few people would have experienced it. Unbeknownst to me at the time, this meant it would report on both the 14b packages (since they contain nothing after decompression) and the 46b packages (since they don't actually contain a tar header but 10k of \0 which is unrecognisable to setup as a valid tar header.) I admit that I don't regularly install packages from _obsolete so I never saw it in any of my testing. Some time later someone reported using a setup snapshot and seeing the warning for an empty 14b package. At the time I attributed this to the 14b package not being a 46b package, and added code to setup to skip the 14b package without a warning, assuming incorrectly that the 46b case also worked as no one had reported that -- until now. What I intend to do is add another special-case for checking that if the first 512 bytes are all zeros to assume it's an empty tar file and suppress the warning. This will mean that both 46b and 14b packages are correctly handled, as well as still preserving the warning if a real package is unrecognisable. But until I can add that, if you are using a snapshot version only the 14b packages will be correctly handled; the 46b ones will warn. This is mostly just a nuisance as installation continues after the warning is dismissed and it's not like you're missing anything from the empty package, but it's a nuisance nonetheless and setup ought to be able to handle both types of empty package. I don't think there's any need to convert anything on the mirrors again because the next actual release version of setup should cope with both, and people using snapshots should be able to deal. Brian
Re: Perl 5.10 stabilization
Reini Urban schrieb: 2008/4/16, Yaakov (Cygwin Ports) <[EMAIL PROTECTED]>: My perl packages are now ready for 5.10, as soon as you're ready to stabilize: > Great! I started now the latest perl-5.10.0-4 build on my 2nd machine, but my connection seems to be very bad today. So it will be at the end of this week finished testing the latest build. BTW: I finished building a static perl (single exe), and a non-threaded perl (much faster), but I still have to find the cause for the two missing static libs. I've found and fixed those linker problems and some more -Uusedl problems (static libperl only), but I'm still not happy with cornercases and certain hardcore packages. Maybe we should really wait for a 5.10.1 to go stable. But I don't think that the new regex engine will get much faster with 5.10.1. Current changes from -3 to -4: No API changes, just one added DynaLoader.o in libperl and added one missing Win32CORE.a, so your packages will be fine. And I've removed -Dusesitecustomize for performance reasons. The packages are already at my setup site. Anyway, I hope to finish testing until next weekend. The current 5.10.0-4 version has the same test errors as 5.8.9, which is one more test failure than 5.8.8. ext/Time/HiRes/t/HiRes..FAILED--non-zero wait status: 15 The upcoming 5.8.9 is also keeping me steady smoking and adjusting build scripts, and I still have no time for fixing icu to be able to ITP parrot. A perl-debug (perl5.10.0d.exe) and perl-nonthreaded package (perl5.10.0-nt.exe) for raw speed is also in consideration. (side-by side install), since I need that anyway, and packaging is quite easy with the changed build framework. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: cygport and CYGWIN-PATCHES
Charles Wilson wrote: How is cygport supposed to create, ex nihilo, your custom README and custom .hint files, I don't expect it to. I keep versions of these files in the same directory as the cygport file. cygport could be told about these files, and copy them into the proper location during prep. The version numbers and change log stuff will have to be edited, of course, but that's no argument against starting with a known-good base. Same thing with src patches? Pretty much, yes. :) If the previous version required a source patch and it applies cleanly to the new version, it's likely correct, though possibly incomplete. If it fails to apply cleanly, cygport can back out the changes and tell the user to build a new one. Thus, you could tell cygport about a stock src.patch file to try, just like you tell it about the base README and setup.hint files. Thanks for writing up the steps you use with cygport. They belong in cygport's README. :)
Re: setup.exe: Invalid or unsupported tar format
On Mon, May 05, 2008 at 08:13:58PM -0600, Eric Blake wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > According to Brian Dessent on 5/5/2008 3:11 PM: > |> I have an empty meta-package to pull in other packages copied from one > |> of the _obsolete packages. I understand these are created via 'tar -T > |> /dev/null -cjf foo.tar.bz2' (see > |> http://cygwin.com/ml/cygwin-apps/2008-04/msg00105.html), and diff > |> reports the results identical; the file size is the expected 46 bytes. > > It sounds like we need to replace all the 46-byte files with 14 byte ones? > ~ But the empty file is technically not a valid tar file, since it lacks > the required trailing blocks. Yes, I'm confused by this. I did replace all of the zero length tar files with the 46 byte versions. That's what I've always done when creating an empty package. cgf
Re: setup.exe: Invalid or unsupported tar format
--- Brian Dessent ha scritto: > > The setup.exe source (install.cc, > Installer::installOne) looks like it > > expects an error peeking from try_decompress in > this situation, but > > running in the debugger shows > try_decompress->peek() successfully > > reading '0'. Note that if you bunzip2 the empty > package, you get a 10K > > tarball which is all zeroes, so success isn't > completely unexpected... > $ tar --show-defaults --format=gnu -f- -b20 --quoting-style=escape --rmt-command=/usr/sbin/rmt.exe --rsh-command=/usr/bin/rsh $ ls -lrt 10240 May 6 11:30 prova1.tar my guess 20*512= 10240 bytes Regards Marco Tante idee per la salvaguardia del nostro Pianeta su Yahoo! For Good http://it.promotions.yahoo.com/forgood/environment.html
