[PATCH] gnu: Add prometheus.

OpenSubmitted by Gábor Boskovits.
Details
5 participants
  • Gábor Boskovits
  • Leo Famulari
  • Ludovic Courtès
  • Pierre Neidhardt
  • zimoun
Owner
unassigned
Severity
normal
G
G
Gábor Boskovits wrote on 22 Feb 2019 12:45
(address . guix-patches@gnu.org)(name . Gábor Boskovits)(address . boskovits@gmail.com)
20190222114537.1431-1-boskovits@gmail.com
* gnu/packages/monitoring.scm
(go-github-com-prometheus-prometheus-cmd-prometheus): New variable.
---
gnu/packages/monitoring.scm | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)

Toggle diff (34 lines)
diff --git a/gnu/packages/monitoring.scm b/gnu/packages/monitoring.scm
index 4384406227..0fd6b9e49b 100644
--- a/gnu/packages/monitoring.scm
+++ b/gnu/packages/monitoring.scm
@@ -447,3 +447,27 @@ written in Go with pluggable metric collectors.")
     (description "This package provides a file system monitor.")
     (home-page "https://github.com/emcrisostomo/fswatch")
     (license license:gpl3+)))
+
+(define-public go-github-com-prometheus-prometheud-cmd-prometheus
+  (package
+    (name "go-github-com-prometheus-prometheus-cmd-prometheus")
+    (version "2.7.1")
+    (source (origin
+              (method git-fetch)
+              (uri (git-reference
+                    (url "https://github.com/prometheus/prometheus.git")
+                    (commit (string-append "v" version))))
+              (file-name (git-file-name name version))
+              (sha256
+               (base32
+                "08nd88m162bw5612cvw5fl028l2n9jy1v4w2a8cyd0dj4lxs5d98"))))
+    (build-system go-build-system)
+    (arguments
+     '(#:import-path "github.com/prometheus/prometheus/cmd/prometheus"
+       #:unpack-path "github.com/prometheus/prometheus"))
+    (synopsis "Monitoring system & time series database")
+    (description "Prometheus is an open-source monitoring system with a
+dimensional data model, flexible query language, efficient time series database
+and modern alerting approach.")
+    (home-page "https://github.com/prometheus/node_exporter")
+    (license license:asl2.0)))
-- 
2.20.1
G
G
Gábor Boskovits wrote on 22 Feb 2019 13:21
Re: bug#34613: Acknowledgement ([PATCH] gnu: Add prometheus.)
(address . 34613@debbugs.gnu.org)
CAE4v=phFeyXQOY59QbPkZKCRLsNFc5EhDJ_UCOzjsoSD3yT36A@mail.gmail.com
Hello,

I have packaged prometheus.

There are some problems with it however:

The tarball has a vendor directory, containing sources of third party
go stuff. How do we deal with that?
(Should we package the stuff there, and link the sources into the tree?)

I have noticed a few possible problems:
indicates that glyphicons is possibly non-free, needs further
investigation.
does not copy the original LICENSE file from upstream, it is MIT
licensed. Should report a bug against prometheus.

Other preliminary license checks does not show further issues.

I would like to know if anyone could help me get this package into
shape, and point me towards a way to use inputs instead of linking the
source into the build tree. It would be nice, if we didn't have to
build these stuffs twice.
I am willing to do the work, but I need some pointer, as I am not into go.

Unbundling would also help to get a more exact license line.

Any help welcome.

Additionally:
1. this package misses a service,
2. only prometheus is built, the repository contains some other tools,
like promtool, those are not provided.

Best regards,
g_bor
L
L
Ludovic Courtès wrote on 11 Mar 2019 23:19
Re: [bug#34613] Acknowledgement ([PATCH] gnu: Add prometheus.)
(name . Gábor Boskovits)(address . boskovits@gmail.com)
87k1h5rr3k.fsf@gnu.org
Hi Gábor!

Gábor Boskovits <boskovits@gmail.com> skribis:

Toggle quote (6 lines)
> There are some problems with it however:
>
> The tarball has a vendor directory, containing sources of third party
> go stuff. How do we deal with that?
> (Should we package the stuff there, and link the sources into the tree?)

I think we generally do that yes. Pierre, Leo?

Toggle quote (5 lines)
> I have noticed a few possible problems:
> https://github.com/prometheus/prometheus/blob/master/vendor/github.com/influxdata/influxdb/LICENSE_OF_DEPENDENCIES.md
> indicates that glyphicons is possibly non-free, needs further
> investigation.

Glyphicons appears to be non-free, indeed. Could you check what Debian
does, for instance? It may be that we can just remove or replace it
with something else.

Toggle quote (4 lines)
> does not copy the original LICENSE file from upstream, it is MIT
> licensed. Should report a bug against prometheus.

OK.

Toggle quote (6 lines)
> I would like to know if anyone could help me get this package into
> shape, and point me towards a way to use inputs instead of linking the
> source into the build tree. It would be nice, if we didn't have to
> build these stuffs twice.
> I am willing to do the work, but I need some pointer, as I am not into go.

I’m ignorant about Go, but hopefully Pierre, Leo, or someone else with
experience with Go packaging can provide some guidance!

It’d be great to have Prometheus!

Thank you
Ludo’.
P
P
Pierre Neidhardt wrote on 12 Mar 2019 08:03
(name . Ludovic Courtès)(address . ludo@gnu.org)
878sxkh8v8.fsf@ambrevar.xyz
Toggle quote (4 lines)
> > (Should we package the stuff there, and link the sources into the tree?)
>
> I think we generally do that yes. Pierre, Leo?

We used to, but since Go 1.10 there is a bug in the compiler which keeps tracks
of _all_ recursive dependencies in the resulting _static_ binary. This can
result in a ridiculously large closure size.

As for now, I'd recommend the following:

- If there are many dependencies (check the vendor/ folder), use it, it will be
easier and produce a package with an ideal closure size.

- If it's only a few dependencies, it's probably worth it to package all of them
independently.

Toggle quote (5 lines)
> > I am willing to do the work, but I need some pointer, as I am not into go.
>
> I’m ignorant about Go, but hopefully Pierre, Leo, or someone else with
> experience with Go packaging can provide some guidance!

For a Go package with unvendored deps, I suggest you look at "demlo", it's
reasonably easy to understand. For vendored deps, look at go-ipfs.

The Go build system does most things right. A few pointers:

- Prometheus might use its own build system, e.g. with a Makefile. Then you'll
have to read the makefile to know what it's doing.

- In Go, it's possible to include multiple packages in the same repository. Our
Go build system does not handle this very well and it's not possible to use
multiple such packages as dependencies: you need to create a union. See
go-golang-org-x-crypto-union.

Let me know if you need more help, I can look into it.

Good luck!

--
Pierre Neidhardt
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAlyHWdsACgkQm9z0l6S7
zH+YlAf/Tv0VqZc1TyvxNMVsm15r8A4PhR7c2wX9p4ZGr5foS9OKozfMwqPO+NDW
u6QhFKLoE2U13ACgMxm0nV1RNgV3+U6kuxBxxZy4UIRS3m9qiPG4Zj3qgMGTnU9T
wujLlkNy4YiYCiGi6kXtgRdm8m50+IX/6qX5KJFWB/hmQkWKv75zzKGjVU5USQo2
r1HAz11twWBDsChgbl7KhEuIa0Lq7jHawOkTbF3bxD/KdDUFPyzd002fjmpQpHZz
RpKmJPVrpiMH6Cpu1GoAbW+0bJCr5jeGLvMMG2HxeA55lCBgOaeJU3zSQqePd2/D
VUk+P0tLiGAzTPKmEmizePrrYfXC5Q==
=i+P+
-----END PGP SIGNATURE-----

L
L
Leo Famulari wrote on 12 Mar 2019 20:31
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)
20190312193156.GA27496@jasmine.lan
On Tue, Mar 12, 2019 at 08:03:55AM +0100, Pierre Neidhardt wrote:
Toggle quote (4 lines)
> We used to, but since Go 1.10 there is a bug in the compiler which keeps tracks
> of _all_ recursive dependencies in the resulting _static_ binary. This can
> result in a ridiculously large closure size.

I am about to push a fix for this, probably to the staging branch. But I
think you should feel free to use the vendor tree for now and unbundle
things later.

Toggle quote (5 lines)
> - In Go, it's possible to include multiple packages in the same repository. Our
> Go build system does not handle this very well and it's not possible to use
> multiple such packages as dependencies: you need to create a union. See
> go-golang-org-x-crypto-union.

This becomes uneccesary with the work I am about to push.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlyICSkACgkQJkb6MLrK
fwhZ4g/8D+cw59cWu4bx8oigMQ+6ZrbVUnVWAZCq1FHEFFPtdWZUqGUp5SYRnjFV
QHMuZX57IwE53UxMZqk1pXkfEIEUyn7ShSd7C9mE6KT159i//V7SwxJGeIh5Jkzm
Whswg3HL2anD8KNROC9OvwAYpz+sBRGGazni2jokXUI03wJU+sakeZt4zjt5o/WH
R+Hq+q+TOpvJmjSySd9UBdIX1HsWkXESf8leRGLL3LTXl4XUAlWKheDUor4me15t
p/qu+c91sJWrc99/JTUknF/aaoVf0DkLJSnW+ZgKn4HpXGgd48mpRFfukeCWF4Cv
O9KeFWUdvgy7w7f9XdB1B0iITserrAX1IyxkdHyq10Lfd4tMkyx6d1BegnsLdiDR
9uiYFH+UD5JOMKXD0I5FulI1saLLwz91um1S3Mz7Dh07TjBSp4JNIbhUcpYCpqRp
Fg+tya2JwkVrnoY8lK0WFWIDtJlsN60J5gUjjAJQT8RuEs7N47f3/TqWLuhL3yJF
MGxCskB/KOH0pLAkp2EEcbrzyzrkgSWqPhDeYn+eQK0JHSQRtgFb8HY6Zr8uT3Wd
A0aisgY4EjdK6+O0tAlTjHUiKDqgCY0cK+gqPJXwK422wYHDKVz3fSVMSNy8MSHO
Yt+AHrhZASHn+4PJXOAQJRgwTGS3Y9YBqWaK5F79yW5pMP5RKcM=
=wgHS
-----END PGP SIGNATURE-----


G
G
Gábor Boskovits wrote on 12 Mar 2019 22:24
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)
CAE4v=pjGc4RWQb234PoGm5K4vu9LRRS9289Qy_oUK-eVfY5krw@mail.gmail.com
Hello,

Pierre Neidhardt <mail@ambrevar.xyz> ezt írta (időpont: 2019. márc.
12., K, 8:04):

Toggle quote (4 lines)
>
> - If there are many dependencies (check the vendor/ folder), use it, it will be
> easier and produce a package with an ideal closure size.

There are quite a lot.

Toggle quote (5 lines)
> The Go build system does most things right. A few pointers:
>
> - Prometheus might use its own build system, e.g. with a Makefile. Then you'll
> have to read the makefile to know what it's doing.

Yes, it does, but it turns out it is not actually needed.

Toggle quote (10 lines)
>
> - In Go, it's possible to include multiple packages in the same repository. Our
> Go build system does not handle this very well and it's not possible to use
> multiple such packages as dependencies: you need to create a union. See
> go-golang-org-x-crypto-union.
>
> Let me know if you need more help, I can look into it.
>
> Good luck!

Thanks!

Toggle quote (4 lines)
> Pierre Neidhardt
> https://ambrevar.xyz/


Best regards,
g_bor
G
G
Gábor Boskovits wrote on 12 Mar 2019 22:29
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAE4v=phonQqRR+1B+0cDagNYN9owhk1Vw2WhtZebNR0qucgCvA@mail.gmail.com
Hello,

Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2019. márc. 11., H, 23:20):
Toggle quote (10 lines)
>
> Hi Gábor!
>
> Gábor Boskovits <boskovits@gmail.com> skribis:

