RE: [ITP] graphviz/libgraphviz4/libgraphviz-devel/graphviz-doc/graphviz-contrib: An open source graph visualization software
Dave Korn wrote on 02 May 2008 10:56: > Dr. Volker Zell wrote on 02 May 2008 09:20: > >> Hi >> >> I would like to contribute and maintain the >> 'graphviz/libgraphviz4/libgraphviz-devel/graphviz-doc/graphviz-contrib' >> packages. > > Your sense of timing is perfect. I just spent an evening trying to > build this myself and finally got going with some half-working crudely > limping along static build... > >> For downloading > > Will test over the weekend. Thanks very much! Well, the packaging looks ok, and the binaries appear to work after a bit of crude smoke-testing, but I can't successfully rebuild from source. I've tried on two different systems now (both fairly up-to-date), and they've both hung up at this stage: - Making all in vmalloc make[3]: Entering directory `/tmp/volker/graphviz/rebuild/graphviz-2.18-1/build/lib/vmalloc' mkdir -p ../../FEATURE /tmp/volker/graphviz/rebuild/graphviz-2.18-1/src/graphviz-2.18/iffe - set cc gcc : run /tmp/volker/graphviz/rebuild/graphviz-2.18-1/src/graphviz-2.18/lib/vmalloc/fea tures/vmalloc > ../../FEATURE/vmalloc - In each case there was a stuck exe running, "FALBA2320.exe" for one and FUBIK-something-or-other on the other. The stuck exe was using zero cpu and just sitting there indefinitely. Running it manually at the command-line didn't stall. The sh.exe that invoked the iffe script is still alive but also stalled. After killing the exe, the shell wakes up and carries on with the build. The FALBA2320.c test was checking for the presence of strdup and sure enough it doesn't seem to appear in any of the feature test macros in build/FEATURE/vmalloc. cheers, DaveK -- Can't think of a witty .sigline today
Re: [ITP] graphviz/libgraphviz4/libgraphviz-devel/graphviz-doc/graphviz-contrib: An open source graph visualization software
> Dave Korn writes: > Well, the packaging looks ok, and the binaries appear to work after a bit of > crude smoke-testing, but I can't successfully rebuild from source. I've tried > on two different systems now (both fairly up-to-date), and they've both hung > up at this stage: > - > Making all in vmalloc > make[3]: Entering directory > `/tmp/volker/graphviz/rebuild/graphviz-2.18-1/build/lib/vmalloc' > mkdir -p ../../FEATURE > /tmp/volker/graphviz/rebuild/graphviz-2.18-1/src/graphviz-2.18/iffe - set cc > gcc : run > /tmp/volker/graphviz/rebuild/graphviz-2.18-1/src/graphviz-2.18/lib/vmalloc/fea > tures/vmalloc > ../../FEATURE/vmalloc > - > In each case there was a stuck exe running, "FALBA2320.exe" for one and > FUBIK-something-or-other on the other. The stuck exe was using zero cpu and > just sitting there indefinitely. Running it manually at the command-line > didn't stall. The sh.exe that invoked the iffe script is still alive but also > stalled. After killing the exe, the shell wakes up and carries on with the > build. > The FALBA2320.c test was checking for the presence of strdup and sure enough > it doesn't seem to appear in any of the feature test macros in > build/FEATURE/vmalloc. Sorry, I'm busy at the moment I can only say it worked for me. I'll check again if I can reproduce. Ciao Volker
setup.exe: Invalid or unsupported tar format
I've built setup.exe from source (updated today), and the ChangeLog says Brian Dessent fixed the "Invalid or unsupported tar format" problem with empty tar.bz2 files, but I am still seeing the error popup. 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. 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... $ cygcheck -cd | grep 'bzip\|tar\|cygwin' bzip2 1.0.3-2 cygwin 1.5.25-7 mingw-bzip2 1.0.3-2 tar 1.19-1 Am I missing anything? I'm not sure the best way to fix this; the following patch worked, but seems unlikely to actually be correct in all cases. Is an empty tarball the only case where the peek value will be zero? Index: install.cc === RCS file: /cvs/cygwin-apps/setup/install.cc,v retrieving revision 2.83 diff -u -p -w -r2.83 install.cc --- install.cc 9 Apr 2008 02:25:27 - 2.83 +++ install.cc 5 May 2008 20:15:13 - @@ -259,7 +259,7 @@ Installer::installOne (packagemeta &pkgm /* Decompression succeeded but we couldn't grok it as a valid tar archive. */ char c; - if (try_decompress->peek (&c, 1) < 0) + if (try_decompress->peek (&c, 1) < 0 || !c) // assume 0 indicates empty tarball /* In some cases, maintainers have uploaded bzipped 0-byte files as dummy packages instead of empty tar files. This is common enough that we should not treat this as an -- Bryan Thrall FlightSafety International [EMAIL PROTECTED]
Re: setup.exe: Invalid or unsupported tar format
"Thrall, Bryan" wrote: > I've built setup.exe from source (updated today), and the ChangeLog says > Brian Dessent fixed the "Invalid or unsupported tar format" problem with > empty tar.bz2 files, but I am still seeing the error popup. > > 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. That fix was for empty bzipped files, i.e. the result after decompression is a 0 byte file, so it's not exactly relevant to this situation. > 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... This code should not have ever been reached if the file contained a valid tar header, since archive::extract should not have returned NULL in that case. For a valid-yet-empty tar file (i.e. what the 46 byte thing is supposed to be) archive::extract should succeed but the first call to next_file_name will return an empty string. But it seems that "tar -T /dev/null" doesn't in fact produce anything resembling a valid tar file, it simply spits out 10k of zeros. And I checked all the old existing 46 byte .tar.bz2 files, and they are in fact just 10k of bzipped zeros. Sigh. Why does tar do this? This causes ::extract to return NULL (since it looks nothing like a tar file) but it's also not an empty file, so peek doesn't fail either. And again, to recap: the reason for generating an error instead of silently moving on in this situation was to diagnose the case where the maintainer used a strange tar implementation to create a package -- without the error the package will be silently skipped which is very confusing. But it seems like this nonsense 10k of zeros will have to be special cased in order to be able to detect the desired error case from the bogus error case. In the mean time, I suggest you use a real empty file as workaround (i.e. bzip2 file.tar.bz2) as that should correctly be detected as an empty package if you're using the current setup. Brian
RE: setup.exe: Invalid or unsupported tar format
Brian Dessent wrote on Monday, May 05, 2008 4:12 PM: > And again, to recap: the reason for generating an error instead of > silently moving on in this situation was to diagnose the case where > the maintainer used a strange tar implementation to create a package > -- without the error the package will be silently skipped which is > very confusing. But it seems like this nonsense 10k of zeros will > have to be special cased in order to be able to detect the desired > error case from the bogus error case. > > In the mean time, I suggest you use a real empty file as workaround > (i.e. bzip2 file.tar.bz2) as that should correctly be > detected as an empty package if you're using the current setup. Thanks for the explanation. I used 'bzip2 < /dev/null > file.tar.bz2', generating a 14 byte tar.bz2 file, and setup.exe handles it just fine. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED]
Re: setup.exe: Invalid or unsupported tar format
-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. | | But it seems that "tar -T /dev/null" doesn't in fact produce anything | resembling a valid tar file, it simply spits out 10k of zeros. Perhaps this is worth a question on the upstream tar list? According to http://www.opengroup.org/onlinepubs/009695399/utilities/pax.html, it looks like a valid tar file can exist without files, but needs 2 blocks of all 0 bytes to identify the end of the tar file. And since the default tar configures with tar options of -b20, I'm actually surprised it's not 20k of NUL bytes (2 blocks * 20 units of 512 per block). You can reduce the size of a valid tarball with 'tar -b1 -c -T /dev/null', but that's still a 1k file of all NULs. | | In the mean time, I suggest you use a real empty file as workaround | (i.e. bzip2 file.tar.bz2) as that should correctly be | detected as an empty package if you're using the current setup. By the way, the special 1.7 setup has this error enabled by default, making it report failure on any attempt to install packages like 'gcc' which are empty tarball placeholders with dependencies elsewhere when trying out the 1.7 tree. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgfvuYACgkQ84KuGfSFAYBH+QCfZomHQERLb7wBUUAP7+S26lUL fIEAnR6LS68JtzQOr8hKiDZPgMgUj2c1 =sLs1 -END PGP SIGNATURE-
