Guix supported-systems option

Guix supported-systems option

[phodina via]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

Hello,

I have recently uncovered a "feature" that works little bit than described in the manual,

During definition of a new variable, package, there is an option called supported-systems​ which defaults to %default-systems​.

However, if the package is known to work on certain architecture the right thing is to list the supported architectures, right?

If I select package which is not supported by my current architecture and build it I get notification like this one:
`warning: package grafana@9.3.2 does not support x86_64-linux`

So suppose I have the same package for different architectures, each has it's own unique tarball.

I've defined one package and inherited from it, changing the source​ for the other and selecting the correct supported-systems​.
Unfortunately, this approach fails as Guix does not select the right package I want to use on the current system.

So should the approach be to define just one variable for the package and then conditionally select the right tarball/git for the package?

Also is this considered bug or a feature?

FIY I know the right way would be to build Grafana from source in this case which would solve the issue I just wanted to know in general more about the use case of the supported-systems​ option.

----
Petr

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: grafana.scm --]
[-- Type: text/x-scheme; name=grafana.scm, Size: 4627 bytes --]

;;; SPDX-License-Identifier: GPL-3.0-or-later
;;; Copyright © 2021-2022 Petr Hodina <phodina@protonmail.com>

(define-module (nongnu packages grafana)
  #:use-module (guix packages)
  #:use-module (gnu packages base)
  #:use-module (gnu packages elf)
  #:use-module (gnu packages gcc)
  #:use-module (gnu packages glib)
  #:use-module (guix download)
  #:use-module (nonguix build-system binary)
  #:use-module ((guix licenses)
                #:prefix license:))

(define-public grafana-bin
  (package
    (name "grafana")
    (version "9.3.2")
    (source (origin
              (method url-fetch)
              (uri (string-append
                    "https://dl.grafana.com/oss/release/grafana-" version
                    ".linux-amd64.tar.gz"))
              (sha256
               (base32
                "177d396sg6pwa7vwsdwqy6fg17kq47n619s4745z62s6inq3i0vr"))))
    (build-system binary-build-system)
    (arguments
     '(#:strip-binaries? #f ;TODO: For some reason it fails validate-runpath
       ;; phase if enabled
       #:install-plan `(("bin/grafana-cli" "bin/grafana-cli")
                        ("bin/grafana-server" "bin/grafana-server")
                        ("conf/defaults.ini" "etc/grafana/grafana.ini")
                        ("conf" "share/grafana/")
                        ("public" "share/grafana/")
                        ("scripts" "share/grafana/")
                        ("plugins-bundled" "share/grafana/"))
       #:patchelf-plan (list (list "bin/grafana-cli"
                                   '("glibc" "gcc:lib"))
                             (list "bin/grafana-server"
                                   '("glibc" "gcc:lib")))
       #:phases
       ;; TODO: This should be moved to the service
       (modify-phases %standard-phases
         (add-after 'unpack 'fix-data-dir-path
           (lambda _
             (substitute* "conf/defaults.ini"
               (("data = data")
                "data = /var/lib/grafana")
               (("logs = data/log")
                "data = /var/logs/grafana")
               (("plugins = data/plugins")
                "data = /var/lib/grafana")))))))

    (supported-systems '("x86_64-linux"))
    (native-inputs (list patchelf))
    (inputs `(("gcc:lib" ,gcc "lib")
              ("glibc" ,glibc)))
    (synopsis "Platform for monitoring and observability")
    (description
     "Grafana allows you to query, visualize, alert on
and understand your metrics no matter where they are stored.  Create, explore,
and share dashboards with your team and foster a data-driven culture:
@enumerate
@ite Visualizations: Fast and flexible client side graphs with a multitude
of options.  Panel plugins offer many different ways to visualize metrics
and logs
@item Dynamic Dashboards: Create dynamic & reusable dashboards with template
variables that appear as dropdowns at the top of the dashboard.
@item Explore Metrics: Explore your data through ad-hoc queries and dynamic
drilldown.  Split view and compare different time ranges, queries and data
sources side by side.
@item Explore Logs: Experience the magic of switching from metrics to logs with
preserved label filters. Quickly search through all your logs or streaming them
live.
@item Alerting: Visually define alert rules for your most important metrics.
Grafana will continuously evaluate and send notifications to systems like Slack,
PagerDuty, VictorOps, OpsGenie.
@item Mixed Data Sources: Mix different data sources in the same graph! You can
specify a data source on a per-query basis. This works for even custom
datasources.
@end enumerate")
    (home-page "https://grafana.com/")
    (license license:agpl3)))

(define-public grafana-bin-aarch64
  (package
    (inherit grafana-bin)
    (name "grafana")
    (version "9.3.2")
    (source (origin
              (method url-fetch)
              (uri (string-append
                    "https://dl.grafana.com/oss/release/grafana-" version
                    ".linux-arm64.tar.gz"))
              (sha256
               (base32
                "1ps8aa279fh8hcngda794f69w6hm78pw9pgvwyxlnx229581zrkv"))))
    (supported-systems '("aarch64-linux"))))

(define-public grafana-bin-armhf
  (package
    (inherit grafana-bin)
    (name "grafana")
    (version "9.3.2")
    (source (origin
              (method url-fetch)
              (uri (string-append
                    "https://dl.grafana.com/oss/release/grafana-" version
                    ".linux-armv7.tar.gz"))
              (sha256
               (base32
                "0avndch41m5k7gpxzdk8k1gzz3nyscmw3va4mk5813vbfmynv2bn"))))
    (supported-systems '("armhf-linux"))))

Re: Guix supported-systems option

[Julien Lepiller]

I think you have multiple packages with the same name and version, but different supported systems. Am I right?

If that is the case, then guix will select a package based on the specification you give it, so if you give a name, it will select the package with that name and the highest version available. If multiple packages match this criteria, one is selected arbitrarily.

Now, supported-systems does not mean "remove this package on other architectures", but rather "can't build this on other architectures". So it's perfectly possible that guix will arbitrarily select a package for a different architecture.

I can see two solutions: as you mentionned, get source depending on architecture, that way the other architecture packages are not defined. Another possibility is to append say -x86_64 to the package name.

Does it make sense?

Le 14 janvier 2023 20:33:13 GMT+01:00, phodina via <help-guix@gnu.org> a écrit :
>Hello,
>
>I have recently uncovered a "feature" that works little bit than described in the manual,
>
>During definition of a new variable, package, there is an option called supported-systems​ which defaults to %default-systems​.
>
>However, if the package is known to work on certain architecture the right thing is to list the supported architectures, right?
>
>If I select package which is not supported by my current architecture and build it I get notification like this one:
>`warning: package grafana@9.3.2 does not support x86_64-linux`
>
>So suppose I have the same package for different architectures, each has it's own unique tarball.
>
>I've defined one package and inherited from it, changing the source​ for the other and selecting the correct supported-systems​.
>Unfortunately, this approach fails as Guix does not select the right package I want to use on the current system.
>
>So should the approach be to define just one variable for the package and then conditionally select the right tarball/git for the package?
>
>Also is this considered bug or a feature?
>
>FIY I know the right way would be to build Grafana from source in this case which would solve the issue I just wanted to know in general more about the use case of the supported-systems​ option.
>
>----
>Petr

Re: Guix supported-systems option

[phodina via]

Hi Julien,

> I think you have multiple packages with the same name and version, but different supported systems. Am I right?

you are correct. I have multiple package definitions as shown in the attached scheme file.

The names and versions are exactly the same, just the origin differs and Guix picks "randomly" one of them.

I did as you suggested to rename the packages - append the arch. This works in short term but I'd like to have one profile and just apply it on my laptop (x86_64) as well as on Raspberry Pi (aarch64, recently added to Guix by Stefan).

Having different names will then not work or results in even bigger mess with if statements.

> Now, supported-systems does not mean "remove this package on other architectures", but rather "can't build this on other architectures". So it's perfectly possible that guix will arbitrarily select a package for a different architecture.

Well this is the reason I ask. I though this has deeper meaning as to tell Guix, okay you found a package with that name, but it's not for current architecture. So keep looking and if you don't find any other return this one with a warning that it's not supported.

So the "right" way would be conditionally select the right origin for the package and use just one package definition with list of supported systems, right?

----
Petr

Re: Guix supported-systems option

[Julien Lepiller]

That's how it's done with some packages that need arch-specific things (inputs, build phases, …) so yes :)

Le 14 janvier 2023 23:01:49 GMT+01:00, phodina <phodina@protonmail.com> a écrit :
>Hi Julien,
>
>> I think you have multiple packages with the same name and version, but different supported systems. Am I right?
>
>you are correct. I have multiple package definitions as shown in the attached scheme file.
>
>The names and versions are exactly the same, just the origin differs and Guix picks "randomly" one of them.
>
>I did as you suggested to rename the packages - append the arch. This works in short term but I'd like to have one profile and just apply it on my laptop (x86_64) as well as on Raspberry Pi (aarch64, recently added to Guix by Stefan).
>
>Having different names will then not work or results in even bigger mess with if statements.
>
>> Now, supported-systems does not mean "remove this package on other architectures", but rather "can't build this on other architectures". So it's perfectly possible that guix will arbitrarily select a package for a different architecture.
>
>Well this is the reason I ask. I though this has deeper meaning as to tell Guix, okay you found a package with that name, but it's not for current architecture. So keep looking and if you don't find any other return this one with a warning that it's not supported.
>
>So the "right" way would be conditionally select the right origin for the package and use just one package definition with list of supported systems, right?
>
>----
>Petr