>
> Glyphicons appears to be non-free, indeed. Could you check what Debian
> does, for instance? It may be that we can just remove or replace it
> with something else.

I've checked this, this is not actually included in the prometheus
source anywhere,
only copied from the influxdb license file. The only other appearance
of glyphicons
in the code is for the web interface, where it is part of bootstrap,
and as such it is under
apl2.0 there.

I don't know if it is a problem to allow this influxdb module stub to
live in the source,
but I don't think so... (I would not consider this as a case of
promoting use of non-free
software.) Wdyt?

Toggle quote (3 lines)
> Thank you
> Ludo’.

Best regards,
g_bor
L
L
Ludovic Courtès wrote on 13 Mar 2019 11:06
(name . Gábor Boskovits)(address . boskovits@gmail.com)
87d0mvay1m.fsf@gnu.org
Hi,

Gábor Boskovits <boskovits@gmail.com> skribis:

Toggle quote (25 lines)
> Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2019. márc. 11., H, 23:20):
>>
>> Hi Gábor!
>>
>> Gábor Boskovits <boskovits@gmail.com> skribis:
>
>>
>> Glyphicons appears to be non-free, indeed. Could you check what Debian
>> does, for instance? It may be that we can just remove or replace it
>> with something else.
>
> I've checked this, this is not actually included in the prometheus
> source anywhere,
> only copied from the influxdb license file. The only other appearance
> of glyphicons
> in the code is for the web interface, where it is part of bootstrap,
> and as such it is under
> apl2.0 there.
>
> I don't know if it is a problem to allow this influxdb module stub to
> live in the source,
> but I don't think so... (I would not consider this as a case of
> promoting use of non-free
> software.) Wdyt?

