* Package name : roughtime Upstream Author : Google, Inc. * URL : https://roughtime.googlesource.com/roughtime * License : Apache 2.0 Programming Lang: Go Description : Secure time synchronisation Roughtime is a protocol that aims to achieve rough time synchronisation in a secure way that doesn't depend on any particular time server, and in such a way that, if a time server does misbehave, clients end up with cryptographic proof of it.
Hi, FYI this will be slightly delayed as it uses Bazel to build which is not in Debian (yet)... Regards,
block 782654 by 838416 thanks Hi, Can you update on the latest status? Regards,
unblock 782654 by 838416 block 838416 by 782654 thanks Hi lamby, I think you swapped the blocker and blockee there. Also, I would be pretty keen on seeing roughtime packaged in Debian, so don't hesitate to ping me in you need a co-maintainer. :) Best, nicoo
Nicoo, I think you forgot to cc or bcc control@bugs.debian.org … but I fixed it in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838416;msg=21 so no worries. Well, if you could package Bazel… :) Regards,
Unfortunately, there's more work than just "packaging" Bazel. Just to package Bazel, the open issues are: (1) Getting Bazel's dependencies packaged in Debian, with acceptable versions. (2) Fixing the Bazel build process to use Debian JAR files, rather than pre-built versions shipped with Bazel. (3) Fixing the Bazel build process to comply with Debian policy around static linking and self-extracting binaries. But... even with that, Bazel cannot be used to _build_ a Debian package, because it does not create Debian-policy-compliant binaries, and it does not support all the Debian cross-compiler flags. In order to fix that, a bunch more integration work is needed, including rewriting the Bazel "architecture specs" to use Debian architecture names or tuples instead, and to fix the built-in rules to properly support fully-dynamic linking and library installation paths. So, yeah, it's a lot of work, and I haven't really had time to make much progress. Cheers, Kyle Moffett
Kyle Moffett wrote: […] Oh! My smiley was meant to represent how packaging Bazel is not a simple task and thus imply you were delaying for no obvious reason! Apologies that did not come across via email. Oh, can you elaborate on this? Thanks so much for clarifying the other issues; very useful for myself and for others coming across this bug report. If your opinionn should, for example, Roughtime try and rewrite the build system in the meantime/long-term? Regards,
Chris Lamb wrote: Gentle ping on this? Best wishes,
I spent a while working on it off and on, but there is a decent amount of tweaking and other packaging work needed to get policy-compliant bazel packages. (E.G: There are quite a few binary JAR files shipped in the upstream tarball that don't necessarily match the versions in Debian). I just didn't have the spare time, especially now that I have a kid, to sink into one package. (Also, FWIW, if you want to _create_ policy-compliant packages using bazel, there is a lot more work than just getting a policy-compliant bazel package, because bazel needs to understand debian multiarch compilers, standard build flags, etc). Cheers, Kyle Moffett
Hi Kyle, (or other interested/involved parties) Bazel has suddenly become more important because it is preventing us from getting packages working that would help with the COVID-19 pandemic. Due to the significance, I am copying the Debian Med team as well as key people from this bug's history in the hopes of getting something moving quickly. recently? Did you ever upload any of your work? In the meantime, I see that Bazel has an unofficial Ubuntu build [1]. Do you know anything about that? It seems like a good place for us to start if you aren't close to a product yourself. Oh, and to state this explicitly: I'm happy to work on this if it'll help it get into Debian faster! I just don't want to step on anyone's toes if someone has already made significant progress on this ITP.
That's the build Google provides that is built with Bazel itself, using a ton of vendored libraries. (Because that's how Google operates internally.) Generally the pkg_deb output[1] is not really policy-compliant and more built from the ground up without any Debian tooling. So the /mere existence/ of that package (which was there from the beginning) does not help the quest of getting Bazel packaged for Debian, unfortunately. Kind regards Philipp Kern, obviously not speaking for Google [1] https://github.com/bazelbuild/bazel/blob/f828b4c77805ad0ea6afecef798aa69d68bec8d4/scripts/packages/debian/BUILD#L69
Upstream seems to be friendly Time to prod them: https://github.com/bazelbuild/bazel/issues/9408
Philipp and Bastien, Thank you both for your responses! On Thu, Apr 9, 2020 at 4:23 PM Bastien ROUCARIES < roucaries.bastien@gmail.com> wrote: Thanks for highlighting that. It indeed seems that they will likely realize the importance of their software right now and help. Pinged. :) [1] Ah, ok. Good to know. Thanks. Might be better to just start with a vanilla source package then. I'm playing around with it just to see what I can get working while we wait for a reply to my ping on Bastien's GitHub issue. Well that's not as encouraging as I'd hoped but still good information to have. Sounds like our best shot for getting something working in the near-term is active cooperation and support from Google. Here's hoping they support that!!
To those interested in Bazel in Debian: We just had a very positive discussion with upstream and I think that finally getting Bazel into Debian is on the horizon. This endeavor is going to be larger than one person, in the long run if not right at this moment. Therefore, I would like to create a Bazel packaging team in Debian since a team approach is what will ensure this build system remains viable and well-supported even after the short-term goal of helping to get software into Debian to address the COVID-19 pandemic. If you are subscribed to this bug and are interested (or know someone who is), please let me know if you would like to be part of that team in some capacity. I am happy to continue coordinating this team and I am equally happy to pass that responsibility on if anyone else has a strong desire to do that. Since Kyle was previously working this project by himself, I definitely defer to him if he has the time and desire to lead the new team. Looking forward to getting a good group of people together who can contribute to this, to whatever extent they are able!
Hi Olek,
while I doubt that I'll be of technical help to work on this package I'd
like to express that I'm extremely happy. Your effort for bazel which
will finally a big step to get tensorflow in which is a precondition for
several COVID-19 releavant packages is really welcome.
Thanks a lot
Andreas.
Dear Debian Developer, thank you for your consideration of packaging roughtime for Debian! Would an (alternative) roughtime client be more suitable, easier for packaging? I've created a simple list with information about roughtime including a roughtime client list. Will expand that list as other roughtime clients are discovered. https://www.whonix.org/wiki/Dev/TimeSync#roughtime Copying the the roughtime client list here for convenience. * https://roughtime.googlesource.com/roughtime * https://github.com/cloudflare/roughtime * https://github.com/int08h/roughenough * https://github.com/int08h/roughenough-fuzz * https://github.com/ffledgling/python-roughtime * https://github.com/dansarie/pyroughtime * https://github.com/Merovius/notary/tree/master/roughtime * https://github.com/nahojkap/craggy * https://github.com/tajchert/securetime * https://github.com/topics/roughtime * https://github.com/bnoordhuis/node-roughtime Kind regards, Patrick