Planned Guix services downtime on May 10th
Hello! The Max Delbrück Center [0], which graciously hosts the Berlin Guix infrastructure, will be conducting upgrades to their data center. The Berlin fleet of machines will have to be powered down between 01:00 and 06:00 (Berlin time) on May 10th, which will cause the following service disruptions: 1. https://ci.guix.gnu.org downtime (use bordeaux.guix.gnu.org instead) 2. https://issues.guix.gnu.org downtime (use Debbugs instead [1]) The website should remain available, if the fallback in place works as expected. [0] https://www.mdc-berlin.de/ [1] https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix -- Thanks, Maxim
Re: Adding content-addressed URLs to https://guix.gnu.org/sources.json
Hi Simon, Simon Tournier writes: > Hi Ludo, Maxim, all, > > On mar., 25 avril 2023 at 14:40, Ludovic Courtès > wrote: > >>> Somehow, it reveals 3 currently uncovered cases: computed-file appearing >>> as, >>> >>> 1. ’origin’ in source field (ruby-sorbet-runtime) >>> 2. ’inputs’ (racket-minimal) >>> 3. ’snippet’ in origin in source field (chromium) >> >> I think #1 and #2 are okay: we can use any file-like object there, not >> just origin/package. Of course, is meant to be the best choice >> for ‘source’, and the best choice for ‘inputs’. But I think >> it’s fine to occasionally resort to some other abstraction when these >> two are not adequate. > > I agree that any file-like object is nice. Somehow, the issue is to > “unpack“ the information of this object. For instance, > > scheme@(guix-user)> (define ruby-sorbet-runtime (@@ (gnu packages ruby) > ruby-sorbet-runtime)) > scheme@(guix-user)> (package-source ruby-sorbet-runtime) > $1 = #< name: > "ruby-sorbet-runtime-0.5.10610.20230106174520-1fa668010-checkout" gexp: > # (string-append # url: > "https://github.com/sorbet/sorbet; commit: > "0.5.10610.20230106174520-1fa668010" recursive?: #f> # sha256:0f21dl06alxwn6xgdxyrkd58plmmsv04z2bcls9ld4cfzsrs5537> () > 7fd7ad6b81e0>:out> "/gems/sorbet-" #) # out>)) gnu/packages/ruby.scm:14071:5 7fd7ae734480> guile: #f options: > (#:local-build? #t)> > > > and as far as I understand, this case cannot be handled by some generic > code. The extraction of the “real” origin needs manual and specific > extraction because of this ’computed-file’. > > For sure, ’source’ can use any file-like object because some use-cases > require that. However, I would be tempted to use an ’origin’ as a > preferred choice – i.e., when it’s possible and try to make it > possible. ;-) Because, somehow, it “normalizes“ the source information > and eases its extraction. I'm not sure I follow, perhaps because I lack context about how Disarchiver use the source field of a package. Would you mind explaining a bit what the problem is or pointing me to a place it was already explained? -- Thanks, Maxim
Re: bug#63098: [PATCH] gnu: guitarix: Update to 0.44.1.
Hi John, John Kehayias skribis: > From c652ee7b7339d287b623692190d66c3f5f3a90ee Mon Sep 17 00:00:00 2001 > From: John Kehayias > Date: Wed, 26 Apr 2023 18:25:35 -0400 > Subject: [PATCH] gnu: guitarix: Update to 0.44.1. > > * gnu/packages/audio.scm (guitarix): Update to 0.44.1. > [arguments]: Use gexps. > [native-inputs]: Remove labels LGTM, thanks! Ludo’.
New German PO file for 'shepherd' (version 0.10.0rc1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'shepherd' has been submitted by the German team of translators. The file is available at: https://translationproject.org/latest/shepherd/de.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/shepherd/ 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/shepherd.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.
ocaml bootstrap (was Re: Core-updates merge)
On Fri, Apr 28, 2023 at 04:17:40PM +0200, Simon Tournier wrote: > Hi Andreas, > > On mar., 25 avril 2023 at 16:09, Andreas Enge wrote: > > > - OCaml could be simplified by dropping version 4.07 (Julien Lepiller). > > Well, 4.07 is the version that is de-bootstrapped, i.e. bootstrapped > using ’camlboot’ via Guile – for details see [2]. > > However, higher versions (4.09, 4.14, 5) does not use this seed and thus > they are not de-bootstrapped. Well, I do not know the status upstream; > from my point of view, we have two options: > > a) Agree with other distros and OCaml folks to rely on a common OCaml > 4.07 bootstrapped using camlboot and then use this OCaml 4.07 as the > seed for the subsequent versions. Somehow having a way to verify the > current OCaml compiler without running again and again via camlboot. > > b) Build ourselves a chain from 4.07 bootstrapped with camlboot to > modern OCaml compilers. However, each time we modify one dependency of > camlboot, it means rebuild the complete chain. Well, bootstrapping via > camlboot can be very slow and I do not know if we have the resources > for non-x86_64 architecture. Here, the list of the emerged > dependencies: I think similarly to the very slow *-mes part of the bootstrap chain, we have to realize that some parts are just very slow. (A vote for b) I built camlboot once on aarch64, probably a year ago. IIRC it took more than 24 hours. I will say that it is doable without needing 8GB of ram, which is also a limiting factor for the slow architectures. > $ guix graph camlboot -t bag-emerged | grep label | cut -d'=' -f2 > "camlboot@0.0.0-1.45045d0", shape > "guile@3.0.9", shape > "pkg-config@0.29.2", shape > "tar@1.34", shape > "gzip@1.12", shape > "bzip2@1.0.8", shape > "file@5.44", shape > "diffutils@3.8", shape > "patch@2.7.6", shape > "findutils@4.9.0", shape > "gawk@5.2.1", shape > "sed@4.8", shape > "grep@3.8", shape > "xz@5.2.8", shape > "coreutils@9.1", shape > "make@4.3", shape > "bash-minimal@5.1.16", shape > "ld-wrapper@0", shape > "binutils@2.38", shape > "gcc@11.3.0", shape > "glibc@2.35", shape > "glibc-utf8-locales@2.35", shape > "libffi@3.4.4", shape > "bash-minimal@5.1.16", shape > "libunistring@1.0", shape > "libgc@8.2.2", shape > > c) Fix the dependencies of camlboot. Looking at camlboot, there's a native input of guile-3.0. Unless we want to bootstrap using some of the boot0 packages or actually find the minimum set of packages needed and remove the rest that are brought in by implicit-inputs (recursively) I think it's already as small as possible. > > Well, it seems a separated discussion but it echoes the recent blog post [3] > about “The Full-Source Bootstrap”. :-) > > 2: > https://10years.guix.gnu.org/video/camlboot-debootstrapping-the-ocaml-compiler > 3: > https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/ > > > Cheers, > simon > > > -- 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