What’s influxdb? I’m afraid I don’t understand this sufficiently well
to provide useful comments, but I trust you to make the right decision.
:-)

The thing is, Glyphicons does seem to be non-free, so if it ends up
being included one way or another, we have a problem. I would have
expected Debian to provide replacement icons or something like that.

Thanks,
Ludo’.
G
G
Gábor Boskovits wrote on 13 Mar 2019 13:33
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAE4v=piqORpLwLiZ_QZHeF+DidnA_-E_C+6CMZU4jZ4L2xt7Ow@mail.gmail.com
Hello,

2019. márc. 13., Sze 11:06 dátummal Ludovic Courtès <ludo@gnu.org> ezt írta:

Toggle quote (34 lines)
> Hi,
>
> Gábor Boskovits <boskovits@gmail.com> skribis:
>
> > Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2019. márc. 11., H,
> 23:20):
> >>
> >> Hi Gábor!
> >>
> >> Gábor Boskovits <boskovits@gmail.com> skribis:
> >
> >>
> >> Glyphicons appears to be non-free, indeed. Could you check what Debian
> >> does, for instance? It may be that we can just remove or replace it
> >> with something else.
> >
> > I've checked this, this is not actually included in the prometheus
> > source anywhere,
> > only copied from the influxdb license file. The only other appearance
> > of glyphicons
> > in the code is for the web interface, where it is part of bootstrap,
> > and as such it is under
> > apl2.0 there.
> >
> > I don't know if it is a problem to allow this influxdb module stub to
> > live in the source,
> > but I don't think so... (I would not consider this as a case of
> > promoting use of non-free
> > software.) Wdyt?
>
> What’s influxdb? I’m afraid I don’t understand this sufficiently well
> to provide useful comments, but I trust you to make the right decision.
> :-)
>
Influxdb is an optional dependency, you can configure prometheus to use it
as storage. It is not included in any ways. What is included is a module
that can connect to it.

