Re: Golang mudules to follow common grouping
Hi, Sharlatan Hellseher writes: > Hi Guix! > > I've noticed the number of Golang packages start growing. I expect more > packages > to be reviewed and merged by quick check of Issues. > > I think it's time to split (gnu packages golang) into some logical groups, see > Python, Lisp for example. > > - golang-web > - golang-check > - golang-build > - golang-compression > - golang-crypto > - golang-xyz > - golang-... > > Thoughts? This sounds good to me. Beware of correctly migrating the copyright lines though... these can be annoying to move. -- Thanks, Maxim
[PATCH] doc: Mention the responsibilities that blocking comes with.
Hello!
This is a heads-up regarding a modification to or contributing
guidelines I am considering to make:
Maxim Cournoyer writes:
> * doc/contributing.texi (Commit Access): Mention that blocking comes with
> extra responsibilities.
>
> Change-Id: I27cafcb351f68057b7882198e72e9bf66ccc1262
> ---
> doc/contributing.texi | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/doc/contributing.texi b/doc/contributing.texi
> index 864190b119..082a288704 100644
> --- a/doc/contributing.texi
> +++ b/doc/contributing.texi
> @@ -2030,7 +2030,11 @@ Commit Access
> consensus and make decisions based on consensus. To learn what
> consensus decision making means and understand its finer details, you
> are encouraged to read
> -@url{https://www.seedsforchange.org.uk/consensus}.
> +@url{https://www.seedsforchange.org.uk/consensus}. The project uses the
> +@samp{Requiring people who block to help find solutions} block variant,
> +which means a participant wishing to block a proposal bears a
> +special responsibility for finding alternatives and proposing ideas/code
> +to resolve the deadlock.
>
> The following sections explain how to get commit access, how to be ready
> to push commits, and the policies and community expectations for commits
I'll leave it open for 2 weeks to let some time for people to voice any
opinions. If you have something to say about it, now is a good time!
--
Thanks,
Maxim
Re: Opportunity For Guix: RFI Areas of long-term focus and Prioritization
Hi jgart, "jgart" writes: > Hi Guixers, > > Just reposting this chat message from Ryan Prior over #guix for anyone > interested: > >> The US Federal government has an RFI open on "Areas of long-term > focus and Prioritization". They're looking for 10 page briefing memos > on supporting memory-safe languages, strengthening software supply > chains, sustaining FLOSS, behavioural/economic incentives to secure > the OSS ecosytem, or other related ideas. > Sounds like an interesting opportunity for Guix hackers > > https://cloudisland.nz/@freakboy3742/110969575789548640 > > I don't have the time currently to submit an RFI on behalf of GNU Guix but > maybe someone else is interested in this opportunity? Thanks for sharing, I've tried my luck. My RFI reply was about strengthening free software distribution supply chain via GNU Guix and GNUnet. -- Thanks, Maxim
Golang mudules to follow common grouping
Hi Guix! I've noticed the number of Golang packages start growing. I expect more packages to be reviewed and merged by quick check of Issues. I think it's time to split (gnu packages golang) into some logical groups, see Python, Lisp for example. - golang-web - golang-check - golang-build - golang-compression - golang-crypto - golang-xyz - golang-... Thoughts? -- … наш разум - превосходная объяснительная машина которая способна найти смысл почти в чем угодно, истолковать любой феномен, но совершенно не в состоянии принять мысль о непредсказуемости.
Re: core-updates invites to an ungrafting party
Hi John, John Kehayias writes: > Hi Maxim et al, > > On Sun, Oct 08, 2023 at 11:12 AM, Maxim Cournoyer wrote: > >> Hello Guix! >> >> The core-updates branch is still alive, and has accumulated (or plans >> to) a few changes that cause world-rebuilds, such as fixes to >> git-minimal (bug#65924) as well as docbook improvements (bug#65479) and >> fixes to the build systems so that deep input rewriting works as >> intended (bug#65665). >> >> I think we could also batch ungrafting of all grafted packages, to make >> the most out of this complete rebuild. >> > > That sounds good, we have suddenly got a bunch of grafts deep in the > dependency tree. > > Speaking of which, I was planning to at least ungraft libx11 and > libxpm, recipients of recent grafts for security reasons, on a > forthcoming mesa-updates branch. I'm just waiting for the next point > release of mesa, since 23.2.1 is actually the first release where > typically a first .1 release is considered the start of the stable > series. (Though 23.2 has had a long release candidate time.) > > So, what are we thinking of the time to build/merge core-updates? I > was hoping to do some ungrafting and updating in the mesa-related > ecosystem this week, depending on upstream. I should be able to drive this merge in a speedy manner, since I have a lot of time at the moment. I'm hopeful it could be merged into master in a month time (so, approximately mid-November). > I'll start a separate thread soon to ask for what patches to include > there that I don't already know about, but I'm happy to include > similar scope ungrafting if that makes sense before core-updates. To keep things easy to follow and avoid duplicating efforts, I'd keep most ungrafting to core-updates, unless those pertaining to other teams such as mesa. -- Thanks, Maxim
Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
On 10/2/23 5:24 AM, Wilko Meyer wrote: - Where solicitations to complete the survey are broadcast is very important. E.g. if we only send it to guix-dev, this skews the responses to questions like "where do you talk about Guix". Definitely, I'm not entirely sure on how to solve this; publishing surveys on as many channels that seem fitting could maybe mitigate this? Then again the selection of communication channels is highly subjective as well. I don't think we have to be very selective about where to broadcast the survey. I think the answer is: anywhere Guix people hang out or anyone feels it might be useful to do so. I think the only danger here is missing some popular hangout spots due to ignorance of their existence. We should enumerate them to ensure we catch them all. - When soliciting responses to the survey, it's very important to set expectations about the survey in the solicitation. It is important to briefly describe what the survey is like and how long the survey will take. Without this, some people will have uncertainty about what they're committing to and not even try. - The survey should endeavor to remain on the shorter end; many will not complete longer surveys. This is another good reason to start with a narrow focus on questions regarding contributions instead of a general survey. - Does the survey need translation to eliminate language barriers? Most FLOSS surveys I've looked at were english only; which comes with a certain language bias. Realistically I'd say that, given a survey may contain free form questions, translation also seems to be a resource issue when it comes to analyzing the results. Does the GNU project have a "general translation" team? Maybe some of our Guix community members who speak multiple languages would be willing to translate the survey into their primary language? - The survey should use a uniform measurement system throughout. Don't use scales with different magnitudes in different questions, and don't suddenly invert whether higher is better or worse. Good point, this also means that questions should be asked in a way, that they can be answered using the same metrics/scale? I think that's the idea and should be the rule for which there are exceptions. - As you've already mentioned, free-form questions are very difficult to quantify, and I think we should use them with caution. Communities rooted in philosophical values, as Guix is, have impassioned people and resolving a large number of free-form responses to a quantitative statement may be difficult. My approach to free form questions is to, on one hand try to quantify trends (things that are mentioned often, key topics that are mentioned), on the other try to derrive actionable items/issues from them that can be worked on. Quantifiying qualitative responses is cumbersome, and as you've also pointed out, quite difficult; but identifying trends/key topics and maybe actionable items/issues from those could work. WDYT? My opinion is that we should not do free form questions for this first time. We're new at this, we have enough topics to cover, and the topics we are covering seem to cause a lot of discussion (that's good) which could lead to a lot of text to read through. - Up front, it may be difficult to identify all the root-causes of something the project wants to know about. Instead of trying to infer these, ask the questions directly. E.g. instead of questions about liking crunchy vegetables, orange vegetables, and root vegetables, ask whether they like carrots. However, if you think you have some idea of the root-causes, you can ask those as well to see if the correlation you think exists does. If we've a first draft of a prospective, narrowed-down on contributions, survey, the questions should probably be benchmarked against these criteria. I revisted my loose collection of survey questions I posted earlier on here and realized that I probably have to rephrase a vast majority of those, to be consistent with this. - You may want to ensure the survey has "marker questions" which clearly categorize your responder for you to make it easier to make the statements you'd like to make. E.g. if you're interested in analyzing what vegetarians vs omnivores think of carrots, ask that so you don't have to try and infer it later. I'll revisit the original thread on how to decrease cognitive overhead for contributors to see what good markers could be. With a grain of salt, I think we should figure out ways to identify participants that: - were contributors to guix before but stopped contributing Maybe: (1) Have you made contributions to Guix in the past? This is our marker question. combined with: (2) How many contributions to Guix per month would you estimate you've made in the past year? (identify ranges we're interested in) This is a dimension that would be useful to hav
Re: IDEA: missing-tests-pypi-error? condition
Hi, "jgart" writes: >> You want `info -f doc/guix.info`. > > Ah yes, I actually used that flag once before and had forgotten it... FWIW, it works for me even without '-f'. -- Thanks, Maxim
Re: Need people to help with kernel updates
Hi Leo, Leo Famulari writes: > Yes, the hashes of the kernel source code and linux-libre's "deblobbing" > scripts have to be updated. I have some scripts that fetch and calculate > the hashes (attached). Thanks for sharing these scripts with me, I've had a look into them to get familiar with them & so far they seem pretty useful! > I'm not a kernel developer or expert. The upstream defaults for kernel > 'settings' are sensible. We usually differ from the defaults by enabling > support for lots of hardware. Sounds reasonable, supporting as much hardware as possible seems feasible for a generic config for a kernel build. > My impression is that x86_64-linux is by far the most popular platform > for Guix users, and then aarch64-linux, and then the rest. > > Architectural support is a problem of the type "What came first: the > chicken or the egg?" So, if anyone wants to improve support for these > other architectures, you'll be making an egg from scratch, in the hope > that people will start using the kernels :) Yes, imho we're still a few years away from seeing more RISC-V systems. In terms of ARM, I do see some u-boot packages for SBCs in bootloaders.scm, so I assume people are using them, but I agree that x86_64 should have by far the biggest share. > I invite you to choose, email or IRC :) Mail sounds good to me! (I'm rather sporadically active on IRC, so mail usually is a better bet) > To summarize, this work needs regular but brief attention. There's not > much feedback from the community, so we do our best and make sure the > basics work before pushing (reboot and connect to the internet). I'm > eager to help grow the community of people working on this, and can help > answer questions and give advice about things like the configs. Thank you for this. I've seen the recent thread on making linux-libre 6.5 the default kernel[0] and will have some time at hand later on today. I could try to prepare a patch set doing this to get more familiar with the process, which would then need a review. WDYT? [0]: https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00027.html -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Making linux-libre@6.5 the default kernel
On Mon, Oct 9, 2023, at 03:20, Ada Stevenson wrote: > So, to make things clear, the delay in making 6.5 the default kernel is > in part because you lack sufficient support in the case that things go > wrong or some urgent change needs to be pushed? There's almost never anything wrong, but I haven't even had the time to download the upstream updates, calculate the hashes, prepare patches, push to a staging branch, wait for results from CI, then push to master. Or to put it another way, I haven't wanted to use the time I have available.
Re: performance issue with TeX Live
Hello, Emmanuel Beffara writes: > De Nicolas Goaziou le 13/09/2023 à 14:39: >> It may be interesting to compare location and contents of the ls-R files >> in both installations. > > I tried to explore this but I see no reason why the ls-R files would be > ignored I spent some time exploring this, but I cannot tell either. Though, it is plausible that the problem is related to ls-R files, or, more accurately, the reason why they are not read. Note that those files are not installed in every tree. For example `texlive-updmap.cfg' doesn't create any so, IIUC, any TeX Live tree used as a build input require to navigate the file system. I also tried to tweak TEXMFDBS and TEXMF values in "texmf.cnf" from "texlive-libkpathsea" package, but couldn't find a sweet spot. At the moment, I'm running out of ideas, and time. > I do want to contribute to a solution, because right now texlive is > practically unusable in Guix. FWIW, I use modular TeX Live regularly, so "unusable" is probably a bit strong. However, I agree the current situation is frustrating. Regards, -- Nicolas Goaziou
Re: IDEA: missing-tests-pypi-error? condition
> You want `info -f doc/guix.info`. Ah yes, I actually used that flag once before and had forgotten it... Thanks!
Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
To counter this point: > But the present organisation looks defunct. There’s no strong leadership. A lack of central-ised leadership is a good thing If this is their only reason for calling the organisation defunct then this point is invalid however I am unsure if this is where the critique lies In that spirit i am pondering how something akin to central leadership mandating such a change occur in this environment. The biggest concern I can think of about doing something like this and degrading existing workflows would be alienating developers who prefer the existing methods and perhaps had a hand in making them what they are currently. A lot of people in a company would likely grumble about such a mandate as a way of getting over it. I guess here some examples: - consensus could be tried for in a formal polling process and it be worked on post consensus - one could also do the work and propose it then to dispell any concerns of achievability but at the risk of it not being used - one could also try building an approach in which the project would gradually fade into a state where both options are viable, and then perhaps, should consensus be reached then, the project could fade into a state with solely the changed tooling example stages: - current tooling - git repo-s mirrored, chat channel-s bridged - facilitate project interaction on new git hosting method ( issues, mr-s, ...) - fade towards solely using the consensus desired tooling I think consensus is more suitable to large decisions than voting when maintenance of the group boundary ( guix devs) and maintenance of the number of states ( a set of tooling with only one tool per use case ( savannah or gitlab, matrix or irc, ...)) is desired an issue like this could cause a split and sometimes that is ok but when that is undesirable, if the one resulting state is formed then a continuous discussion process to form this one state into something which has the least cummulative "friction" is desirable. whilst this may be slower initially than a top down mandate, those adapting to a top down mandate would have to adjust from what they are most comfortable causing slow down in the future page 154 of this document presents a diagramatic representaion of a consensus process: https://www.radicalroutes.org.uk/wp-content/uploads/woocommerce_uploads/2022/10/How2WorkersCo-op2019A5Lo-Res-pslouz.pdf In defence of meta discussion, i think meta discussion is really just discussion where an assumed component is brought back into discussion. I am new to the project as well, in my experience I have found the mailing lists to be quite fun, i havent submitted any patches to guix yet so i can not comment on that perhaps an alternative could be mailing list propaganda to garner the excitement that currently surrounds something like discord one trend i have seen with guix is the tendency to use existing technology with extensions to achieve ones means instead of using/ developing a technology which includes all desired features as standard, maybe this is a function of the older style the irc and mailing lists are both publically logged and the system-s seem cohesive the logs on irc are harder to read than scrolling up in something like matrix, also the lack of non-text media can be tricky On Mon, 9 Oct 2023 at 11:29, Tao Hansen wrote: > > Hello, I hope it's ok I'm replying to this email as a follow-up to > decreasing the cognitive overhead for new users. I'm also brand new to > the Guix community and ecosystem. I wanted to share a perspective from a > user on a Lemmy instance who wrote why the Guix ecosystem was not > friendly enough to meet them where they were, a person in their early > twenties. I'd like to suggest approach their criticism with compassion > and open-mindedness. > > @velox_vulnus writes at https://lemmy.ml/comment/4625080 > > > I don’t like the vibe of ageism against young people that is > > associated with GNU. What is also frustrating is their reluctance to > > improve their infrastructure. > > > This reason is kind of terrible, I admit, but they could choose to > > move over to Matrix over IRC, but they choose to be willingly open to > > spam over having a proper, documented chat channel. I am also > > reluctant to use my personal mail, for the mailing list. Matrix gives > > me that anonymity, without also having to geopardize on participation. > > NixOS is on Matrix, and that’s why I like it. I know Matrix isn’t > > perfect, but it the better choice between any other messenger. > > This user could use an email address dedicated to Guix discussion but > really I can only agree that sticking to IRC, which requires a lot of > effort to keep a history log and more effort to host a bouncer makes > contributing to synchronous discussions difficult. I, myself, am only > active on the community-run Matrix server and another, less free, > channel because the overhead is just too high. > > > They could choose to remove non
Re: [guix_milan] Guix Milan first meetup
Hello everyone, Just a quick reminder for tomorrow's Guix meetup at the LiQuido Rooftop Bar. Date: Tuesday, 10 October, 18:30 CEST Location: iQ Hotel, via Giovanni Battista Pirelli 5 - Milan Mobilizon page: https://mobilizon.fr/events/92c351df-66bb-4e81-9180-6e8ceec60196 How to find us: 1. enter the iQ Hotel, via Giovanni Battista Pirelli 5 - Milan 2. take the lift (next to the reception) to the LiQuido Rooftop Bar 3. look for the table with the Guix logo on it Kind regards, Andrea
Re: IDEA: missing-tests-pypi-error? condition
Hi jgart, > Is there a way to open the guix manual directly? > > Not sure why info opens a "main page" with all my texinfo manuals when > I give it doc/guix.info as an argument... 🦆 You want `info -f doc/guix.info`. HTH, -- Josselin Poiret signature.asc Description: PGP signature
Re: Need people to help with kernel updates
El 9/10/23 a las 1:22, John Kehayias escribió: Hi Leo, On Sat, Oct 07, 2023 at 02:04 PM, Leo Famulari wrote: Hello, For a few years, I've been handling updates of the linux-libre kernel by myself. Now I want some more people to help with this. Just wanted to say thanks for this work that goes on mostly behind the scenes; I've never had any kernel hiccups related to Guix. Let's hope I didn't just jinx that, but our rollbacks and generation selection at boot actually make it a lot less painful to experiment here. Same here, thanks a lot, Leo :) OpenPGP_0x0AB0D067012F08C3.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Failed to build in QA
This is probably down to a top level circular dependency. In particular, trying to paraview to compute the version to form part of the native-search-path at the top level causes problems. I'm wondering why it builds fine locally but causes problems in QA have you any pointers what might be the difference? Making openfoam have LD_LIBRARY_PATH as a search path seems like the incorrect use of search paths though, since you're searching for something in the same package. Replacing this with wrapping would be an improvement, although still I'm unsure why LD_LIBRARY_PATH would need setting in this case Hmm maybe you are right, will try to wrap the binaries instead... OpenPGP_0xC375C6AF05125C52.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: How to properly package umbrella projects?
Side note: different subprojects have different licenses. That would not factor into my decision. Well, apart from adding a ‘license’ argument to the procedure, but there are other missing arguments (synopsis, description) from that rough example anyway. Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity.
Re: How to properly package umbrella projects?
Hi Horse, On 2023-10-08 7:52, Unstable Horse wrote: short question: a program I'm writing depends on gst-plugin-gtk4 which is a part of gst-plugins-rs[0]. What's the most appropriate way to package such a project: In the majority of cases, I would say: a single package (here, ‘gst-plugins-rs’) with multiple outputs. However. - This repository seems to be cleanly designed to efficiently(?) build only a single plug-in[1], rather than building all of them only to throw most away. Verify that, though. - This is Rust, with its associated Cargo dependency hell, and dependencies seem to be neatly declared[2] per-plug-in. I think it's wise to bite off only as much as you're currently willing to chew. For those reasons at least, I'd go for a single gst-plugin-rs-gtk4 package, written in this style: (define* (gst-plugin-rs name (native-inputs '()) (inputs '()) (cargo-inputs '()) (cargo-development-inputs '())) …) (define gst-plugin-rs (gst-plugin-rs "gtk4" #:inputs (…) …) You'll have to do some work in gst-plugin-rs to change the default of "auto" for each unwanted plug-in. Side note: different subprojects have different licenses. That would not factor into my decision. Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity. [0]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs [1]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/main/meson_options.txt [2]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/main/video/gtk4/Cargo.toml
[PATCH cuirass] doc: Fix evaluation hook URL example.
* doc/cuirass.texi (Invocation): Fix URL in the example of the push hook.
---
doc/cuirass.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/cuirass.texi b/doc/cuirass.texi
index 69c58f7..00f00c1 100644
--- a/doc/cuirass.texi
+++ b/doc/cuirass.texi
@@ -561,7 +561,7 @@ example with a command along these lines:
@example
wget --post-data="" -O /dev/null \
- https://cuirass.example.org/@var{jobset}/hooks/evaluate
+ https://cuirass.example.org/jobset/@var{jobset}/hook/evaluate
@end example
You would typically run that command as a @dfn{push hook} on the servers
base-commit: e159c74ca6f666a32eb9b778067e00941a4bfa36
--
2.42.0
Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
Hello, I hope it's ok I'm replying to this email as a follow-up to decreasing the cognitive overhead for new users. I'm also brand new to the Guix community and ecosystem. I wanted to share a perspective from a user on a Lemmy instance who wrote why the Guix ecosystem was not friendly enough to meet them where they were, a person in their early twenties. I'd like to suggest approach their criticism with compassion and open-mindedness. @velox_vulnus writes at https://lemmy.ml/comment/4625080 > I don’t like the vibe of ageism against young people that is > associated with GNU. What is also frustrating is their reluctance to > improve their infrastructure. > This reason is kind of terrible, I admit, but they could choose to > move over to Matrix over IRC, but they choose to be willingly open to > spam over having a proper, documented chat channel. I am also > reluctant to use my personal mail, for the mailing list. Matrix gives > me that anonymity, without also having to geopardize on participation. > NixOS is on Matrix, and that’s why I like it. I know Matrix isn’t > perfect, but it the better choice between any other messenger. This user could use an email address dedicated to Guix discussion but really I can only agree that sticking to IRC, which requires a lot of effort to keep a history log and more effort to host a bouncer makes contributing to synchronous discussions difficult. I, myself, am only active on the community-run Matrix server and another, less free, channel because the overhead is just too high. > They could choose to remove non-Libre JS from GitLab, Sourcehut or > Gitea, or at least come with a new source hosting platform, but they > choose not to. I also have a hard time with the insistence on the "Old Ways" as somehow more pure, more legitimate than the new. There's some sense of the expression, "You kids get off my lawn!" And the decentralized nature of sending Git patches by email, which I still have not ventured to try, makes it hard to *discover* Guix development in a single place. A user needs to go to any one of the mailing lists, pull the Git repo or browse Savannah or the issue frontend for bugs and new features they might be interested in, and generally have an idea of what they want to be looking for to find it. Discovery by serendipity is missing. When using the mailing list, even figuring out how to reply to the right thread here in Gnus is trying and I'm not even sure if I've done it right: people change the subject line, threads grow so large they become unmanageable; I had to make sure I CC'd the whole list instead of just reply to this mail's author. I still haven't figured out how to stick guix-devel in my Gnus home screen: my starting view is always empty and I have to remember the shortcut to get to the gigantic overview of every Gmane list (this isn't a cry for help). There's more to their post: I encourage folks to check it out. We have the FOSS technology to tackle a lot of these critiques and bring in a whole new wave of contributors. We have fully open Git forges and modern messaging protocols to make a brand new developer-friendly Guix a reality.
How to properly package umbrella projects?
Hi Guix, short question: a program I'm writing depends on gst-plugin-gtk4 which is a part of gst-plugins-rs[0]. What's the most appropriate way to package such a project: 1. A package just for gst-plugin-gtk4, or 2. A package for gst-plugins-rs that installs all of its subprojects? Side note: different subprojects have different licenses. [0]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs
Re: performance issue with TeX Live
Hello, De Nicolas Goaziou le 13/09/2023 à 14:39: > Emmanuel Beffara writes: > > > I am facing a severe performance issue with TeX Live: compilation of any > > document is an order of magnitude slower with a Guix installed system as > > compared to a manual installation. Is anyone confronted to this phenomenon, > > or > > is there a way to fix this ? > > I also experienced a noticeable slowdown; I don't know how to fix it yet. [...] > A ls-R file is generated during profile creation (see > `texlive-font-maps' function in "guix/profiles.scm") but it seems it is > not read. > > It may be interesting to compare location and contents of the ls-R files > in both installations. I tried to explore this but I see no reason why the ls-R files would be ignored and I don't know how to explore this further. I do want to contribute to a solution, because right now texlive is practically unusable in Guix. -- Emmanuel
Re: Making linux-libre@6.5 the default kernel
Hi! Hi Leo! :) The reason is that I haven't had enough time to make these changes lately, and for a while I have been the only person updating the kernel in Guix. That makes a lot of sense. I had no idea - the reason I came to the mailing list was to figure out what everyone's doing, and that's proved very fruitful. Thank you for all of your work :) So, to make things clear, the delay in making 6.5 the default kernel is in part because you lack sufficient support in the case that things go wrong or some urgent change needs to be pushed? That makes sense, and I'm sorry it is this way. :/ I'd like for more people to join the effort, and there's some info about that subject here: https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00079.html I don't think I'll be of much help - I'm pretty unfamiliar with kernel configuration, and I currently have a few Guix packages that I'm working on that are taking up most of my Guix time. However, I wish you the best, and I do hope that you're able to muster some extra hands from the community. During the university holidays I'll see if I'm able to lend some help - even if it isn't full-time! Thanks! Ada (adanska) On 10/8/23 6:17 PM, Leo Famulari wrote: On Tue, Oct 03, 2023 at 11:05:40AM +, Ada Stevenson wrote: Hi Guix! Hi! I understand why that may be; the commit is quite new, and pushing new kernel versions on everyone is a pretty big thing. I just want to know what the timeline on this sort of thing is - when can we expect the new 6.5 kernel to become the default? Thanks for asking about this. The reason is that I haven't had enough time to make these changes lately, and for a while I have been the only person updating the kernel in Guix. I'd like for more people to join the effort, and there's some info about that subject here: https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00079.html OpenPGP_0x99A5BEE5B59C15DB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
