Re: GNU and GSoC
Hi, Having Guix be part of GSoC would be fantastic! I'd love to have the opportunity to be mentored. It would be exciting for Guix to receive some more attention, as well as showing people how fun it is to hack on :) Thanks, Ada On 2/23/24 7:38 AM, Pjotr Prins wrote: The GNU project is a GSoC org again. Last year Sarthak did a great job working on parameterization of Guix. It works, and you can try the code. See => https://guix.gnu.org/blog/2023/parameterized-packages-for-gnu-guix/ => https://blog.lispy.tech/ For this year GNU can propose projects again. We should suggest Guix, Mes and Hurd projects in the coming two weeks. Ping Gábor, Sarthak, Arun, Efraim or me if you are interested in co-mentoring an effort. Note that GSoC is competitive for orgs, mentors and students. It requires effort, but anyone who participates can attest it is rewarding. I have been doing this for more than 10 years. It is a great programme. Pj.
GNU and GSoC
The GNU project is a GSoC org again. Last year Sarthak did a great job working on parameterization of Guix. It works, and you can try the code. See => https://guix.gnu.org/blog/2023/parameterized-packages-for-gnu-guix/ => https://blog.lispy.tech/ For this year GNU can propose projects again. We should suggest Guix, Mes and Hurd projects in the coming two weeks. Ping Gábor, Sarthak, Arun, Efraim or me if you are interested in co-mentoring an effort. Note that GSoC is competitive for orgs, mentors and students. It requires effort, but anyone who participates can attest it is rewarding. I have been doing this for more than 10 years. It is a great programme. Pj.
Re: You're invited to the first patch review session!
Hello! Le jeudi 22 février 2024 à 15:53 -0800, Vagrant Cascadian a écrit : > On 2024-02-22, Steve George wrote: > > We're going to run some online patch review sessions. The first one > > is on *Thursday, 7th March* and you can sign-up here: > > > > https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024 > > Hoping to make it for some of these, thanks for doing it! > > One small point is if people could include the scheduled times in UTC > in > addition to "arbitrary" timezones. It is much easier to compare > against > UTC (especially because it does not do daylight savings time) if you > don't happen to be in one of the specified timezones. :) I believe this ical file represents the event accurately (for March 7), but I’m not the organizer. Best regards, Vivien BEGIN:VCALENDAR PRODID:-//Ximian//NONSGML Evolution Calendar//EN VERSION:2.0 METHOD:PUBLISH BEGIN:VTIMEZONE TZID:Europe/Paris X-LIC-LOCATION:Europe/Paris BEGIN:DAYLIGHT TZNAME:CEST TZOFFSETFROM:+0100 TZOFFSETTO:+0200 DTSTART:19810329T02 RRULE:FREQ=YEARLY;UNTIL=20370329T01Z;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZNAME:CET TZOFFSETFROM:+0200 TZOFFSETTO:+0100 DTSTART:19961027T03 RRULE:FREQ=YEARLY;UNTIL=20361026T01Z;BYDAY=-1SU;BYMONTH=10 END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:17ffaaac680917ea4c9e1221f0788ff5d8f07d99 DTSTAMP:20240222T054943Z DTSTART;TZID=Europe/Paris:20240307T18 DTEND;TZID=Europe/Paris:20240307T192500 SEQUENCE:2 SUMMARY:Guix Patch Review Sessions 2024 TRANSP:OPAQUE URL:https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024 DESCRIPTION:Each session is run at 18:00 CET (Paris)\, 17:00 BST (London)\, 13:00 EST (New York) and we'll generally try to:\n\n— Introduction to someone's patch review process (30 mins)\n— Patch review together (1 hour)\n\nThis will be an informal\, friendly and interactive environment where anyone can ask questions\, show how they do something or make suggestions. It's on-line which restricts things a little\, but the goal is to be interactive and learn together.\n\nIf there are particular topics or questions you'd like to explore please add them below. CLASS:PUBLIC CREATED:20240223T060822Z LAST-MODIFIED:20240223T060822Z X-EVOLUTION-CALDAV-ETAG: 5d7e787386622c655ff0945084556a2a576d778a4044080867938dd45fabee5f END:VEVENT END:VCALENDAR
Re: Feedback of the GNU Guix manual
Hi Matt, Matt writes: > On Wed, 21 Feb 2024 18:20:19 +0100 Maxim Cournoyer wrote --- > > > Thanks for the follow-up. > > Thank you! Seems like we were looking at it at about the same time :) > > > Like Josselin, I prefer to keep the mention that the tarball archive > > includes the transitive dependencies of Guix (it's explicit; "archived > > binaries" is a bit vague to my taste). > > I tried to address that in the diff I wrote up before I saw your message. I > agree, "archived binaries" is awkward. I changed it in my update. > > > I've pushed your adjusted suggestions with commit ec9c8b0c1a. > > Cool. I'll work on the next item in the list. Please let me know if there's > something more regarding this item based on the v2 update. Great, sounds good. I've checked your v2 update, but opted to keep things as they are (following my own edition of your initial work, which was committed). Thank you for your efforts! -- Maxim
Re: Proposal to turn off AOT in clojure-build-system
Hi Maxime! Maxime Devos writes: >>On Thu, Feb 22 2024, Andreas Enge wrote: >>> Am Thu, Feb 22, 2024 at 03:57:41PM +0100 schrieb Maxime Devos: Yes. It appears you are unfamiliar with (...) It also appears you are unfamiliar with (...) >>> >>> May I suggest to not make assumptions about what other people are familiar >>> with or not? There is no point in claiming that others are less knowledge- >>> able than you; they may know as much or even more than you >> >>Asking questions can avoid any such conclusions. It's my favorite >>thing. Here, I might have asked: "Do you know about...?" > > OK. I don’t think I’ll do that. Your sharp replies came off as harsh, which is unfortunate because you seem to bring points of technical merits. Please smooth out your interactions/communication style, to ensure it remains pleasant for everyone involved, taking these code of conduct items into account: * Demonstrating empathy and kindness toward other people * Being respectful of differing opinions, viewpoints, and experiences -- Thanks, Maxim
Re: You're invited to the first patch review session!
On 2024-02-22, Steve George wrote: > We're going to run some online patch review sessions. The first one is on > *Thursday, 7th March* and you can sign-up here: > > https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024 Hoping to make it for some of these, thanks for doing it! One small point is if people could include the scheduled times in UTC in addition to "arbitrary" timezones. It is much easier to compare against UTC (especially because it does not do daylight savings time) if you don't happen to be in one of the specified timezones. :) live well, vagrant signature.asc Description: PGP signature
You're invited to the first patch review session!
Hi We're going to run some online patch review sessions. The first one is on *Thursday, 7th March* and you can sign-up here: https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024 The background is that Guix has many fantastic contributions that are waiting to be reviewed and added to the archive. We have the QA system that does test builds, but each patch also needs to be evaluated and checked. Anyone can review patches, and reviews help to confirm that a patch is in good shape to be added to the archive. Doing patch reviews is also a great way to learn about Guix, the different packages and methods involved in packaging. To encourage new reviewers to step forward, and to have some fun we're going to run on-line patch review sessions. These will be informal, probably chaotic - but fun - with the aim that we learn as a group how to review packages. Each session will be hour 1:30 and they are rotating through the week, so there should be plenty of opportunities to come along. We're using the Guix London's Meet-up and the sessions run on Jitsi. We'll try and talk a bit about how to do reviews, and then we'll try and do some reviews, learning and asking questions together! Hope to see you there! Steve / Futurile
RE: Proposal to turn off AOT in clojure-build-system
>On Thu, Feb 22 2024, Andreas Enge wrote: >> Am Thu, Feb 22, 2024 at 03:57:41PM +0100 schrieb Maxime Devos: >>> Yes. It appears you are unfamiliar with (...) >>> It also appears you are unfamiliar with (...) >> >> May I suggest to not make assumptions about what other people are familiar >> with or not? There is no point in claiming that others are less knowledge- >> able than you; they may know as much or even more than you > >Asking questions can avoid any such conclusions. It's my favorite >thing. Here, I might have asked: "Do you know about...?" OK. I don’t think I’ll do that. Best regards, Maxime Devos.
RE: Proposal to turn off AOT in clojure-build-system
>Am Thu, Feb 22, 2024 at 03:57:41PM +0100 schrieb Maxime Devos: >> Yes. It appears you are unfamiliar with (...) >> It also appears you are unfamiliar with (...) >May I suggest to not make assumptions about what other people are familiar with or not? There is no point in claiming that others are less knowledge- able than you; they may know as much or even more than you, and still come to different conclusions. (And even if people were unfamiliar with something, I would object to this haughty tone and suggest a more pleasant way of making suggestions.) This is hypocritical, you are (somewhat implicitly) making assumptions on my (un)familiarity with good manners and (somewhat implicitly) claiming that I am less knowledges than you on good manners. Furthermore, you aren’t actually suggesting a more pleasant to formulate the message of the part you quoted. Also, I did not simply _assume_ that Steve was unfamiliar with transformation, I _concluded_ that Steve was likely unfamiliar by what they didn’t mention in their e-mails. Furthermore, the mere “likelihood” is included in the paragraph you quoted as part of the word “appears” – I did not claim that Steve is unfamiliar, I only claimed that it appeared to be the case, which is not the same thing. After all, perhaps Steve does know that such transformation exist but personally concluded them to not be a proper solution for some reason. In that case, now people know there is a disagreement on the role of transformations w.r.t. AOT and perhaps the source of the disagreement can be resolved, furthering knowledge and bring us closer to deciding on what the proper AOT default would be. You mention that other people might know more, but there is also a flipside to this – sometimes people know _less_. In this case, perhaps Steve simply did not know about transformations and the proposed use of transformations in combination with enabling AOT by default would be agreeable to Steve and as such perhaps an answer to the decision whether to enable AOT by default. As such, simply _assuming_ that Steve knew of transformations would be wrong, so I had to mention the option of transformations. I did not simply claim that Steve is less knowledgable than me, at most it could be said that I (implicitly) claimed that Steve is less knowledged than me on the relation between transformations and Clojure AOT problems, but even then, I included a qualifier “It appears that”, not “It is the case that”. The beginning “It appears you are unfamiliar with [...]” is simply a perfectly cromulent beginning of a sentence, not some assertion of superiority. >For instance concerning the topic at hand, knowing that users may transform packages as they wish to me seems to be independent of which default choice we should make for the distribution. It is not independent, see my previous e-mail where I explained how the existence of transformations turns some problems mentioned w.r.t. enabling AOT into non-problems. If you have a disagreement with that explanation, please actually say what the disagreement is instead of only saying that you disagree. The former might bring us closer to some collective decision on what the proper default behaviour is for Guix, the latter doesn’t, is almost useless and makes it look like you didn’t bother to read the ‘(...)’ part. While I suppose it is technically possible you have read the part ‘(...)’, given your response I simply don’t believe you did and hence I consider it fair to conclude that you are not familiar with the contents of the (...) part. Best regards, Maxime Devos
Re: Proposal to turn off AOT in clojure-build-system
Hey, On Thu, Feb 22 2024, Andreas Enge wrote: > Am Thu, Feb 22, 2024 at 03:57:41PM +0100 schrieb Maxime Devos: >> Yes. It appears you are unfamiliar with (...) >> It also appears you are unfamiliar with (...) > > May I suggest to not make assumptions about what other people are familiar > with or not? There is no point in claiming that others are less knowledge- > able than you; they may know as much or even more than you Asking questions can avoid any such conclusions. It's my favorite thing. Here, I might have asked: "Do you know about...?" Goodwill toward all, Felix
Re: Proposal to turn off AOT in clojure-build-system
Am Thu, Feb 22, 2024 at 03:57:41PM +0100 schrieb Maxime Devos: > Yes. It appears you are unfamiliar with (...) > It also appears you are unfamiliar with (...) May I suggest to not make assumptions about what other people are familiar with or not? There is no point in claiming that others are less knowledge- able than you; they may know as much or even more than you, and still come to different conclusions. (And even if people were unfamiliar with something, I would object to this haughty tone and suggest a more pleasant way of making suggestions.) For instance concerning the topic at hand, knowing that users may transform packages as they wish to me seems to be independent of which default choice we should make for the distribution. Andreas
RE: Proposal to turn off AOT in clojure-build-system
>> [...] >> > But, I would like to draw attention to this thread on Clojureverse as the >> > best source I could find: >> >Alex Miller is the main community manager for Clojure, and is a maintainer >> >of the core libraries, so his perspective is key. He notes that, AOT code >> >is tied to *specific versions of Clojure*: >> > >> > "AOT'ed code is that it is inherently the product of a particular version >> > of tthe Clojure compiler ... I would recommend NOT AOT compiling >> > libraries" [4] >> >> This reasoning does not follow – yes, it is tied to the Clojure version, so >> what? Guix automatically rebuilds dependents when the dependency (in this >> case, the Clojure compiler) changes. (...) >I think this preceding sentence is the heart of different assumptions between >us. >The Clojure packages we haave are for developers writing applications >(libraries and tools). The ecosystem has very few end-user applications [0]. >As a Clojure developer I can use the Clojure tools from Guix, and a few >libraries. We (and all the other distributions) have a miniscule portion of >the Clojure/Java library universe [1]. This leads to the following usage >scenarios: >1. A developer installs Clojure from Guix, and uses libraries from outside >Guix. They can install the JVM/Clojure and some common tools (like clj-tools-cli). They will use libraries from elsewhere, including their own. AOT compilation is a problem because of the issue of mixed AOT and non-AOT. >2. A developer installs a Clojure from outside Guix, uses libraries from >inside Guix This will cause problems because the Guix Clojure libraries will have been AOT'd by a different version of the compiler. It's also fairly common to install/use parallel versions of Clojure/jvm due to different deployment needs, this is likely to cause difficult to find bugs. My answer to (1) and (2) is: (a) About “install Clojure from outside Guix + use libraries inside Guix”: If these libraries are AOT: Don’t do that, then. If you mix-and-match binaries (in this case, .class files) different distributions, you are free to do so, but when (not if, when) things break, you get to keep the pieces. If these libraries are just the .clj files (not AOT) (which as I understand it is the standard situation): doesn’t seem a problem to me (see point (b)). Adding source from other places is one thing (probably ok), adding binaries is another (probably not ok, especially if unstable ABIs (see Clojure compiler) and mismatched versions (see hypotheses of 2.) are involved. (b) What is this “the issue of mixed AOT and non-AOT”? Do you have a source on this? Besides Clojure supposedly, I haven’t ever heard of such problems for any language – for example, there is no such issue with Guile and AFAIK not for Python. I haven’t heard of any such issues for the Common Lisp implementations either (though I haven’t checked), so this doesn’t seem like a “Clojure doesn’t do hygienic macros” issue. (c) Guix isn’t forcing anyone to use AOT’d libraries. If people really want to assist in murdering the climate (or its a situation where total cost of non-AOT is lower than AOT), they can unfortunately (*) simply do so applying a recursive transformation that adds #:aot? #false flags everywhere or whatever the exact argument is (**). Given that this transformation has some legitimate use cases, this transformation could even be a pre-canned procedure + transformation included in Guix itself (*) ‘unfortunately’ only applies to the first case. For the case in parentheses, replace by ‘fortunately’. (**) IIRC is wasn’t #:aot? but some other name, but that’s not really the point here. (d) If a deployment need multiple versions of Clojure, then just fix your deployment to make everything work with the latest version of Clojure. Or, if you for some reason don’t do that, just use a (recursive) transformation to change the version of the Clojure compiler used to match the Clojure that will be used in the particular deployment. (e) You can simply add missing packages to Guix as the need arises. >I can see the sense of compiling to byte code if it's an end-user application. >In that case we'd want to make the start-up as fast as possible. Your comments >seem to have this use-case in mind. >But, today there aren't any such end-user Clojure applications in Guix. That’s a shame. Hopefully that will change some day. Also, this is false, “clojure-tools” exists – developers are people too (I don’t care about the “_end_-user” distinction – surely developers want fast start-up as well). Also, I _don’t_ have that use case in mind – I have efficiency in general in mind, efficiency of the start-up is only a part of that. The point is: most likely you will want the application to have AOT code, and that library has dependencies. Furthermore, likely many of these dependencies are dependencies of other applications as well. Instead of redoing the compilation of N sha
Re: cannot boot after installation on VPS (via rescue system)
> > On one VPS of mine (which also happens to have Guix installed via > > rescue mode) the root is mounted from /dev/vda1. > > Out of curiosity: what's the hoster, please? https://rapiddc.pl/ It's a result of a long search for a decent Europe-based provider. I didn't choose any of the mainstream providers because of their ToS (even well-reputed Gandi had somewhat customer-hostile ToS; the requirement to purchase an insurance finally convinced me not to use them). 1984 was pretty fair but offered a DPA in horribly broken english (I still use them for non-business needs). The one I chose isn't perfect, either. As you can see, they have GDPR-incompliant Google spyware on their website (though it causes no legal risk to their customers) and they rely on nonfree JS. I couldn't find a provider who does everything perfectly so I chose based on priorities. From my PoV it's a domestic provider which also makes things easier for me (and possibly harder for others who'd like to use this message as some kind of recommendation). Good to see you solved your issue :) Wojtek -- (sig_start) website: https://koszko.org/koszko.html fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A follow me on Fediverse: https://friendica.me/profile/koszko/profile ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end) On Thu, 22 Feb 2024 08:25:57 +0100 Giovanni Biscuolo wrote: > > On one VPS of mine (which also happens to have Guix installed via > > rescue mode) the root is mounted from /dev/vda1. > > Out of curiosity: what's the hoster, please? pgp_WRV10AA06.pgp Description: OpenPGP digital signature
Re: cannot boot after installation on VPS (via rescue system)
Hi Saku!
Saku Laesvuori writes:
Now I'm trying to use it on two VPS from two different vendors, booted
in rescue mode, but after the installation (via bootstrap-guix.sh) when
I reboot the VPS I get the usual grub menu but the boot process suddenly
fails with this error (manually copied from web console, sorry for
possible typos):
[...]
>>
>> I'm not on Linode, I'm working on OVH and Hetzner VPSs
>
> I had to add "virtio_scsi" to initrd-modules to get Guix to boot on a
> Hetzner VPS. Maybe that could be the problem here, too?
Yes: you got it!
I asked Hetzner support to have the Guix installer ISO as "custom ISO"
and was able to do a guided install... and it (re)booted fine. The
first thing that got my attention was this line in the working
config.scm:
--8<---cut here---start->8---
(initrd-modules (append '("virtio_scsi") %base-initrd-modules))
--8<---cut here---end--->8---
...and it makes sense! [1]
I also missed that line in (info "(guix-cookbook) Running Guix on a
Linode Server") ;-(
I still have not tested that fix with my bootstrap-guix.sh installation
script, but I'm pretty sure it will work.
Thank you so much! Gio'
[1] I also need to enhance my qemu scripts needed for testing
--
Giovanni Biscuolo
Xelera IT Infrastructures
signature.asc
Description: PGP signature
Re: cannot boot after installation on VPS (via rescue system)
>>> Now I'm trying to use it on two VPS from two different vendors, booted >>> in rescue mode, but after the installation (via bootstrap-guix.sh) when >>> I reboot the VPS I get the usual grub menu but the boot process suddenly >>> fails with this error (manually copied from web console, sorry for >>> possible typos): >>> >>> [...] > > I'm not on Linode, I'm working on OVH and Hetzner VPSs I had to add "virtio_scsi" to initrd-modules to get Guix to boot on a Hetzner VPS. Maybe that could be the problem here, too? signature.asc Description: PGP signature
