Re: tensorflow_2.3.1-1_amd64.changes ACCEPTED into experimental, experimental
On Wed, 2022-02-09 at 19:53 +0000, Wookey wrote:
>
> My plan there was to move on to tensorflow 2.5.0 (or thereabouts)
> because cmake is allegedly properly supported and not having to deal
> with bazel and its perverse view of how things should be built would
> make things go so much faster.
Agreed.
> I don't know if there are issues with that. Certainly a newer
> tensorflow
> would presumably be a good thing?
Generally we should follow the new upstream releases. But we have
to also consider the bazel compactibility:
https://github.com/tensorflow/tensorflow/blob/master/.bazelversion
The master branch requires bazel 5.0.0 while we have 3.5.1 in unstable.
So it may be a good idea to upgrade to the latest tensorflow version
that the bazel in archive supports.
https://github.com/tensorflow/tensorflow/blob/v2.5.3/.bazelversion
Version 2.5.3 requires 3.7.2 ... I don't know whether anything would
break.
Bazel is volatile. When I worked on tensorflow packaging bazel
may break something on every version bump, in my impression.
> I guess if the 2.3.1 fix isn't too taxing people would like to have a
> working upload of that before version-bumping because then at least
> we
> have _something? Right. I do actually have a 2.3.1 with tflite built
> too (which was more-or-less working - there was some annoying issue
> with it insisting on downloading something or other IIRC). But of
> course even that would be another trip through new.
>
> So I guess I'm taking feedback on the relative usefulness of
> 1) a 2.3.1 that actually builds
> 2) a 2.3.1 with tflite too
> 3) a newer tensorflow version.
>
> Wookey
If you have tensorflow reverse dependencies in mind, or regard
tflite as an important component, please follow your mind.
I think fixing stuff in any order should be fine before
we ship the python3-tensorflow binary package.
Thus I hold a neutral view on the three options.
Reply to: