Hi Charles, On Mon, Mar 05, 2012 at 10:03:03PM +0900, Charles Plessy wrote: > it is just that problem solved or not, I did not manage to go further. > > I spent tens of hours on this package, and still from one work session to the > other, I do not remember or understand what I did for making the package > build, > and I what I concretely need to do to make it uploadable. Worse, a fresh git > clone fails to build.
Strange my clone builds perfectly with git-buildpackage as well as a freshly created one using git clone git+ssh://[email protected]/git/users/plessy/snappy-java.git It ends up with lintian warnings (which are new since the time I worked on the package but are perfectly in the line of what I wrote in my last mail[1] when suggesting to strip problematic files from upstream source. P: snappy-java source: source-contains-hg-tags-file .hgtags P: snappy-java source: source-contains-prebuilt-windows-binary src/main/resources/org/xerial/snappy/native/Windows/amd64/snappyjava.dll P: snappy-java source: source-contains-prebuilt-binary src/main/resources/org/xerial/snappy/native/Linux/amd64/libsnappyjava.so P: snappy-java source: source-contains-prebuilt-windows-binary src/main/resources/org/xerial/snappy/native/Windows/x86/snappyjava.dll P: snappy-java source: source-contains-prebuilt-binary src/main/resources/org/xerial/snappy/native/Linux/i386/libsnappyjava.so P: snappy-java source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5 P: libsnappy-java-java: no-upstream-changelog > I think that my understanding on how java packages work > is too low, and I am not sure I want to invest the time learning it. In my last mail about this[1] I mentioned my upload to http://lists.debian.org/debian-med/2012/02/msg00005.html I would regard a test whether it works with your final target picard-tools as a useful precondition for a final upload. Could you please confirm that it works as expected? If yes, just tell me how to proceed. I'm pretty proud about my ability to break Git archives and injecting a *changed* upstream source into an existing repository with an existing pristine-tar seems like even less gifted people than me could succeed in breaking it. Because the package in in a private Git archive of yours anyway (is this correct or are there other clones hanging around??) we have the following options: 1. Create a fresh Git archive (in Debian Med) with the *changed* upstream tarball? 2. Inject the packaging into SVN What would you prefer (third option according to your preference is welcome). Kind regards Andreas. [1] http://lists.debian.org/debian-med/2012/02/msg00005.html -- http://fam-tille.de -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
