Re: [COVID-19 Hackathon] Bazel build system pending NEW
Hi Michael, I went through the list of missing dependencies. aws-*: I'm not interested in them. In the past I just (manually) filtered out all the code associated with aws functionalities. Most of them are possibly not packaged yet. abseil-cpp: this is a tricky one. Similar to facebook/folly. It does not guarantee a stable ABI. Once the system-provided abseil breaks the tensorflow, we have to embed one. Anyway it's present in our archive: libabsl-dev but I don't know whether tensorflow builds against it. re2: already present in archive. I guess there is no reason to embed it. boringssl: maybe a simple string replacement s/boring/open/g will just work? farmhash: in archive, and I'm the uploader. Ping me if it needs to be updated. eigen: sometimes TF relies on new features that debian's libeigen3-dev does not provide. In that case we have to use an embedded tarball again. highwayhash: in archive, and I'm the uploader. fft2d: TF uses merely 1 source file from this project for merely one OP/Kernel. Just keep it embedded. The last upstream update was ~10 yrs ago (IIRC). On Mon, Aug 31, 2020 at 05:32:56PM +0200, Michael R. Crusoe wrote: > Hey Mo, we have some unpackaged dependencies. Currently TensorFlow can be > built > using code copies, but obviously that isn't a great plan. Here are the current > code copies: > https://github.com/meteorcloudy/tensorflow/tree/r2.2-debian/debian > /dist > > If you want to help out you can use the bazel-bootstrap and > libcheck-framework-java binary packages from https://people.debian.org/~olek/ > packages/ Great! Thanks for the hint.
Re: [COVID-19 Hackathon] Bazel build system pending NEW
On Mon, Aug 24, 2020 at 4:51 PM Olek Wojnar wrote: > Hi Mo, > > Sorry about the slow reply, I've been a bit buried with emails and I'm not > answering them as well as I would like. :( > > On Wed, Aug 19, 2020 at 12:40 AM Mo Zhou wrote: > >> Hi Olek, >> >> What a good news! Your hardword is much appreciated. >> > > Thanks! I'm really looking forward to this making life easier for people > who want to package software that uses Bazel to build. > > There are some preliminary packaging changes (using bazel) for >> tensorflow. Is it in shape so that I can build TF from the git repo? >> Or what remains to be done? >> > > I'm not sure, Michael (copied above) took the lead on the TensorFlow > packaging. Michael, could you please provide an update? Are you running > into any specific issues that you could use help with? > Hey Mo, we have some unpackaged dependencies. Currently TensorFlow can be built using code copies, but obviously that isn't a great plan. Here are the current code copies: https://github.com/meteorcloudy/tensorflow/tree/r2.2-debian/debian/dist If you want to help out you can use the bazel-bootstrap and libcheck-framework-java binary packages from https://people.debian.org/~olek/packages/ > > Our primary contact on the upstream Bazel team (who also does some work > with upstream TensorFlow) verified that the latest Debian Bazel > (bazel-bootstrap) package *does* successfully build TensorFlow but I > believe there may have been some TensorFlow dependencies that were still > missing in Debian? > I've added our upstream contact Yun Peng to this thread. > > -Olek >
Re: ycm-cmake-modules / Re: Introduction and joining the debian-science/robotics team
Hi Joost, Thanks again... On 31/08/2020 11:27, Joost van Baal-Ilić wrote: > I've found some explanation at > https://lintian.debian.org/tags/file-references-package-build-path.html I already tried adding export DEB_BUILD_MAINT_OPTIONS = buildinfo=+path and export DEB_BUILD_MAINT_OPTIONS = reproducible=+fixfilepath to debian/rules, but neither of them helped. If I understand it correctly, the both just add a few c/c++ build flags... I might try fixing the file manually with `sed`, but I don't know if that's the right way to do it. > I'm pretty sure this issue has occured in lots of other packages but > my websearch skills fail it now... > > There's also https://tests.reproducible-builds.org/debian/reproducible.html > and lots of documentation supplied @ reproducible-builds.org . > > Does this help? I _might_ have time to search a bit more later. I think this is the page that should contain the related documentation is this one: https://reproducible-builds.org/docs/build-path/ I couldn't find anything working there, though. I managed to fix the lintian warning in this way: https://salsa.debian.org/science-team/ycm-cmake-modules/-/commit/6218fcf5a14095b2a34c7f85b780979ac76499b7 I couldn't find a better way to do it, does this seem a proper fix? Anyway the reprotest is still failing, the problem seems to be the searchindex.js file (generated by sphinx) that has some different content, but it is not a path. I don't think this can be fixed in the package, it should probably be fixed in sphinx. Cheers, Daniele
Re: ycm-cmake-modules / Re: Introduction and joining the debian-science/robotics team
Hi Daniele, On Mon, Aug 31, 2020 at 11:15:41AM +0200, Daniele E. Domenichelli wrote: > On 28/08/2020 14:02, Joost van Baal-Ilić wrote: > > I had a quick look at it and I didn't find any obvious flaws, apart > > from > > > > Now running lintian ycm-cmake-modules_0.11.3-3_amd64.changes ... > > W: ycm-cmake-modules: embedded-javascript-library > > usr/share/doc/ycm-cmake-modules/html/_static/language_data.js please use > > sphinx > > N: 23 tags overridden (23 info) > > Finished running lintian. > > > > . Could you look into that? > > > Thanks for the review. > The warning should be fixed now. Nice! > I was also able to enable salsa-ci, see > https://salsa.debian.org/science-team/ycm-cmake-modules/-/pipelines/170272/builds > > Unfortunately the "reprotest" (that if I understand it correctly is a > reproducibility test) is failing, probably for this lintian warning: > > I: ycm-cmake-modules: file-references-package-build-path > usr/share/doc/ycm-cmake-modules/html/todo.html > > This file contains entries like > > ``` > (The href="manual/ycm-superbuild.7.html#id2">original entry is > located in > /build/ycm-cmake-modules-0.11.3/help/manual/ycm-superbuild.7.rst, line > 215.) > ``` > > for each `.. todo::` line in the sphinx documentation. > > Unfortunately I don't know what is the proper fix it, since it is a file > generated by sphinx... Do you have any suggestion? I think you're right that /build/... in sphinx generated docs causes problems. I've found some explanation at https://lintian.debian.org/tags/file-references-package-build-path.html I'm pretty sure this issue has occured in lots of other packages but my websearch skills fail it now... There's also https://tests.reproducible-builds.org/debian/reproducible.html and lots of documentation supplied @ reproducible-builds.org . Does this help? I _might_ have time to search a bit more later. Thanks, Bye, Joost
Re: ycm-cmake-modules / Re: Introduction and joining the debian-science/robotics team
On 28/08/2020 14:02, Joost van Baal-Ilić wrote: > I had a quick look at it and I didn't find any obvious flaws, apart > from > > Now running lintian ycm-cmake-modules_0.11.3-3_amd64.changes ... > W: ycm-cmake-modules: embedded-javascript-library > usr/share/doc/ycm-cmake-modules/html/_static/language_data.js please use > sphinx > N: 23 tags overridden (23 info) > Finished running lintian. > > . Could you look into that? Thanks for the review. The warning should be fixed now. I was also able to enable salsa-ci, see https://salsa.debian.org/science-team/ycm-cmake-modules/-/pipelines/170272/builds Unfortunately the "reprotest" (that if I understand it correctly is a reproducibility test) is failing, probably for this lintian warning: I: ycm-cmake-modules: file-references-package-build-path usr/share/doc/ycm-cmake-modules/html/todo.html This file contains entries like ``` (The original entry is located in /build/ycm-cmake-modules-0.11.3/help/manual/ycm-superbuild.7.rst, line 215.) ``` for each `.. todo::` line in the sphinx documentation. Unfortunately I don't know what is the proper fix it, since it is a file generated by sphinx... Do you have any suggestion? Thanks. Cheers, Daniele
