Re: [ungrafting] cURL is missing the 'curl-use-ssl-cert-env' patch
Marius Bakke skriver: > Now the question is: should we restore this patch, and in practice > restart the branch almost from scratch? Or drop it, considering > upstream has rejected it[0]? Following a discussion on IRC, we decided to reinstate the patch and get rid of the newly added graft at the same time. Apologies to those who already started building it! signature.asc Description: PGP signature
Re: Staging branch
Thank you! Let’s test!
Re: Staging branch
On Sun, Dec 13, 2020 at 02:12:59PM -0800, John Soo wrote: > As far as I understand it, it adds just enough to the rust package > definition to add the extra rustfmt output. Okay, I tweaked the commit message and pushed as 48926b588528c5a2b591e1e97a5757eb78d3cac1. Now the branch is frozen! Let's get to work making sure everything still works :) signature.asc Description: PGP signature
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
On Sun, Dec 13, 2020 at 01:50:35PM -0800, John Soo wrote: > The patch adds an extra output, leaving the compiler unchanged so nothing > should be effected in runtime as far as I know. But the patch does a lot more than just add another output, right?
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
On Sun, Dec 13, 2020 at 01:44:01PM -0800, John Soo wrote: > 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? What I'm wondering is: does the patch make a simple change that is unlikely to break a lot of dependents? Or could it be more complicated? For example, changing a piece of documentation will probably not break any dependents and, if it did, it would probably be easy to fix. On the other hand, updating the Python interpreter is usually a huge amount of work because many Python packages break and require upstream fixes. Are you able to "guesstimate" the impact of this patch in those terms? I know very little about Rust so I'm not able to.
Re: Staging branch
Leo Famulari writes: > On Sun, Dec 13, 2020 at 12:02:50PM -0800, John Soo wrote: >> Is there any chance this could make it to staging before the merge? >> >> http://issues.guix.gnu.org/42295 > > Can you clarify what it does (I'm not that familiar with Rust). > > Is it likely that things will "just work", or will we need to do a lot > of clean-up work? The staging branch is for "non-disruptive" changes > that cause between 300 and 1800 packages to be rebuilt. > > I counted 1175 instances of 'rust-build-system' in the packages, so if > it rebuilds every Rust package, it's within the limits for staging. I'm > not sure how many non-Rust packages depend on Rust transitively — ffmpeg > is one. It's a bit difficult to find, but following through from this Patchwork series [1], you can find this list of affected packages [2]. Unfortunately that page doesn't give a count, but clicking through to the JSON representation of the data, gives an array with 1663 elements in it, so I think there are 1663 packages where the derivation would change (at least for x86_64-linux). 1: https://patchwork.cbaines.net/project/guix-patches/patch/5407eb2f-b499-2520-e0e5-48ca7171e...@ftbfs.org/ 2: https://data.guix-patches.cbaines.net/compare/package-derivations?base_commit=1485736b94706a29db3d3b3d7ff9f9e69bfaef67_commit=178c879ef04bfa876606ab1f849430b12b291b35=x86_64-linux=none_change=_name=_results=_results=on signature.asc Description: PGP signature
Re: Staging branch
On Sun, Dec 13, 2020 at 12:02:50PM -0800, John Soo wrote: > Is there any chance this could make it to staging before the merge? > > http://issues.guix.gnu.org/42295 Can you clarify what it does (I'm not that familiar with Rust). Is it likely that things will "just work", or will we need to do a lot of clean-up work? The staging branch is for "non-disruptive" changes that cause between 300 and 1800 packages to be rebuilt. I counted 1175 instances of 'rust-build-system' in the packages, so if it rebuilds every Rust package, it's within the limits for staging. I'm not sure how many non-Rust packages depend on Rust transitively — ffmpeg is one.
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: Staging branch
On Sun, Dec 06, 2020 at 12:58:46PM -0500, Leo Famulari wrote: > The plan is to start building it next Friday, December 11. Due to reasons, there are still a few more patches to be added to the branch. They should be pushed today. The plan is to work on the branch this week and complete it next weekend. signature.asc Description: PGP signature
Polkit now depends on Rust
Hello, Newer versions of 'polkit' depend on mozjs 78, which unsurprisingly depends on Rust. As Rust currently only builds on x86_64, that means an important piece of desktop systems will no longer work on other architectures. How should we deal with this? I see a couple of options: 1. Stick with Polkit 0.116 indefinitely, backporting security fixes as they are discovered. 2. Use the newer version of Polkit on x86_64 only, leaving other architectures to "fend for themselves" so to speak. 3. Make Polkit work with mozjs 60. 4. Fix Rust on other architectures. Obviously 4 is the better option, but I suppose it can take a while. I don't think anyone is actively working on it. Volunteers wanted! Thoughts? signature.asc Description: PGP signature
Re: FAQ: How to set up a guix development environment?
Am 13.12.20 um 14:21 schrieb Christopher Baines: I think if you add openssl to --ad-hoc along with nss-certs, then you should get the search paths setup. Thanks, this did the trick -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: FAQ: How to set up a guix development environment?
Hartmut Goebel writes: > Hi, > > for setting up a guix development environment, the manual recommends > >guix environment guix > > Anyhow, this is not enough, since e.g "./preinst-env guix lint" will > fail with "TLS certificate error". Also > >guix environment guix --ad-hoc nss-certs > > does not succeed, since SSL_CERT_DIR still need to be set up manually. I think if you add openssl to --ad-hoc along with nss-certs, then you should get the search paths setup. signature.asc Description: PGP signature
FAQ: How to set up a guix development environment?
Hi, for setting up a guix development environment, the manual recommends guix environment guix Anyhow, this is not enough, since e.g "./preinst-env guix lint" will fail with "TLS certificate error". Also guix environment guix --ad-hoc nss-certs does not succeed, since SSL_CERT_DIR still need to be set up manually. Currently I'm working around this by using shell-scripts, shih re setting ups profiles and re-spawning the shell. Anyhow. I'm seeking for a more elegant solution. Any ideas? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Specifying dependencies in manifest
Hi, how to specify "dependencies of package" in a manifest? Background: I'm using a manifest file for defining my development environment and keeping up with the dependencies of some of the packages is cumbersome. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
