Re: $EDITOR and “guix edit”
Hi Liliana,
Liliana Marie Prikler skribis:
>> > Maybe we can check for a guix_editor shell function and invoke that
>> > rather than EDITOR if defined?
>>
>> ‘guix edit’ cannot “invoke” a shell function though.
>>
>> I was thinking of something more gross, like checking whether the
>> basename of $EDITOR is ‘kate’ or ‘vscode’ and in that case do
>> whatever is relevant for those editors.
>>
>> WDYT?
> I see your gross "checking whether the basename of $EDITOR is ‘kate’…"
> and I raise my "use $GUIX_EDITOR which uses substring replacements for
> ${LINE} and ${FILE} implemented in pure Guile code"
I’m not sure I understand your proposal. Are you suggesting that
‘GUIX_EDITOR’ would contain arbitrary Scheme code that ‘guix edit’ would
evaluate?
Ludo’.
Re: Add anchors in HTML documentation
Hi, Christian Miller skribis: >> I agree that anchor symbols in the text would help. We’d need to tweak >> the Texinfo output and/or use @anchor more frequently in the Texinfo >> source of the manual. > > It should do it automatically instead of using @anchor everytime, > since this would be repetitive. I also saw that Emacs has sometimes > the same problem. If this affects Texinfo to generate a different > output, we may should move it to the Texinfo ML (do they have one?). > Therefore not only Guix would profit from it. Yes, there’s bug-texi...@gnu.org if you feel like bringing it up there. :-) Ludo’.
Re: Guix Days & Declarative and Minimalistic Computing: CfP for FOSDEM 2024
Hey! Pjotr Prins skribis: > Please spread among our small community. FOSDEM is great, so if you > happen to want to come to Brussels you can also attend the Guix days > before: > > => https://libreplanet.org/wiki/Group:Guix/FOSDEM2024 I added my name there; consider doing it too. :-) Looking forward to meeting all the wonderful people again! Ludo’.
Re: $EDITOR and “guix edit”
Am Samstag, dem 09.12.2023 um 10:24 +0100 schrieb Ludovic Courtès:
> Hi Liliana,
>
> Liliana Marie Prikler skribis:
>
> > > > Maybe we can check for a guix_editor shell function and invoke
> > > > that
> > > > rather than EDITOR if defined?
> > >
> > > ‘guix edit’ cannot “invoke” a shell function though.
> > >
> > > I was thinking of something more gross, like checking whether the
> > > basename of $EDITOR is ‘kate’ or ‘vscode’ and in that case do
> > > whatever is relevant for those editors.
> > >
> > > WDYT?
> > I see your gross "checking whether the basename of $EDITOR is
> > ‘kate’…" and I raise my "use $GUIX_EDITOR which uses substring
> > replacements for ${LINE} and ${FILE} implemented in pure Guile
> > code"
>
> I’m not sure I understand your proposal. Are you suggesting that
> ‘GUIX_EDITOR’ would contain arbitrary Scheme code that ‘guix edit’
> would evaluate?
No, it'd contain the shell-esque "${LINE}" and "${FILE}" that would get
replaced by Scheme code looking for those strings.
Cheers
Re: Syntactic Diabetes (was Re: A friendlier API for operating-system declarations)
Hello!
Edouard Klein skribis:
> Thank you Liliana and Attila for the swift and actionable feedback :)
>
> Below is a revised proposition.
>
> Here is a minimal working example of an os declaration:
> --mwe.scm---
> (use-modules
> (beaver system)
> (beaver functional-services)
> (gnu packages version-control)
> (gnu services web)
> (gnu services telephony)
> (gnu services ssh)
> (gnu services base)
> (guix gexp))
>
> (-> (minimal-ovh "osef")
> (instantiate nginx)
> (instantiate mumble-server
> (welcome-text "coucou")
> (port 64738))
> (extend openssh `(("alice" ,(local-file
> "/home/edouard/.ssh/id_rsa.pub"
> (modify openssh
> (password-authentication? #f)
> (allow-empty-passwords? #t))
> (remove guix))
> ---
>
> To see the value of this syntactic sugar, try to replicate this MWE with
> the standard syntax. It's not horrendous, but it *is* off-putting to
> many newcomers to git, whereas this sugary piece is more readable for
> them (sample size of 1, p=0.0005).
Glad you ran a user study. :-)
This is looking more and more like:
(define-syntax ->
(syntax-rules ()
((_ os rules ...)
(operating-system
(inherit os)
(services (modify-services (operating-system-user-services os)
rules ...))
One thing that always makes me hesitate due to the longstanding hygienic
macro tradition in Scheme is non-hyienic introduction of identifiers: in
the example you gave above, the identifiers ‘openssh-service-type’ and
‘openssh-configuration’ are automatically derived from ‘openssh’. This
could lead to surprises and makes grepping harder. But I don’t know,
maybe that’s the price to pay?
Maybe one conclusion we can draw from this is that configuration records
and service types should be more closely tied to one another.
>>> (service+ OS SERVICE [CONF])
>>> (service- OS SERVICE)
This one looked really revolutionary, but it’s inspiring too!
Thanks,
Ludo’.
Re: role of core-updates
Hi! Andreas Enge skribis: > When we started implementing the teams idea, I thought we would get rid > of the core-updates branch altogether. I still think it should not exist > as such, but be folded into the teams workflow. I am still mildly worried > that we have this branch into which many unrelated things get dumped, > without a clear responsibility who pushes it forward and on which timeline. Yeah, I share this sentiment. > There is a "core" team, but this is probably not the same thing: I think > there are packages outside of the core team scope that cause now inside > the core-updates branch. Maxim and I briefly discussed this on IRC and concluded we should have a ‘core-packages’ team for basically base.scm and commencement.scm (the ‘bootstrap’ team should be co-responsible for commencement.scm), and maybe also guile.scm. With that in mind, ‘core-updates’ would effectively become the branch of the ‘core-packages’ team: the branch where we update packages in these files (primarily the toolchain and Guile), perhaps also (guix build utils), and that’s all. How does that sound? Ludo’.
Re: RISC-V builds and substitutes
Hi! Christopher Baines skribis: > There's now HiFive Unmatched Rev B boards available [1], so is there > interest in buying additional boards for the project so that we can > improve substitute availability and get QA doing RISC-V things? Speaking for myself, I think it would be nice, but I would prioritize investing in what it takes to get faster feedback from qa.guix for the already-established architectures (for example, it seems qa.guix is short on x86_64 hardware.) Ludo’.
Re: [bootstrappable] GNU Mes 0.26 released
Hello, Janneke Nieuwenhuizen skribis: > We are happy to announce the release of GNU Mes 0.26. > > It's been only a month since the previous release mainly because most > this work has been waiting for 0.25 to be released. This release > represents 194 commits over one year by two people. This release brings > Guile module support and support for running Gash and Gash-Utils. Wo0t, congratulations! > *** Mes now has a Guile-compatible record interface. > *** Mes now has a Guile-compatible hash-table interface. > *** Mes now uses exceptions instead of asserts. > *** Mes now supports Guile-compatible modules and variable lookup. > *** The reader now supports `#\fs', `#\nl', and `#\np'. > *** Mes now supports vectors in syntax-rules. > *** Dynamic-wind was fully implemented. > *** Mes now has regex support. > *** Mes now supports functional record setters. > *** simple-format now supports `~%'. > *** Charsets can now be used in `string-index'. > *** The (srfi srfi-14) module was completed. > 9 new modules > (ice-9 ftw), (ice-9 i18n), (ice-9 receive), (ice-9 regex), (rnrs io > ports), (rnrs bytevectors), (srfi srfi-2). (srfi srfi-11). (srfi srfi-37). > 46 new functions > alist-cons, append-reverse!, call-with-port, call-with-input-file, > call-with-input-string, call-with-output-file, chdir, clone-port, > closedir, concatenate, drop, drop-while. environ, execle, > file-system-fold, fold-matches, getpid, hash-clear!, hash-fold, > hash-map->list, hash-remove!, hash-table?, link, list-matches, > match-let, mkdir, opendir, partition, pipe, primitive-exit, readdir, > reduce, rename-file, rmdir, seek, set-fields, span, sleep, > string-concatenate-reverse, string-count, string-pad, string-pad-right, > string>, string<, umask, uname, utimes, vector-fold. > *** Mes now supports running Gash and Gash-Utils. This is big deal!! That looks like an important milestone on the bootstrapping journey in Guix. Well done! Ludo’.
Re: role of core-updates
Am Sat, Dec 09, 2023 at 11:16:14AM +0100 schrieb Ludovic Courtès: > With that in mind, ‘core-updates’ would effectively become the branch of > the ‘core-packages’ team: the branch where we update packages in these > files (primarily the toolchain and Guile), perhaps also (guix build > utils), and that’s all. > How does that sound? Sounds good, thanks to you and Maxim for thinking it through! Andreas
Discontinuing data.guix.gnu.org?
Hello! Christopher Baines skribis: > As previously set out, I'm planning to stop hosting the data service > instances this year. While I would like to stop hosting the server for > data.guix.gnu.org, I forgot the outcome of previous discussions, but it seems to me that the service itself and all the data it accumulated over the years are super valuable. I would be sad to see it go! Is there something we can do to not lose it all? It could be distributing responsibility, reducing the scope, ensuring hosting is managed collectively by the project, etc. WDYT? Ludo’.
Re: Unreleased wget
Hi Andreas, On Tue, 05 Dec 2023 00:12:14 +0800, Andreas Enge wrote: > > Speaking of core-updates, I made a mistake during the latest merge > last spring. We needed a new wget release and the wget maintainers took > some time, so I rolled a "non-release" 1.21.3.24 before the 1.21.4 > release (in core-updates, commit 93f9c260ac333ae7b86bfaeeead674fe01d924ce > updates wget to the 1.21.4 release, one more reason to hope for a merge > soon), for which I stored a .tar.lz on a server of my own. > > However, this release does not exist (and I actually removed the file from > the server, but for the time being keep it still around on my laptop, and > it is still available in the build farm); and I did not realise it would > break the time machine (which I did not use at the time). > > Is there a good way forward to allow a way backward? Maybe you can make it available again in that URL and archive it via web.archive.org so that downloads can fall back to it? Thanks
Shutting down qa.guix?
Hello, Christopher Baines skribis: > I am still planning to shutdown data.qa.guix.gnu.org and > QA which depends on it within the next couple of weeks. I do hope it can > return some point though, and hopefully sooner rather than later. > > On this like most decisions I'm indecisive, I could try and keep the > current server going, but it's not the most cost effective setup and > it's very low on disk space. I could replace the server with some > slightly better setup, but this would still mean I'm managing a key part > of the infrastructure, which is something I'm trying to move away > from. There was some discussion of the project taking over the hosting, > and maybe that will happen at some point, but it hasn't happened yet. So > while not having qa.guix.gnu.org for a time isn't ideal, I'm still going > with this approach. I think this underlines a collective failure to get our act together. I believe there’s consensus that qa.guix is useful and has been a boost for reviewers and contributors; we’d probably all want it to provide quicker feedback, which is a sign of success: we’ve come to rely on it. I know this has been discussed several times and it remains unclear to me why as a project we never managed to move forward—maybe the comfort of the status quo? Anyway, would it be possible for you to transfer billing of the hardware (Hetzner?) to Guix Foundation? Does Guix Foundation know what it would cost them? The “spending committee” (Tobias, Ricardo, and myself), which oversees expenditure from the funds held at the FSF, can also be in the loop to provide additional financial support. As for system administration, is there documentation that people willing to help could look at? Very concrete things like: what services are running on which machines, what do I do if one of them is stuck or if I get this error message, etc. Thanks, Ludo’. PS: You’ve done amazing work over the years. As a contributor, I find it super reassuring to know that you’re always available and focused, committed to improving patch workflows for many years. It’s been a long road already and I admire this level of commitment and hard work.
Re: Upgrading Guix's security team
Hello! Tobias Geerinckx-Rice skribis: > Great, I was waiting for someone to reply so's to glom on and ask to be > included in the same commit to minimise noise. Could you take care of updating the security web page? Ludo’.
Re: shepherd: hardening error handling
Hello! Attila Lendvai skribis: > the codebase seems to use catch/throw, and at some places with comments like > "for Guile 2.2". what is the minimum guile version that the shepherd codebase > wants to support? the README says "GNU Guile 3.0.x or 2.2.x". is this still > intended? or can i assume guile 3? i.e. use with-exception-handler, > raise-exception, guard, &co. instead of catch/throw with key and args? The source of truth is ‘configure.ac’, which reads: GUILE_PKG([3.0 2.2]) CI checks that (and in fact ‘guile2.2-fibers’ currently fails to build due to a non-deterministic test failure): https://ci.guix.gnu.org/eval/latest/dashboard?spec=shepherd I think we’ll keep it that way in 0.10.x, but for 1.0.x, we can drop 2.2. When we drop 2.2, we can probably switch ‘with-exception-handler’ & co., with care. Thanks, Ludo’.
Re: What's the difference between a shell environment and a profile?
Hi, Simon Tournier skribis: > It does not differ. What differs is that “guix shell” raises nothing > for the collision – maybe “guix shell” does not check the collision, I > do not remember – when “guix package” raises an error for the same > collision. Indeed, ‘guix shell’ does not check collisions, for “historical reasons”. Perhaps something worth fixing at some point: https://issues.guix.gnu.org/54350 Ludo’.
Re: issues.guix.gnu.org seems stop updating
Hi, Maxim Cournoyer skribis: > Andy Tai writes: > >> https://issues.guix.gnu.org/recent, for example, only shows issues up to Dec >> 6. >> >> Not sure if this is due to some data services stopping running or such... > > Perhaps the machine was restarted and the manual rsync job not > restarted? We still don't have a service for it (bug #59180). No, apparently it was a problem at debbugs.gnu.org, now resolved. Many thanks to Tobias, Felix, and others who’ve been discussing with the folks over at #savannah to figure it out! Ludo’.
Re: Unreleased wget
Hi, Andreas Enge skribis: > Speaking of core-updates, I made a mistake during the latest merge > last spring. We needed a new wget release and the wget maintainers took > some time, so I rolled a "non-release" 1.21.3.24 before the 1.21.4 > release (in core-updates, commit 93f9c260ac333ae7b86bfaeeead674fe01d924ce > updates wget to the 1.21.4 release, one more reason to hope for a merge > soon), for which I stored a .tar.lz on a server of my own. > > However, this release does not exist (and I actually removed the file from > the server, but for the time being keep it still around on my laptop, and > it is still available in the build farm); and I did not realise it would > break the time machine (which I did not use at the time). > > Is there a good way forward to allow a way backward? I’ve now uploaded a copy of that tarball to ftp.gnu.org/gnu/guix/mirror. As a rule of thumb, we should always store upstream tarball copies or variants thereof on that server. For the record, here’s what we get right now when bypassing substitutes: --8<---cut here---start->8--- $ guix time-machine -q --commit=8852e6bb5521edca099d6f346efc92db3244584c -- build -S wget --check The following derivation will be built: /gnu/store/cqq5m8chqnbwpd0d59ai0v19hrpkxmay-wget-1.21.3.24-2b723.tar.lz.drv building /gnu/store/cqq5m8chqnbwpd0d59ai0v19hrpkxmay-wget-1.21.3.24-2b723.tar.lz.drv... Starting download of /gnu/store/12y21qcxcz9p2g3m29j3rw6g8660bni3-wget-1.21.3.24-2b723.tar.lz >From https://www.multiprecision.org/wget-1.21.3.24-2b723.tar.lz... download failed "https://www.multiprecision.org/wget-1.21.3.24-2b723.tar.lz"; 404 "Not Found" Starting download of /gnu/store/12y21qcxcz9p2g3m29j3rw6g8660bni3-wget-1.21.3.24-2b723.tar.lz >From >https://bordeaux.guix.gnu.org/file/wget-1.21.3.24-2b723.tar.lz/sha256/17ip94mvax83h0gh4905jqc64g5qf3vgxr3bj9gn02pijjm5lzbp... downloading from https://bordeaux.guix.gnu.org/file/wget-1.21.3.24-2b723.tar.lz/sha256/17ip94mvax83h0gh4905jqc64g5qf3vgxr3bj9gn02pijjm5lzbp ... warning: rewriting hashes in `/gnu/store/5q1c82ncvcr77sbmz412ssiqv7ih42r2-wget-1.21.3.24-2b723.tar.lz'; cross fingers successfully built /gnu/store/cqq5m8chqnbwpd0d59ai0v19hrpkxmay-wget-1.21.3.24-2b723.tar.lz.drv successfully built /gnu/store/cqq5m8chqnbwpd0d59ai0v19hrpkxmay-wget-1.21.3.24-2b723.tar.lz.drv /gnu/store/5q1c82ncvcr77sbmz412ssiqv7ih42r2-wget-1.21.3.24-2b723.tar.lz --8<---cut here---end--->8--- Thanks, Ludo’.
Re: Discontinuing data.guix.gnu.org?
Ludovic Courtès writes: > Hello! > > Christopher Baines skribis: > >> As previously set out, I'm planning to stop hosting the data service >> instances this year. While I would like to stop hosting the server for >> data.guix.gnu.org, > > I forgot the outcome of previous discussions, but it seems to me that > the service itself and all the data it accumulated over the years are > super valuable. I would be sad to see it go! There was a discussion back in April, but no action came directly from it. Just having data.qa.guix.gnu.org was discussed, and at least concentrating on getting to a sustainable hosting situation there seemed like a sensible priority. The longer history provided by data.guix.gnu.org does have value though in my view. > Is there something we can do to not lose it all? It could be > distributing responsibility, reducing the scope, ensuring hosting is > managed collectively by the project, etc. WDYT? Since that discussion, I have disabled the database dumps and backups, which has reduced (to 62€ per month) the hosting costs (although obviously not having backups isn't ideal). It's possible to further reduce the hosting costs as well by switching away from a VM to a physical machine at Hetzner. But yeah, given that having at least one data service instance is a key part of keeping the bordeaux build farm running, managing the hosting through the project seems to be the way to go. I'm just not sure how we can get there, or what I can do to move things in that direction. signature.asc Description: PGP signature
Extra Guix hack day before Guix days?
Before FOSDEM we are organizing the traditional Guix days at ICAB. If you want to join sign-up on https://libreplanet.org/wiki/Group:Guix/FOSDEM2024 (the page is a wiki and editable). The Guix days and FOSDEM tend to be filled time-wise. We are wondering who would want to come a day early for a hacking session where we just work on Guix projects? Pj.
Re: Shutting down qa.guix?
Ludovic Courtès writes: > Hello, > > Christopher Baines skribis: > >> I am still planning to shutdown data.qa.guix.gnu.org and >> QA which depends on it within the next couple of weeks. I do hope it can >> return some point though, and hopefully sooner rather than later. >> >> On this like most decisions I'm indecisive, I could try and keep the >> current server going, but it's not the most cost effective setup and >> it's very low on disk space. I could replace the server with some >> slightly better setup, but this would still mean I'm managing a key part >> of the infrastructure, which is something I'm trying to move away >> from. There was some discussion of the project taking over the hosting, >> and maybe that will happen at some point, but it hasn't happened yet. So >> while not having qa.guix.gnu.org for a time isn't ideal, I'm still going >> with this approach. > > I think this underlines a collective failure to get our act together. > > I believe there’s consensus that qa.guix is useful and has been a boost > for reviewers and contributors; we’d probably all want it to provide > quicker feedback, which is a sign of success: we’ve come to rely on it. > > I know this has been discussed several times and it remains unclear to > me why as a project we never managed to move forward—maybe the comfort > of the status quo? In addition, it's also unclear to me who should be making decisions on things like this. I also think that fundamentally I may think that processes and tooling to make changes is more important than others regard it to be. While it has no inherent value to users, personally I see it as so much more important than actual Guix features or packages since the value to users comes through Guix getting better faster, because of the increased pace of changes and reduced number of regressions. > Anyway, would it be possible for you to transfer billing of the hardware > (Hetzner?) to Guix Foundation? Does Guix Foundation know what it would > cost them? I believe so, at least I think that's possible. The costs have also been discussed previously. > The “spending committee” (Tobias, Ricardo, and myself), which oversees > expenditure from the funds held at the FSF, can also be in the loop to > provide additional financial support. > > As for system administration, is there documentation that people willing > to help could look at? Very concrete things like: what services are > running on which machines, what do I do if one of them is stuck or if I > get this error message, etc. The configuration for beid, the machine that runs data.qa.guix.gnu.org and Patchwork is in maintenance.git. It could probably use some more comments to provide some context for the configuration. There's also probably a benefit from making some high level architecture diagrams for QA and the bordeaux build farm, and I can try and make a start on these. As for monitoring and responding to problems, that's a bit more complicated, but in most cases a herd restart of the relevant bit will temporarily resolve the issue. I'm still working on mitigating some of the underlying problems that cause things to break. signature.asc Description: PGP signature
Re: Shutting down qa.guix?
Hi Chris, I agree that Guix should step in to maintain the level of service that QA currently offers, by paying for hosting and sharing responsibility for system administration. Whether the software's maintained or improved is something over which we've historically had very poor control. Things go awry when we pretend otherwise. Christopher Baines 写道： it's not the most cost effective setup Has this been explained in more detail before? I also think that fundamentally I may think that processes and tooling to make changes is more important than others regard it to be. The disproportionate amount of effort you've put in, mostly unaided, implies as much. (Proportionally disproportional thanks for that, by the way.) Both more comments to provide some context for the configuration. and making some high level architecture diagrams for QA and the bordeaux build farm would be very much appreciated! As for monitoring and responding to problems, that's a bit more complicated, but in most cases a herd restart of the relevant bit will temporarily resolve the issue. Chuffed that the Guix Data Service embodies the same debugging philosophy as the other Guix infrastructure. Kind regards, T G-R signature.asc Description: PGP signature
Re: bug#66964: Request for merging "mesa-updates" branch
Hi, On Tuesday, November 14th, 2023 at 12:36 PM, Kaelyn wrote: > > Hi John, > > On Tuesday, November 14th, 2023 at 12:11 PM, John Kehayias > john.kehay...@protonmail.com wrote: > > > Hi Kaelyn, > > > > On Sun, Nov 12, 2023 at 08:01 PM, Kaelyn wrote: > > > > > Hi, > > > > > > I've just submitted a pair of patches for the mesa-updates branch: > > > https://issues.guix.gnu.org/67136 updating xorgproto and > > > xorg-server-xwayland. The xorgproto is a high-impact update (guix > > > refresh reports rebuilding 8710 packages would ensure 22871 dependent > > > packages are rebuilt), but required to update to the latest xwayland > > > as xwayland requires a newer version of presentproto than in the > > > current guix xorgproto package. The updating and ungrafting of mesa > > > and a number of X.org related libraries seemed like a good time (and > > > place) to update xorgproto as well. > > > > > > Cheers, > > > Kaelyn > > > > Thanks for the patches. I think mesa-updates in this current iteration > > is set on builds (ended up being a lot more due to the ungrafting but > > seems done on our main architectures for several days now). I had to > > make some other changes to fix some larger breakages but at this point I > > think it will just be taking us back in the build queue too much. > > > > So I think it would make more sense on the next big rebuild, either > > core-updates (talk about doing that with more ungrafts right now) or > > I'll do mesa-updates again when the next release of mesa hits. Or maybe > > it makes sense to just do another branch for xwayland? > > > > Open to ideas! I'll send a separate message soon on the status of > > mesa-updates and see what people think, but my thought was to merge this > > to master in the next day or so if there are no objections. > > > > Thanks! > > John > > > No worries! I realize I was a little late to the party for the mesa-updates > branch (had some ongoing technical issues), so if core-updates is still early > enough in the process I think it would be good to push the changes to that > branch. The current xwayland is pretty old, and the updated version has quite > a few CVEs fixed in comparison (just > https://www.phoronix.com/news/X.Org-Halloween-Bugs-2023 and > https://www.phoronix.com/news/X.Org-Server-Holiday-2022 list 8 CVEs fixed > between xwayland 21.1.3 and 23.2.2). I forgot to sent an email when I did this, but a few weeks ago I updated the xorgproto/xwayland update ticket (#66964) to refer to core-updates instead of mesa-updates and sent in a v2 of the patches rebased against core-updates. Cheers, Kaelyn
Western US mirroring?
Hi, just an idea: The GNU Guix project currently has a substitution server mirror in the East coast of the US. No mirror in the Western US. The OSU Open Source Lib (https://osuosl.org/) offers hosting resources to FOSS projects... https://osuosl.org/services/ Maybe the GNU Guix project can request hosting service from them, to have a substitution mirror, for example, so more resources can be available for downloading of artifacts for Guix users... Maybe this can be expanded later to have more services for Guix and other GNU projects in the West coast of the US, in cooperation with the FSF IT? Wonder if the idea is OK.
Ext4 corruption in some stable kernels
Hi, It's possible Guix never shipped the affected "stable" kernels, but a brief pointer seemed appropriate. For details, please see here. [1] Kind regards Felix [1] https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuhc3@quack3/
Re: Western US mirroring?
Hi Andy, On Sat, Dec 09 2023, Andy Tai wrote: > The OSU Open Source Lib (https://osuosl.org/) offers hosting resources > to FOSS projects... Great idea! I am in the SF Bay Area and would benefit. Thanks! Kind regards Felix
Re: RFI: Guix XMPP service.
Hi, On Fri, Dec 08 2023, MSavoritias wrote: > 2. We can self host our own prosody instance. I host my own Prosody instance (mostly to talk to Soprani). [1][2] I recommend the project host its own, as well. The server is very lightweight. Unfortunately, my system's uptime history is not suitable for a project instance. For DNS, I'd be happy to offer help.juix.org, but an official address is probably better. XMPP is great. Thanks for the initiative! Kind regards Felix [1] https://codeberg.org/lechner/system-config/src/commit/b566b08a982a12f896cd6ef7849dbac0ce2e/host/wallace-server/operating-system.scm#L1195-L1200 [2] Message retention in my setup may only be thirty days.
Re: Ext4 corruption in some stable kernels
Hi Felix (and Leo, Cc-ed) On Sun, 10 Dec 2023 11:00:47 +0800, Felix Lechner via Development of GNU Guix and the GNU System distribution. wrote: > > Hi, > > It's possible Guix never shipped the affected "stable" kernels, but a brief > pointer seemed appropriate. For details, please see here. [1] > > Kind regards > Felix > > [1] https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuhc3@quack3/ > From the linked thread and report in Debian[1], 6.1.64 (and maybe 5.10.202 + 5.15.140) are affected. Unfortunately we have shipped them for about 1 week. Leo has sent #67724 yesterday to update kernels, maybe we can merge updates for these three versions quicker? Thanks --- [1]: https://micronews.debian.org/2023/1702150551.html
Heisenbug
Hi, Running 'make' in a hacked Guix, I get this error the first time around: [ 84%] LOAD gnu/tests/ldap.scm [ 84%] LOAD gnu/tests/linux-modules.scm [ 84%] LOAD gnu/tests/mail.scm [ 84%] LOAD gnu/tests/messaging.scm [ 84%] LOAD gnu/tests/networking.scm [ 84%] LOAD gnu/tests/package-management.scm [ 84%] LOAD gnu/tests/pam.scm [ 85%] LOAD gnu/tests/reconfigure.scm ice-9/eval.scm:293:34: error: label: unbound variable hint: Did you forget a `use-modules' form? make[2]: *** [Makefile:7104: make-system-go] Error 1 make[2]: Leaving directory '/lcl/lechner/guix/git' make[1]: *** [Makefile:6152: all-recursive] Error 1 make[1]: Leaving directory '/lcl/lechner/guix/git' make: *** [Makefile:4268: all] Error 2 When I run 'make' a second time, the error changes to: [ 77%] LOAD gnu/artwork.scm [ 77%] LOAD gnu/bootloader.scm [ 77%] LOAD gnu/bootloader/grub.scm [ 77%] LOAD gnu/bootloader/extlinux.scm [ 77%] LOAD gnu/bootloader/u-boot.scm [ 77%] LOAD gnu/bootloader/depthcharge.scm [ 77%] LOAD gnu/ci.scm error: profile: source expression failed to match any pattern make[2]: *** [Makefile:7104: make-system-go] Error 1 make[2]: Leaving directory '/lcl/lechner/guix/git' make[1]: *** [Makefile:6152: all-recursive] Error 1 make[1]: Leaving directory '/lcl/lechner/guix/git' make: *** [Makefile:4268: all] Error 2 What's a good way to debug this, please? Where is my error? Thanks! Kind regards Felix
Re: Ext4 corruption in some stable kernels
Hi, On Sun, 10 Dec 2023 13:35:30 +0800, Hilton Chain wrote: > > Hi Felix (and Leo, Cc-ed) > > On Sun, 10 Dec 2023 11:00:47 +0800, > Felix Lechner via Development of GNU Guix and the GNU System distribution. > wrote: > > > > Hi, > > > > It's possible Guix never shipped the affected "stable" kernels, but a brief > > pointer seemed appropriate. For details, please see here. [1] > > > > Kind regards > > Felix > > > > [1] https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuhc3@quack3/ > > > > From the linked thread and report in Debian[1], 6.1.64 (and maybe 5.10.202 + > 5.15.140) are affected. Unfortunately we have shipped them for about 1 week. > > Leo has sent #67724 yesterday to update kernels, maybe we can merge updates > for these three versions quicker? > > Thanks > --- > [1]: https://micronews.debian.org/2023/1702150551.html Based on the commit log and [1], the offending commit was not actually included in 5.10.y and 5.15.y releases. And according to [2], a fix has benn added[3] to v6.1.66, so only v6.1.64 and v6.1.65 are affected. Thanks --- [1]: https://lore.kernel.org/stable/2023112502-supernova-copier-7615@gregkh/ [2]: https://lore.kernel.org/stable/2023120643-evade-legal-ee74@gregkh/ [3]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.1.66&id=ea574927fc0bc343016ea3337fcfc0b3fb26fe08
Re: Western US mirroring?
Sounds like a great idea! Le 10 décembre 2023 02:19:16 GMT+01:00, Andy Tai a écrit : >Hi, just an idea: > >The GNU Guix project currently has a substitution server mirror in the >East coast of the US. > >No mirror in the Western US. > >The OSU Open Source Lib (https://osuosl.org/) offers hosting resources >to FOSS projects... >https://osuosl.org/services/ > >Maybe the GNU Guix project can request hosting service from them, to >have a substitution mirror, for example, so more resources can be >available for downloading of artifacts for Guix users... > >Maybe this can be expanded later to have more services for Guix and >other GNU projects in the West coast of the US, in cooperation with >the FSF IT? > >Wonder if the idea is OK. >
Re: RFI: Guix XMPP service.
On 12/10/23 05:53, Felix Lechner wrote: Hi, On Fri, Dec 08 2023, MSavoritias wrote: 2. We can self host our own prosody instance. I host my own Prosody instance (mostly to talk to Soprani). [1][2] I recommend the project host its own, as well. Yeah the consensus so far seems to be to host our own. It is pretty easy as you said so it shouldn't be a problem for me to maintain it. Do you think it would be ok to use a VPS? Or do we want a physical server at somebody's home? The server is very lightweight. Unfortunately, my system's uptime history is not suitable for a project instance. For DNS, I'd be happy to offer help.juix.org, but an official address is probably better. Yeah under the guix domain would be best. We also have the guix.info of the foundation but idk how good it would be to be under that. XMPP is great. Thanks for the initiative! Yw ^^ Was missing an XMPP instance and since i can step up I did :) Kind regards Felix [1] https://codeberg.org/lechner/system-config/src/commit/b566b08a982a12f896cd6ef7849dbac0ce2e/host/wallace-server/operating-system.scm#L1195-L1200 [2] Message retention in my setup may only be thirty days. MSavoritias
