Re: EU NGI funding cut engagement opportunity
On 2024-07-21 01:15, Juliana Sims wrote: Greetings comrades, As many of you are likely already aware, the European Union has recently made plans to cut funding to its Next Generation Internet (NGI) initiative which funds hundreds of FOSS projects, including many related to Guix itself. The current plan is to shift these funds into artifical intelligence research. Petites Singularités has started an open letter to call on the EU to restore this funding. I would very much support Guix signing onto it. The document, and instructions for participating in this effort, can be found here: https://pad.public.cat/lettre-NCP-NGI For full disclosure, my work on the Shepherd is funded by NGI through NLnet. While my funding is secure, it would be a tragedy if the opportunity which I have been given to build something really cool and (I hope) revolutionary were denied to others. In solidarity, Juli I signed the open letter myself. https://ekaitz.elenq.tech/ And we are discussing about writing something in Guix about this, too. Thanks for pointing it out.
Re: EU NGI funding cut engagement opportunity
On 2024-07-21 01:15, Juliana Sims wrote: Greetings comrades, As many of you are likely already aware, the European Union has recently made plans to cut funding to its Next Generation Internet (NGI) initiative which funds hundreds of FOSS projects, including many related to Guix itself. The current plan is to shift these funds into artifical intelligence research. Petites Singularités has started an open letter to call on the EU to restore this funding. I would very much support Guix signing onto it. The document, and instructions for participating in this effort, can be found here: https://pad.public.cat/lettre-NCP-NGI For full disclosure, my work on the Shepherd is funded by NGI through NLnet. While my funding is secure, it would be a tragedy if the opportunity which I have been given to build something really cool and (I hope) revolutionary were denied to others. In solidarity, Juli The building of resilient and decentralised protocol and server technologies should be considered advantageous - if only as a matter of soft power. For example, here is a detailed breakdown of how Japan uses its cultural assets as a form of soft diplomacy - to the extent that it is happy to run investment funds at a loss: https://yewtu.be/watch?v=IM2VIKfaY0Y I felt that PS position seems correct. I always thought the funds NGI has received was peanuts and a bargain for the European project. Id sign it but Im not sure whether independents are encouraged. In any case, my (very) distinct informatics work progressed significantly as a consequence of the funding and prestige from NLNet (Icebreaker project). One would think that, given the growing spectre of authoritarianism and disinformation (that is exerting itself across many locations), that it would be useful for people to be able to say in a sustainable way: "I am here, this is who I am" *rechecks EU election results* Oh, FFS
Re: Sustainable funding and maintenance for our infrastructure
Simon Tournier skribis: > Well, from my perspective, the question is architecture per > architecture. I mean, I think it’s doable to find sponsor (companies or > academic institutions) for x86_64 because it’s commonly used. And > that’s not the case for less used others. In the past we got donations from Arm: https://guix.gnu.org/en/blog/2018/aarch64-build-machines-donated/ I imagine the same could happen today for “alternative” architectures. Ludo’.
Re: Should we document how to detect if build machines are reachable before trying to offload?
Hi, Sergio Pastor Pérez skribis: >> Do you remember exactly under what circumstances it hangs? I think >> ‘guix offload’ should handle that situation gracefully and we should fix >> it if it does not. > > Yeah. It happens when I have a build machine configured like so and I > disconnect it from the Ethernet connection: > > (build-machines > (list > #~(build-machine > (name "remote") > (systems (list "x86_64-linux" "i686-linux")) > (host-key %remote-host-key > (private-key %local-key > > > With this configuration `guix offload test` will timeout after 30 > seconds, as you describe. But this other command will hang indefinitely: > > $ timeout 1m guix build imhex -M 0 > The following derivation will be built: > /gnu/store/9absqzdd4ak3pms2jw6rkhlmjvm8zzyv-imhex-1.35.1.drv > process 12199 acquired build slot '/var/guix/offload/bordercollie:22/0' > guix offload: error: failed to connect to 'bordercollie': No route to host > waiting for locks or build slots... > process 12199 acquired build slot '/var/guix/offload/bordercollie:22/0' > guix offload: error: failed to connect to 'bordercollie': No route to host I believe the problem here is that offloading always wants to offload. That is, when all the machines in /etc/guix/machines.scm are unavailable, ‘guix offload’ says so to guix-daemon, but then guix-daemon just keeps retrying (if you had more than one machine in /etc/guix/machines.scm, one of which is unavailable, ‘guix offload’ would just pick another one.) I guess this is probably what we should permit: building locally when we cannot offload. Does that make sense? Ludo’.
Re: ci.guix.gnu.org is getting back to life
Hello! Ludovic Courtès skribis: > • We upgraded the Honeycombs (AArch64) and POWER9 build machines. At > this stage 3 AArch64 and 2 POWER9 build machines are fully > operational behind ci.guix: > > https://ci.guix.gnu.org/workers > > Another Honeycomb, grunewald, is undergoing maintenance at the MDC > and should be back soon. grunewald has been back to work for a week, so we’re making progress! There was a regression in Cuirass that, when a worker is found unresponsive, would cause all the builds performed on that workers to be rescheduled (instead of just those that were running on the worker at that time!). It took me a while to notice it, but that certainly slowed things down as workers would end up rebuilding the same things again occasionally (not actually rebuilding when substitutes from a previous build were available, but still). The Arm workers have been busy, which has improved substitute availability for aarch64-linux and armhf-linux, but there’s still a lot of progress to be made: https://qa.guix.gnu.org/branch/master https://qa.guix.gnu.org/branch/core-updates So far they’ve been mostly processing relatively old ‘master’ builds and recent ‘gnome-team’ builds; I hope they can start working on ‘core-updates’ now. Ludo’.
Re: ‘core-updates’ rebased: testing needed!
Leo Famulari skribis: > On Mon, Jun 17, 2024 at 11:30:37PM +0200, Ludovic Courtès wrote: >> 1. Checking whether your favorite packages build and work. > > Libreoffice is blocked on core-updates, due a build failure of > libetonyek, caused by a bug in Boost: > > https://issues.guix.gnu.org/72040 > > I think that Libreoffice is really important and we don't want to lose > it on master. > > Currently, the only solution I've found is to patch or upgrade Boost, > which is an expensive rebuild. But there may be other solutions. Your > thoughts? What about adding a new Boost version specifically for use in LibreOffice? Eventually that version would become the default one, but that can happen later. Thanks, Ludo’.
Re: Update default Golang version on go-team branch
Hello Sharlatan, Sharlatan Hellseher skribis: > I had a courage to refresh the default Goang version to build packages > from 1.17 to 1.21 as all version before it are already EoL. After > rebuilt 900+ packages locally I've fixed some failing to build packages. > > The packages in golang-build were refresh as well which involve to > rebuild about 1000+ packages depending on them. > > The changes are pushed to go-team brunch to check any other failures. Congrats on moving forwards with this! Ludo’.
Re: EU NGI funding cut engagement opportunity
Hi! Ekaitz Zarraga skribis: > On 2024-07-21 01:15, Juliana Sims wrote: >> Greetings comrades, >> As many of you are likely already aware, the European Union has >> recently made plans to cut funding to its Next Generation Internet >> (NGI) initiative which funds hundreds of FOSS projects, including >> many related to Guix itself. The current plan is to shift these >> funds into artifical intelligence research. >> Petites Singularités has started an open letter to call on the EU to >> restore this funding. I would very much support Guix signing onto >> it. The document, and instructions for participating in this effort, >> can be found here: https://pad.public.cat/lettre-NCP-NGI >> For full disclosure, my work on the Shepherd is funded by NGI >> through NLnet. While my funding is secure, it would be a tragedy if >> the opportunity which I have been given to build something really >> cool and (I hope) revolutionary were denied to others. >> In solidarity, >> Juli > > I signed the open letter myself. > https://ekaitz.elenq.tech/ > > And we are discussing about writing something in Guix about this, too. Yes. We’re waiting for feedback from Guix maintainers but I think it would make a lot of sense to publish the letter on the Guix blog. As a reminder, Guix has directly benefited from several NGI-funded projects, and indirectly with support for Mes, the RISC-V port of the bootstrap chain, Shepherd/Spritely, and Guile. Ludo’.
Re: Reducing "You found a bug" reports
Hi, Simon Tournier skribis: > On Mon, 17 Jun 2024 at 14:59, Ludovic Courtès wrote: > >>> It doesn’t feel great to tell users to report a bug for things that >>> aren’t bugs. They’re either closed, or never followed up on; it’s a >>> poor experience on both ends. >> >> I agree, it’s pretty bad. >> >> I’m fine removing the “report a bug” message, maybe replacing it with >> some clearer diagnostic and suggestion? WDYT? > > Could we detect if it comes from networking? Somehow catch the error > and run some code that checks stuff and so report more “accurate” > messages? Someone™ would need to analyze some of the reports we have (some of them have already been commented on) to determine what happened and whether that is something we could diagnose differently. Ludo’.
System log (syslogd) for the Shepherd
Hello Guix! I recently pushed a ‘wip-syslogd’ branch in the Shepherd, which should be ready to merge in ‘devel’ in the coming days. It implements an in-process “system log” service that does the same job as good’ol syslogd as currently used in Guix System (info "(inetutils) syslogd invocation"). This is again an optional service. The goal here is to make sure shepherd can take care of everything related to service logging because that’s fundamentally part of its job. A concrete advantage of this built-in syslogd is that it can start logging earlier and can log until the very end—currently syslogd starts relatively late and terminates relatively early, which makes it hard to debug shutdown problems. See “sudo herd graph | xdot -” to visualize where ‘syslogd’ currently is in the dependency graph. The main parts are in place. What’s still missing is: reading kernel messages, integrating with the ‘log-rotation’ service, and documenting. Feedback welcome! Ludo’.
Re: Should we document how to detect if build machines are reachable before trying to offload?
Hello. > I guess this is probably what we should permit: building locally when we > cannot offload. > > Does that make sense? Yeah, makes sense. Regards! Sergio.
Re: Should we document how to detect if build machines are reachable before trying to offload?
Hello, On Sun, Jul 21, 2024 at 12:57 PM Ludovic Courtès wrote: > I guess this is probably what we should permit: building locally when we > cannot offload. > > Does that make sense? > What about making "build locally" not a special case, but just "offloading to localhost" ? Maybe as an implicit default, so that it would work naturally as today. And with some way to deny it for people who don't want to build locally at all, whatever their reason might be. Would that trim some "build locally"-specific code ? Is that already how it's done ? Is the idea crazy / dumb ? -- Vincent Legoll
Re: Should we document how to detect if build machines are reachable before trying to offload?
On 2024-07-21 16:26:41 +, Vincent Legoll wrote: > Hello, > > On Sun, Jul 21, 2024 at 12:57 PM Ludovic Courtès wrote: > > > I guess this is probably what we should permit: building locally when we > > cannot offload. > > > > Does that make sense? > > > > What about making "build locally" not a special case, but just "offloading > to > localhost" ? That will not work without reworking (fixing) the offload mechanism. (Some?) flags are currently ignored for offload (--check, --rounds, ...), but you want to have them working at least locally when you need them. > > Maybe as an implicit default, so that it would work naturally as today. > > And with some way to deny it for people who don't want to build locally > at all, whatever their reason might be. > > Would that trim some "build locally"-specific code ? > > Is that already how it's done ? > > Is the idea crazy / dumb ? No, I like it in general, if nothing else it would put the offload code on critical path, ensuring it fully works. I wonder what are the downsides (I am sure there are some). > > -- > Vincent Legoll Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Shepherd log rotation service
Hi Ludo', On Sat, May 18 2024, Ludovic Courtès wrote: > I’ve just pushed a simple log rotation service for Shepherd: I have a patch removing rottlog from all Guix "services" that use the Shepherd's :log-file feature, which works fine. Do I need to provide a Guix "service" for the log rotation? If so, may I somehow reuse the Shepherd service definition [1] which doesn't contain any G-exps, in the Guix "service" definition, which does? This won't work: --8<---cut here---start->8--- (define (log-rotation-shepherd-service config) (match-record config (compression calendar-event expiry size-threshold) #~((log-rotation-service #$calendar-event #:compression #$compression #:expiry #$expiry #:rotation-size-threshold #$size-threshold --8<---cut here---end--->8--- Thank you for your help, and thanks for the recent syslog announcement! Kind regards Felix [1] https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service/log-rotation.scm?h=devel#n219
