Re: RFI: Guix XMPP service.
Hi, On 12/10/23 4:04 PM, MSavoritias wrote: On 12/10/23 17:56, Vivien Kraus wrote: Le dimanche 10 décembre 2023 à 17:45 +0200, MSavoritias a écrit : There is also a trust issue. For acceptance, we need bridging. For bridging, we need policing. And for policing, we need people with time. I am of the opinion that bridging would be a bad idea. The differences between IRC and XMPP are significant enough that bringing would probably be more disruptive than conducive to acceptance. A better approach would to simply have a separate IRC and XMPP channel. If people end up preferring XMPP, more people will simply elect to use it. In any project eventually the main communication channels tend to split up into smaller groups once they get to a certain size anyway for a number of reasons. This doesn't stop these other spaces from being 'accepted', and if we have the XMPP channel become official, I think this is acceptance enough. That's a good question yeah. Whether we want bridging that is. Personally I am leaning that we don't. Because bridging can ruin the experience of people that use XMPP. But I can see it either way. Maybe we could do something a little smarter, like having sneek deliver messages in both IRC and XMPP. Vivien There are mirroring ways yeah. That would be a better solution. Because there is biboumi but it basically just creates an IRC room in XMPP. Also sneek should filter stuff probably. Because xmpp allows pictures and long messages and such. So it shouldn't mirror everything as is. I don't know how possible it is though. Maybe some custom setup of something. That said I do have my doubts whether this is more trouble than its worth personally. Given that IRC and XMPP are two very different protocols that are probably gonna attract a different community. Agreed. Specifically, mobile XMPP clients work far, far better than their IRC counterparts out of the box. I think we'd see a lot of people come to the XMPP server due to it's great mobile accessibility. In short, I think we should host our own XMPP server (maybe a VPS for uptime purposes? With media uploads and message logs, storage would be much more of a factor to consider compared to IRC) under the guix.gnu.org domain name and list it on the website. I think once we get to that stage, investigating how to keep track of message logs (perhaps mirroring logs to logs.guix.gnu.org, perhaps under a separate page to the IRC logs) will be vital in moderation efforts. Bridging would cause more problems and potentially solve a problem that we shouldn't want to solve (having one unified space). MSavoritias Ada (adanska)
Re: Ext4 corruption in some stable kernels
On Mon, 11 Dec 2023 08:13:58 +0800, Leo Famulari wrote: > > Everyone with commit privileges should feel free to push these patches to > master if they seem okay. I won't be able to help today. OK, I have applied "[PATCH 2/8] gnu: linux-libre 6.1: Update to 6.1.66." from #67724 as 65334547674bdaeb75eb37ffbe23ba6f9fd486b1 and pushed.
Re: Ext4 corruption in some stable kernels
Everyone with commit privileges should feel free to push these patches to master if they seem okay. I won't be able to help today. Leo On Sun, Dec 10, 2023, at 00:35, 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
Re: Should commits rather be buildable or small
On 12/10/23 18:20, Attila Lendvai wrote: FWIW, this commit policy has always bothered me as a newcomer to Guix. pretty much everywhere else it's a major offence against your colleagues to commit something that breaks the build in any way. In the last few months I’ve repeatedly seen assertions in a similar style as this one. They always genuinely surprise me, and it’s probably not just because I’m oblivious and out of touch. well, both point of views are reasonable. they just make different tradeoffs. I find it hard to see any benefit to anyone from making commits so small that they are known to break things that will be fixed later in the same series. Even aside from `guix time-machine`, substitute building, and the like, a human reading the diff won't be able to see what the true impact of the change is. On the concrete issue: On 12/10/23 10:28, Saku Laesvuori wrote: >> However, in each commit at least the package touched in that >> commit ought to build. > This should, of course, be theoretically possible with at least one > update order but I don't know how would I discover that order (more > efficiently than by trial and error. I don't want to try ~800² different > combinations). Preparing a large set of updates like this is already a great deal of work. It does not seem to me like a good use of volunteers' time to ask them to break such an update into hundreds of tiny pieces, especially not if the result is hundreds of broken commits to Guix. Philip
Re: Should commits rather be buildable or small
> > FWIW, this commit policy has always bothered me as a newcomer to > > Guix. pretty much everywhere else it's a major offence against your > > colleagues to commit something that breaks the build in any way. > > > In the last few months I’ve repeatedly seen assertions in a similar > style as this one. They always genuinely surprise me, and it’s probably > not just because I’m oblivious and out of touch. well, both point of views are reasonable. they just make different tradeoffs. i think an abstraction is missing here, let's call it guix log for this mail. it's something like the git log, but one that lists the buildable and substitutable states of the guix repo. it's probably the same thing that causes the discrepancy between git commits and substitutes: the build servers are not building every commit of the git repo. they pick an unpredictable (?) series of commits, skipping some inbetween. if i guix pull, or guix time-machine to the "wrong" commit, then i'll need to build some stuff locally. sometimes these can be heavy packages. this hypothetical 'guix log' is probably also what's missing between a hypothetical staging branch and master, whose role would be to make sure that commits don't reach the users prior to having substitutes for them. does this make sense? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Sometimes I wonder whether the world is being run by smart people who are putting us on or by imbeciles who really mean it.” — Mark Twain (1835-1910)
Re: Shutting down qa.guix?
Hi, On sam., 09 déc. 2023 at 11:54, Ludovic Courtès wrote: > I think this underlines a collective failure to get our act together. I do not consider a collective failure considering the payment for the service. About the maintenance of such service, that’s another question, IMHO. :-) > 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? Just to put context about these questions for transferring billing: 1. The initial discussion happened on the private mailing list guix-sysadmin. Board of Guix Foundation had been CC on July 6th. 2. Chris provided billing information on July 14th. Then Andreas answered that it is sustainable for Guix Foundation, potentially with the help of Guix Spending Committee. 3. On July 13th, the Solidary Administration Council of Guix Foundation had been solicited; as specified by Guix Foundation statutes. 4. On September 12th, the SAC voted yes about supporting the financial cost of QA. Moreover, since it is a recurrent cost, some means for collecting money had also been discussed. 5. Then what has been unexpected is the energy that the Board of Guix Foundation invested in resolving an unrelated but blocking situation with our bank. It probably slowed down all the operational part. Well, from my understanding of the Guix Foundation side, all is ready for transferring the current billing and, again from my understanding of the situation, what is missing is the effective operational transfer. Now, some relationships with our bank are smoothed… somehow. :-) > 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. Since it is recurrent cost, yes it would nice to discuss between Guix Foundation’s SAC and Spending Committee how to secure the financial support of a recurrent cost. > 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. I still remember the first time we met with Chris, it was back on December 2018, right before Reproducible Build Summit in Paris. Chris already presented what could be done for improving the patch workflows. It’s inspiring to see such commitment and hard work over the years. Cheers, simon
Re: Heisenbug
Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > While executing meta-command: > error: label: unbound variable > >> ,reload > > While this gives > > While executing meta-command: > unknown file name for module # > > Also, what is a meta-command, please? The Guile manual doesn’t define the term but consistently uses it for things like “,reload” or “,bt”, i.e. any command that is not supposed to be evaluated directly as program code but in the meta environment of the REPL itself. -- Ricardo
Re: Should commits rather be buildable or small
Attila Lendvai writes: >> I guess "required" here means that in some cases Guix's policy is to >> prefer small commits over buildable commits (with the previous >> definition). I at least don't see any technical reasons why it would be >> required. The question then becomes whether that policy applies in this >> case. > > > FWIW, this commit policy has always bothered me as a newcomer to > Guix. pretty much everywhere else it's a major offence against your > colleagues to commit something that breaks the build in any way. In the last few months I’ve repeatedly seen assertions in a similar style as this one. They always genuinely surprise me, and it’s probably not just because I’m oblivious and out of touch. Also in Guix it is not okay to commit intermediate things that break stuff. Commits should, however, also tell a reviewable story and not be a big blob of thousands of lines of non-trivial changes. (The one exception has always been fixes of repeated typos, but this is not what this discussion is about.) For what it’s worth: when I do bulk R upgrades I generally have one commit per package upgrade, because it’s easy to review in a git log in the future and easy to revert individual changes with fine grain access. Of course I group upgrades that depend on one another (e.g. r-arrow together with apache-arrow and the inheriting python-arrow). -- Ricardo
Re: Should commits rather be buildable or small
> > Define "buildable" and "unbuildable". > > > I used these definitions: a buildable commit does not have build > failures (or at least no new ones). An unbuildable commit introduces > new build failures (in this case a lot of them). > > Buildable commits are safe spots to land on with time-machine in the > sense that the packages defined in them can be used. I expect it would > be very painful to try jumping to past commits with time-machine if a > large portion of the commits in Guix were unbuildable. [...] > I guess "required" here means that in some cases Guix's policy is to > prefer small commits over buildable commits (with the previous > definition). I at least don't see any technical reasons why it would be > required. The question then becomes whether that policy applies in this > case. FWIW, this commit policy has always bothered me as a newcomer to Guix. pretty much everywhere else it's a major offence against your colleagues to commit something that breaks the build in any way. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “I will probably be asked why I don't cite the author's name? Because my philosophy teacher taught me that it sometimes jeopardizes the effects of the quote.” — Author's name withheld.
Re: Shutting down qa.guix?
Hi, Christopher Baines writes: > Tobias Geerinckx-Rice writes: > >> Christopher Baines 写道： >>> it's not the most cost effective setup >> >> Has this been explained in more detail before? > > Probably not, beid is currently a CPX51 Hetzner cloud server costing > €65.33 a month. This has been useful as it's enabled scaling the > resources dynamically, but it would be possible to reduce the costs and > still have sufficient RAM/disk space by using a Hetzner server auction > machine for example. > > It's not all about cost though, given the data service is one of the > slow points of QA, if we want QA to get faster at giving feedback, it's > probably important to not try and cut costs on this part of the system. Isn't QA mostly slow because of the lack of x86 build machines? Does the head node needs to be powerful itself? What kind of resources does it likes having the most? CPU? RAM? Storage? -- Thanks, Maxim
Re: RFI: Guix XMPP service.
On 12/10/23 17:56, Vivien Kraus wrote: Le dimanche 10 décembre 2023 à 17:45 +0200, MSavoritias a écrit : There is also a trust issue. For acceptance, we need bridging. For bridging, we need policing. And for policing, we need people with time. That's a good question yeah. Whether we want bridging that is. Personally I am leaning that we don't. Because bridging can ruin the experience of people that use XMPP. But I can see it either way. Maybe we could do something a little smarter, like having sneek deliver messages in both IRC and XMPP. Vivien There are mirroring ways yeah. That would be a better solution. Because there is biboumi but it basically just creates an IRC room in XMPP. Also sneek should filter stuff probably. Because xmpp allows pictures and long messages and such. So it shouldn't mirror everything as is. I don't know how possible it is though. Maybe some custom setup of something. That said I do have my doubts whether this is more trouble than its worth personally. Given that IRC and XMPP are two very different protocols that are probably gonna attract a different community. MSavoritias
Re: RFI: Guix XMPP service.
Le dimanche 10 décembre 2023 à 17:45 +0200, MSavoritias a écrit : > > There is also a trust issue. For acceptance, we need bridging. For > > bridging, we need policing. And for policing, we need people with > > time. > > That's a good question yeah. Whether we want bridging that is. > Personally I am leaning that we don't. > > Because bridging can ruin the experience of people that use XMPP. But > I > can see it either way. Maybe we could do something a little smarter, like having sneek deliver messages in both IRC and XMPP. Vivien
Re: Should commits rather be buildable or small
Am Sonntag, dem 10.12.2023 um 17:28 +0200 schrieb Saku Laesvuori: > > Hi Saku, > > > > Am Freitag, dem 08.12.2023 um 10:42 +0200 schrieb Saku Laesvuori: > > > Hi, > > > > > > I'm planning on refreshing Guix's haskell packages as my fix for > > > https://issues.guix.gnu.org/66347 requires rebuilding all of them > > > anyway. Should I try to keep commits small with only one update > > > per commit (which is more work but managable if I don't care > > > about the commits being buildable) or should I try to keep them > > > buildable (i.e. update everything in one commit)? It is quite > > > certain that most of them will not build after updating ghc or a > > > subset of their dependencies, so making many small commits would > > > cause nearly all of them to be unbuildable. > > > > Define "buildable" and "unbuildable". > > I used these definitions: a buildable commit does not have build > failures (or at least no new ones). An unbuildable commit introduces > new build failures (in this case a lot of them). > > Buildable commits are safe spots to land on with time-machine in the > sense that the packages defined in them can be used. I expect it > would be very painful to try jumping to past commits with time- > machine if a large portion of the commits in Guix were unbuildable. Yeah, it's not really good commit etiquette to drop a bunch of world- breaking builds on top of master. We mostly use feature branches for larger changes. OTOH, if it rebuilds less than 300 packages, it really is your call – the number of breakages is limited in that case too :) > > Depending on the context, it may be fine or even required to break > > dependant packages for a short while and update them along a longer > > series. > > I guess "required" here means that in some cases Guix's policy is to > prefer small commits over buildable commits (with the previous > definition). I at least don't see any technical reasons why it would > be required. The question then becomes whether that policy applies in > this case. This is typically allowed when branching off, as few people will time- machine into an intermediate commit on an off-master branch safe for debugging some very arcane failures. > > However, in each commit at least the package touched in that > > commit ought to build. > > This should, of course, be theoretically possible with at least one > update order but I don't know how would I discover that order (more > efficiently than by trial and error. I don't want to try ~800² > different combinations). A reasonable way is to plan according to guix graph. Tackle the low- level nodes first and stack the high-level nodes on top. If two packages share immediate dependencies, but neither relies on the other, then any order is fine between these two. Cheers
Re: RFI: Guix XMPP service.
On 12/10/23 16:43, Felix Lechner wrote: Hi MSavoritias, On Sun, Dec 10 2023, MSavoritias wrote: Do you think it would be ok to use a VPS? Or do we want a physical server at somebody's home? It's a community question. Everyone knows about IRC, and it works well. I'm not sure there is a "we want" for XMPP, even though the protocol is superior. "We want" was in the context of what would be acceptable as hosting so that we can have the room under the same domain as guix. The past few days has given me an indication that there is a good amount of people that want something else than IRC and email. There is also a trust issue. For acceptance, we need bridging. For bridging, we need policing. And for policing, we need people with time. That's a good question yeah. Whether we want bridging that is. Personally I am leaning that we don't. Because bridging can ruin the experience of people that use XMPP. But I can see it either way. Regarding moderation its not a problem to find moderators for the room. Add like 5-10 of them so that we always have somebody online. I have been running XMPP for the past two years like this. Libera.chat has great volunteers that have a long track record in maintaining a service that people rely upon. A group of people would have to step up for XMPP here. I agree. Hopefully this thread will encourage some people that there is a chance we have an XMPP instance :D And we (the people doing/wanting the xmpp instance) can get some permission to set it up under a guix domain. MSavoritias Kind regards Felix
Re: Should commits rather be buildable or small
> Hi Saku, > > Am Freitag, dem 08.12.2023 um 10:42 +0200 schrieb Saku Laesvuori: > > Hi, > > > > I'm planning on refreshing Guix's haskell packages as my fix for > > https://issues.guix.gnu.org/66347 requires rebuilding all of them > > anyway. Should I try to keep commits small with only one update per > > commit (which is more work but managable if I don't care about the > > commits being buildable) or should I try to keep them buildable (i.e. > > update everything in one commit)? It is quite certain that most of > > them will not build after updating ghc or a subset of their > > dependencies, so making many small commits would cause nearly all of > > them to be unbuildable. > > Define "buildable" and "unbuildable". I used these definitions: a buildable commit does not have build failures (or at least no new ones). An unbuildable commit introduces new build failures (in this case a lot of them). Buildable commits are safe spots to land on with time-machine in the sense that the packages defined in them can be used. I expect it would be very painful to try jumping to past commits with time-machine if a large portion of the commits in Guix were unbuildable. > Depending on the context, it may be fine or even required to break > dependant packages for a short while and update them along a longer > series. I guess "required" here means that in some cases Guix's policy is to prefer small commits over buildable commits (with the previous definition). I at least don't see any technical reasons why it would be required. The question then becomes whether that policy applies in this case. > However, in each commit at least the package touched in that > commit ought to build. This should, of course, be theoretically possible with at least one update order but I don't know how would I discover that order (more efficiently than by trial and error. I don't want to try ~800² different combinations). - Saku signature.asc Description: PGP signature
Re: Heisenbug
Hi Attila, On Sun, Dec 10 2023, Attila Lendvai wrote: > M-x geiser > ,m (gnu tests reconfigure) Thanks for those hints! That yields ;;; compiling /lcl/lechner/guix/git/guix/scripts/system/reconfigure.scm ;;; compiled /home/lechner/.cache/guile/ccache/3.0-LE-8-4.7/lcl/lechner/guix/git/guix/scripts/system/reconfigure.scm.go ;;; compiled /home/lechner/.cache/guile/ccache/3.0-LE-8-4.7/lcl/lechner/guix/git/gnu/tests/reconfigure.scm.go While executing meta-command: error: label: unbound variable > ,reload While this gives While executing meta-command: unknown file name for module # Also, what is a meta-command, please? Kind regards Felix
Re: RFI: Guix XMPP service.
Hi MSavoritias, On Sun, Dec 10 2023, MSavoritias wrote: > Do you think it would be ok to use a VPS? Or do we want a physical > server at somebody's home? It's a community question. Everyone knows about IRC, and it works well. I'm not sure there is a "we want" for XMPP, even though the protocol is superior. There is also a trust issue. For acceptance, we need bridging. For bridging, we need policing. And for policing, we need people with time. Libera.chat has great volunteers that have a long track record in maintaining a service that people rely upon. A group of people would have to step up for XMPP here. Kind regards Felix
Re: December London Guix meetup
Hi all, Just a gentle reminder for tomorrow's hybrid Guix meetup! See you all tomorrow! :-) Regards, Arun > The next Guix London meetup is scheduled for Monday 11th December, 6 pm > London time (UTC) onward. 😃🤖🌈💻 Join us in person or online, address > and link below. > > - In person, from 6:00 pm: 20 Farringdon St, EC4A 4AB > - Online, from 6:10 pm: https://meet.jit.si/london-guix-meetup > > https://www.meetup.com/guix-london/events/297591582/ > > If you attend in person, please make sure you RSVP (either on meetup.com > or as an off-list reply to this mail) and share your full name (or a > nickname) so that we can register you at the building's reception. > > The main part of the meetup will be a talk on G-expressions by Simon > Tournier. If you have any Guix or Guile related question or topic, there > should be time to talk about that too. All welcome! > > # Agenda > > - Kick-off (~5 mins): The meetup kicks off at 6:10 pm UTC (please arrive > at 6:00 pm if you're attending in person, that gives us some leeway to > sort access badges and other practicalities out) with a quick round of > intros. If you like, you're welcome to briefly introduce yourself > now. You're also welcome to jump on and off the call at any time. > > - G-expressions, a talk by Simon Tournier (~30 mins + QA): Introduced in > 2021 as part of a significant refactoring, the "Big Change", > G-expressions have become the regular tool for defining Guix > packages. We will start with some Scheme core concepts such as > quasiquote and unquote and then go to G-expressions. As an example, we > will compute the Fibonacci sequence using G-expressions, derivations, > and the Guix daemon. > > - Open discussion (~30 mins): If you have any Guix related question or > idea that you want to share with us, this is a great time to bring it > up. > > # Contact > > For any question, please get in touch via any of the following channels: > > - Arun: arunis...@systemreboot.net > - Fabio: m...@fabionatali.com and https://octodon.social/@fabionatali > - Guix Devel mailing list: https://lists.gnu.org/mailman/listinfo/guix-devel/ > > Guix London has no official ties with the Guix project. We commit to > promote the project and to always operate with the best intentions; any > mistake that we might make is due to us, Guix London, not the Guix > project. > > # Code of conduct > > We, Guix London's organisers, intend to create an open, friendly, and > safe environment where people from the most diverse backgrounds can get > together, learn about, teach, and discuss Guix and related topics in a > welcoming and constructive way. > > To this end, Guix London adheres to the Guix project's official Code of > Conduct, as published at this link. Please make sure you familiarise > with the document and that you share its principles, before attending > our events. > > Should you—at any time before, during, or after one of our events—want > to raise an issue or discuss any CoC-related topic, please do not > hesitate to reach out to the organisers at the contacts below. > > - Arun Isaac, arunis...@systemreboot.net > - Fabio Natali, m...@fabionatali.com > > # Get involved > > Should you be interested in becoming a Guix London organiser, please let > us know. It'd be great to have you onboard. No previous Guix knowledge > is required. If you're interested (or simply want to know more), do not > hesitate to reach out to us! > > Similarly, if you want to present on any Guix-related topic at one of > our events, that's also great. We'd love to hear from you.
Re: Better support remote deployment
Ludovic Courtès writes: > That said, I wonder if this would really be more convenient than SSH’ing > into the target machine and running the commands right there. Perhaps > I’m missing something about the use case? The use case is to have a development host where packages are built and then pushed / installed on a remote that lacks the prerequisites to build the packages (e.g. checkout of development source repositories). I feel it would be a good fit for “guix deploy”, which has a similar set of assumptions but for deploying Guix System rather than mere package profiles. -- Ricardo
Re: Heisenbug
> What's a good way to debug this, please? in Geiser i usually get the proper error message: M-x geiser ,m (gnu tests reconfigure) ,reload > Where is my error? good question! silently swallowing errors and warnings should be something that is frown upon, and only ever employed when deemed really necessery. and we thought about it... twice. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “One cannot redistribute wealth without first becoming master of all wealth; redistribution is first and foremost monopoly.” — Anselme Bellegarrigue (ca. 1820–1890)
Re: Patch Review Flow
This is also interesting for me, since I have created my first patch for guix: adding libsurvive as a package. Alex
Re: Shutting down qa.guix?
Tobias Geerinckx-Rice writes: > Christopher Baines 写道： >> it's not the most cost effective setup > > Has this been explained in more detail before? Probably not, beid is currently a CPX51 Hetzner cloud server costing €65.33 a month. This has been useful as it's enabled scaling the resources dynamically, but it would be possible to reduce the costs and still have sufficient RAM/disk space by using a Hetzner server auction machine for example. It's not all about cost though, given the data service is one of the slow points of QA, if we want QA to get faster at giving feedback, it's probably important to not try and cut costs on this part of the system. signature.asc Description: PGP signature
Re: Why bash-minimal is part of sbcl package
Pan Xie skribis:
> Hello
>
> I find this interesting thing but I don't have an explanation. When query the
> "references" of my Gnu Store item "sbcl", it shows that sbcl references
> bash-mininal, as the following output shows:
>
> # guix gc --references /gnu/store/sbbp9nvslqcf3bmcnz5wgxf2qpsi757
> /gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib
> /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35
> /gnu/store/mzx7j93w5szyzrgnql8dqhqdgjh6si02-mpfr-4.2.0
> /gnu/store/nl194qnq5lhjxpfwcs15xqihnfqif335-zstd-1.5.2-lib
> /gnu/store/sbbp9nvslqcf3bmcnz5wgxf2qpsi757i-sbcl-2.3.7
> /gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16
> /gnu/store/ybadavwz1z9kmxanqy3siw38lnkwnkrp-gmp-6.2.1
>
> However when I look into sbcl's package definition, there is no bash-minimal
> as
> its input. I can use guix graph find a path from sbcl to bash-minimal:
>
> # guix graph --path sbcl bash-minimal
> sbcl@2.3.7
> texlive-updmap.cfg@66594
> texlive-scheme-basic@66594
> texlive-collection-basic@66594
> texlive-bin@20230313
> cairo@1.16.0
> bash-minimal@5.1.16
>
> bash-minimal is indeed one of cairo's package input. However cairo also has
> inputs like ghostscript and libspectre, which sbcl does not reference.
>
> "guix size sbcl" also reports bash-minimal is part of sbcl package, and "guix
> pack sbcl" will include bash-minimal in its final tarball.
>
> So the question is, which part of sbcl's package definition tells Guix it need
> to add bash-minimal as part of sbcl? Is there a practical method to figure
> that
> out?
Hi.
It looks like there are some contrib libraries of sbcl that need
a shell, which is why the bash-minimal available in the build
environment is referenced by some files in the sbcl package.
I guess we should list bash-minimal explicitly in the inputs...
--8<---cut here---start->8---
$ grep -R bash-minimal $(guix build sbcl)
grep:
/gnu/store/yqqjrhap1jp0aqs5p7xs5j13z0nza1zj-sbcl-2.3.7/lib/sbcl/contrib/sb-executable.fasl:
binary file matches
grep:
/gnu/store/yqqjrhap1jp0aqs5p7xs5j13z0nza1zj-sbcl-2.3.7/lib/sbcl/contrib/asdf.fasl:
binary file matches
grep:
/gnu/store/yqqjrhap1jp0aqs5p7xs5j13z0nza1zj-sbcl-2.3.7/lib/sbcl/contrib/sb-aclrepl.fasl:
binary file matches
grep:
/gnu/store/yqqjrhap1jp0aqs5p7xs5j13z0nza1zj-sbcl-2.3.7/lib/sbcl/contrib/uiop.fasl:
binary file matches
/gnu/store/yqqjrhap1jp0aqs5p7xs5j13z0nza1zj-sbcl-2.3.7/share/sbcl/contrib/asdf/pull-asdf.sh:#!/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/sh
-e
/gnu/store/yqqjrhap1jp0aqs5p7xs5j13z0nza1zj-sbcl-2.3.7/share/sbcl/contrib/asdf/asdf.lisp:
#+os-unix (string
`("/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/sh" "-c"
,command))
/gnu/store/yqqjrhap1jp0aqs5p7xs5j13z0nza1zj-sbcl-2.3.7/share/sbcl/contrib/asdf/asdf.lisp:
#+os-unix ,@'(ext:run-program
"/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/sh"
:arguments `("-c" ,%command))
/gnu/store/yqqjrhap1jp0aqs5p7xs5j13z0nza1zj-sbcl-2.3.7/share/sbcl/contrib/asdf/uiop.lisp:
#+os-unix (string
`("/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/sh" "-c"
,command))
/gnu/store/yqqjrhap1jp0aqs5p7xs5j13z0nza1zj-sbcl-2.3.7/share/sbcl/contrib/asdf/uiop.lisp:
#+os-unix ,@'(ext:run-program
"/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/sh"
:arguments `("-c" ,%command))
/gnu/store/yqqjrhap1jp0aqs5p7xs5j13z0nza1zj-sbcl-2.3.7/share/sbcl/contrib/sb-aclrepl/repl.lisp:
(sb-ext:run-program
"/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/sh" (list
"-c" string-arg)
/gnu/store/yqqjrhap1jp0aqs5p7xs5j13z0nza1zj-sbcl-2.3.7/share/sbcl/contrib/sb-executable/sb-executable.lisp:
"#!/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/sh --
/gnu/store/yqqjrhap1jp0aqs5p7xs5j13z0nza1zj-sbcl-2.3.7/share/sbcl/contrib/sb-posix/posix-tests.lisp:
(stat-2 (sb-posix:stat
"/gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16/bin/sh"
--8<---cut here---end--->8---
signature.asc
Description: PGP signature
Why bash-minimal is part of sbcl package
Hello I find this interesting thing but I don't have an explanation. When query the "references" of my Gnu Store item "sbcl", it shows that sbcl references bash-mininal, as the following output shows: # guix gc --references /gnu/store/sbbp9nvslqcf3bmcnz5wgxf2qpsi757 /gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35 /gnu/store/mzx7j93w5szyzrgnql8dqhqdgjh6si02-mpfr-4.2.0 /gnu/store/nl194qnq5lhjxpfwcs15xqihnfqif335-zstd-1.5.2-lib /gnu/store/sbbp9nvslqcf3bmcnz5wgxf2qpsi757i-sbcl-2.3.7 /gnu/store/v9p25q9l5nnaixkhpap5rnymmwbhf9rp-bash-minimal-5.1.16 /gnu/store/ybadavwz1z9kmxanqy3siw38lnkwnkrp-gmp-6.2.1 However when I look into sbcl's package definition, there is no bash-minimal as its input. I can use guix graph find a path from sbcl to bash-minimal: # guix graph --path sbcl bash-minimal sbcl@2.3.7 texlive-updmap.cfg@66594 texlive-scheme-basic@66594 texlive-collection-basic@66594 texlive-bin@20230313 cairo@1.16.0 bash-minimal@5.1.16 bash-minimal is indeed one of cairo's package input. However cairo also has inputs like ghostscript and libspectre, which sbcl does not reference. "guix size sbcl" also reports bash-minimal is part of sbcl package, and "guix pack sbcl" will include bash-minimal in its final tarball. So the question is, which part of sbcl's package definition tells Guix it need to add bash-minimal as part of sbcl? Is there a practical method to figure that out?
