Re: No default OpenJDK version?
I think the first step would be to target openjdk 9, since it already introduces quite a lot of changes compared to java 8. To do it, I would suggest to change the default jdk in the ant-build-system and maven-build-system, and see what is broken, if it can simply be updated without breaking dependents, or if it (and its dependencies) needs to be built with an older jdk. Some packages are bootstrap packages that are quite old and will never support a newer jdk. For some of them, we can simply specify a source/target level (not sure it's supported by the build-system yet), but I remember trying and a few need java 5, which is no longer a supported level. I have already added support for java modules in the ant-build-system, and I just pushed a few updates to some packages that could not previously be built with java 9. Le 20 avril 2024 19:19:37 GMT+02:00, Markku Korkeala a écrit : >On Tue, Apr 16, 2024 at 10:37:30PM +0200, Julien Lepiller wrote: >> Currently, most java packages use the implicit jdk from the build system >> (ant- or maven-build-system), which is… icedtea@8. We still have quite a lot >> of old packages that don't build with openjdk9, so I'm not sure when we can >> update the default jdk… > >Hi, > >is there effort to update the default jdk at some point? I could help with >it. I'm not familiar with the guix java build systems, but have long >experience as a Java developer. I also maintain few java packages in Fedora >and saw the transition to to jdk11 [1], jdk17 [2] and now to jdk21 [3]. The >pages have documented common issues and workarounds, which might help. > >[1]: https://fedoraproject.org/wiki/Changes/Java11 >[2]: https://fedoraproject.org/wiki/Changes/Java17 >[3]: https://fedoraproject.org/wiki/Changes/Java21 > >Best wishes, >Markku > >> Le 16 avril 2024 22:25:33 GMT+02:00, Vagrant Cascadian >> a écrit : >> >When recently taking a look at diffoscope, I was reminded that there is >> >effectively no default openjdk version, you have to pick a specific >> >version for each package definition... >> > >> >At some time in diffoscope's history, that was openjdk@12. >> > >> >But there are quite a few versions to choose from: >> > >> > guix package -A openjdk | sort -V >> > openjdk 9.181 out,jdk,doc gnu/packages/java.scm:869:2 >> > openjdk 10.46 out,jdk,doc gnu/packages/java.scm:1140:2 >> > openjdk 11.0.22 out,jdk,doc gnu/packages/java.scm:1218:2 >> > openjdk 12.33 out,jdk,doc gnu/packages/java.scm:1536:2 >> > openjdk 13.0.14 out,jdk,doc gnu/packages/java.scm:1576:2 >> > openjdk 14.0.2 out,jdk,doc gnu/packages/java.scm:1583:2 >> > openjdk 15.0.10 out,jdk,doc gnu/packages/java.scm:1598:2 >> > openjdk 16.0.2 out,jdk,doc gnu/packages/java.scm:1617:2 >> > openjdk 17.0.10 out,jdk,doc gnu/packages/java.scm:1625:2 >> > openjdk 18.0.2.1out,jdk,doc gnu/packages/java.scm:1642:2 >> > openjdk 19.0.2 out,jdk,doc gnu/packages/java.scm:1646:2 >> > openjdk 20.0.2 out,jdk,doc gnu/packages/java.scm:1663:2 >> > openjdk 21.0.2 out,jdk,doc gnu/packages/java.scm:1667:2 >> > >> >Some packages may only work with a specific era of openjdk, but I >> >suspect many of the packages in guix just picked whatever version >> >happened to be present when it was added to guix. >> > >> >Which makes it hard to know when to update the openjdk dependency... >> > >> >In the diffoscope case, it seems to have work fine with openjdk@21, with >> >the only result being that some openjdk-version-specific tests pass and >> >some are skipped as a one-for-one trade compared to the old openjdk@12. >> > >> >Alternately, I would be tempted to switch to openjdk@17, which is the >> >current default in Debian, so has a little more testing behind it... >> > >> >Though there is a bit of a perverse incentive to stick with the oldest >> >version that still works, due to openjdk having a very long bootstrap >> >chain of itself... >> > >> >And then the question gets to be of diffoscope's dependencies, what >> >versions of openjdk do they pull in (notably enjarify, which uses >> >openjdk@12, although that also seems to work ok with openjdk@21)? >> > >> > >> >Would it make sense to have an openjdk "default" version, so packages >> >could instead depend on that, and only need to specify a version if >> >needed for some particular reason? Or is compatibility across openjdk >> >versions troublesome enough that it really always needs to be handled on >> >a case-by-case basis? >> > >> > >> >live well, >> > vagrant >>
Re: Welcome to Zheng (z572) as a new committer!
Congratulations! Maxim Cournoyer writes: > Hi comrades, > > Zheng has joined the committers to help improving cross-compilation, > riscv64, and KDE, among others. > > Let's wish them a warm welcome! > > Happy hacking! -- Retrieve my PGP public key: gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC Zihao signature.asc Description: PGP signature
A capture-stdout wrapper procedure in (guix build utils)?
Hallo, I noticed this capture-stdout wrapper procedure while reviewing Tomas' patch 68289⁰: , | (define (capture-stdout . prog+args) | (let* ((port (apply open-pipe* OPEN_READ prog+args)) | (data (get-string-all port))) | (if (= 0 (status:exit-val (close-pipe port))) | (string-trim-right data #\newline) | (error "command failed" ` Since this seems to be a somewhat general and useful pattern, do you think it might be worth to add it (or a variation thereof) to '(guix build utils)'? Thanks, best wishes, Fabio. ⁰ https://issues.guix.gnu.org/issue/68289/#0-lineno93 -- Fabio Natali https://fabionatali.com
Re: Status of ‘core-updates’
Hi Christopher, Christopher Baines writes: > Ludovic Courtès writes: > >> What’s the status of ‘core-updates’? What are the areas where help is >> needed? >> >> I know a lot has happened since the last update¹, which is roughly when >> I dropped the ball due to other commitments, but I’m not sure where we >> are now. > > I haven't really been following core-updates, but I have had a look > since there's a request to merge it now [1]. > > I'm really concerned by the commits on the branch though, assuming I'm > using Git right, there are 6351 commits on the branch: > > git log --pretty=oneline core-updates ^master | wc -l > > Somehow, I think there's been a couple of pushes of commits to > core-updates that have partially duplicated lots of commits from master, > I put some more details in: > > https://issues.guix.gnu.org/70456#3 > > I think keeping the Git commit history clean and representative is > really important, so to me at least this means core-updates can't be > merged to master in it's current form, even if the changes overall from > these 6351 commits are reasonable. > > I'm really not sure how to move forward though, I had a go at trying to > rebuild the branch without introducing the thousands of duplicate > commits and that produced a branch with 765 commits over master, which > still seems a lot, but a big improvement over 6351: > > https://git.cbaines.net/guix/log/?h=chris-core-updates-no-duplicates-attempt > > That was really hard going though, as there's plenty of merge conflicts > along the way, and I'm pretty sure I solved some of them > incorrectly. The resulting branch also differs from core-updates. I also think Git commit history is important, but in this case I weigh the value of removing ~5000 duplicated rust commits against the risks of resolving merge conflicts wrong or forgetting commits upon attempting to recreate the branch from scratch lower than the benefit. > Maybe someone with more time, care and attention could do a better job, > but it might be more worthwhile just starting fresh and rather than > trying to produce a like for like branch just without the thousands of > duplicate commits, effectively manually rebase the branch (without the > duplicate commits) on master and try to get the commits in to a usable > state. Given the little attention core-updates is currently receiving, I doubt someone is willing to put the effort to recreate the branch from scratch to clean its git history; at least speaking for myself I'd rather spend the little hack time I have to work on it toward getting it finalized. I believe how these duplicates came to exist was probably two separate master -> core-updates merge commits, with one of them ending up being rebased on top of the other, probably so that it could be pushed. Perhaps we could capture in our contribution guidelines that rebasing a merge commit should never be done to keep the history clean, and that in a situation where: 1. a merge has been prepared locally (with conflicts resolved and all) 2. a new commit has appeared on the remote branch the solution should be to merge the remote branch into the local one instead of rebasing the local one on the remote one (as is usually done). Disclaimer: I haven't actually tried this suggested approach, which should be done before documenting it, if there's a consensus to do so. In other words, I suggest we document what *not* to do to avoid repeating the same mistake in the future, and move on. -- Thanks, Maxim
Re: Concerns/questions around Software Heritage Archive
Hello, I’m following up on this since discussion since it’s been a month and I haven’t heard any updates. Summarizing the situation: - SHF has an opaque, difficult, and undocumented process for handling name changes. I’s like to stress again that this is *not* strictly a transgender issue (though it likely affects them more, or in worse/different ways) -- it is a human respect issue. Many, many more cisgender people change their name than transgender people. - SHF gave their archive to HuggingFace, an "AI" company which is generating derived works with no attribution or provenance, in ways which violate the both licenses of the projects used to train their model, and the SHF principles for LLMs. - HuggingFace wasn’t respecting requests to opt-out of their model. On the first point, it sounds like SHF has made concrete progress to improve[1], which is very good to hear. If SHF continues on this course, I think the concern is resolved. On the third point, HuggingFace has begun honoring opt-out requests, but is still very far behind. Also, they don’t remove code from the older versions of their model -- it remains there forever. This is progress, but still, not great. On the second point, I have not seen any public statements indicating that either SHF or HuggingFace even acknowledges the problem. SHF’s most recent newsletter[2], published in April 2024 (after these concerns came to light), continues to tout that StarCoder2 is "the first AI model aligned with our principles," which appears to be false. StarCoder2 includes both licensed and unlicensed code, and HuggingFace’s own StarChat2 playground produces works derivative of this code, with no attribution or licensing information. There is also no statement or position on the SHF news blog. Nor hsa HuggingFace either fixed their tools, or made a statement. This is still very much a live concern. I have a few questions: - Has Guix reached out to SHF to express these concerns / get a response? - Whether a public or private response, what would Guix consider to be an acceptable response? An unacceptable respoinse? - How long is Guix willing to wait for a response? Thanks, — Ian [1]: https://cohost.org/arborelia/post/5273879-they-are-fixing-some [2]: https://www.softwareheritage.org/wp-content/uploads/2024/04/Software-Heritage-2024-Vision-Milestones-Newsletter.pdf Ian Eure writes: Hi Guixy people, I’d never heard of SWH before I started hacking on Guix last fall, and it struck me as rather a good idea. However, I’ve seen some things lately which have soured me on them. They appear to be using the archive to build LLMs: https://www.softwareheritage.org/2024/02/28/responsible-ai-with-starcoder2/ I was also distressed to see how poorly they treated a developer who wished to update their name: https://cohost.org/arborelia/post/4968198-the-software-heritag https://cohost.org/arborelia/post/5052044-the-software-heritag GPL’d software I’ve created has been packaged for Guix, which I assume means it’s been included in SWH. While I’m dealing with their (IMO: unethical) opt-out process, I likely also need to stop new copies from being uploaded again in the future. Is there a way to indicate, in a Guix package, that it should *never* be included in SWH? Is there a way to tell Guix to never download source from SWH? I want absolutely nothing to do with them. Thanks, — Ian
Fallout from recent nss-certs changes
Some recent nss-certs changes have a negative side effects which needs to be fixed. A patch of mine was pushed recently (commit 0920693381d9f6b7923e69fe00be5de8621ddb6f), which adds nss-certs 3.98 to (gnu packages certs), under the nss-certs-3.98 variable. Then, commit fdfd7667c66cf9ce746330f39bcd366e124460e1 was pushed, which adds nss-certs to %base-packages-networking. This references the nss-certs variable, which is version 3.88.1. If an operating-system’s packages includes `(specification->package "nss-certs")', this causes breakage, because that form selects version 3.98, but %base-packages includes 3.88.1, which causes an error on the next `guix system reconfigure' due to conflicting package versions in the profile. Prior to commit 65e8472a4b6fc6f66871ba0dad518b7d4c63595e, the graphical installer would ask users if they wanted to install nss-certs, and put this form into the operating-system’s packages, so there are likely many users affected -- it bit me, and I’ve seen a couple in IRC as well. I think the options to fix this are: 1. Removing (specification->package "nss-certs") from one’s operating-system. 2. Grafting nss-certs 3.98 onto nss-certs 3.88.1. 3. Replacing nss-certs 3.88.1 with 3.98. The most expedient option is 1, as it can be applied by users -- but there’s probably not a good way to communicate that this needs to happen. There was some talk in IRC about grafting nss/nss-certs, but it looks like this didn’t happen. An upgrade is the best path, but would probably need to happen in core-updates, since this rebuilds a large number of packages. Thoughts on this? Thanks, — Ian
Re: rust-team branch merged
Efraim Flashner writes: Currently if you were to pull in rust-rand-0.8 and rust-rand-0.7 then you'd have both rand-0.*.crate files in the registry but only one of them would be listed in share/cargo/registry/index/ra/nd/rand. I need to adjust the generation of that file to combine multiple sources if they exist, and sort them (I'm not sure it's necessary, but wouldn't be surprised if we hit undefined behaviour if they were listed multiple times or out of order). Hi Efraim, I'm currently investigating this limitation of your proposed patch. Did you have a strategy in mind for how to fix it? I see that the index files are currently generated during a phase of cargo-build-system, rather than as a profile hook. So, to build an index that properly reflects the contents of a profile, it would seem that the two simplest options are: a) keep your existing index-generation logic during the build, and merge these per-package index files when building the profile; or b) move your patch's index-generating code out of the build phase and into a profile hook, so that we build each index file in a single pass (for all versions of a package) rather than merging the files from each package output. On the surface option (b) seems cleaner, but maybe you had a reason for generating the index contents during the build? Jason
Guix bios installation: Grub error: unknown filesystem
I'm having trouble installing guix in qemu, using a "fresh" guix ISO. ``` building /gnu/store/byjlc85abyjc3fjj9z982677skmda7ib-module-import-compiled.drv... building /gnu/store/psw8xn9qpsjjnrqmjrfv0v3jj9fphq5m-module-import-compiled.drv... building /gnu/store/a1zcrrcdwhb4wb2g4r0ph8mqclq7f5xn-install-bootloader.scm.drv... guix system: error: '/gnu/store/li1ic17hz460vp1sg0cx2dwgw8q7i8pj-grub-2.06/sbin/grub-install --no-floppy --target=i386-pc --boot-directory /mnt/boot /dev/sda' exited with status 1; output follows: Installing for i386-pc platform. /gnu/store/li1ic17hz460vp1sg0cx2dwgw8q7i8pj-grub-2.06/sbin/grub-install: error: unknown filesystem. ``` Here's what I've tried so far: 1. The ISO from 2022 https://ftpmirror.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso: Success 2. Generated a new ISO today: Failure These are the channels, on the booted ISO: ``` guix describe guix 65e8472 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 65e8472a4b6fc6f66871ba0dad518b7d4c63595e ``` Steps I used to install (1) and (2): ``` parted -s /dev/sda -- mklabel msdos mkpart primary ext4 1MiB 100% parted /dev/sda set 1 boot on mkfs.ext4 -L my-root /dev/sda1 mount LABEL=my-root /mnt cp /etc/configuration/lightweight-desktop.scm /mnt/etc/config.scm # adjust disk, bootloader herd start cow-store /mnt guix system init /mnt/etc/config.scm /mnt ``` Findings: I didn't really dig too deeply yet; Only noticed that this command produces a different result, depending on whether the install succeeds, or not `grub-probe --target=fs --device /dev/sda` - Success: `ext2` - Failure: `grub-probe: error: unknown filesystem.` I also tried using GPT instead of MBR, but it makes no difference.
Re: No default OpenJDK version?
On Tue, Apr 16, 2024 at 10:37:30PM +0200, Julien Lepiller wrote: > Currently, most java packages use the implicit jdk from the build system > (ant- or maven-build-system), which is… icedtea@8. We still have quite a lot > of old packages that don't build with openjdk9, so I'm not sure when we can > update the default jdk… Hi, is there effort to update the default jdk at some point? I could help with it. I'm not familiar with the guix java build systems, but have long experience as a Java developer. I also maintain few java packages in Fedora and saw the transition to to jdk11 [1], jdk17 [2] and now to jdk21 [3]. The pages have documented common issues and workarounds, which might help. [1]: https://fedoraproject.org/wiki/Changes/Java11 [2]: https://fedoraproject.org/wiki/Changes/Java17 [3]: https://fedoraproject.org/wiki/Changes/Java21 Best wishes, Markku > Le 16 avril 2024 22:25:33 GMT+02:00, Vagrant Cascadian > a écrit : > >When recently taking a look at diffoscope, I was reminded that there is > >effectively no default openjdk version, you have to pick a specific > >version for each package definition... > > > >At some time in diffoscope's history, that was openjdk@12. > > > >But there are quite a few versions to choose from: > > > > guix package -A openjdk | sort -V > > openjdk 9.181 out,jdk,doc gnu/packages/java.scm:869:2 > > openjdk 10.46 out,jdk,doc gnu/packages/java.scm:1140:2 > > openjdk 11.0.22 out,jdk,doc gnu/packages/java.scm:1218:2 > > openjdk 12.33 out,jdk,doc gnu/packages/java.scm:1536:2 > > openjdk 13.0.14 out,jdk,doc gnu/packages/java.scm:1576:2 > > openjdk 14.0.2 out,jdk,doc gnu/packages/java.scm:1583:2 > > openjdk 15.0.10 out,jdk,doc gnu/packages/java.scm:1598:2 > > openjdk 16.0.2 out,jdk,doc gnu/packages/java.scm:1617:2 > > openjdk 17.0.10 out,jdk,doc gnu/packages/java.scm:1625:2 > > openjdk 18.0.2.1out,jdk,doc gnu/packages/java.scm:1642:2 > > openjdk 19.0.2 out,jdk,doc gnu/packages/java.scm:1646:2 > > openjdk 20.0.2 out,jdk,doc gnu/packages/java.scm:1663:2 > > openjdk 21.0.2 out,jdk,doc gnu/packages/java.scm:1667:2 > > > >Some packages may only work with a specific era of openjdk, but I > >suspect many of the packages in guix just picked whatever version > >happened to be present when it was added to guix. > > > >Which makes it hard to know when to update the openjdk dependency... > > > >In the diffoscope case, it seems to have work fine with openjdk@21, with > >the only result being that some openjdk-version-specific tests pass and > >some are skipped as a one-for-one trade compared to the old openjdk@12. > > > >Alternately, I would be tempted to switch to openjdk@17, which is the > >current default in Debian, so has a little more testing behind it... > > > >Though there is a bit of a perverse incentive to stick with the oldest > >version that still works, due to openjdk having a very long bootstrap > >chain of itself... > > > >And then the question gets to be of diffoscope's dependencies, what > >versions of openjdk do they pull in (notably enjarify, which uses > >openjdk@12, although that also seems to work ok with openjdk@21)? > > > > > >Would it make sense to have an openjdk "default" version, so packages > >could instead depend on that, and only need to specify a version if > >needed for some particular reason? Or is compatibility across openjdk > >versions troublesome enough that it really always needs to be handled on > >a case-by-case basis? > > > > > >live well, > > vagrant >
Welcome to Zheng (z572) as a new committer!
Hi comrades, Zheng has joined the committers to help improving cross-compilation, riscv64, and KDE, among others. Let's wish them a warm welcome! Happy hacking! -- Thanks, Maxim
Re: Status of ‘core-updates’
Ludovic Courtès writes: > What’s the status of ‘core-updates’? What are the areas where help is > needed? > > I know a lot has happened since the last update¹, which is roughly when > I dropped the ball due to other commitments, but I’m not sure where we > are now. I haven't really been following core-updates, but I have had a look since there's a request to merge it now [1]. I'm really concerned by the commits on the branch though, assuming I'm using Git right, there are 6351 commits on the branch: git log --pretty=oneline core-updates ^master | wc -l Somehow, I think there's been a couple of pushes of commits to core-updates that have partially duplicated lots of commits from master, I put some more details in: https://issues.guix.gnu.org/70456#3 I think keeping the Git commit history clean and representative is really important, so to me at least this means core-updates can't be merged to master in it's current form, even if the changes overall from these 6351 commits are reasonable. I'm really not sure how to move forward though, I had a go at trying to rebuild the branch without introducing the thousands of duplicate commits and that produced a branch with 765 commits over master, which still seems a lot, but a big improvement over 6351: https://git.cbaines.net/guix/log/?h=chris-core-updates-no-duplicates-attempt That was really hard going though, as there's plenty of merge conflicts along the way, and I'm pretty sure I solved some of them incorrectly. The resulting branch also differs from core-updates. Maybe someone with more time, care and attention could do a better job, but it might be more worthwhile just starting fresh and rather than trying to produce a like for like branch just without the thousands of duplicate commits, effectively manually rebase the branch (without the duplicate commits) on master and try to get the commits in to a usable state. Any ideas? Thanks, Chris signature.asc Description: PGP signature
Re: Should we include nss-certs out of the box?
On 2024-04-19, 11:25 -0400, Maxim Cournoyer wrote: > Could you please take a look at > '65e8472a4b6fc6f66871ba0dad518b7d4c63595e', which I hope didn't leave > no longer useful 'nss-certs' doc/examples behind ? Hi Maxim, absolutely, I should be able to give a look today or tomorrow. I'll send an update here. Thanks, best wishes, Fabio.
Re: Fix grammar and markup (was Re: Feedback of the GNU Guix manual)
On Fri, 19 Apr 2024 22:56:13 +0200 pelzflorian (Florian Pelz) wrote --- > Hello Matt, pushed as 86fb0e039bf30cf85e2066401f9a384427c47ea8. > > I was bold enough to retain the xref change in (Setting Up the Daemon) > prompted by Ludo, because starting a sentence with @xref is recommended > in the Texinfo manual and its examples, while @pxref at the start of a > phrase is not preferrable, according to the “info "(texinfo)@pxref"”. > > Again, Texinfo cross-references are complicated. > > (In the German translations, I always wrote only @ref, but only because > @xref is not properly translated; Emacs in particular is not > internationalized at all.) Sounds good, thank you!
Re: Creating a documentation team?
On Fri, 19 Apr 2024 16:09:53 +0200 Ludovic Courtès wrote --- > Hi Florian and all, > > I figure you’ve been doing a lot of review and writing of the manual. > Should we create a documentation team, of which you could be a honorary > member? :-) > > I feel like ensuring doc consistency, be it regarding the content, > terminology, typography, or use of markup, is a job in its own that > could be best reviewed by people familiar with and interested in those > issues. I'm in favor of this and would enjoy continuing to help with the docs.
