Re: Which kernel series to use in the installer and for installed systems?
On Thu, May 27, 2021 at 04:02:46PM -0400, Mark H Weaver wrote: > Hi, > > Vagrant Cascadian writes: > > Would it be too complicated to include both the latest LTS kernel and > > the most recently packaged kernel in the installer, and default to using > > the same kernel for the installation? > > Sounds good to me. More specifically, I would suggest offering the user > a choice between using the latest stable kernel, or using the latest > kernel from the most recent LTS series at the time of installation. > > If the user chooses the latter option, the installer would produce an OS > configuration containing "(kernel linux-libre-X.YY)", where X.YY is > latest LTS series at installation time. > > The idea is that if they choose the LTS kernel option today, > 'linux-libre-5.10' would be put into their OS config, so they would stay > on the 5.10 kernel series until they explicitly update to a later > series. This is a good choice for production systems where stability is > more important than running the latest code, and even for ordinary users > who wish to have control over when major kernel updates are done. > > I would recommend avoiding the 'linux-libre-lts' variable, because it > fails to provide the primary benefit that LTS kernels are meant to > provide: the ability to postpone potentially disruptive major kernel > upgrades until a time of the user's choosing, when the user is prepared > for possible breakage. Users who put 'linux-libre-lts' in their OS > configurations should expect that a major kernel upgrade will happen > several years before it is needed, and could happen unexpectedly any > time they upgrade their system. Unless they carefully inspect the > 'guix' command output _every_ time they upgrade their system, users of > the 'linux-libre-lts' variable are unlikely to notice a major kernel > upgrade until it has already been done. > > Thoughts? > > Thanks, >Mark > IIRC the Debian installer offers linux, linux-major.minor and linux-major.minor.point in the installer. I don't really understand why and how a newer kernel would make things stop working, but I could see offering linux-libre, linux-libre-lts and linux-libre-5.10 (using the 1.3.0 release as the example). -- 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
Questions reqarding packaging and conventions
Hello, I'm trying to debug and fix issues with Kerberos based authentication on both Icecat and qutebrowser and got a few questions: Via strace I found that icecat tries load `libgssapi.so` which doesn't exist. Trivially creating the file as a symbolic link to the `libgssapi_krb5.so` provided by the `mit-krb5` package and exposing via LD_LIBRARY_PATH solves the issue and fixes Kerberos based authentication. - Question 1: Should this be fixed in the mit-krb5 package or in the icecat package? - Question 2: What would be the best way of creating this link in a package? I've played with creating a modified `mit-krb5` (i.e. `my-mit-krb5`) with the following additional build phase: (modify-phases %standard-phases (add-after 'install 'create-link (lambda _ (let* ((libpath (getenv "out")) (origin (format #f "~a/lib/libgssapi_krb5.so" libpath)) (target (format #f "~a/lib/libgssapi.so" libpath))) (symlink origin target)) #t)) This works, but creates the link with full path target instead of relative like the rest of links created naturally by the original build process: ❯ ls -l /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi* lrwxrwxrwx 3 root root 21 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi_krb5.so -> libgssapi_krb5.so.2.2 lrwxrwxrwx 3 root root 21 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi_krb5.so.2 -> libgssapi_krb5.so.2.2 -r--r--r-- 2 root root 380520 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi_krb5.so.2.2 lrwxrwxrwx 7 root root 82 Jan 1 1970 /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi.so -> /gnu/store/irhvqdpc4zvyj9in514lv859mjkyi7p3-my-mit-krb5-1.18/lib/libgssapi_krb5.so Should I try to `chdir` to the path before creating the link, or is there a cleaner way of doing something like this? qutebrowser Kerberos support comes from `qtwebengine`. The only change needed would be to add `mit-krb5` as input and add the "--webengine-kerberos=yes" qmake option in its `configure` build phase. My question here is about whether there is any policy requiring formal justification to increase the number of dependencies of a certain package or this would be considered a valid request/patch. Best regards, Ignacio
Re: Expat 2.4.0 (and 2.4.1) with security fixes released
Hi everyone, more than half of you have updated to 2.4.1 already [1], very nice. Please let me know if you need any help with updating or backporting or something like that. Thanks and best Sebastian [1] https://repology.org/project/expat/information On 24.05.21 01:01, Sebastian Pipping wrote: > Hello everyone! > > > Expat 2.4.0 (and 2.4.1) most importantly brings protection against > Billion Laughs Attacks (CVE-2013-0340). There is a blog post [1] and > the change log with more details. > > If you have patches for Expat that are still required with version > 2.4.1, please send them my way. Thank you! > > Best > > > > Sebastian > > > [1] > https://blog.hartwork.org/posts/cve-2013-0340-billion-laughs-fixed-in-expat-2-4-0/ > [2] https://github.com/libexpat/libexpat/blob/R_2_4_1/expat/Changes >
Re: Adding Substitute Mirrors page to installer
Hi Mathieu, I added the test as you recommended, **however** it looks to me that within the test, reading the configuration file leads to an non-`operating-system?` object, which seems strange. I was forced to modify the main code as below: + (substitute-urls (and (operating-system? os) + (and=> (find +(lambda (service) + (eq? guix-service-type + (service-kind service))) +(operating-system-services os)) + (compose guix-configuration-substitute-urls + service-value In previous version there was no`(and (operating-system? os) ...)` guard, as we expect that the generated file, when `load`ed, will result in an `operating-system`, so I wonder why the testing environment is somehow different. Printing via `syslog "~A~%"` shows the `os` object as being some `#`, not an `operating-system` object. Unfortunately I am not very familiar with any particular wrinkles regarding Guile and its loading system, so I am unsure what is going wrong here... In any case I checked it manually by creating an installer image and then installing into 2 different VMs, one with ci.guix.gnu.org and the other with mirror.sjtu.edu.cn. Thanks raid5atemyhomework >From 41b174da1e38b71563405f1be48331fbe0e5700d Mon Sep 17 00:00:00 2001 From: raid5atemyhomework Date: Tue, 16 Mar 2021 23:45:37 +0800 Subject: [PATCH] gnu: Add substitute mirrors page to installer. * gnu/installer/services.scm (system-service) [snippet-type]: New field. (%system-services): Add substitute mirrors. (service-list-service?): New procedure. (modify-services-service?): New procedure. (system-services->configuration): Add support for services with `'modify-services` snippets. * gnu/installer/newt/services.scm (run-substitute-mirror-page): New procedure. (run-services-page): Call `run-substitute-mirror-page`. * gnu/services/base.scm (guix-shepherd-service)[start]: Accept second argument, a space-separated list of substitute URLs. * gnu/installer/final.scm (%user-modules): New variable. (read-operating-system): New procedure. (install-system): Read the installation configuration file and extract substitute URLs to pass to `guix-daemon` start action. * gnu/installer/tests.scm: Add new page in testing. --- gnu/installer/final.scm | 37 +++- gnu/installer/newt/services.scm | 26 +- gnu/installer/services.scm | 62 - gnu/installer/tests.scm | 12 +-- gnu/services/base.scm | 15 ++-- 5 files changed, 136 insertions(+), 16 deletions(-) diff --git a/gnu/installer/final.scm b/gnu/installer/final.scm index fc0b7803fa..2324c960f2 100644 --- a/gnu/installer/final.scm +++ b/gnu/installer/final.scm @@ -22,9 +22,13 @@ #:use-module (gnu installer steps) #:use-module (gnu installer utils) #:use-module (gnu installer user) + #:use-module (gnu services) + #:use-module (gnu services base) #:use-module (gnu services herd) + #:use-module (gnu system) #:use-module (guix build syscalls) #:use-module (guix build utils) + #:use-module (guix ui) #:use-module (gnu build accounts) #:use-module (gnu build install) #:use-module (gnu build linux-container) @@ -38,6 +42,20 @@ #:use-module (ice-9 rdelim) #:export (install-system)) +;; XXX duplicated from guix/scripts/system.scm, but that pulls in +;; (guix store database), which requires guile-sqlite which is not +;; available in the installation environment. +(define %user-module + ;; Module in which the machine description file is loaded. + (make-user-module '((gnu system) + (gnu services) + (gnu system shadow + +(define (read-operating-system file) + "Read the operating-system declaration from FILE and return it." + (load* file %user-module)) +;; XXX + (define %seed (seed->random-state (logxor (getpid) (car (gettimeofday) @@ -174,6 +192,16 @@ or #f. Return #t on success and #f on failure." options (list (%installer-configuration-file) (%installer-target-dir + ;; Extract the substitute URLs of the user configuration. + (os (read-operating-system (%installer-configuration-file))) + (substitute-urls (and (operating-system? os) + (and=> (find +(lambda (service) + (eq? guix-service-type + (service-kind service))) +(operating-system-services os)) + (compose guix-configura
Re: Ungrafting CI jobs
Hello Leo,
I monitored a previous evaluation of the ungrafting Cuirass
specification that was more successful, with more than 17000 builds
performed in less than 24 hours, a new record! The recent evaluation is
sadly less victorious.
> The latest iteration failed en masse due to network timeouts between
> build farm nodes.
Yes, I described this issue here: https://issues.guix.gnu.org/48468 and
hopefully fixed it with https://issues.guix.gnu.org/48556.
I need to perform a reconfigure / deploy but I'm waiting to have a few
days ahead of me to fix potential issues.
> It lets us see that the Audacity build is not attempted due to the
> failure of wxwidgets. And in turn, the failure of webkitgtk and libsoup.
> However, there is no information (logs, duration) available about those
> failed builds.
When a build is cancelled ("Cancel pending builds" button), all
its dependents are automatically updated to "Failed dependency". It
looks like this is the case for https://ci.guix.gnu.org/build/515005/details.
> What can we do to clear all these "spurious" build failures and re-try
> building the branch? I already tried using the "restart all builds"
> button, but there were still a lot of spurious failures.
I think the easiest way to recover from this situation is to remove the
ungrafting specification and recreate it. It ensures that no build will
fail because of previously failing/cancelled build dependencies.
Note that when a build B is restarted in Cuirass ("Restart" button), any
other build B' depending from B, will automatically be restarted if B
becomes successful and all the other dependencies of B' are already
successful.
I used this mechanism to restart a few builds failing on the master
branch because of substitutes timeout. I hope that when the keep-alive
patchset will solve this situation.
Thanks,
Mathieu
