Re: gnu: Add syncthing.

[Leo Famulari]

On Fri, Dec 16, 2016 at 01:48:57PM +0100, Petter wrote:
> On 2016-12-16 02:52, Leo Famulari wrote:
> > On Thu, Dec 15, 2016 at 10:06:59PM +0100, Petter wrote:
> > > I've prefixed most of the packages with "golang-" now. However,
> > > there are
> > > some
> > > packages already starting with "golang-", f.ex.
> > > "golang-org-x-text-unicode-norm",
> > > and I left those alone. It's inconsistent, but I felt this was
> > > preferable to
> > > names like "golang-golang-org-x-text-unicode-norm". What do you think?
> > 
> > That's the right way. It fits the package naming guidelines:
> > 
> > https://www.gnu.org/software/guix/manual/html_node/Package-Naming.html
> 
> I'm able to interpret your answer both ways, should I make it
> "golang-golang-org-x-text-unicode-norm"?

I'm sorry to be unclear :)

I meant to say that the package should be called 
"golang-org-x-text-unicode-norm".

This matches what we do for Python packages:

If a project already contains the word python, we drop this; for
instance, the module python-dateutil is packaged under the names
python-dateutil and python2-dateutil. If the project name starts with py
(e.g. pytz), we keep it and prefix it as described above. 

https://www.gnu.org/software/guix/manual/html_node/Python-Modules.html

> > > Finally, there's a telemetry configuration in Syncthing. It is opt-in;
> > > but it will ask the user after a few hours if they want to join. The
> > > plan is to disable the question, however I suspect I've messed up the
> > > build system in that area, so this takes some more looking in to.
> > 
> > Personally, I'm fine with the upstream "opt-in" nag warning. It only
> > shows up when you open the Syncthing web interface; it's not an
> > intrusive desktop "notification". Once the user has said "yes" or "no",
> > it doesn't appear again until Syncthing makes a change to what
> > information they collect.
> > 
> > But, if people think our package should never ask, I don't mind if we
> > disable the request, as long as we share our changes with the Syncthing
> > project and they don't notice anything broken.
> 
> I'll make an attempt at this while the jury is out, primarily to
> retrieve the ability to edit files. (Either I broke it, or I need to
> learn how to use (snippet).

I applied the following diff to my package, and it made Syncthing
generate new configuration files with telemetry disabled. However, this
requires some of the tests to be adjusted. This caveat makes me wonder
if it's the right place to make the change, although I didn't find
another place with my limited Go knowledge.

diff --git a/gnu/packages/syncthing.scm b/gnu/packages/syncthing.scm
index 0ef38fcae..c67e85039 100644
--- a/gnu/packages/syncthing.scm
+++ b/gnu/packages/syncthing.scm
@@ -61,6 +61,13 @@
              (setenv "GOBIN" (assoc-ref outputs "out"))
              #t))
 
+         (add-after 'unpack 'disable-telemetry
+           (lambda _
+             (with-directory-excursion "src/github.com/syncthing/syncthing"
+               (substitute* "lib/config/optionsconfiguration.go"
+                 (("json:\\\"urAccepted\\\"")
+                   "json:\"urAccepted\" default:\"-1\"")))))
+
          (add-before 'build 'increase-test-timeout
            (lambda _
              (substitute* "src/github.com/syncthing/syncthing/build.go"

> Yes! Help please. The meta-data part is tricky and time consuming, I'd
> rather spend my Guix time on the build system than descriptions
> etc. Synopsis and descriptions are just stuff i found on their
> home-page.

Okay, I'll work on this and put it on a Git branch somewhere.

> > Don't forget the revision counter :)
> 
> Oh, I didn't see the need for it, with version being:
> "20160522.452c976".
> 
> Should version really be: "20160522-1.452c976"? I don't see revision
> here contributing any value.

[...]

> > > +(define-public golang-github-com-cznic-bufs
> > > +  (let ((commit "3dcccbd7064a1689f9c093a988ea11ac00e21f51"))
> > > +    (package
> > > +      (name "golang-github-com-cznic-bufs")
> > > +      (version (string-append "20160818." (string-take commit 7)))
> > 
> > Is this string '20160818' the date of the commit? If the package has no
> > releases, we use '0.0.0' in place of the version.
> 
> Yes. I figure this is best because some later project we'll package
> may be pinned to an earlier commit of a library, and then what?
> Incrementing the revision number would suggest this was of newer date,
> when it's not, and make the older commit appear as the newest version
> of the two to Guix.

We didn't really make a decision in the previous discussion:

https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00422.html

If Go packages have to use specific commits of their dependencies, then
we'll need to specify that version each time we use the package.

If we decide to use the date anyways, remember that commit timestamps
tend not to be chronologically ordered. The "push" timestamp would be
more meaningful.

I don't know the best way to get this timestamp, but you can see them
with:
git reflog --date=local origin/master

> > > +    (arguments
> > > +     `(#:import-path "github.com/cznic/internal/slice"
> > > +       #:unpack-path "github.com/cznic/internal"))
> > 
> > Is it too much to wonder if both the import-path and the unpack-path
> > could be auto-generated in cases like this? :)
> 
> We should consider this together with the url:
> (url (string-append "https://github.com/cznic/internal";))
> 
> "slice" is here a directory/package in the repository. For github.com
> we could probably assume that the repo is github.com/account/repo, but
> other domains may have different layouts. Also keeping in mind that
> the requested package could be a subpackage,
> "github.com/cznic/internal/slice/tricks".
> 
> For github.com this would suggest we use url of the subpackage in the
> recipe, otherwise we don't have the import-path, but this url is not
> retreivable (404 Not Found). And then we would need for (git-fetch) to
> cut the url after the repo part. At this point I think we're at a
> place we don't want to be.
> 
> I think the best we can do is only to skip #:unpack-path in these
> scenarios, and unpack according to domain and path of the url, as long
> as domain and path matches the start of the import-path. But as
> mentioned earlier, I don't know how to access the url in the build
> phases.
> 
> I like that you're looking for simplifying the recipes, this is my
> goal too. And I'm sure we can automate more.

Okay, hopefully somebody else has some advice here!