Re: Packaging FreeCAD

help 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 bl

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

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 progr

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 Gabor! Thanks! I’ll let you know when I submit a patch. - John

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

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

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 Geerinc

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

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 b

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: 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: Stackage LTS 14

place 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

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

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

Re: articles on Elm and Guix

Thanks Robert! This is very relevant to my job. Nice write up! - 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 yo

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 yo

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

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

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

Re: extending the documentation of the Scheme API

Hi Ricardo, Yes! I think that would really emphasize the hackability of Guix. - 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: 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 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 all, Thanks to Efraim, tokei is in master. 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 calle

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

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 bu

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

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

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

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

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

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

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 alphabe

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.

<    1   2