Re: Release v1.4?
On 2022-06-06 01:57, zimoun wrote: > Hi, > > On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès wrote: > >> guix time-machine --branch=staging -- … >> >> Remaining things to check: >> >> - [ ] system tests >> - [ ] status on non-x86_64 architectures > > I agree. To me, it is part of the same effort. From my point of view, > we missed the window for releasing at the previous core-updates merge. > I would like to avoid to miss it. :-) > > Somehow, we all have various constraints on our agenda so if we do not > set some deadlines in advance, it is hard to free some slots compared to > the continuous other “urgent” tasks from elsewhere. > > My email is a call (July is a proposal) for synchronizing our agenda and > agree on some deadlines and make them happen. > > > Cheers, > simon can i help with the system tests? how do i do those? ~vidak
Re: Teams
Hello Ricardo, I would suggest to extend a bit the scope of this idea. What about creating an etc/tutors.scm file as the one attached. This way people would run something like: --8<---cut here---start->8--- git send-email $(get-tutors.scm HEAD^^) *.patches --8<---cut here---end--->8--- The get-tutors.scm command would take a git reference as argument. From this git reference the list of edited files would be extracted. Once matched with the modules field of tutors.scm, the ML & tutors that should be CC'ed would be returned. For the previous example, if the patches are modifying (gnu packages bioconductor), the command would be: --8<---cut here---start->8--- git send-email --to guix-patc...@gnu.org --cc guix-r-patc...@gnu.org --cc rek...@elephly.net --cc zimoun.touto...@gmail.com *.patches --8<---cut here---end--->8--- People could subscribe to the relevant ML if they want to follow specific subjects. If someone wants to become a tutor, a patch could be sent against the tutors.scm file. Being listed in the tutors.scm file would imply some duties, such as trying to review part of the traffic for the tutored parts. We could then turn this tutors.scm file into a website page, transforming the tutors SEXP into an HTML table. WDYT? Thanks, Mathieu tutors.scm Description: Binary data
Re: Release v1.4?
Hi, On Fri, 03 Jun 2022 at 18:41, Ludovic Courtès wrote: > guix time-machine --branch=staging -- … > > Remaining things to check: > > - [ ] system tests > - [ ] status on non-x86_64 architectures I agree. To me, it is part of the same effort. From my point of view, we missed the window for releasing at the previous core-updates merge. I would like to avoid to miss it. :-) Somehow, we all have various constraints on our agenda so if we do not set some deadlines in advance, it is hard to free some slots compared to the continuous other “urgent” tasks from elsewhere. My email is a call (July is a proposal) for synchronizing our agenda and agree on some deadlines and make them happen. Cheers, simon
aarch64 workers appear to have stalled on ci.guix.gnu.org
Per https://ci.guix.gnu.org/eval/364633?status=pending , there are ~5k scheduled jobs, all aarch64-linux. Per https://ci.guix.gnu.org/workers, all workers report being idle. Thus, it looks like the aarch64 builders have stalled.
Re: wishlist: “repack” generations history of profile
Hi Simon and developers, what about a flag - e.g. --backup - and a related funcion for "guix package -d generations" and "guix gc -d generations" (other?) that saves "channels-generation-.scm" and "manifest-generation- for each deleted generation? This way we can keep the current deletion of generations and status logic while giving users a utility to automaticcaly keep old channels.scm and manifest.scm files, of course the responsibility to store the backups (where, how, why) is on the users shoulders Sorry I'm not able to help with such implementation, it's just an idea for an alternative one. zimoun writes: [...] > Therefore, you want to roll-back to the first generation and see… Bah > you cannot because it is many months old and the sysadmin runs “guix gc > -d 3m” to save some space. I'm a sysadmin, please understand the ungrateful job to administer a machine in a "shared servers context" in which users have the power to administer their software profiles except they are not willing to do it properly. Each and every user is /also/ a little sysadmin ;-) "guix gc -d 3m" by sysadmins for their users is "hard delegation" "guix package -d " by users and "guix gc -C" by sysadmins is "soft delegation" and more fair IMHO [...] > However, we are often saying: do not worry, you can always travel back > in time (implicitly assuming Guix have the information :-)). If this is the case, IMHO we should patch the manual: what part of the manual do you have in mind? > And this assumption is often missed which leads to uncomfortable > situations, not to say maybe some scientists are sometime blaming > sysadmin and/or Guix promoter. :-) I know: when a system does not work as expected is always someone else resposibility, usually sysadmins :-O > Somehow my point is: The time scale of a project is often very different > to the time scale of GC on a machine. Most of the time, the old Somehow my point is: sysadmins and users should peacefully agree on a Guix package and profile management policy, documenting it for the organization [...] Happy Guixing! :-D Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Teams
FWIW, I just want to commend whoever is packaging TexLive. My last update covered March of this year - no mean feat given that it is a 3.4GB package aggregate. (sorry I cant do more direct contributions for Guix atm, looking forward to such an honour eventually) On 04-06-2022 14:07, Ricardo Wurmus wrote: Hi Guix, this is not a new idea[1]: let’s add a page to the website that lists teams and a mail alias for each of the teams. For example, the “R team” consists of people familiar with how R packaging works in Guix, e.g. Simon and myself. There would be an alias “guix-tea...@gnu.org”. People with questions about R in Guix could write an email to that alias. Mumi could also send email to guix-tea...@gnu.org to remind them about patches relating to R / Bioconductor / CRAN, etc. Maintainers could write to these teams before releases to ask if there are any obstacles to a release. As a first step I’d suggest collecting teams, setting up the email aliases, and updating the website to show the existing teams. Here’s a draft of three teams: * R team Simon Tournier Ricardo Wurmus * Java team Julien Lepiller * Rust team Efraim Flashner Aleksandr Vityazev Arun Isaac John Soo Maxim Cournoyer Nicolas Goaziou Tobias Geerinckx-Rice What do you think? -- Jonathan McHugh indieterminacy@libre.brussels
Re: Mummi wishlist: API using Message-ID
Hi Ricardo, On Sat, 04 Jun 2022 at 13:00, Ricardo Wurmus wrote: > This is now implemented in mumi. Really cool! Thank you! The bridge between tools becomes easier. For instance, I use the Emacs frontend of Notmuch where ’cI’ allow to stash the Message-ID, then I can directly paste it for referencing. Cheers, simon
Re: Teams
If we make a team per build system, I'd be in ant, maven, ocaml and dune :) I think there was also interest in formal methods, it could be a team. On June 5, 2022 11:51:20 AM GMT+02:00, zimoun wrote: >Hi Ricardo, > >On Sat, 04 Jun 2022 at 14:07, Ricardo Wurmus wrote: > >> As a first step I’d suggest collecting teams, setting up the email >> aliases, and updating the website to show the existing teams. Here’s >> a draft of three teams: > >Well, a team per build system would fit more or less the needs, I >guess. It is not a big deal if there are some overlaps. > >For what is it is worth, I would suggest that people with commit access >appear at least once in one team, if possible. > > >> * R team >> Simon Tournier >> Ricardo Wurmus > >In addition, add me to: > >* Julia team > > >Cheers, >simon >
Re: Teams
Hi Ricardo, On Sat, 04 Jun 2022 at 14:07, Ricardo Wurmus wrote: > As a first step I’d suggest collecting teams, setting up the email > aliases, and updating the website to show the existing teams. Here’s > a draft of three teams: Well, a team per build system would fit more or less the needs, I guess. It is not a big deal if there are some overlaps. For what is it is worth, I would suggest that people with commit access appear at least once in one team, if possible. > * R team > Simon Tournier > Ricardo Wurmus In addition, add me to: * Julia team Cheers, simon
Re: wishlist: “repack” generations history of profile
Hi, On Sat, 04 Jun 2022 at 09:39, Giovanni Biscuolo wrote: > IMHO all users must understand that for > their projects (profiles) to be reproducible and versioned the /only/ > way is to keep channels.scm and manifests.scm in a VCS (i.e. git) I agree. This practise is the target but as a matter of fact, we are not there yet. From what I daily see, scientists are starting to integrate Git in their workflow, they are also starting to provide how they generate their computational environment, but some are slower than others. ;-) >> That’s why, something like “repack” is missing. As a user, I should be >> able to do >> >> guix package --switch-generation=1 >> >> whatever the sysadmin collects about the old generations and whatever I >> saved using some external tools. > > ...except you wish to reproduce the project on another machine, or > /gnu/store is lost or corrupted for some reason On the same machine, by the same user. Consider that the project is 2 years long, you start to install some packages and run an analysis, 4 months later you receive other data and you analyse using an updated version of tools, 2 months later you want to reanalyse all and you use another updated version of tools… and you have some differences. Therefore, you want to roll-back to the first generation and see… Bah you cannot because it is many months old and the sysadmin runs “guix gc -d 3m” to save some space. Such roll-back should be possible – a full rebuild the profile though. I mean, let GC as usual but also “repack“ the necessary information. Then, if you wish to run on another machine, you can always run ’export-manifest’ and ’export-channels’ from this “repack”. I agree that tracking channels.scm and manaifest.scm is the good practise. And I am trying to promote this very hard. :-) However, we are often saying: do not worry, you can always travel back in time (implicitly assuming Guix have the information :-)). And this assumption is often missed which leads to uncomfortable situations, not to say maybe some scientists are sometime blaming sysadmin and/or Guix promoter. :-) Somehow my point is: The time scale of a project is often very different to the time scale of GC on a machine. Most of the time, the old generations are useless and it is fine to remove them. But for few rare cases, they are necessary – and it is impossible to know in advance or to know the range of time. These few exceptions do not justify to keep all these old generations; it does not make sense because the “environmental costs” (storage, electricity, etc.). Today, the only way is a manual tracking when it could be nice to have a more automatic feature; similarly as ’export-manifest’ and ’export-channels’, they are not necessary per se because the good practise is track the files using Git, but they are very handy in many situations. :-) Cheers, simon
Re: Teams
Hello, Am Sat, Jun 04, 2022 at 02:07:15PM +0200 schrieb Ricardo Wurmus: > As a first step I’d suggest collecting teams, setting up the email > aliases, and updating the website to show the existing teams. Here’s > a draft of three teams: if something like this makes sense, I would be interested in joining a team around algebra.scm and maths.scm. Or maybe a C team :) Andreas
Re: Teams
Hi Ricardo, > As a first step I’d suggest collecting teams, setting up the email > aliases, and updating the website to show the existing teams. Here’s > a draft of three teams: * Python Team Lars-Dominik Braun * Haskell Team Lars-Dominik Braun Anyone interested to join these with me? Cheers, Lars
Re: Teams
On Sat, Jun 04, 2022 at 02:50:49PM +, Tobias Geerinckx-Rice wrote: > I think we should also have (natural) language 'teams' who can be > pinged when, e.g., a news item lands, through a single > guix-translators@ meta-alias, and who can co-ordinate before > releases. If we do so, please add me too for -de. Regards, Florian
Re: Teams
Hello everyone, Ricardo Wurmus writes: > As a first step I’d suggest collecting teams, setting up the email > aliases, and updating the website to show the existing teams. I think an installer team would be good too (which I would gladly join). WDYT of the following teams: * Installer (which I'd gladly join); * System; * Home; * Internals? Maybe that would add too many teams, but I think the first three could be pretty useful. How do we automatically make Mumi understand which team a patch should notify? I've just started using public-inbox/lei and the `dfn:` search term is pretty useful, it lets you select only patches that change specific files. For example, `dfn:gnu/installer*` would match all patches that touch the installer. Best, -- Josselin Poiret
