Re: Are declarative app configs worth it?

Hi there, I think specifying each option is too much to maintain - however I what about an alist or hashmap? Nixos has used the freeform module type to great success and this feels like the same situation.

Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues

Hi Gio! I am very sorry I have let it slip. If there are patches I need to get to, I can put them in to emacs-guix. I believe we should get the savannah version up to snuff and use that as the one in guix. My apologies again. I may be able to look into it this weekend if that's alright. Kindl

Re: Packaging rust-analyzer is not necessary.

Hi Paul And Maxime, > Even if you didn't succeed at updating _all_ dependencies, if you > have patches for some of them, please send them. It will help people > in the future with updating rust-analyzer or other rust packages. I had a patchset (here: https://issues.guix.gnu.org/46162) adding rus

Re: Desktops on non-x86_64 systems

Hi Guix, I had the same thought as Maxim. In my quest for arm support for ghc, I thought about using a cross-compiled version. Is this possible or even desirable? I think for rust and ghc it would be very helpful - if somewhat less principled than a bootstrap all the way up (on the same compute

Re: Create branch for Haskell build changes and updates?

have tried but I don’t know how to build it. I also nominate updating the ghc-profile-hook. It needs some work to be fully functional. Perhaps a search-path would be the way to go there? Kindly, John Soo

Re: Some more rust/cargo insights

Oh my goodness, I’m so sorry for the top quote.

Re: Some more rust/cargo insights

Hi Hartmut and Pjotr, My feeling on this is that we should partner with the Rust community to make shared library support from cargo a priority. Specifying an output directory is currently a nightly feature, that could be helpful. In general Rust tooling does not compose with existing tools. I

[PATCH] gnu: alacritty: Update to 0.7.1.

Hey Tobias and Nicolás, I added alacritty some time ago but I do use it every day.I don’t use Wayland (yet) though so I can’t say whether the hack in question is working. I can confirm that the update is just fine on X though. Sorry for not keeping it more

Re: [Emacs-Guix] make: Error 255

Hi zimoun, What about using guix to build like: guix build -f guix.scm I believe that is how that file is meant to work. I’m not sure it entirely answers your question on how to test but maybe something like this would work: guix environment -L . --ad-hoc ema

Re: [Emacs-Guix] make: Error 255

Hi zimoun, What exactly did you do? It sounds like you checked out emacs-guix and ran make? - John

Re: Staging branch [substitute availability aarch64-linux]

I’ve been working on ghc and making some progress. I’d love to have more support for rust but I’m not sure what the issue is.

Re: Emacs-Guix repository location moved to Savannah

> I can't think of a better place nor can I imagine we'll be overwhelmed > by emacs-guix patches. > > (And if we are, that's probably a good thing at this point?) That is my thought, too. >> As to the patch, I would like to apply it. Is Guix System still the >> preferred name? > > Yep. There's

Re: Emacs-Guix repository location moved to Savannah

Hi Pierre, I forgot to answer your other question. Emacs-Guix is a sub-project of Guix on Savannah https://savannah.gnu.org/projects/guix it is "Emacs interface to GNU Guix". The repository is available at https://git.savannah.gnu.org/cgit/guix/emacs-guix.git. - John

Re: Emacs-Guix repository location moved to Savannah

Hi Ryan, Ryan Prior writes: > How do you feel about removing commands that nobody feels like fixing? It > might help Emacs-Guix build a reputation for reliability. I plan on trying to fix them all, but I may remove some if they are just not possible any longer. > I think it's a good idea. Con

Re: Emacs-Guix repository location moved to Savannah

Hi Tobias, Tobias Geerinckx-Rice writes: > Hi, > > John Soo 写道： >> Emacs-Guix has a new home! I just pushed >> a42f66cb40a9e60611f429a403b08dbed29bae02 to Emacs-Guix on Savannah. > > Thank you for taking care of this, and innumerable thanks to Alex for > creating

Re: Emacs-Guix repository location moved to Savannah

Hi Pierre! Pierre Neidhardt writes: > > - guix-devel-build-package-definition > > It seems that Geiser chokes on it because of the output. > I don't know if this can be worked around somehow. > If not, an alternative would be to invoke the `guix repl` executable > instead of using Geiser

Re: New emacs-guix location

Hi Alex! Alex Kost writes: > Hello, I am fine, thanks! I hope you are still well! > >> I volunteered to maintain some version of >> emacs-guix recently. How do you feel about a fork moving to Savannah? > > You (and all the Guix people) are free to do whatever you think is > appropriate. Emac

Emacs-Guix repository location moved to Savannah

Hi Guix! Emacs-Guix has a new home! I just pushed a42f66cb40a9e60611f429a403b08dbed29bae02 to Emacs-Guix on Savannah. My first order of business will be fixing the broken subcommands. I don't use many of them, though. If you have a command you want fixed, please let me know and I will priortiz

Commit Access to Emacs-Guix

Hello Guix, I have taken up maintainership of the new home of Emacs-Guix on Savannah. This message is signed with the key I will be using to sign commits on Emacs-Guix. Thank you! John signature.asc Description: PGP signature

Re: Staging branch

Hi Guix, Leo Famulari writes: > It is supposed to be running, but something has broken. This does happen > from time to time... Ah well... For what it is worth I have rebased on staging and reconfiguring my system on it built successfully. Also my manifest built successfully. I don't have ma

Re: Packaging elm-compiler 0.19.1

Hi Matthew, Matthew Kraai writes: > I think that elm-compiler is built with GHC 8.6.5, not GHC 8.8.3.  > When I run `guix environment --pure --ad-hoc ghc@8.6.5 -- ghc-pkg > list`, its output contains `time-1.8.0.2`.  I tried changing the > definition of `ghc-8` in `haskell.scm` from `ghc-8.6` t

Re: Staging branch

Hi there, Is staging not running in ci?It looks like the last time it ran was just before the rustfmt output of rust (commit 48926b5).Did changing rust@1.46 somehow keep ci from running on staging? Maybe I am missing something. Any clues? John

Re: Packaging elm-compiler 0.19.1

Hi Matthew, I’m not 100% sure how guix handles the ghc “boot” libraries but I think time is installed alongside ghc. Doing guix environment --pure --ad-hoc ghc -- ghc-pkg list gets me time-1.9.3. So I do think the version bounds should be satisfied without any other dependency. Mind s

Re: Discussion: How to package rust crates now and in future?

Hey Hartmut, I’m not sure which way I fall here. I think probably keepijg ci on for most crates makes sense if we can work instead towards real shared libraries. In any case, I would like to propose a working group for rust. Perhaps we can meet monthly in jitsi or elsewhere.

Re: Staging branch

Thank you! Let’s test!

Re: Staging branch

As far as I understand it, it adds just enough to the rust package definition to add the extra rustfmt output.

Re: Staging branch

Hi Leo, The patch adds an extra output, leaving the compiler unchanged so nothing should be effected in runtime as far as I know. - John

Re: Staging branch

Hello, icecat, ungoogled-chromium, alacritty, ripgrep, exa and others depend on it at least. I have been using the patches for a few weeks. What do you think? - John

Re: Staging branch

Hello there, Is there any chance this could make it to staging before the merge? http://issues.guix.gnu.org/42295 Thanks! John

Re: Guix day: Summary fo rust BoF session

Hi Hartmut and Sébastien, I started with some talking points which I will attach. We did not get to everything though. Mostly we discussed the possibility of using system dependencies and installing actual compiled artifacts. Someone mentioned that the possibility of using system dependencies cam

Re: FreeCAD fails to compile

Nice work Ekaitz! I worked hard on freecad, it is quite a difficult program to package. That was a weird issue that I asked about on the freecad forums. Perhaps it is fixed upstream now, which would be excellent. Thanks for keeping it up to date! - John

New emacs-guix location

Hello Alex and Guix, Hope you are well.I volunteered to maintain some version of emacs-guix recently. How do you feel about a fork moving to Savannah? Best wishes, John Soo

Re: [sr #110376] Creating an Emacs-Guix Git repository for Guix

Hi Ludo and Guix, Ludovic Courtès writes: > URL: > > > Summary: Creating an Emacs-Guix Git repository for Guix > Project: Savannah Administration > Submitted by: civodul > Submitted on: Mon

Re: libgccjit and gccemacs

Hello Andrea, Formbi, and Guix, I got gccemacs and the no-x version to compile. They do not run entirely correctly and the closure size is quite large. That said, it feels snappy! I submitted patches to issue 44775: https://issues.guix.gnu.org/issue/44775 If someone could investigate the retaine

Re: GNU Guix 1.2.0rc1 available for testing!

Hello, I have a fix for emacs-guix. Once I make the repository on savannah, that patch should be easy to make.I may be able to get to that around Wednesday. - John

Re: Fixing and maintenance of emacs-guix (guix.el)

Hi Ludo, Ludovic Courtès writes: > As I wrote in another message before reaching this one, my understanding > is that “we” now have to take over maintenance of Emacs-Guix. As part > of that process, we can discuss what interfaces would be useful to > Emacs-Guix and arrange to keep them stable.

Re: Reviving Emacs-Guix

Hi everyone, Ludovic Courtès writes: > Any Emacser around willing to take care of it at least in “maintenance > mode”? It seems like fixing the issues we currently have wouldn’t be > too hard. Then we can tag a release. I think I can do it. I can't promise a lot of new work but I can at least

Fixing and maintenance of emacs-guix (guix.el)

Hi Guix, emacs-guix (also known as guix.el) has been broken for some time. I submitted https://gitlab.com/emacs-guix/emacs-guix/-/merge_requests/8 to support guix versions >= 1.1. However, two changes also have to occur for proper support. * Some bindings will need to be exposed on the guix sid

Re: Announcing emacs-guix-packaging

Hi Zomoun, zimoun writes: > $ ag '\(@' --scheme $(guix build emacs-guix -S) > /gnu/store/…-emacs-guix-0.5.2-2.58a840d-checkout/scheme/emacs-guix/actions.scm > 200:((@@ (guix scripts build) log-url) store file)) > > /gnu/store/…-emacs-guix-0.5.2-2.58a840d-checkout/scheme/emacs-gui

Re: Anybody please help improving rust crates importer

Hello Hartmut, There is a patch set that has slightly bit rotted that does what you want. It could use a little polish but any work on it would be appreciated: http://issues.guix.gnu.org/38408 Thanks for thinking about the rust ecosystem in guix! - John

Re: RFC: subcommand to pause/resume builds

Hello everyone, Ludovic Courtès writes: >> After perusing info recutils some, I expected the output to be more >> like: >> >> ChildProcessPID: 16923 >> ChildProcessCommand: guile --no-auto-compile -L >> /gnu/store/8a0wry8cvr405ha8d8bpjyzj5dzghigd-module-import >> /gnu/store/mh1fkn1d9c9mg6hihxvjn

RFC: subcommand to pause/resume builds

Hello Guix, I just sent a patch to normalize the output of processes with bug number 44460. The allows me to compose recutils with kill to get the desired effect of pausing all process trees for the things I want without any convoluted implementation.I think I would be sat

Re: RFC: subcommand to pause/resume builds

After even further investigation, Does guix processes output the desired rec format? It seems hard to select the child process pid: ChildProcess: 16923: guile --no-auto-compile -L /gnu/store/8a0wry8cvr405ha8d8bpjyzj5dzghigd-module-import /gnu/store/mh1fkn1d9c9mg6hihxvjngxmn3qjmp38-ungoogled-chr

Re: RFC: subcommand to pause/resume builds

After further review, I realize that guix processes already formats for recutils. I never think to reach for that tool, but it seems good.

Re: RFC: subcommand to pause/resume builds

Hello Tobias :), Tobias Geerinckx-Rice writes: > Ludo', > > Ludovic Courtès 写道： >> First, note that the daemon is unaware of “packages”, it only knows >> about “derivations”. > > Derivations have a (file) name, which can be matched with a regex > allowing one to, say, ‘pause libreoffice’. It wo

Re: RFC: subcommand to pause/resume builds

Hello! I want to preface all this by saying this is not a huge priority to me. pause/resume would just be a nice quality of life improvement. Ludovic Courtès writes: > First, note that the daemon is unaware of “packages”, it only knows > about “derivations”. Agreed. I was thinking mostly about

RFC: subcommand to pause/resume builds

Hi Guix! I was looking to pause a long build today and asked on IRC how to accomplish pause/resume. It seems this is possible already with the following: kill --signal SIGSTOP|SIGCONT {pids-of-build-process-tree} There is already a command to list the processes associated to guix commands: guix

Re: getting started with the texlive importer

Nice work! That bug has been around for years I think. Thanks! John

Re: merge wip-haskell?

Nice! Thanks Tim!

Re: merge wip-haskell?

On another note: Does anyone know why idris, agda, and purescript are failing? I have only been able to do very little recently to look at them. - John

Re: Improving CI throughput

Hi Ludo and Guix, I am not sure how much I can devote to the problem, but bpf now works in guix. The bpftrace scripting language is there if it might help. Hope that helps a little, John

Re: merge wip-haskell?

Hi Ricardo and Jakub, Ah ok. Sorry I had forgotten the point of the thread. Sounds like a plan! - John On Aug 7, 2020, at 8:59 AM, Ricardo Wurmus wrote:  Jakub Kądziołka writes: >> On Fri, Aug 07, 2020 at 08:12:36AM -0700, John Soo wrote: >> I would rather wait until some e

Re: merge wip-haskell?

Hi Jakub, I could see splitting the static output being useful but I would rather wait until some evidence that the closure size would be too large. Also I’m not sure propagation is necessary for dependents to find libraries or use paths from an input. Thoughts? John On Aug 7, 2020, at 8:04

Re: merge wip-haskell?

Hi Ricardo, Nice! Sounds good to me. There are a couple other bits of work I’d like to see make it in. I believe there was also some work being done to de-duplicate flags sent to gcc sent by ghc (this was the only thing keeping stack from building). I hope that can make it in, too! If there

Re: The rust:cargo output - why?

Hi Jakub, I agree. In my mind, anything that would be installed via rustup add component would be a separate output. Aside from that, to reduce closure size, Maybe the docs can go into a separate output? But cargo is quite integral to the rust workflow I was very confused by cargo as a se

Re: RUNPATH problem building Rust 1.40.0

Hi Matthew and Ludo, I’ve been using the rust versions (up to 1.44) from this patch set without issue: http://issues.guix.gnu.org/40957 Hope that helps, John

Re: Returning to the project

Hey welcome back Brett! I was hopeful about the formal methods working group! Also all your work on the MLton toolchain was very interesting. I don’t think any work has been done on those since you left off :) Good to see you, - John

