guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Notes from the Guix meetup


From: Ludovic Courtès
Subject: Notes from the Guix meetup
Date: Tue, 11 Dec 2018 18:22:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hello Guix!

Yesterday ~9 people showed up at the Guix meeting we had at Inria in
Paris.  Below are notes I took of the different topics we discussed (we
came up with the agenda live.)  The notes might not be perfectly
understandable as-is, so feel free to ask if you have any questions!

Thanks to everyone who came yesterday and made it a pleasant day!

Ludo’.


* agenda

** bootstrapping

  - core-updates(-next) status report by janneke
  - ~20 packages before we reach gcc/glibc
    - maintenance burden
  - redundancy between Mes & Guile
    - strategy for bootstrappable Scheme?
    - using Mes instead of Guile in bootstrap derivations?
  - on wip-bootstrap: Gash used instead of “coreutils&co”
    - able to build make, sed, gzip, bash
  - Gash/Geesh merger

** user services & config

  - wip-deploy?
  - example: running znc, jackd
    + user service
    + systemctl --user
  - deploying Shepherd service + config
  - what interface?
    + add to =guix package -m= manifests?
      * would allow services to appear in the output of =guix pack= &
        co.
      * add an =activate= script to source PROFILE/etc/profile *and*
        start services (à la CONDA)
    + add a new separate command?
      * that way people wouldn’t have to use manifests
  - having a central view of user profiles
    + =guix package --list-profiles=?
  - user the (gnu services) API?
    + feasible?
  - use case: web dev
    + “guix system vm” or “container” could fill that use case
      + note: fix “guix system container” to not require root privileges
        (Bubblewrap?)

** “skill share” (after lunch)

  - (guix swh) (Ludo’)
  - EXWM (Janneke)
  - git worktree (Ricardo)

** HPC, “workflows”, and all that

  - overview & status
  - supporting “the cloud”
    + service that produces Docker/Singularity images
    + todo: produce layered Docker images like Nix folks
  - workflows
    + snakemake doesn’t handle software deployment
      + or does so through Docker
    + GWL = workflow + deployment
      + add support for Docker
      + add “recency” checks
      + data storage: IRODS?
  - Docker arguments
    + security: handling patient data with untrusted “:latest” images
    + Guix allows for “bisect”

** substitute delivery

  - options
    + commercial CDNs
      + should be possible to opt out of the CDN (privacy issue)
      + CloudFront (Amazon), Fastly, Akamai
      + make it cdn.guix.info?
      + ability to cap expenses?
      + cost estimate? donation?
    + handcrafted mirror network
    + help people run their stuff
      * provide GuixSD services
      * have a shared list of publish services
      * see the SKS key servers: geolocation-based DNS balancing
    + Bittorrent
      * requests are broadcasted -> privacy issue
    + IPFS
      + requests are broadcasted?
    + make substitute servers accessible over Tor
  - UX
    - the graft issue
      - you don’t know what’s going to be built
  - monitoring of head/build nodes
    + currently lacking!
    + prometheus-node-exporter is per-machine, no aggregation
    + Zabbix? Nagios?
  - replication of the berlin head node
    + using keepalived?
  - replication of the Git repo?
    + contact members of https://gitlab.com/GNU/Guix
  - organizational issues
    + example: rebooting berlin?
    + how to react to urgent matters?

** code review & automation

  - https://patchwork.cbaines.net
  - patchwork limitations
    + cannot determine reliably whether something has been merged
  - providing a ‘guix review’ command for patch submitters
    - rationale: everything we provide as a service should be available
      as a command for people to run
    - runs ‘guix lint’
    - runs ‘guix build’
    - optionally builds reverse dependencies
    - …
  - ‘guix apply NNN’ where NNN is a debbugs issue number
    + guile-debbugs
    + figure out what the latest version of the patch is
    + send email notification with mailutils?
    + or: update local database with issue status?
    + downside: we’d be reimplementing part of Patchwork
    + convention for Git branch names: “queue-NNN” where NNN is the
      debbugs number
  - automatic patch application as the horizon?
    + would allow substitutes to be available as soon as the patch hits
      master
  - ‘guix import’ as a service
  - ‘guix refresh’ as a service with human approval




reply via email to

[Prev in Thread] Current Thread [Next in Thread]