Toggle quote (5 lines)
>
> The thing is, Glyphicons does seem to be non-free, so if it ends up
> being included one way or another, we have a problem. I would have
> expected Debian to provide replacement icons or something like that.
>
In the case it is included, as part of bootstrap, it is under the apache
license, because of a special agreement, that when it is part of bootstrap
it is dual licensed to this effect. My current evaluation is that it is ok
to include the package as is.

Toggle quote (4 lines)
>
> Thanks,
> Ludo’.
>
Attachment: file
L
L
Ludovic Courtès wrote on 18 Mar 2019 09:31
(name . Gábor Boskovits)(address . boskovits@gmail.com)
87pnqotwhd.fsf@gnu.org
Hi,

Gábor Boskovits <boskovits@gmail.com> skribis:

Toggle quote (2 lines)
> 2019. márc. 13., Sze 11:06 dátummal Ludovic Courtès <ludo@gnu.org> ezt írta:

[...]

Toggle quote (9 lines)
>> The thing is, Glyphicons does seem to be non-free, so if it ends up
>> being included one way or another, we have a problem. I would have
>> expected Debian to provide replacement icons or something like that.
>>
> In the case it is included, as part of bootstrap, it is under the apache
> license, because of a special agreement, that when it is part of bootstrap
> it is dual licensed to this effect. My current evaluation is that it is ok
> to include the package as is.

OK, sounds good.

Thank you for explaining!

Ludo’.
Z
Z
zimoun wrote on 7 Apr 14:29 +0200
Re: bug#34613: [PATCH] gnu: Add prometheus.
(name . Gábor Boskovits)(address . boskovits@gmail.com)(address . 34613@debbugs.gnu.org)
86mtgx2i0r.fsf@gmail.com
Hi,

What is the status of this old patch#34613:



On Fri, 22 Feb 2019 at 12:45, Gábor Boskovits <boskovits@gmail.com> wrote:
Toggle quote (39 lines)
> * gnu/packages/monitoring.scm
> (go-github-com-prometheus-prometheus-cmd-prometheus): New variable.
> ---
> gnu/packages/monitoring.scm | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/gnu/packages/monitoring.scm b/gnu/packages/monitoring.scm
> index 4384406227..0fd6b9e49b 100644
> --- a/gnu/packages/monitoring.scm
> +++ b/gnu/packages/monitoring.scm
> @@ -447,3 +447,27 @@ written in Go with pluggable metric collectors.")
> (description "This package provides a file system monitor.")
> (home-page "https://github.com/emcrisostomo/fswatch")
> (license license:gpl3+)))
> +
> +(define-public go-github-com-prometheus-prometheud-cmd-prometheus
> + (package
> + (name "go-github-com-prometheus-prometheus-cmd-prometheus")
> + (version "2.7.1")
> + (source (origin
> + (method git-fetch)
> + (uri (git-reference
> + (url "https://github.com/prometheus/prometheus.git")
> + (commit (string-append "v" version))))
> + (file-name (git-file-name name version))
> + (sha256
> + (base32
> + "08nd88m162bw5612cvw5fl028l2n9jy1v4w2a8cyd0dj4lxs5d98"))))
> + (build-system go-build-system)
> + (arguments
> + '(#:import-path "github.com/prometheus/prometheus/cmd/prometheus"
> + #:unpack-path "github.com/prometheus/prometheus"))
> + (synopsis "Monitoring system & time series database")
> + (description "Prometheus is an open-source monitoring system with a
> +dimensional data model, flexible query language, efficient time series database
> +and modern alerting approach.")
> + (home-page "https://github.com/prometheus/node_exporter")
> + (license license:asl2.0)))

Because the Go ecosystem changed a bit since the submission, do we merge
this patch? Especially in the light of:

There are some problems with it however:

The tarball has a vendor directory, containing sources of third party
go stuff. How do we deal with that?
(Should we package the stuff there, and link the sources into the tree?)



Well, I propose to drop this submission since the last interaction is
from 3 years, 2 weeks, 6 days ago and then start a fresh one. WDYT?


Cheers,
simon
Z
Z
zimoun wrote on 23 Jun 10:24 +0200
control message for bug #34613
(address . control@debbugs.gnu.org)
86mte3948v.fsf@gmail.com
tags 34613 + moreinfo
quit
?