Re: Towards a graphical installer?

raingloom writes: > Can the TUI installer be used with a screen reader? AFAIK it can't but > I'd love to be proven wrong. I was just thinking about accessibility in Guix recently. I was wondering something similar. > Anyway, there are also other accessibility options that are useful. High > c

Request for proposals on Rust and Go build systems (RE: Medium-term road map)

Hi Guix, I lost the specific thread on the medium-term road map that applies. A few suggestions have been made to improve updates the source-only build systems we have (Rust and Go). I would like to suggest that we do make changes to these and put them on the road map. Can we put together some c

Re: GNU Guix maintainer collective update

to echo the sentiment that Guix is nice software but has even nicer leadership and community. Thank you so much for your service, Ricardo. I hope to see you around. > Let's also welcome Mathieu Othacehe in his new role! Congratulations, > Mathieu! :-) Congratulations Mathieu! Kindly, John Soo

Bump stackage LTS

Hi Guix, Stackage and ghc have moved quite a bit since our stackage and ghc versions. Would it be ok to start work on bumping our package set to a newer set of working packages and compilers? What is the state of the wip-haskell branch? Kindly, John

Re: TLS certificates for web browsers in guix environment --container

Hi Pierre, I think you need the nss-certs package in the environment, to start. Does adding them help? - John

