Re: Guix pull: avoiding "Computing Guix derivation"
> I see that build in build-self.scm isn't a derivation, but most of the time > spent in build is, to my knowledge, while the daemon is building the > build-program derivation. build-program in build-self.scm returns a > gexp->script file-like object and I see various /gnu/store > *-compute-guix-derivation.drv files in my store. Sorry, saying "most of the time is spent on building the build-program derivation" is not correct. Most of the time is spent on running the compute-guix-derivation script. D'oh. I'll spend more time trying to understand the current system.
Re: Guix pull: avoiding "Computing Guix derivation"
Hi ! I may be a bit dense, but there's one part I don't understand: Ludovic Courtès writes: > Hi, > > Edouard Klein skribis: > >> - Why is this step not substitutable ? The inputs are known, a hash can >> be derived, a substitute server could be queried for an output of that >> hash ? What am I missing ? Does the guix derivation not end up in the >> store ? What makes it so special that it can't be served by a substitute >> server ? > > It’s not substitutable because it’s not a derivation. It’s not a > derivation because it needs to access the store to “compute the Guix > derivation”. > Doesn't it have hashable inputs ? Like the different git hashes of the different channels, plus the hash of whatever guix+guile revision is actually doing the work ? I think my misunderstanding boils down to a bad mental model of how guix works. What I imagine the "Computing guix derivation" step to be is no different than building a package whose inputs are the channels' sources, guile, and the current guix, and whose output is the new guix. Simon and Richard pointed out that the combinatorial combination of all possible input combination makes this hard to substitute, but I don't understand how its result, once in the store, can't lead to a simple linking from the profile to the store, instead of re-running the "Computing guix derivation" step when guix pull is called with the same inputs. Surely my mental model is wrong somehow ? > The latter could be addressed with “nested” or “recursive” derivations > as Nix calls them, but it’s quite a beast. > > Anther option would be to have a built-in derivation builder that would > do that process on behalf of users. That would turn the process into a > derivation, which is thus cachable, substitutable, etc. > >> - Is there a way (even a very dirty one, like hand copying stuff accross >> /var/guix/profiles/per-user/*/current-guix) I can stop paying this 4 >> minutes per user price ? As I said, this is downtime on my server, as >> I need to stop all other services to let guix pull finish. > > I don’t know of any quick hack for that. > > Thanks, > Ludo’.
Re: Guix pull: avoiding "Computing Guix derivation"
Thank you both for this detailed explanations. I think I have a better grasp at the problem. Keep in mind that I never not dive into guix's internals. I just - had previous experience with Gentoo and Source Mage (anyone remember this distro ?) who did some interesting steps towards reproductibility back in the day - knew what a Merkle dag is - read the manual and dived in with an overconfidence in my understanding of how this all works. To simplify the problem somewhat, bear in mind that a very good first step would be to avoid the "Computing Guix derivation" step, once it's been done already once and its result is "nothing to do". If that could happen, I could just run it as root once (4 minutes of downtime a week is manageable) and let the other users enjoy my cache. Simon Tournier writes: > Hi Richard, > > On lun., 13 mai 2024 at 20:52, Richard Sent > wrote: > >> You're correct. This solution wouldn't be sufficient to avoid "Computing >> Guix Derivation" for every possible A or B. To my understanding it could >> reduce the frequency this occurs. > > [...] > >> Assuming D changes significantly less frequently than A, B, C..., I >> would think this should be something we could feasibly substitute (at >> least for recent D and Z). > > Well, the package ’guix’ has changed 14 times over the past year. > Therefore, this D cannot be this package ’guix’, IMHO. > > $ git log --format="%cd %s" --since="1 year ago" | grep 'gnu: guix: Update' > Mon May 13 18:22:53 2024 +0200 gnu: guix: Update to 7ca9809. > Tue Mar 12 14:27:01 2024 +0100 gnu: guix: Update to 4c94b9e. > Mon Mar 11 23:14:37 2024 +0100 gnu: guix: Update to 8f4ffb3. > Sat Dec 2 15:37:44 2023 +0100 gnu: guix: Update to 1.4.0-16.aeb494322c. > Thu Nov 30 07:15:36 2023 +0100 gnu: guix: Update to 1.4.0-15.e0885fcfbb. > Thu Nov 9 10:42:55 2023 +0200 gnu: guix: Update to a60ff46. > Fri Oct 6 12:26:44 2023 +0200 gnu: guix: Update to e863274. > Thu Sep 28 11:44:08 2023 +0200 gnu: guix: Update to d0438fc. > Mon Sep 18 12:31:52 2023 +0200 Revert "gnu: guix: Update to > 1.4.0-11.658de25e99." > Mon Sep 18 06:49:46 2023 +0200 gnu: guix: Update to 1.4.0-11.658de25e99. > Tue Aug 22 21:30:49 2023 +0200 gnu: guix: Update to 1.4.0-10.4dfdd82210. > Tue Aug 22 11:17:52 2023 +0200 gnu: guix: Update to 30355c1. > Mon Oct 2 09:28:02 2023 +0200 gnu: guix: Update to 1.4.0-12.b9fae146d6. > Mon Aug 21 18:44:49 2023 +0200 gnu: guix: Update to 0e6215a. > Fri Jun 9 22:11:14 2023 +0200 gnu: guix: Update to 44bbfc2. > > > Maybe I have a bad practise but here my “guix pull” history: > > $ guix pull -l | grep Generation > Generation 1 nov. 17 2023 13:18:58 > Generation 2 déc. 11 2023 10:55:51 > Generation 3 févr. 02 2024 01:56:52 > Generation 4 mars 25 2024 18:22:25 > Generation 5 mai 13 2024 19:28:31(current) > > Therefore, I am not convinced that replacing "Computing Guix derivation" > (build-aux/build-self.scm) by the package ’guix’ would be robust enough. > > (Assuming another package ’guix’, lighter e.g., without requiring the > test suite, etc.) > > All that said, any experiment – even if it appears at first clunky – is > very welcome! This part will be improved only if there is a collective > effort / discussion / try, IMHO, i.e., by challenging the status quo. :-) > > Cheers, > simon
Re: Guix pull: avoiding "Computing Guix derivation"
Hi, Good advice, thank you ! I just began playing with btrfs, and I see that you can convert an existing ext4 to a btrfs, so I may try that (I'll just run some backups first). I was not aware that guix deploy does the computation on the local computer rather than on the target. I'll look more into it, thanks ! As for the user profiles, those exist because the users are real human users. The server in question is https://the-dam.org, a GNU Guix public access server. I'll keep this thread posted on how it went :) Cheers, Edouard. Ryan Sundberg writes: > Hi Edouard, I have couple of ideas for you, which may help with your > deployment process: > > 1) if possible, mount /gnu on a btrfs filesystem with zstd compression > enabled. This will let you fill up at least 3x of your physical disk space > because the store compresses very well. > > 2) for production servers you should try using `guix deploy` to push rather > than pull profiles. This will offload most of the process to the machine > pushing the deployment. > > With regards to multi user profiles, if this is a typical server (not a > terminal/shell server) I wonder why you need to have per user profiles at > all. I > only say this because I am not sure about running `guix deploy` on an > individual > user basis. > > Sincerely, > Ryan Sundberg > > May 13, 2024 8:08:35 AM Edouard Klein : > >> Hi Guix, >> >> First, I'd like to apologize for not having taken the time to answer >> those who helped me on a previous guix performance issue (with >> containers), the reason is tied to the topic of this email: the store >> has eaten all the space of my server, and solving that takes precedence >> over everything else, because no space == no services. >> >> So, I need to clear some space, and to do that I need to have every user >> run guix pull (and by that I mean root will sudo -u $user guix pull), >> then update all of their profiles, and then guix gc >> --delete-generations. >> >> This ought to turn deduplication up to 11, and enjoy a reduced store >> size. >> >> I've already solved the cache size problem: >> mount -t overlay overlay -o \ >> lowerdir="/root/.cache/guix",upperdir="/home/$user/.cache/guix-overlay",workdir="/home/$user/.cache/guix-workdir" >> \ >> "/home/$user/.cache/guix" >> >> Then >> bindfs --mirror=$user /home/$user/.cache/guix /home/$user/.cache/guix >> >> This lets root (who just ran guix pull) share its cache with every user, >> and avoid blasting away 700MB of disk space in every $HOME to reproduce >> the cache. >> >> However, now, I'm facing the previously addressed problem of guix pull >> being slow and hungry: >> https://www.mail-archive.com/guix-devel@gnu.org/msg66442.html (Guix pull >> speed) >> https://yhetil.org/guix/87h6mwf4u3@lapenas.dev/T/ (guix pull >> performance) >> >> On my server, in order to run guix pull, I have to stop all other >> services otherwise I run out of ram. >> >> Then, one root has pulled, I need to wait 4 minutes /per user/ for guix >> pull to finish its "Computing Guix derivation" step. >> >> I would like to know two things, one is for the sake of knowledge, and >> the other is to solve the problem at hand: >> >> - Why is this step not substitutable ? The inputs are known, a hash can >> be derived, a substitute server could be queried for an output of that >> hash ? What am I missing ? Does the guix derivation not end up in the >> store ? What makes it so special that it can't be served by a substitute >> server ? >> >> - Is there a way (even a very dirty one, like hand copying stuff accross >> /var/guix/profiles/per-user/*/current-guix) I can stop paying this 4 >> minutes per user price ? As I said, this is downtime on my server, as >> I need to stop all other services to let guix pull finish. >> >> Thanks in advance. >> >> Sorry for beating a dead horse, it's just that I can't scale anything up >> until I solve these performance issues. Sure I could rent a bigger >> server, but that's just kicking the can down the road. >> >> >> Cheers, >> >> Edouard.
Re: Guix pull: avoiding "Computing Guix derivation"
>> - Why is this step not substitutable ? The inputs are known, a hash can >> be derived, a substitute server could be queried for an output of that >> hash ? What am I missing ? Does the guix derivation not end up in the >> store ? What makes it so special that it can't be served by a substitute >> server ? > >It’s not substitutable because it’s not a derivation. It’s not a >derivation because it needs to access the store to “compute the Guix >derivation”. I see that build in build-self.scm isn't a derivation, but most of the time spent in build is, to my knowledge, while the daemon is building the build-program derivation. build-program in build-self.scm returns a gexp->script file-like object and I see various /gnu/store/*-compute-guix-derivation.drv files in my store. Ergo, if more of the inputs to build-program were locked, the compute-guix-derivation output should be substitutable. To my knowledge the problem largely lies in that the modules imported in build-self.scm are from the current Guix, which vary wildly between machines and is rarely, if ever, substitutable. In theory if those modules were pinned to particular versions, the bulk of the time spent in build would be removed. Obviously there are challenges with this approach. For one, if we were to use the "guix" package to run build and generate compute-guix-derivation.drv, what would we do if a user on Guix A wanted to upgrade/downgrade to B, but the Guix package was changed in-between? I think the various problems are solvable, perhaps by making the solution opt-in. e.g. $ guix pull --quick, which attempts to build channels using an infrequently updated Guix/Guix-subset to more regularly match an existing compute-guix-derivation in a substitute server's store. Sorry if the formatting on this is off, sent from my phone.
Re: Scheduling a new release?
Christina O'Donnell writes: > On 08/05/2024 14:01, Christopher Baines wrote: >> I think it would be nice to have a new release, and indeed release more >> often, I think the way to get there is for less things to be broken >> between releases, such that releasing takes less effort in terms of >> testing and fixing things. >> >> To give some specific issues, I've run up against the recent issues with >> nss [1][2] and I don't think we could release with the nss package as is >> currently. >> >> 1: https://issues.guix.gnu.org/70662 >> 2: https://issues.guix.gnu.org/70663 > > I can fix these by disabling tests, but I would prefer if someone with > more experience packaging for guix could make a decision on > it. Otherwise, I don't have any problem reducing the number of tests > and disabling all tests on PowerPC at least. > > I could also do some analysis if it was deemed necessary, inserting a > patch to measure the timings of each test/cycle. Additionally, I could > try packaging some of the versions between 0.88 and 0.98 to identify > the exact change that could be to blame. However, both of these seem > overkill, given the backlog of patches/issues we have left to get > through, and the manpower we currently have to work with. > > Would any of that be helpful? The problem described by #70663 has now been fixed on master through the changes in #70693. The general point I was making though is that if we can improve tooling and processes so that problems are spotted before they reach master, then releasing should be easier. signature.asc Description: PGP signature
Re: Guix user statistics and upstream/downstream dependencies
Hi John, John Kehayias writes: > Hi Guix-ers, > > I have been working on putting in a concept note (to be hopefully > invited for a full proposal) for the Open Technology Sustainability > Fund (thanks Maxim for posting this earlier!). My goal would be to get > support for some broad and deep improvements to Guix around > user/contributor workflows, governance and organization, and generally > improving our response to bugs/patches/feature work. Unfortunately > this comes at a very busy time of year for me, and just before I head > off for some travel. > > Anyway, I wanted to ask if there is any info or statistics anyone has > to help with some project information they request: > > 1. Users & Beneficiaries: Provide an overview of the project’s user >base, their demographics and statistics, and any other indirect >beneficiaries. > > 2. Dependencies: Provide an overview of the project’s software >upstream and downstream dependencies. > > For the first, maybe someone has some unofficial surveys or things > like download stats, mirrors, etc.? We have detailed anonymized nginx logs of all downloaded substitutes from Berlin, at least. If you are interested to use this data as a source we could probably make it available to you since it's anonymized (real IP addresses have been obfuscated). -- Thanks, Maxim
Re: Scheduling a new release?
Hi, On 08/05/2024 14:01, Christopher Baines wrote: I think it would be nice to have a new release, and indeed release more often, I think the way to get there is for less things to be broken between releases, such that releasing takes less effort in terms of testing and fixing things. To give some specific issues, I've run up against the recent issues with nss [1][2] and I don't think we could release with the nss package as is currently. 1: https://issues.guix.gnu.org/70662 2: https://issues.guix.gnu.org/70663 I can fix these by disabling tests, but I would prefer if someone with more experience packaging for guix could make a decision on it. Otherwise, I don't have any problem reducing the number of tests and disabling all tests on PowerPC at least. I could also do some analysis if it was deemed necessary, inserting a patch to measure the timings of each test/cycle. Additionally, I could try packaging some of the versions between 0.88 and 0.98 to identify the exact change that could be to blame. However, both of these seem overkill, given the backlog of patches/issues we have left to get through, and the manpower we currently have to work with. Would any of that be helpful? ... Kind regards, Christina
Re: Guix pull: avoiding "Computing Guix derivation"
Hi, Edouard Klein skribis: > - Why is this step not substitutable ? The inputs are known, a hash can > be derived, a substitute server could be queried for an output of that > hash ? What am I missing ? Does the guix derivation not end up in the > store ? What makes it so special that it can't be served by a substitute > server ? It’s not substitutable because it’s not a derivation. It’s not a derivation because it needs to access the store to “compute the Guix derivation”. The latter could be addressed with “nested” or “recursive” derivations as Nix calls them, but it’s quite a beast. Anther option would be to have a built-in derivation builder that would do that process on behalf of users. That would turn the process into a derivation, which is thus cachable, substitutable, etc. > - Is there a way (even a very dirty one, like hand copying stuff accross > /var/guix/profiles/per-user/*/current-guix) I can stop paying this 4 > minutes per user price ? As I said, this is downtime on my server, as > I need to stop all other services to let guix pull finish. I don’t know of any quick hack for that. Thanks, Ludo’.
Re: New mumi www and mumi compose subcommands
Hello, Arun Isaac skribis: > $ mumi current 22138 > #22138 Search paths of dependencies are not honored > opened on 10 Dec 2015 09:36 by Ludovic Courtès > > $ mumi www > [opens the issue in your web browser] > > $ mumi compose > [opens your mail client to compose an email to that issue with addresses > pre-filled correctly] Nice! > The www and compose subcommands rely on xdg-open to open your browser > and mail client correctly. Won’t work with Gnus, but nice still. ;-) Should “we” (i.e., you :-)) add these examples to the “Debbugs User Interfaces” section of the manual? Thanks, Ludo’.
Re: Re-activate Coirass specification
Hi, Sharlatan Hellseher skribis: > In the end I've deactivated golang-team specification attempting to > resurrect already existing go-team one, but there is no any UI option to > re-activate the specification. It may well be the case that one has to spawn ‘psql’ on the machine and change the spec row to have is_active = 1. We should fix that! Ludo’.
Re: Demystifying SSH configuration for remote software forges on Guix System
Hi, Ashvith Shetty skribis: > And finally, I've come across `home-openssh-service-type` - which I've yet > to try, but reading from the docs, am I supposed to put my private and > public keys in the repository? How do I go about this? Isn't that a > security risk? Never ever put private keys in a repo. I use ‘home-gpg-agent-service-type’ as my SSH agent: https://guix.gnu.org/manual/devel/en/html_node/GNU-Privacy-Guard.html If you already use Guix Home, you can set it up by adding a few lines to your Home config, along the lines of the example in the manual above. If you don’t, you could start ‘gpg-agent --ssh-support’ or ‘ssh-agent’ manually, for example from ~/.xsession or similar startup file. HTH! Ludo’.
Re: Guix pull: avoiding "Computing Guix derivation"
Hi Richard, On lun., 13 mai 2024 at 20:52, Richard Sent wrote: > You're correct. This solution wouldn't be sufficient to avoid "Computing > Guix Derivation" for every possible A or B. To my understanding it could > reduce the frequency this occurs. [...] > Assuming D changes significantly less frequently than A, B, C..., I > would think this should be something we could feasibly substitute (at > least for recent D and Z). Well, the package ’guix’ has changed 14 times over the past year. Therefore, this D cannot be this package ’guix’, IMHO. --8<---cut here---start->8--- $ git log --format="%cd %s" --since="1 year ago" | grep 'gnu: guix: Update' Mon May 13 18:22:53 2024 +0200 gnu: guix: Update to 7ca9809. Tue Mar 12 14:27:01 2024 +0100 gnu: guix: Update to 4c94b9e. Mon Mar 11 23:14:37 2024 +0100 gnu: guix: Update to 8f4ffb3. Sat Dec 2 15:37:44 2023 +0100 gnu: guix: Update to 1.4.0-16.aeb494322c. Thu Nov 30 07:15:36 2023 +0100 gnu: guix: Update to 1.4.0-15.e0885fcfbb. Thu Nov 9 10:42:55 2023 +0200 gnu: guix: Update to a60ff46. Fri Oct 6 12:26:44 2023 +0200 gnu: guix: Update to e863274. Thu Sep 28 11:44:08 2023 +0200 gnu: guix: Update to d0438fc. Mon Sep 18 12:31:52 2023 +0200 Revert "gnu: guix: Update to 1.4.0-11.658de25e99." Mon Sep 18 06:49:46 2023 +0200 gnu: guix: Update to 1.4.0-11.658de25e99. Tue Aug 22 21:30:49 2023 +0200 gnu: guix: Update to 1.4.0-10.4dfdd82210. Tue Aug 22 11:17:52 2023 +0200 gnu: guix: Update to 30355c1. Mon Oct 2 09:28:02 2023 +0200 gnu: guix: Update to 1.4.0-12.b9fae146d6. Mon Aug 21 18:44:49 2023 +0200 gnu: guix: Update to 0e6215a. Fri Jun 9 22:11:14 2023 +0200 gnu: guix: Update to 44bbfc2. --8<---cut here---end--->8--- Maybe I have a bad practise but here my “guix pull” history: --8<---cut here---start->8--- $ guix pull -l | grep Generation Generation 1nov. 17 2023 13:18:58 Generation 2déc. 11 2023 10:55:51 Generation 3févr. 02 2024 01:56:52 Generation 4mars 25 2024 18:22:25 Generation 5mai 13 2024 19:28:31(current) --8<---cut here---end--->8--- Therefore, I am not convinced that replacing "Computing Guix derivation" (build-aux/build-self.scm) by the package ’guix’ would be robust enough. (Assuming another package ’guix’, lighter e.g., without requiring the test suite, etc.) All that said, any experiment – even if it appears at first clunky – is very welcome! This part will be improved only if there is a collective effort / discussion / try, IMHO, i.e., by challenging the status quo. :-) Cheers, simon
Re: time-bomb and CI? (was bug#69800: kcalendarcore time-bomb)
Hi, Simon Tournier skribis: > Other said, would it be possible to have one (or more) node that build > with a date in the future? Say 3 years. In Bordeaux? Or in Berlin? > Using the “Dolorean VM” [2], it could be nice to setup one node. [...] > https://guix.gnu.org/en/blog/2024/adventures-on-the-quest-for-long-term-reproducible-deployment Yes! As I wrote in the blog post above, I think the best way to help get there is to work on optimizing the ‘virtual-build-machine’ service a bit, along the lines noted in the blog post above (SSH over AF_VSOCK, guest store overlaid over the host store itself mounted as virtiofs, etc.). The second best way is to propose a patch against maintenance.git adding ‘virtual-build-machine’ services to some of the build machines (similar to how we add childhurds to some of them) so we can start experimenting. It’ll be kinda random—some builds will be offloaded to the VMs, some won’t—but it’s a start. Ludo’.
Re: Scheduling a new release?
Hi Christopher, Christopher Baines skribis: > While releases will still require bursts of effort, I think we need a > more sustainable approach to actually achieve more frequent releases. I think this is largely an organizational problem. As discussed at the 2023 Guix Days (!), we could follow a model similar to that of NixOS: form a release team (~4 people) dedicated to keeping track of issues in particular wrt. the installer, and committed to publishing a release within 4–6 months. (I think several people actually volunteered back in Feb. 2023. :-)) After that, another team, possibly with some overlap, would take over. What matters IMO is to make sure people on the team are not on their own (they coordinate the effort, they don’t fix every single bug by themselves), that they have agency (they decide what goes into the release and what’s left for later), and they do not risk burn-out (it’s a fixed-term mandate). Anyway, I agree it’s high time we published a new release! I would encourage anyone with some experience to volunteer on the team. Again, that doesn’t require expertise on the whole code base but rather a good idea of which teams to talk to and methodology to keep track of things to be done. Thanks, Ludo’.
Re: font-packaging guidelines
Hi, not sure what your question is. The code formatting style can be checked with "guix lint". Am 02.05.24 um 12:26 schrieb not emma: 29 │ (synopsis "Iconic font aggregator, collection, and patcher") 30 │ (description 31 │ "Nerd Fonts patches developer targeted fonts with a high number 32 │ of glyphs (icons). Specifically to add a high number of extra glyphs 33 │ from popular ‘iconic fonts’ such as Font Awesome, Devicons, Octicons, and others.") Reading this, I do not understand what this package is. "patcher" sounds like a tool, and the description says "patches". But you are talking about fonts, and the package is called "font-…". Collection of 'iconic' fonts? Font containing icons collected from may other icon fonts? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [PATCH] gnu: glibc: Update patches following upstream's master branch.
Hi, Josselin Poiret skribis: > From: Josselin Poiret > > * gnu/packages/patches/glibc-2.39-git-updates.patch: New patch. > * gnu/local.mk (dist_patch_DATA): Register it. > * gnu/packages/base.scm (glibc): Use it. > > Change-Id: I13ff3fa2eddd8296d138f87c9069487e9543b3bd > --- > How about the following patch? [...] > +(patches (search-patches "glibc-2.39-git-updates.patch" > + "glibc-ldd-powerpc.patch" > "glibc-2.38-ldd-x86_64.patch" > "glibc-dl-cache.patch" > "glibc-2.37-versioned-locpath.patch" As discussed on IRC, I would suggest one file per security fix, with “CVE-xyz” in the file name so that ‘guix lint’ can recognize it. But if that’s too tedious/inconvenient, let’s do it like you did here. In that case, we also need to add the ‘lint-hidden-cve’ package property. So I’d say you can go ahead with one of these two approaches. Either way, what matters here is to make sure we remove the glibc graft. Thank you! Ludo’.
Re: `make check` fails when trying to build from Git
Hi Ashvith, I pushed the commits below, which should address the two failures you reported: 7ca9809cdbf tests: Skip ‘terminal-string-width’ test on encodings other than UTF-8. 723d45866f1 tests: Remove interference from the user’s Git config. Lemme know if that helps! Thanks, Ludo’.
Re: bug#40316: nss not reproducible
Hi, Christina O'Donnell skribis: > On 06/05/2024 11:12, Ludovic Courtès wrote: [...] >> For sure I’d be happy if the test suite could run faster, but does >> upstream offer such an option? When you say “a single pass”, is that >> something upstream supports? > Yes, you can control the tests by setting environment variables > NSS_TESTS to a list of tests and NSS_CYCLES to a list of 'cycles' > (what I previously called passes). The default is: > > "standard pkix threadunsafe" > > * 'standard' runs all of the below tests with default settings: > "cipher lowhash cert dbtests tools sdr crmf smime ssl ocsp merge > pkits ec gtests ssl_gtests policy" > > * 'pkix' runs the tests "lowhash libpkix cert tools ssl ocsp pkits ec > gtests ssl_gtests policy" with PKIX enabled. > > * 'thread_unsafe' runs "ssl ssl_gtests" with "THREAD_UNSAFE" enabled. Interesting. > My thinking would be to run the thread_unsafe cycle normally, but to > reduce the test overlap between standard and pkix however, I can't say > that I'm knowledgeable enough of NSS to claim that that wouldn't leave > gaps that might bite us some point down the line. So it might be best > to leave it as is unless someone familiar with NSS can confirm that > it'd be safe to disable some tests/cycles. Right, there doesn’t seem to be an obvious way to disable those without also weakening test coverage. I wonder what Debian and others are doing. Thanks for explaining! Ludo’.
Re: Guix user statistics and upstream/downstream dependencies
Hi John, Andrew Tropin and a few contributers are also using and extending Guix into its own developer and power user friendly GNU/Linux distribution, you can find more info on the project page : https://git.sr.ht/~abcdw/rde Or we can answer any questions you would have with Andrew. You can also find a collection of channels, packages and services here : https://toys.whereis.%E3%81%BF%E3%82%93%E3%81%AA (or here if badly pasted : https://git.sr.ht/~whereiseveryone/toys) There are probably multiple projects of interest there for you. Cheers, Nicolas On 2024-05-13 05:13, John Kehayias wrote: > Hi Guix-ers, > > I have been working on putting in a concept note (to be hopefully > invited for a full proposal) for the Open Technology Sustainability > Fund (thanks Maxim for posting this earlier!). My goal would be to get > support for some broad and deep improvements to Guix around > user/contributor workflows, governance and organization, and generally > improving our response to bugs/patches/feature work. Unfortunately > this comes at a very busy time of year for me, and just before I head > off for some travel. > > Anyway, I wanted to ask if there is any info or statistics anyone has > to help with some project information they request: > > 1. Users & Beneficiaries: Provide an overview of the project’s user >base, their demographics and statistics, and any other indirect >beneficiaries. > > 2. Dependencies: Provide an overview of the project’s software >upstream and downstream dependencies. > > For the first, maybe someone has some unofficial surveys or things > like download stats, mirrors, etc.? > > A Guix user/contributor survey came up in the past and is one I would > propose doing as part of this proposal as I think we are lacking some > useful information. > > For the second, obviously we depend on things like Guile and Shepherd, > as well as everything that makes a distro tick (packages). But what > about downstream? > > I know Guix is used for some research, high performance computing, > ...what else do people know of or anywhere we mention this? (Would be > great to have a "powered by Guix" on our website, by the way!) > > Anyway, any useful information please do send my way (privately if you > prefer)! I will need to wrap this up by the 15th unfortunately, and > probably a long shot, but would be fantastic to get some funding to be > able to work full time on Guix. And if I make it to the proposal stage > I'll be reaching out to put together more formal pieces and recruiting > people that would like to work on any funded work. > > Thanks all! > John > > -- Best regards, Nicolas Graves
