New Swedish PO file for 'guix' (version 0.16.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/guix/sv.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/guix/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/guix.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: Automatically building packages affected by submitted patches
Ricardo Wurmus writes: >> In short, following on from some previous emails about Patchwork [1] and >> tracking and inspecting how Guix changes over time [2], I've got to the >> point where I have a very rough setup for building packages changed by >> patches sent to the guix-patches mailing list. > > This is great! I'm glad you think so :) >> With the goal of displaying a check in Patchwork about the >> build status of the affected packages, I need to compare what's been >> build by my Cuirass instance, with what https://ci.guix.info/ has >> built. To do this, my current plan is to have the Guix Data Service >> monitor a number of Cuirass instances somehow, extract information from >> them and store it. > > Would it not make sense to have the build farm perform the builds > instead of having a separate Cuirass instance? I'm using my Cuirass instance because it's easy to test with. But yes, I can see advantages in using the main build farm to perform the builds, especially in potentially providing substitutes more promptly. Were you thinking of anything in particular? >> - Looks at patch series in the Patchwork database that have been >>processed through the patchwork-test-series job in Laminar. > > Is the Laminar job something that could become part of Cuirass itself? The patchwork-test-series job [1] running within Laminar is doing a few things: - It takes the patches from patchwork.cbaines.net and applies them to the master branch. - (part 1) It pushes the resulting Git commits/branch up to [2]. - (part 2) It instructs the Guix Data Service to fetch the base and tip of the branch, and load the data from those commits. - (part 3) It also stores the hashes of the commits in the same database used by Patchwork. The above 3 parts of the process are a bit complicated, so I'll attempt to explain how they fit together. If you want to instruct Cuirass to build all the packages that are new or that have been changed, you need to know what the state was before the patches, and what the state with the patches looks like. This is where part 2 comes in. Once the Guix Data Service has processed the two commits, it can provide this information. This is where part 1 comes in providing the patches in a more machine readable form to the Guix Data Service and Cuirass, as they both fetch from the Git branch created in part 1. The Guix Data Service takes time to work out what's changed between the two revisions. This is where storing the commit hashes against the Patchwork series in the same database as Patchwork (part 3) comes in. That allows regularly checking if there are any Patchwork series that don't have a specification in Cuirass, and attempting to create one using the information from the Guix Data Service. 1: https://laminar.cbaines.net/cfg/jobs/patchwork-test-series.run 2: https://git.cbaines.net/guix/patches So back to your question, I don't think any of the above would fit neatly within Cuirass. I'm still thinking of Cuirass as a build service, you describe what you want it to build, and it goes away and does that. One thing I've become aware of recently is how similar Cuirass and the Guix Data Service actually are. The evaluations part of Cuirass and storing the derivations is very similar to the Guix Data Service. Do let me know if you have more thoughts or questions... Chris signature.asc Description: PGP signature
Re: Eliminate environment variable hints?
Hello, Ricardo Wurmus skribis: > when installing a package into a profile Guix very helpfully tells you > that you may need to set certain environment variables. It doesn’t tell > you that these environment variables can also be set by source’ing the > generated etc/profile file. > > I have seen the bashrc and bash_profile files of many users and they are > usually full of conflicting environment variable definitions. In these > files I often also see these Guix recommendations. > > I think Guix should suggest sourcing the generated etc/profile file > instead of listing explicit environment variable definitions. It would > be less noisy and less confusing, in my opinion. > > What do you think? When (re)sourcing etc/profile, you might clutter some variables. For instance, if you do that several times, you can end up with: PATH=$HOME/.guix-profile/bin:$HOME/.guix-profile/bin:$HOME/.guix-profile/bin:… Conversely, the hint upon installation disappears if the entry is already present in the variable. That’s a fine point but I occasionally rely on this as a user. That said, I understand your concern. What about changing the message to: You might need to run: . …/etc/profile Alternately, you can define the following environment variables: … Too verbose? Confusing? Thanks, Ludo’.
DNS delegation
Hi,
we've already discussed that multiple times, we'd like to have a DNS
delegation for guix.gnu.org, so that we can manage the zone ourselves
without having to rely too much on fsf sysadmins.
Here is a patch (untested) that aims at doing that. I've configured
bayfront and berlin to be DNS authoritative servers. bayfront is the
master (it is the one that needs to be updated when a change happens in
the zone), and berlin is set as slave (it will automatically follow
changes in bayfront). I've enabled dnssec on bayfront, since it's the
one that's going to sign the zone, and transfer signatures to its slave.
Currently the zone (in modules/sysadmin/dns.scm) is incomplete. What
needs to be there?
From 331a85e469579c02a3fc338a6fb0bade3916c666 Mon Sep 17 00:00:00 2001
From: Julien Lepiller
Date: Mon, 4 Mar 2019 22:00:22 +0100
Subject: [PATCH] hydra: Add dns services for guix.gnu.org.
* hydra/bayfront.scm (services): Add knot-service.
* hydra/berlin.scm (services): Add knot-service.
* hydra/modules/sysadmin/dns.scm: New file.
---
hydra/bayfront.scm | 16 +++-
hydra/berlin.scm | 19 -
hydra/modules/sysadmin/dns.scm | 70 ++
3 files changed, 101 insertions(+), 4 deletions(-)
create mode 100644 hydra/modules/sysadmin/dns.scm
diff --git a/hydra/bayfront.scm b/hydra/bayfront.scm
index fae5cb5..6ec21f2 100644
--- a/hydra/bayfront.scm
+++ b/hydra/bayfront.scm
@@ -1,7 +1,7 @@
;; OS configuration for bayfront, the frontend of the compile farm.
-(use-modules (gnu) (guix) (sysadmin people) (sysadmin services))
-(use-service-modules base networking admin shepherd)
+(use-modules (gnu) (guix) (sysadmin people) (sysadmin services) (sysadmin dns))
+(use-service-modules base dns networking admin shepherd)
(use-package-modules admin certs linux ssh tls vim package-management web wget)
(define %sysadmins
@@ -124,6 +124,18 @@ Happy hacking!\n"))
(service ntp-service-type)
+ ;; DNS
+ (service knot-service-type
+(knot-configuration
+ (zones (list (knot-zone-configuration
+ (inherit guix.gnu.org-zone)
+ (dnssec-policy "default")
+ (acl '("transfer-allow")
+ (acls (list (knot-acl-configuration
+(id "transfer-allow")
+(address (list berlin-ip4))
+(action '(transfer)))
+
(frontend-services %sysadmins
#:nar-ttl (* 45 24 3600)
#:motd %motd
diff --git a/hydra/berlin.scm b/hydra/berlin.scm
index 8d63a14..343e104 100644
--- a/hydra/berlin.scm
+++ b/hydra/berlin.scm
@@ -1,8 +1,8 @@
;; OS configuration for "berlin", the frontend of the compile farm
;; hosted at the MDC.
-(use-modules (gnu) (guix) (sysadmin services) (sysadmin people))
-(use-service-modules base databases monitoring networking admin shepherd)
+(use-modules (gnu) (guix) (sysadmin services) (sysadmin people) (sysadmin dns))
+(use-service-modules base databases dns monitoring networking admin shepherd)
(use-package-modules admin certs emacs linux monitoring
ssh tls vim package-management
web wget ci rsync)
@@ -164,6 +164,21 @@ Happy hacking!\n"))
(tty "ttyS0")
(baud-rate "115200")))
+ ;; DNS
+ (service knot-service-type
+ (knot-configuration
+(zones (list (knot-zone-configuration
+ (domain "guix.gnu.org")
+ (master '("bayfront-master"))
+ (acl '("notify-allow")
+(acls (list (knot-acl-configuration
+ (id "notify-allow")
+ (address (list bayfront-ip4))
+ (action '(notify)
+(remotes (list (knot-remote-configuration
+ (id "bayfront-master")
+ (address (list bayfront-ip4)))
+
;; Monitoring
(service zabbix-agent-service-type)
(service zabbix-server-service-type
diff --git a/hydra/modules/sysadmin/dns.scm b/hydra/modules/sysadmin/dns.scm
new file mode 100644
index 000..8ce93e6
--- /dev/null
+++ b/hydra/modules/sysadmin/dns.scm
@@ -0,0 +1,70 @@
+;;; GNU Guix system administration tools.
+;;;
+;;; Copyright © 2019 Julien Lepiller
+;;;
+;;; This program is free software: you can redistribute it and/or modify
+;;; it unde
Re: SANE / simple-scan working for anyone?
Mark, What a coincidence: Mark H. Weaver wrote: I just tried running 'simple-scan' with a CanoScan N1240U/LiDE 30 connected via USB, which has "complete" support according to the SANE docs. Although "lsusb" shows the scanner: I had the exact same problem yesterday with my CanoScan N670U/LiDE 20, which has also been fully supported by SANE for over a decade. Neither Simple Scan nor xsane reported any scanners. I ended up borrowing an Ubuntu machine to do the job… I left home immediately after and won't be able to test it further before the end of the week. Has anyone successfully scanned documents with SANE on a Guix System? Yes, but I hadn't tried recently. Kind regards, T G-R
Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)
On Sun, Mar 03, 2019 at 11:06:32AM -0500, Mark H Weaver wrote: > I don't know about berlin, but hydra.gnu.org has *never* successfully > built ungoogled-chromium. So far, it has made 3 attempts on > x86_64-linux and 5 attempts on i686-linux: [...] > If the same is true on berlin.guixsd.org, that would explain the lack of > binary substitutes. Berlin did build it, soon after the package was first added. I used the substitute on my machine which lacks the capacity build the package. signature.asc Description: PGP signature
Re: perl-getopt-long version string contains a letter
On Mon, Mar 04, 2019 at 05:54:38PM +0100, Ricardo Wurmus wrote: > Hi Guix, > > perl-getopt-long has a version string "v2.49.1". If we change this to > "2.49.1", will installed packages not be upgraded? What can be done in > this case? > As I've wrapped my head around it, Guix doesn't believe in "upgrades" and "downgrades", just in changes in dependencies. So if the version string loses the leading "v" I suppose ASCIIbetically v2.49.1 is a higher value than 2.49.1, but Guix just sees that before it was v2.49.1 and now it's 2.50 so it's time for a change in installed files. Just like if you never run 'guix pull' on a new system it'll continue downgrading overtime. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
SANE / simple-scan working for anyone?
Has anyone successfully scanned documents with SANE on a Guix System? I just tried running 'simple-scan' with a CanoScan N1240U/LiDE 30 connected via USB, which has "complete" support according to the SANE docs. Although "lsusb" shows the scanner: mhw@jojen ~$ lsusb Bus 006 Device 002: ID 04a9:220e Canon, Inc. CanoScan N1240U/LiDE 30 'simple-scan' says "No scanners detected". I took a look at the 'strace' output, and one thing I noticed is that it tries to open /dev/usb/, which doesn't exist on my system. Before I spend more time investigating, does anyone else have insight on this? Has anyone successfully used USB scanners on Guix systems? Mark
perl-getopt-long version string contains a letter
Hi Guix, perl-getopt-long has a version string "v2.49.1". If we change this to "2.49.1", will installed packages not be upgraded? What can be done in this case? -- Ricardo
Typo on Savannah project page.
On savannah.gnu.org/git/?group=guix there is a typo. It says: "Scripts for videos represenging Guix" with represenging being the typo. roptat on irc suggested it should be: "Scripts for videos presenting Guix"
Re: Automatically building packages affected by submitted patches
Hey Chris, > In short, following on from some previous emails about Patchwork [1] and > tracking and inspecting how Guix changes over time [2], I've got to the > point where I have a very rough setup for building packages changed by > patches sent to the guix-patches mailing list. This is great! > With the goal of displaying a check in Patchwork about the > build status of the affected packages, I need to compare what's been > build by my Cuirass instance, with what https://ci.guix.info/ has > built. To do this, my current plan is to have the Guix Data Service > monitor a number of Cuirass instances somehow, extract information from > them and store it. Would it not make sense to have the build farm perform the builds instead of having a separate Cuirass instance? > - Looks at patch series in the Patchwork database that have been >processed through the patchwork-test-series job in Laminar. Is the Laminar job something that could become part of Cuirass itself? -- Ricardo