Re: Adding a %desktop-packages

Hi there, I am on board with providing some predefined lists of packages. I raised the idea of providing smaller lists of packages that might go well together instead of one large %desktop-packages. One reason to do this, for instance, might be to not make someone who wants to use btrfs always im

Mistaken authorship on some commits

Hi Guix! I think I am reported as the author of commits 0cc8cdbe1b0018ec37b1de9032c9eca884bedb6e a97b943b5590c6406a85cb0f2f03fa69d7e3b7d8 c26fd5648c2a24dbd71f4c0851f8b5eced75e0f1 I did not author these, though it would have been likely. Thank you so much, maintainers. - John

Re: bug#30435: libreoffice: Fonts don't show up after install

Hi there, I think this is the same issue as 26877. Can font information be compiled into a fonts.conf? - John

Re: Brainstorming features for issues.guix.gnu.org

Ricardo Wurmus writes: >> It is hard to find how patchsets differ - let alone where >> revisions start and end. > > Do you have an idea how to improve this? Should we use, for example, > the message subject to detect revisions? (E.g. [PATCH 3/3] will > indicate that the end of the patch set has

Re: Brainstorming features for issues.guix.gnu.org

Hi Ricardo! I love the idea of a smoother download/review process. I think I would be happier with a curl-able endpoint to download patches from. I think it might compose with other tools a little more smoothly. Other than that, nothing really comes to my mind. I only just started using it more f

Re: rust (build system) deficits

Hi Hartmut, > My point is less the work, but the non-transitive declarations: nettle-sys is an multi-indirect input for sequioa-sqv, still the later needs to specify these dependencies. Totally agree. I think everyone agreed, too. A few months ago we decided that the package inputs should match

Re: rust (build system) deficits

Hi Hartmut, > On Mar 9, 2020, at 2:26 AM, Hartmut Goebel > wrote: > A second dependancy is "sequoia-openpgp", which requires rhe lalrpop parser generator for building. Now when building `sequioa-sqv`, I need to add all these dependencies again: - nettle-src, since it is "optional" for nettle

Re: rust (build system) deficits

Also I should just say thank you for taking interest in the cargo-build system. Please let me know if I’m missing something. John

Re: rust (build system) deficits

Hi Hartmut, > On Mar 8, 2020, at 10:16 AM, Hartmut Goebel > wrote: The much more serious issue is that we are not able to build non-trivial Rust applications: Given a package which needs to add phases, e.g. for fixing Cargo.toml, we would need to run each package's phases when building any depe

Re: rust (build system) deficits

Hi Hartmut, I agree with you. It seems like a problem for cargo to solve to me. Efraim tried to use the .rlib files to make library files and found it was not really an option. There are more problems, too. The way inputs are done doesn’t fit well with the rest of guix tooling and doesn’t rea

Re: Plan for a release!

Hi Guix, In addition I think issue #38544 (gparted segfaults) should be addressed before a release. I would imagine that partitioning is an activity that happens a lot around new installs. - John

Re: rav1e AV1 encoder

Hi Leo, > Since the packages refer to each other, committing them individually breaks the build until the entire commit series is complete. This will break `git bisect` for 267 commits (the number of packages). You should be committing packages in topological order but the file order is alphabe

Re: Qt build problems after bump to 5.12.7

Submitted qtbase-patched in bug #39758.

Re: Qt build problems after bump to 5.12.7

Pardon me, guix refresh qtbase --list-dependents actually says 668 packages would be rebuild

Re: Qt build problems after bump to 5.12.7

Hi Guix and T G-R, I think i verified that the upstream patch will fix the failing freecad build at least. guix refresh qtbase --list-dependents reports 377 dependents on qtbase though. So that leads to option 1. > 1. If more than 300 qtbase dependents currently build fine: apply > the fix[0] t

Re: Qt build problems after bump to 5.12.7

Hi T G-R, I think that makes sense. I am not sure when I can find the time to do it but I will try. - John

Qt build problems after bump to 5.12.7

Hi Guix, I was looking into the failing freecad build and I found the following bug from the qt 5.12.7 known bugs page (https://wiki.qt.io/Qt_5.12.7_Known_Issues). - Qt-based CMake projects might fail if their build directories contain dots: https://bugreports.qt.io/browse/QTBUG-81715 I think

Re: [WIP] gnu: Add fd. (rust)

> On Feb 7, 2020, at 8:54 AM, John Soo wrote: > I can submit the patches. Patches in at #39488

Re: [WIP] gnu: Add fd. (rust)

Hi Tanguy, I’m glad it helped :). I know how you feel. I felt the same way when ripgrep and alacritty finally worked. I can submit the patches. Can you confirm that fd is working, though? Thanks, John

Re: [WIP] gnu: Add fd. (rust)

y help would be welcome! Clap is missing a dependency in our package set currently. My patches fix that. Good luck! John From aa7847e578bbc40f158377d5265a7d5d49e7badf Mon Sep 17 00:00:00 2001 From: John Soo Date: Tue, 21 Jan 2020 09:55:21 -0800 Subject: [PATCH 4/7] gnu: rust-regex-1.1: Update

Re: Error while packaging Stack

Hi Tim, > I’m not sure, but I could take a look if you send a patch. When I read > this, I thought “response files!” However, the bug report you linked > suggests that there’s some reason they don’t work in this case. Ah man, I'm sorry I sent some patches but I messed up the subject line (see b

Re: Rust packaging coordination

Hi Andreas and everyone, Patches for exa are in #39382 > I have started packaging i3status-rust[1]. This is motivated primarily > by scratching my own itch, and to become more familiar with Guix > packaging. Excellent! Welcome and have fun! > - The dependency tree includes a portion of Rusts as

Re: (not) testing Rust packages?!

Hi Andreas, > On Jan 29, 2020, at 11:01 AM, Andreas Rottmann wrote: > > I'm a new to Guix, and am not sure what you mean by "safely" and > "unwanted store outputs". Running `cargo test` takes the crate source, > and the closure of any `dependencies` and `dev-dependencies`, and > produces no real

Re: Rust packaging coordination

Thanks Martin! I’m looking forward to the recursive crate importer. > On Jan 30, 2020, at 8:59 AM, Martin Becze wrote: > > After that is in I might > work on Alacritty, but if anyone wants to work on it in the meantime feel > free! I guess I’ll start on exa then. Thanks, John

Re: Rust packaging coordination

Hi rust packagers, We have: ripgrep, tokei, cbindgen. I cc'd nicolo because they mentioned wanting exa. I have a patch for it but there are tests failing. If they wanted to give packaging a try, that would also be welcome. I would also like to see alacritty updated to 0.4 in master. Alacritty 0.

Re: (not) testing Rust packages?!

Hey Andreas, > `cargo test` will always build the crate a second time, even if `cargo > build` already ran. This is due to the config attribute `test` being set > (similar a to C preprocessor #define), and thus the actual code being > compiled may be different. Just to make sure, does that mean w

Re: rust-build-system: Unvendor *-sys libraries in phase?

Hi Efraim, > I didn't mean to actually fix it, but it seems that just eliminating > directories is enough to make it work. > > I've attached a simple diff against cargo-build-system and rust-libz-sys > and rust-libgit2-sys which removes the bundled source from both crates > and builds rust-libgit2

Error while packaging Stack

Hi Guix! I'm working on packaging Stack and have all the dependencies. When I try to package stack itself, I get the following error: gcc: error trying to exec '/gnu/store/...-gcc-7.4.0/libexec/gcc/x86_64-unknown-linux-gnu/7.4.0/collect2': execv: Argument list too long I saw the following issue

Re: rust-build-system: Unvendor *-sys libraries in phase?

Hi Efraim, > IMO the correct way to do it would be in the crate source that we > download. We regularly add snippets to remove vendored code, this should > be no different. Totally agree. It seems like a challenge to me to do the other required work since all the building happens only when bu

Re: Parameterized packages

Hey all! I’ve been following very roughly. I have a couple issues with parameterized packages. > On Jan 22, 2020, at 4:24 AM, zimoun wrote: > > Well, I am wanting the same thing: be able to modify the 'arguments' > field but I am not convinced by the design you are proposing because I > have

Re: (not) testing Rust packages?!

Hi Hartmut and Martin, I think it makes sense to run tests now. > Part of the reason is that bringing tests for a given library can bring in a > massive amount of dependencies. I think that we are getting close to having complete dependencies for most rust packages we have and most are declare

rust-build-system: Unvendor *-sys libraries in phase?

Hi guix, After working on a few rust packages, it looks like there could be another step on the process. There are a number of libraries in the crates registry that wrap and vendor c libraries - libgit2, openssl, or jemalloc for example. The wrapping libraries, for reference, are usually calle

Re: Rust packaging coordination

Hi all, Thanks to Efraim, tokei is in master. John

Re: Rust packaging coordination

Hi Martin, > On Jan 18, 2020, at 9:21 AM, Martin Becze wrote: > > version 0.4.0. Attached is my version. Nice! I have 0.3.3. There were some install changes and updates since then. > I have a problem with mine: I can't get the man page to install correctly. The install process was hard on th

Re: Rust packaging coordination

Hi Martin! > On Jan 18, 2020, at 8:48 AM, Martin Becze wrote: > > I have packaged alacritty Nice! Me too! Which version did you package? > I'll wait until you get tokei in! Thank you! Sounds good to me! Can’t wait for alacritty upstream! John

Rust packaging coordination

Hello guix and rust packagers, I’m curious if anyone else is working on packaging rust apps. I have been working on a patch set for tokei and it’s getting close to done. I would not like it if I had to rebase all 50 patches and I wouldn’t want anyone else to have to rebase theirs. So if you ar

Re: extending the documentation of the Scheme API

Hi Ricardo, Yes! I think that would really emphasize the hackability of Guix. - John

Re: Overhauling the cargo-build-system

Hi all, I am working on ripgrep and I was wondering if we could add a key to inputs for cargo inputs instead of using the arguments field. Is there a downside to saying something like `(inputs (("rust-loom" ,rust-loom-0.2 #rust-build) ("rust-quickcheck" ,rust-quickcheck-0.9 #rust-dev

  1   2   >