Re: Bug#692000: ITP: liblbfgs -- L-BFGS solver for dense nonlinear optimization problems
> On Sun, 11 Nov 2012 09:38:07 +0100
> Andreas Tille <tille@debian.org> wrote:
>
> Hi Dima,
>
> sorry for the delay. I admit I'm more involved in Debian Med and hoped
> for some other sponsor on Debian Science. This did not happened and
> thus I try to stand to my suggestion and will help you.
>
> On Sun, Nov 04, 2012 at 10:50:15PM -0800, Dima Kogan wrote:
> >
> > OK. Thanks, Andreas.
> >
> > I just finished the packaging of those two libraries. Their gitwebs are
> >
> > http://anonscm.debian.org/gitweb/?p=debian-science/packages/libdogleg.git
> > http://anonscm.debian.org/gitweb/?p=debian-science/packages/liblbfgs.git
> >
> > libdogleg is more or less ready to go (i.e. I don't anticipate you'll find any
> > major issues).
>
> Hmmm, I noticed that you do not have a pristine-tar branch (in both archives)
> and I finally get
>
> dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../libdogleg_0.08.orig.tar.{bz2,gz,lzma,xz}
>
> Any reason to not use pristine-tar?
I can use pristine-tar here, but I'm not completely clear on why it is useful.
The upstream source comes from a tag in a git repo. This tag fully describes the
sources. One could make a tarball from this tag (this is what pristine-tar would
do), but why would this be a useful thing to do? Tell me if having a
pristine-tar branch is desirable, and I'll set it up.
I belive you see the dpkg-source error not because of the missing pristine-tar
but because you didn't ask for an upstream tarball to be generated. You likely
did a 'git checkout' and then a 'dpkg-buildpackage', right? If you do
'git-buildpackage' instead, it should build the source tarball from the tag
before building the binary package. Please tell me if I'm not understanding
something.
> > liblbfgs has something broken with its upstream build system which causes it to
> > ignore external CFLAGS and LDFLAGS. This makes the hardening options be ignored,
> > and things like DEB_BUILD_OPTIONS=noopt don't work. I looked into fixing it, but
> > my automake knowledge isn't sufficient to do this yet. I don't know if this
> > issue precludes the package from being worthy of being uploaded. In either case,
> > help with this would be appreciated.
>
> Despite also a pristine-tar is lacking (no idea how git-buildpackage
> worked around here - I'm not a Git expert) the build worked and as far
> as I would see it the lintian warnings about hardening are false
> positives. Looking at the build log the hardening options are injected
> and thus I uploaded the package.
Thanks, Andreas. One note is that I don't think the lintian warnings are
entirely false-positives. The liblbfgs Makefiles don't accept external LDFLAGS,
so the linker hardening pieces were likely ignored (-Wl,-z,relro for instance).
This is probably not a huge deal, though.
Also, git-buildpackage can create a tag in the repo to identify particular
package releases. One can make it with 'git-buildpackage --git-tag'. I'll do
this now for liblbfgs.
Thanks again
dima
Reply to: