Re: Merging ‘wip-newt-installer’ in master?

Hi all! I was working on adding more configuration options to the kmscon service. Do you think the service can take advantage of the config file, too? Thanks! John > On Jan 16, 2019, at 10:25 AM, Ludovic Courtès wrote: > > Hi again! > > I pushed a few commits to ‘wip-newt-installer’. > >

Re: Packaging FreeCAD

Hi Paul, Thank you for saving me the headache! I’ll keep this posted with progress. - John > On Jan 14, 2019, at 4:42 AM, Paul Garlick > wrote: > > Hi John, > >> I did not know Debian changed their version of opencascade > > There are two versions of OpenCASCADE in Debian, named

Re: Plan for fish shell in Guix.

Hello, I just have one issue with the patch so far: I can’t seem to unset an abbreviation. An old configuration file seems to be “sticking” around for lack of better term. Otherwise, good stuff! John > On Jan 21, 2019, at 12:32 AM, Meiyo Peng wrote: > > Hello everyone, > > Thank you for

Re: Plan for fish shell in Guix.

Hi, I’m trying it now. Everything seems to work pretty well! Thanks so much! This has been one major issue for me for a while! - John > On Jan 21, 2019, at 12:32 AM, Meiyo Peng wrote: > > Hello everyone, > > Thank you for your patience. > > I investigated the problem and chose to parse

Re: Plan for fish shell in Guix.

Ah! Makes sense! I haven’t had a chance to use 3.0 yet! I’ll try that and see. > On Jan 21, 2019, at 5:24 PM, Meiyo Peng wrote: > > Hi John, > > John Soo writes: > >> I just have one issue with the patch so far: I can’t seem to unset an >> abbreviation. A

hg-fetch with subrepos

Hi guix! Thanks and please bear with my first ever mailing list post. I was trying to package coin3d (https://bitbucket.org/Coin3D/coin/wiki/Home) as it is now under a bsd3 license. The hash of the repo always changes. I think this is due to the .hg files not being recursively deleted for

Re: hg-fetch with subrepos

Thanks! That patch looks familiar :D Looking forward to it. John On Sun, Dec 2, 2018 at 1:59 PM Ludovic Courtès wrote: > Hello, > > Björn Höfling skribis: > > > And I stumbled upon that problem too. Ludovic explained me on IRC: The > > problem is the metadata directory ".hg": It contains

Re: Brain storming cool Guix features

Yes, good ideas! I’m curious if per-user packages could be declared in the system configuration. I think nixOS has that feature now and I’m a little jealous... > On Jan 4, 2019, at 8:10 AM, Pierre Neidhardt wrote: > > Very nice ideas, in particular the manifest-file option! > > Note that

Re: Packaging FreeCAD

Hey Paul, I did not know Debian changed their version of opencascade. I will have to double check that they are using OCCT for FreeCAD still. - John > On Jan 11, 2019, at 1:35 AM, Paul Garlick > wrote: > > Hi John, > > This is good news indeed for Guix-using engineers and architects. I >

Packaging FreeCAD

Hello everyone, I started packaging FreeCAD in a personal channel (https://www.github.com/jsoo1/guix-channel). Has anyone already started or want to collaborate? I’m currently working on the python Shiboken library dependency which I could use some help on. There are a few other things that

Re: “Which important packages fail to build?”

Hi, I think icecat is ok. I’m probably wrong about this but what I understand is that icecat is being rebuilt after the rust bootstrap got merged. Upgrading icecat now requires building several versions of the rust compiler. I hope a substitute becomes available soon since it really does take

Packaging for guix

Hello pyside maintainers, Hope you are all well. I am looking to package freecad for the guix package manager for which pyside is a dependency. I’m having some trouble packaging pyside as the build and environment for guix (like nix) are quite different from a Debian style system. There a

Re: Packaging FreeCAD

10, 2019 at 7:25 AM Efraim Flashner wrote: > On Sun, Mar 10, 2019 at 02:14:15AM +0000, John Soo wrote: > > Hi guix, > > > > Just a quick update. I have little to report on freecad. I am still stuck > > packaging pyside2. I have looked over the debian packaging ru

Re: Packaging FreeCAD

alterations to some paths afterward. The package completely fails to compile for me and I am no expert on python build tooling. Here's what I have tried so far and the error: https://paste.debian.net/1072533. Any help would be very appreciated. Thanks, John On Fri, Feb 15, 2019 at 6:33 PM John Soo

Re: Haskell dependencies for custom cabal builds

019, at 8:06 AM, Timothy Sample wrote: > > Hi John, > > John Soo writes: > >> I’ll check out git-annex as a start. Custom Cabal builds would be a >> nice feature to add to the haskell-build-system. Would it be >> sufficient to add some extra argument to the build

Re: Haskell dependencies for custom cabal builds

12, 2019, at 11:21 AM, Timothy Sample wrote: > > Hi John, > > John Soo writes: > >> Hi there, >> >> I did a little digging this morning and it seems like runhaskell is >> probably deprecated in favor of runghc. Do we expect anyone to be >> using

Re: Haskell dependencies for custom cabal builds

gt; Hello! > > Timothy Sample writes: > >> Hi John, >> >> John Soo writes: >> >>> Hi there, >>> >>> I did a little digging this morning and it seems like runhaskell is >>> probably deprecated in favor of runghc. Do we expect any

Re: Packaging FreeCAD

Hello Guix, I have some small updates and asking for help on freecad (I’m working from my channel github.com/jsoo1/guix-channel). I have been getting a little stuck building the pyside2 dependencies. It seems like freecad is moving from the pyside1 tools (Shiboken and pyside) to pyside2 for

Haskell dependencies for custom cabal builds

Hi Guix, I’ve been working on some Haskell packages and got stuck recently and I didn’t know why until I realized the cabal files have `build-type: Custom` (http://hackage.haskell.org/package/termonad-1.1.0.0/termonad.cabal). I always get missing dependencies even though I have the

Re: Haskell dependencies for custom cabal builds

Thanks Tim, I’ll check out git-annex as a start. Custom Cabal builds would be a nice feature to add to the haskell-build-system. Would it be sufficient to add some extra argument to the build system? Best, John > On Feb 11, 2019, at 12:19 PM, Timothy Sample wrote: > > Hi John,

Re: Packaging FreeCAD

Thanks so much Paul! This is really helpful! > On Feb 15, 2019, at 9:20 AM, Paul Garlick > wrote: > > Hi John, > >> I have been getting a little stuck building the pyside2 dependencies > > There has been an effort to package pyside2 for Debian. This has been > completed in the last six

libelf uri broken?

Hi guix, I was wondering if the url we use for the origin of libelf is still valid. I tried curl and it redirected to an unresolved address. Looks like we have some substitutes on hydra, so it wasn’t such a problem. Just checking. - John

Re: libelf uri broken?

Excellent, thanks T G-R! > On May 25, 2019, at 6:40 PM, Tobias Geerinckx-Rice wrote: > > John, > > John Soo wrote: >> I was wondering if the url we use for the origin of libelf is still valid. I >> tried curl and it redirected to an unresolved address. Looks like w

Re: Packaging FreeCAD

the next release of FreeCAD. - John >> On Mar 9, 2019, at 11:25 PM, Efraim Flashner wrote: >> >> On Sun, Mar 10, 2019 at 02:14:15AM +, John Soo wrote: >> Hi guix, >> >> Just a quick update. I have little to report on freecad. I am still stuck >

Re: Packaging FreeCAD

Thanks Paul! I’m looking forward to it. Another question: do we tend to try to use guix packages whenever a package ships bundled with some third party source? - John > On May 30, 2019, at 9:23 AM, Paul Garlick > wrote: > > Hi John, > > It is good to hear that you have made such good

Re: Packaging FreeCAD

Hi Gabor! Thanks! I’ll let you know when I submit a patch. - John

Re: Packaging FreeCAD

Hi Guix! I'm excited to announce that I opened FreeCAD for the first time this evening thanks most recently to support on the FreeCAD forum! I am no expert in the use of the application, however, so I am sure some issues might be discovered with use. I already know of the following two issues:

Re: Packaging FreeCAD

Hi Paul, > How about engineering.scm for FreeCAD? This module already contains > other CAD-related packages such as LibreCAD and KiCad. Thanks. I did this and am preparing a patch now. - John

Re: Packaging FreeCAD

clarifying them when I submit a patch, Thanks for your help and guidance, John On Tue, Mar 12, 2019 at 3:15 PM John Soo wrote: > Thanks Efraim! > > That helped a lot. I Switched to version 5.11.3 and swapped qt for qtbase > and some extra qt libraries and that moved me past the one blocker

Re: Introducing myself

Hi Tanguy, I just realized you said you wanted an fzf replacement. I recommend fzy. It’s not quite as full featured as fzf but it gets the job done. - John > On Apr 18, 2019, at 1:19 PM, Tanguy Le Carrour wrote: > > (I've just realised that there was a typo in the subject… shame on me! > …

Re: [PySide] Packaging for guix

ux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/shiboken2 > [2] https://wiki.qt.io/Qt_for_Python/GettingStarted/X11 > ________ > From: PySide on behalf of John Soo < > js...@asu.edu> > Sent: Thursday, March 28, 2019 06:21 > To: py

Re: [PySide] Packaging for guix

at a time. Thanks again for all your help! - John On Sat, Apr 27, 2019 at 3:31 PM John Soo wrote: > Hi Cristián and Ricardo, > > A quick update: Shiboken2 builds! Thanks for your guidance! I may have > more questions when building freecad itself, but this was very helpful. > Thanks ag

Re: [PySide] Packaging for guix

Hi Cristián and Ricardo, A quick update: Shiboken2 builds! Thanks for your guidance! I may have more questions when building freecad itself, but this was very helpful. Thanks again! - John On Fri, Apr 19, 2019 at 1:06 PM John Soo wrote: > Hi Cristián, > > Thank you! I have been

Additional system fonts - Feature request/help request

Hi Guix! I have been looking into a different TTY font both for fancy glyphs and unicode support. I also looked into kmscon for keybindings and additional fonts, too. I like being able to specify a console font as a service. I can't use Tamzen, for instance, though, since the console font

Re: Packaging FreeCAD

Thanks for following along in this thread. I just submitted bug#36440. It needs some help but I figured we could continue the discussion there. - John On Wed, Jun 19, 2019 at 2:12 PM John Soo wrote: > Hi Paul, > > > How about engineering.scm for FreeCAD? This module already contai

Re: Maintainer needed for Linux-libre and IceCat packages

Hi Mark, Thank you so much for your work. I second Maxim, it’s sad to see you go and hope to see you around. - John

Re: Let’s merge ‘core-updates’!

Hi Guix, Two more items on core-updates: I get this message on most things now: guile: warning: failed to install locale. Also after a reboot, the early guile repl gets stuck populating /etc. Thanks! - John

Re: Let’s merge ‘core-updates’!

Hi there, I pulled to commit 3128d6a16a80d40d927c41f530dd48ebbb8a036d and tlsdate failed to build. Many other packages and services correctly updated. - John gdjpdqr9ks422a5vky3wj8hjw8diy1-tlsdate-0.0.13.drv.bz2 Description: Binary data

Re: Let’s merge ‘core-updates’!

Hi Marius and Guix, > To make the glibc 2.28 locales available and get rid of this warning for > packages you haven't updated yet, add this to your configuration and > reconfigure: > > (locale-libcs (list glibc-2.28 (canonical-package glibc))) That did the trick, thank you. > This is

Re: Rust = bust?

Hi Swedebugia, Hmm maybe the simplest workaround for a temporary hack would be to add #:tests #f to the arguments of the affected rust package definitions while you work on grin. It will be great when rust substitutes are reliably available... - John > On Jun 30, 2019, at 12:12 PM,

Re: Rust = bust?

Fortunately, I think rust tests are the longest build phase for rust. So I think even a rebuild of all dependents won’t take more than a few hours without tests. Hope rust is taken care of soon! - John > On Jun 30, 2019, at 12:35 PM, swedebugia wrote: > >> On 2019-06-30 21:32, Tobias

Re: Guix beyond 1.0: let’s have a roadmap!

Hi all, I’m a newcomer of sorts but I would like a programming abstraction over profiles. It feels like some requests for better cache file state handling, declarative user services, and declarative user packages could be gained. Plus I think profiles are still maybe the most confusing thing

Re: Stackage LTS 14

Hey everyone, When we bump to Stackage 14 can issue 36653 be closed? - John

Re: Stackage LTS 14

Ah, ok makes sense!

Re: Parallel downloads

Hi everyone, I’ve been watching this from afar and one thing and while I have to agree with this: > .. I suspect there’s little to > be gained by having several connections in parallel. I do have to say that more fine grained concurrency would really help speed up builds without substitutes.

Re: Stackage LTS 14

Hi Tim, Thanks for putting in the work. I use xmobar with a few extra options: dbus, alsa and maybe one more. I can’t remember. I can try submitting a patch for it this week. My only question is how many options should we enable? We can try all.

Re: Overhauling the cargo-build-system

Hi all, I agree with this: > The whole point of package management is that you can use module > building blocks. By having to specify the sub-dependencies in a top > level definition kinda breaks the whole modular thing. It is quite frustrating to have to specify transitive dependencies at the

Re: help with a confusing error: url-fetch, hash, invalid keyword #vu8

Hi Robert, Interesting. Looks alright to me. Also I did just package ormolu myself and everything worked alright. One thing to try is using `guix repl` to reproduce the error. Can you open one up and see what happens? - John

Re: help with a confusing error: url-fetch, hash, invalid keyword #vu8

Hi Robert, Excellent! Glad that helped :D. - John

Re: Stackage LTS 14

Thanks Tim, Marius! Good work! I am really happy about xmobar, it’s so much more stable now. I’ll take a look at idris next time I get the chance. - John

When to add rust packages?

Hi Guix, I packaged a number of Rust programs that I use everyday (ripgrep, alacritty) or I found useful when learning Rust (racer). With the instability of the rust build system and package definition they are a lot to maintain. I would love to send patches for them but I don't want to burden

Re: When to add rust packages?

Thanks, I’ll be sending some patches as soon as I can. As you all know, rust packages have a lot of dependencies so it could take some time. - John

Re: [Proposal] The Formal Methods in GNU Guix Working Group

Hey this is great! I’m a hobbyist too but I’m glad to see a formal methods community in Guix! I’ll be following. - John

Re: Packaging Mercury & Some Struggles

Hi Brett, I like having mercury-minimal I think that’s pretty considerate. To use (ice-9 match) you will need to add it to the list of #:modules in the arguments field then use-module in your phase. I.E.: (arguments `( #:modules ,(cons '(ice-9 match) %gnu-build-system-modules) ... Then in

Re: When to add rust packages?

Hi all, I submitted my patches this morning in #38640. Thanks for the continued work on the rust build system. I like rust tools quite a lot. - John

Adding Purescript

Hi guix, I have packaged PureScript in a channel and I would like to merge it Some of its dependencies are from hackage and are much newer than those in the stackage snapshot we use. So my question is where should the dependencies belong? Thanks! John

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

Hi Mark, I have it - but not with all the correct licenses. What version do you need? John

Re: guix gc doesn't seem to clean old guix revision

Hi, To delete old generations, use `guix system delete-generations`, for packages, use `guix package` with flag `delete-generations`. Hope that helps. As an aside, your question might find more traction on the help-g...@gnu.org list instead; guix-devel is the development list. - John

Re: articles on Elm and Guix

Thanks Robert! This is very relevant to my job. Nice write up! - John

Re: Stackage LTS 14

to put them? - John From 579f1152545ca873c2a38a9bd5ef5c48f394 Mon Sep 17 00:00:00 2001 From: John Soo Date: Thu, 14 Nov 2019 01:10:01 -0800 Subject: [PATCH 2/5] gnu: Add ghc-timezone-series. * gnu/packages/haskell-xyz.scm (ghc-timezone-series): Add it. --- gnu/packages/haskell-xyz.scm | 23

Unikernel build and deploy systems?

Hi guix! I have a more conceptual question than technical. I am really curious about unikernels and I know there is work to support the Hurd. So my thinking is: would it be possible to make a build and deployment system for unikernels? Advantages I see coming from guix are provenance tracking

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

Re: extending the documentation of the Scheme API

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

Helpful imenu matches

Hi Guix, I know there are a lot of emacs users here. I wanted to share this snippet I find really helpful when working with Guile: (defvar guile-imenu-generic-expression (cons '("Public" "^(define-public\\s-+(?\\(\\sw+\\)" 1) scheme-imenu-generic-expression) "Imenu generic expression

Re: Helpful imenu matches

Hi Pierre! Awesome! I will keep my eyes peeled. - John

Emacs 27

Hi guix, Speaking of the next version of emacs, do you think we could add an emacs-next package? I have tried to build from head recently and the recent changes to the dumping mechanism does not work with our current package definition. - John

Re: Emacs 27

Yay! Thank you! I saw Valentin’s channel just the other day. It looked like they solved the problem I had. Thanks again, John

Re: Qt build problems after bump to 5.12.7

Submitted qtbase-patched in bug #39758.

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

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

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

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: 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

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

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 to 1.1.9. * gnu/pac

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

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

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: 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

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

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

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

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

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

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

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

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

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]

Re: Qt build problems after bump to 5.12.7

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

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

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

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

Re: Rust packaging coordination

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

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

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

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: 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

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

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

  1   2   >