Re: How to move forward about Rust? antioxidant, cargo2guix, etc.
On Sun, 16 Mar 2025 16:07:59 +0800, Efraim Flashner wrote: > > [1 ] > +CC Steve, new(ish) rust-team member > > On Sun, Mar 16, 2025 at 02:04:02PM +0800, Hilton Chain wrote: > > I have made the following changes (currently locally): > > - New procedure ‘cargo-inputs’. > > > > (cargo-inputs NAME) returns a copy of (@ (gnu packages rust-crates) > > NAME-cargo-inputs), with #f removed and symbols resolved to (@ (gnu > > packages > > rust-sources) SYMBOL). Both modules can be configured via keyword > > arguments. > > > > This eliminates the need to modify *-cargo-inputs manually. > > Is it possible to add the other more involved cargo inputs like > rust-ring to this list or would that add too much of a burden? For example, currently in my rust-crates.scm, ‘atuin-cargo-inputs’ has a ‘rust-ring-0.17.14’ element, which is defined as a symbol ‘'rust-ring-0.17’, then (cargo-inputs 'atuin) will resolve this symbol to ‘rust-ring-0.17’ variable defined in rust-sources.scm. We won't need to add ‘rust-ring-0.17’ to atuin's inputs then. > > - Importer: Insert *-cargo-inputs alphabetically too. > > Yay! > > > I'll try to keep cargo-build-system compatible with current packages. > > > > Draft migration path: > > 1. Import dependencies to (gnu packages rust-crates) and copy needed > > dependencies to (gnu packages rust-sources). > > 2. Remove #:cargo-inputs of applications, refine their definitions and > > relocate > > them to categorized modules. > > 3. Remove all crates-* modules. > > It seems to me that 2 and 3 can happen later as necessary, that 1 is the > most important part. Especially since I think we'd do well to have the > mixed build-system packages not be cargo-build-system but their other > build-system instead. I agree, so I'll make the changes compatible with current packages.
Re: How to move forward about Rust? antioxidant, cargo2guix, etc.
On Sun, 16 Mar 2025 16:30:08 +0800, Hilton Chain wrote: > > On Sun, 16 Mar 2025 16:07:59 +0800, > Efraim Flashner wrote: > > > > [1 ] > > +CC Steve, new(ish) rust-team member > > > > On Sun, Mar 16, 2025 at 02:04:02PM +0800, Hilton Chain wrote: > > > I have made the following changes (currently locally): > > > - New procedure ‘cargo-inputs’. > > > > > > (cargo-inputs NAME) returns a copy of (@ (gnu packages rust-crates) > > > NAME-cargo-inputs), with #f removed and symbols resolved to (@ (gnu > > > packages > > > rust-sources) SYMBOL). Both modules can be configured via keyword > > > arguments. > > > > > > This eliminates the need to modify *-cargo-inputs manually. > > > > Is it possible to add the other more involved cargo inputs like > > rust-ring to this list or would that add too much of a burden? > > For example, currently in my rust-crates.scm, ‘atuin-cargo-inputs’ has a > ‘rust-ring-0.17.14’ element, which is defined as a symbol ‘'rust-ring-0.17’, > then (cargo-inputs 'atuin) will resolve this symbol to ‘rust-ring-0.17’ > variable > defined in rust-sources.scm. We won't need to add ‘rust-ring-0.17’ to atuin's > inputs then. > > > > - Importer: Insert *-cargo-inputs alphabetically too. > > > > Yay! > > > > > I'll try to keep cargo-build-system compatible with current packages. > > > > > > Draft migration path: > > > 1. Import dependencies to (gnu packages rust-crates) and copy needed > > > dependencies to (gnu packages rust-sources). > > > 2. Remove #:cargo-inputs of applications, refine their definitions and > > > relocate > > > them to categorized modules. > > > 3. Remove all crates-* modules. > > > > It seems to me that 2 and 3 can happen later as necessary, that 1 is the > > most important part. Especially since I think we'd do well to have the > > mixed build-system packages not be cargo-build-system but their other > > build-system instead. > > I agree, so I'll make the changes compatible with current packages. (Resent to have proper To: and Cc:, not sure why my MUA is not good at replying to Efraim's mail)
Re: New procedure to modify operating-system records
Hi, in case someone stumbled upon this thread in the future (probably me, who will again not save this to a known location and will come searching on the list archives :) ), OP changed their usernam on codeberg, so new url is here: https://codeberg.org/pastor/omega/src/branch/main/pastor/utils/gpu-specification.scm
Re: emacs-next periodic updates
Greetings, Just sending another message to report on status: I managed to update emacs-next-minimal to db0bed7a68cd2308eba61247a6a77f73533ffef6 The only package that didn't build properly was emacs-next-pgtk-xwidgets: >checking for webkit2gtk-4.1 >= 2.12 webkit2gtk-4.1 < 2.41.92... no >checkinbg for webkit2gtk-4.0 >= 2.12 webkit2gtk-4.0 < 2.41.92... no >configure: error: xwidgets requested but WebKitGTK+ or WebKit framework not >found. Seems like I'd have to update or write another version of webkitgtk-with-libsoup2. If you want to check it out, I think I could send the patch to this thread. -- Gabriel Santos
Re: New procedure to modify operating-system records
Sergio Pastor Pérez writes: > Hello Rutherther! Thanks for showing interest. > > Rutherther writes: >> Hi, in case someone stumbled upon this thread in the future >> (probably me, who will again not save this to a known location >> and will come searching on the list archives :) ), >> >> OP changed their usernam on codeberg, so >> new url is here: >> https://codeberg.org/pastor/omega/src/branch/main/pastor/utils/gpu-specification.scm > > You no longer need to use my channel, this has been upstreamed to > Nonguix in this commit[1]. That's great to hear that it was upstreamed to a more popular channel! Thanks for the work. > If anyone would like to help with this work, please take a look at the > latest revision of fixing `map-derivation'[2]. We are currently looking > for testers that have some meaningful use cases of this procedure. Btw have you looked into how to meaningfully use this procedure in use-cases like guix system/home build/reconfigure, guix build... Because as far as I can tell, this map-derivation cannot really be used along with them and some sort of custom script would be necessary, or am I missing something? - If so, that would mean the previous solution was way easier to be used, since you just returned operating-system as normally, but with rewrites applied. Regards, Rutherther
Re: emacs-next periodic updates
>webkitgtk-for-gtk3 provides webkit2gtk-4.1, but the version is 2.46.6. You >may not need to use webkitgtk-with-libsoup2 as the base to prepare another >version. Thanks, I'll check out webkitgtk-for-gkt23 to see what I can do. -- Gabriel Santos
New Ukrainian PO file for 'shepherd' (version 1.0.3rc1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'shepherd' has been submitted by the Ukrainian team of translators. The file is available at: https://translationproject.org/latest/shepherd/uk.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/shepherd/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/shepherd.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: emacs-next periodic updates
Gabriel Santos writes: I managed to update emacs-next-minimal to db0bed7a68cd2308eba61247a6a77f73533ffef6 The only package that didn't build properly was emacs-next-pgtk-xwidgets: checking for webkit2gtk-4.1 >= 2.12 webkit2gtk-4.1 < 2.41.92... no checkinbg for webkit2gtk-4.0 >= 2.12 webkit2gtk-4.0 < 2.41.92... no configure: error: xwidgets requested but WebKitGTK+ or WebKit framework not found. Seems like I'd have to update or write another version of webkitgtk-with-libsoup2. webkitgtk-for-gtk3 provides webkit2gtk-4.1, but the version is 2.46.6. You may not need to use webkitgtk-with-libsoup2 as the base to prepare another version. -- Ricardo
Re: Trying out Codeberg
Hello, Adrien 'neox' Bourmault writes: [...] > If I can help by sharing Libre en Communs' experience, I'll be very > happy to do so. I'll start here by explaining a bit what I have in > mind. > > Libre en Communs needed a forge software to be able to provide means > for people (both very technical such as sysadmins and less technical > such as designers or writers) for collaboration. We chose Forgejo > because of its stance for software freedom and because it was the best > solution available at that time as compromise between usability and > performance/resources. > > However, Forgejo is not perfect at all. We lack moderation tools to > fight against e.g abusers, there are sometimes very serious bugs (this > works better lately), and the default CI recipes/code depends on > docker.io images and nodeJS and npm. Also, the javascript generated by > Forgejo is minified, without a clear license header, making LibreJS > blocking it by default (and preventing people from being able to trust > it right away). > > About the CI, we decided to forbid using the default recipes advertized > in Forgejo docs, because we can't verify that everything is free on > code.forgejo.org, and we don't want our infrastructure to depend on npm > for the same reasons. > > Currently, it's possible to use Forgejo CI on our instance with runners > configured with docker (with a dedicated self-hosted docker image, like > a project on our instance does) but also with ssh on a dedicated host, > that can be a chroot. I did not have enough time to test with a `guix > vm` but that seems doable without too much pain. > > Please let me know if you want explanation on how we do anything, or if > I can help further. Thank you for sharing your experience with Forgejo; this is valuable input. The lack of moderation tools sounds problematic. Are there ways around this lack of tooling, or is it just not possible to moderate? -- Thanks, Maxim
Re: How to move forward about Rust? antioxidant, cargo2guix, etc.
Nicolas Graves writes: > 4) The full Guix way > > Most likely : we don't have the manpower in the short term for > going the full guix way, because, and I second Murilo's point here, we > dive in dependency hell quickly with more required efforts than > reasonable (having implemented it myself, despite being quite proud of > it). > > BUT: Maybe antioxidant is still doable. IIRC the hardest was not setting > #:features correctly (I hope IRC). This is because the information about > features required for parent packages is located in parent / dependent > packages, not in child packages. > > Cargo chooses to rebuild everything ; but there is at least another > solution for that : parse all the dependents of a package to record the > different features/versions a package would need to be generated > with. This means when importing, also sinking into crates.io huge > database, but we could construct an inverse cache or something. > And an importer could then generate more than one version of a package, > but several variants, if several variants are indeed required to build > all its transitive parents. > Are you saying that if two dependents of a package A depend on the same package B, but with different features we need to build B with the union of those features? Is it possible to build B twice or will it conflict with itself when building A? > To be even more precise we could search only in blessed.rs or lib.rs. > But we need to pull that from Rust, with dependents too (and not in Guix > like Antioxidant did). > > This could lead to a channel like we've seen for Emacs packages or CRAN, > generating regularly from complete upstream info, and we could > incorporate piece by piece packages that build in this channel into > Guix. With limitations: the deduplication of packages (having 4-5 > versions of the same package) will probably still be necessary. > > Otherwise there's just a lot of work by hand, we probably would like to > avoid. > signature.asc Description: PGP signature
Re: How to move forward about Rust? antioxidant, cargo2guix, etc.
> Are you saying that if two dependents of a package A depend on the same > package B, but with different features we need to build B with the > union of those features? > Exactly, except in some cases where features are incompatible with each other, but that's (very) rare. What's annoying is that we don't know the good scope of features, it's often more than "default" but we still want to minimize it to avoid weird dependency loops. > > Is it possible to build B twice or will it conflict with itself when > building A? > Not sure I remember correctly, IIRC you need a single B.
Re: Automatic tagging of unanswered issues in mumi
>ven. 14 mars 2025 at 14:02, Arun Isaac wrote: > Hi Cayetano, > >> I’m just wondering if the help page up to date with most recent hints. >> >> https://issues.guix.gnu.org/help > > The help page is technically up-to-date since I haven't changed that > interface. However, the help page could be improved significantly by > adding examples of real-world everyday queries people might use. I'll do > that soon. You can help it happen sooner if you reply to this thread > with some concrete examples. :-) I don't need a patch, just text I can > work with. It's always helpful to have these examples written by users > so they are representative of what users actually want to do. I had in mind both, "tag:unanswered" and "tag:team-whatever", which don’t appear in the help page (I understand here that not any tag is accepted by mumi). C. signature.asc Description: PGP signature
New Romanian PO file for 'shepherd' (version 1.0.3rc1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'shepherd' has been submitted by the Romanian team of translators. The file is available at: https://translationproject.org/latest/shepherd/ro.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/shepherd/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/shepherd.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
New Slovak PO file for 'shepherd' (version 1.0.3rc1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'shepherd' has been submitted by the Slovak team of translators. The file is available at: https://translationproject.org/latest/shepherd/sk.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/shepherd/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/shepherd.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
New template for 'shepherd' made available
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to .) A new POT file for textual domain 'shepherd' has been made available to the language teams for translation. It is archived as: https://translationproject.org/POT-files/shepherd-1.0.3rc1.pot Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. Below is the URL which has been provided to the translators of your package. Please inform the translation coordinator, at the address at the bottom, if this information is not current: https://alpha.gnu.org/gnu/shepherd/shepherd-1.0.3rc1.tar.gz We can arrange things so that translated PO files are automatically e-mailed to you when they arrive. Ask at the address below if you want this. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
New Swedish PO file for 'shepherd' (version 1.0.3rc1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'shepherd' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/shepherd/sv.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/shepherd/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/shepherd.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
