On Sat, May 8, 2010 at 3:41 AM, sebb <seb...@gmail.com> wrote: > On 08/05/2010, sebb <seb...@gmail.com> wrote: >> On 08/05/2010, Paul Querna <p...@querna.org> wrote: >> > On Fri, May 7, 2010 at 6:04 PM, sebb <seb...@gmail.com> wrote: >> > > On 08/05/2010, Paul Querna <p...@querna.org> wrote: >> > >> On Fri, May 7, 2010 at 5:33 PM, sebb <seb...@gmail.com> wrote: >> > >> > On 07/05/2010, Paul Querna <p...@querna.org> wrote: >> > >> >> On Fri, May 7, 2010 at 3:48 AM, sebb <seb...@gmail.com> wrote: >> > >> >> > On 07/05/2010, Paul Querna <p...@querna.org> wrote: >> > >> >> >> Test tarballs for Apache Libcloud 0.3.1 are available at: >> > >> >> >> <http://people.apache.org/~pquerna/libcloud-0.3.1/> >> > >> >> > >> > >> >> > Where is the KEYS file? >> > >> >> >> > >> >> >> > >> >> http://www.apache.org/dist/incubator/libcloud/KEYS >> > >> >> >> > >> >> >> > >> >> > The directory structures of the bz2 and zip archives are >> different - the file >> > >> >> > r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json >> > >> >> > is in a different place in the archives. The bz2 archive needs >> to be corrected. >> > >> >> >> > >> >> >> > >> >> I don't understand what or why this is a problem. We use >> python's >> > >> >> distutils to create both the zip file and the tarbz2 from the >> same >> > >> >> export of the 0.3.0 source. The order of a file in a tar-strream >> > >> >> compared to a zip shouldn't matter in material way that I can >> think >> > >> >> of. >> > >> >> >> > >> > >> > >> > It's not the order that is the problem - the directory structure >> is different. >> > >> > The file is in a different directory in the two archives. >> > >> >> > >> >> > >> >> > >> $ find . -name >> r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json >> > >> >> ./tar/apache-libcloud-0.3.1/test/fixtures/rimuhosting/r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json >> > >> >> ./zip/apache-libcloud-0.3.1/test/fixtures/rimuhosting/r_orders_order_88833465_api_ivan_net_nz_vps_running_state.json >> > >> >> > >> I am unable to reproduce this problem on osx using the command line >> > >> tar and unzip tools? >> > >> >> > >> How are you extracting the tarball/zip file? >> > > >> > > Using an Ant script which uses: >> > > >> > > <bunzip2 src="${pathname}" dest="${filename}"/> >> > > <untar src="${filename}" dest="${filename}-bz2"/> >> > > <delete file="${filename}"/> >> > > >> > > with the appropriate settings. >> > > >> > > In the expanded bz2 archive, the file is in: >> > > >> > > test\fixtures\rimuhosting >> > > >> > > This is in parallel with >> > > apache-libcloud-0.3.1 >> > > under which all the other files appear. >> > > >> > > whereas in the expanded zip archive, the file is in: >> > > >> > > apache-libcloud-0.3.1\test\fixtures\rimuhosting >> > > >> > > I don't know whether it is relevant, but the file name is >> > > significantly longer than any of the others. >> > >> > >> > its a bug in ant: >> > https://issues.apache.org/bugzilla/show_bug.cgi?id=41924 >> >> >> Ah - did not know about that. >> It seems Winzip 9.0 has the same problem reading the tar file. >> >> Might perhaps be worth renaming the file if that is possible? > > Or use a different tool to create the tar - I just tried using Ant to > create the tar file with longfile="gnu", and the resulting tar file > is readable with both Ant and Winzip. > > Although using Ant creates an additional dependency, Ant is very commonly > used. > Also, Ant is cross-platform, unlike the current build tool.
libcloud will not be using ant to build its packages. python distutils are the standard for python projects. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
