Re: tensorflow debian package
Hi Wookey,
On Sun, Jan 10, 2021 at 12:38:23AM +0000, Wookey wrote:
> OK. tensorflow made it to the top of my list. Sadly not in time for
> the upcoming stable, but well, that's life.
Cool. Despite tensorflow is extremely important for Debian Med we have
to much other stuff on our agenda, So I need to admit that I'm not
really competent to say something about tensorflow.
> So. I just tried building what is in https://salsa.debian.org/deeplearning-team/tensorflow
>
> One odd thing: the 2.3.1 that is in the pristine-tar branch does not exist as a tag upstream:
> https://github.com/tensorflow/tensorflow/tags
> they have 2.2.2 and 2.3.2.
> That's the upstream in the watch. Did you get 2.3.1 from somewhere else?
I have no idea at all, sorry. :-(
> I have a couple of general questions to start with:
>
> 1) What is the expected build/packaging workflow? I couldn't see a
> README that said. It seems that 'gbp buildpackage' is the rune to
> generate an orig tarball and start a build, but it's not clear if I
> should just commit things (in which case dpkg-source complains about
> changes) or use quilt in the usual way and commit patches? I'm used to
> either quilt-with-no-git or git-debrebase 'autogenerate the patches'
> workflows.
The Debian Med (and Science) team is using quilt[1]. I'm not sure whether
there should be a specific policy for the deeplearning team. But for the
moment I consider following Debian Med (Science) policy a good idea.
> (Hmm, the bazel manpage claims to have 'info' documentation, which
> seems surprising, and is of course wrong :-)
Probably a broken call of help2man. (I consider it a bug in help2man
that it assumes an info page by default which is a broken default.
But I'm to lazy to file that bug since all my scripts are explicitly
preventing that.)
> Is there a clean way to do a 2nd build with gbp? It complains about a
> changed repo, and indeed all the stuff which was patched by the debian
> patches is indeed changed, so I need to do a 'dpkg-source
> --after-build .' to unapply the patches so the repo is clean before
> doing gbp buildpackage. (why doesn't gbp buildpackage set up its build
> state, the way the dpkg-buildpackage does? Perhaps I am using the
> wrong tools here?)
If you follow the configuration suggestions in [1] you build in a
chroot (pbuilder) which prevents changing the Git repository. I admit
if the Git repository is not clean any more that's a bug in the clean
target anyway (but bugs are to be expected in the current packaging).
> OK. It looks like I should commit patches (a-la dpkg-source --commit)
> and use dpkg-buildpackage (and commit the patches to git). Then
> everything seems happy. That's fine by me. After removing the
> --noincompatible_prohibit_aapt1 option which seems to be specific to
> bazel2 I get a build going.
Sounds good!
> It builds for 20mins, doing 1400 jobs, but gives an error:
> INFO: Found 1 target...
> ERROR: /tmp/.cache/bazel/_bazel_wookey/9098405e8d823259e184e732fe09ae8e/external/jsoncpp_git/BUILD.bazel:22:8: declared output 'external/jsoncpp_git/include/json/autolink.h' is a dangling symbolic link
> ERROR: /tmp/.cache/bazel/_bazel_wookey/9098405e8d823259e184e732fe09ae8e/external/jsoncpp_git/BUILD.bazel:22:8: declared output 'external/jsoncpp_git/include/json/features.h' is a dangling symbolic link
> ERROR: /tmp/.cache/bazel/_bazel_wookey/9098405e8d823259e184e732fe09ae8e/external/jsoncpp_git/BUILD.bazel:22:8: Couldn't build file external/jsoncpp_git/include/json/allocator.h: not all outputs were created or valid
> Target //tensorflow:tensorflow_framework failed to build
> INFO: Elapsed time: 1392.385s, Critical Path: 102.20s
> INFO: 1393 processes: 1393 local.
> FAILED: Build did NOT complete successfully
> make[1]: *** [debian/rules:16: override_dh_auto_build] Error 1
>
> I can look into that.
That would be really cool.
> I should really ask you the more general question:
> 2) What still needs doing to make this package ready for debian?
It should fit your needs. ;-)
Well, we have other packages that are depending from python3-tensorflow.
My plan was to see whether the test suite of those packages will work
with the result of the packaging. I can not do more since I personally
have no idea about this software.
> I see that tensorflow-lite is not yet packaged and that is the part
> that I am most interested in, so I'd better work out how to do that, once I've got it building at all.
I'd recommend in focussing on your own needs first. We can check this
whether it also fit the Debian Med rdepends and need to adapt later
(when we finished all the work on those packages that should be part
of Debian 11 and have a realistic chance to be included.
Hope this helps
Andreas.
[1] https://med-team.pages.debian.net/policy/
--
http://fam-tille.de
Reply to: