Re: libsnappy (Was: Bug#662513: RM: emboss/6.3.1-6)
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://tille@git.debian.org/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
Reply to: