Re: BTRFS, LVM, LUKS

Alexandre Oliva writes: > Full-disk encryption (LUKS) is also a strict requirement for me, and so > is multi-disk BTRFS. Note that full disk encryption does work without LVM in Guix, though you do need to then pretty much put everything on one partition :) I think you can also do full disk encry

Re: guix import crate wraps #:cargo-inputs twice

Hey Arne, > On Jun 30, 2019, at 2:20 PM, Arne Babenhauserheide wrote: > > I’ve been working at getting a current Firefox packaged, but > got stuck now. If you’re interested I could send you all the rust > package definitions I created for that — maybe you’ll spot the mistake > right-away. Thank

Re: GNU gettext 0.20.1 released

Hi Miguel, Miguel writes: > Hi Tobias, > > Tobias Geerinckx-Rice : >> Bruno, >> >> Wow. Thank you for this great summary! Would that all projects >> published such clear (and custom) release notes… <3 >> >> I see that gnu/packages/gettext.scm has a nice chronological list >> of copyright

Re: distinguishing between applications and libraries

Robert Vollmert writes: > Good point, but that breaks down once a library is used by a package > outside that module. E.g. consider the various ghc-* packages. Running > “guix search clock” returns `ghc-clock` and `ocaml-mtime`. The first > needs to be public since it’s used elsewhere, the second

packaging postgrest, haskell patches

Hi, now that postgrest 6.0.0 has made it to hackage: http://hackage.haskell.org/package/postgrest I’d like to submit my packaging of it for inclusion in guix. The current state is visible here: https://github.com/robx/guix-postgrest Some questions/open issues: * I’ve submitted a few patch

Re: Rust = bust?

Swedebugia, swedebugia wrote: The following files would be downloaded: \o/ Hooray! Thanks a lot. You're very welcome. Let's hope ci.guix (I must say, ‘Hydra’ rolled off the tongue a lot easier) catches up soon. Kind regards, T G-R signature.asc Description: PGP signature

Re: distinguishing between applications and libraries

> On 30. Jun 2019, at 20:01, Pierre Neidhardt wrote: > > Hi Robert! > > `guix search` and other user-facing tools ignore non-exported packages. > > So you can simply use `define` instead of `define-public` to declare a > package. Good point, but that breaks down once a library is used by a

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: Rust = bust?

On 2019-06-30 21:35, swedebugia wrote: I logged into my substitute server to find out more, but:   athena.tobias.gr ~ λ guix describe   Generation 109  Jun 30 2019 21:11:58    (current)     guix a3d1a34   repository URL: https://git.savannah.gnu.org/git/guix.git   branch: master   c

Re: Rust = bust?

On 2019-06-30 21:32, Tobias Geerinckx-Rice wrote: Swedebugia, swedebugia wrote: http://ci.guix.gnu.org/search?query=rust-1.30 -> http://ci.guix.gnu.org/build/1303680/details "dependency failed" What does that mean? What is going on? That a package (well, derivation) upon which rust@1.30.1 d

Re: Rust = bust?

Hi On 2019-06-30 21:27, Ivan Petkov wrote: Hi swedebugia, Rust 1.30 was recently broken I believe when gdb was upgraded. I’ve pushed out a fix, Nice. so rust 1.30 and anything else should build successfully. Unfortunately there are no substitutes for this currently (the CI keeps showing j

Re: Rust = bust?

Swedebugia, swedebugia wrote: http://ci.guix.gnu.org/search?query=rust-1.30 -> http://ci.guix.gnu.org/build/1303680/details "dependency failed" What does that mean? What is going on? That a package (well, derivation) upon which rust@1.30.1 depends failed to build. I'm almost certain that

Re: Rust = bust?

Hi swedebugia, Rust 1.30 was recently broken I believe when gdb was upgraded. I’ve pushed out a fix, so rust 1.30 and anything else should build successfully. Unfortunately there are no substitutes for this currently (the CI keeps showing jobs in progress and failing after a day, maybe the buil

Re: Rust = bust?

On 2019-06-30 21:12, swedebugia wrote: Hi I'm eager to begin building grin which relies on rust 1.34+ but I get this from a guix checkout compiled yesterday: The following derivations would be built:    /gnu/store/9d9r8c70yz329gl01ywgvf4gql9ir31f-grin-1.1.0.drv    /gnu/store/hgpjq9f5z6rpmid

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

Rust = bust?

Hi I'm eager to begin building grin which relies on rust 1.34+ but I get this from a guix checkout compiled yesterday: The following derivations would be built: /gnu/store/9d9r8c70yz329gl01ywgvf4gql9ir31f-grin-1.1.0.drv /gnu/store/hgpjq9f5z6rpmidsij7nrp20ad38vg98-rust-1.35.0.drv /gnu/

Re: distinguishing between applications and libraries

Hi Robert! `guix search` and other user-facing tools ignore non-exported packages. So you can simply use `define` instead of `define-public` to declare a package. For instance: --8<---cut here---start->8--- (define my-package ... ) --8<---cut

distinguishing between applications and libraries

Hi, I’m currently packaging some tools that would add a decent amount of source-only dependencies. (Some from npm, some for elm). Clearly they should somehow be packaged properly in order to track licensing information and refer to upstream. On the other hand, it doesn’t feel particularly useful

Re: guix import crate wraps #:cargo-inputs twice

Hi Arne, > On Jun 21, 2019, at 2:53 PM, Arne Babenhauserheide wrote: > > Hi, > > When using guix import crate flamer, it generates a pattern like > > (arguments >`((#:cargo-inputs > (("rust-flame" ,rust-flame) >("rust-quote" ,rust-quote) >("rust-syn" ,rust-syn) >

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

Hi Guix! Ludovic Courtès writes: [...] > * devops > > ** TODO ‘guix system reconfigure --target=host.example.org’ is a thing > ** TODO ‘guix deploy’ is a thing ** TODO a Guix version of [[NixOps][https://nixos.org/nixops/]] Having the two above this last one should not be too hard to achie

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

Hello Alex, "Alex Griffin" writes: [...] > ** TODO run-time configuration system for services, similar to OpenWrt's UCI I don't understand this: do you propose to have a CLI to add system configuration sections to a system configuration file? Guix EDSL is much much more flexible than UCI, AFA

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

(this should really be a top-level reply, but I missed the original mail) On 30. Jun 2019, at 15:13, Giovanni Biscuolo wrote: > > Hello, > > Ludovic Courtès writes: > > [...] > >> What do *you* want Guix to address in the future? >> >> #+TITLE: GNU Guix Beyond 1.0—A Road Map A bit of an ou

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

Ludovic Courtès writes: > * UI/UX > > ** TODO grafts and profile hooks run as “build continuations” > > ** TODO ‘package-derivation’ made faster > ** TODO (gnu installer) UI can be used to edit config.scm > ** TODO ‘guix system status’ shows info about the current sta

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

Hello, Ludovic Courtès writes: [...] > What do *you* want Guix to address in the future? > > #+TITLE: GNU Guix Beyond 1.0—A Road Map [...] > * infrastructure > > ** TODO web site officially available at https://guix.gnu.org > ** TODO web site includes a package and service browser > ** TODO G

Re: BTRFS, LVM, LUKS

Hi lxo, I can give some advice reg. libreboot+luks+btrfs, but not reg. LVM and I haven't tested a a btrfs multi-disk setup with GuixSD either unfortunately. Using btrfs and luks on a librebooted laptop works well. > Full-disk encryption (LUKS) is also a strict requirement for me, and so > is mu

Re: guix lint TLS certificate error

Ludovic Courtès writes: > Hi, > > Giovanni Biscuolo skribis: > >> /home/giovanni/{git}/giovanni.biscuolo.net/guix/gnu/packages/astronomy.scm:190:4: >> celestia@1.6.1-815.9dbdf29: failed to create x86_64-linux derivation: >> (srfi-34 #> "/usr/local/var/guix/daemon-socket/socket" errno: 111] 657

Re: Packaging Grisbi

Dear Timothy, Le 06/12, Timothy Sample a écrit : > It looks like all you need to do is install “dconf”. It should work if > you install it into your user profile either using a manifest file or > with “guix install dconf”. (I seem to recall you tried this before, but > looking at the results abo

Re: BTRFS, LVM, LUKS

Hello Alexandre, wellcome to Guix! Alexandre Oliva writes: [...] > My first concern is that it's not clear to me what's meant by lack of > LVM support. I saw patches around April-May 2015, some later > discussions, but not much that would give me much of a clue as to what's > really missing,

Re: Suggest another way of importing GNU Guix GPG key

Hello Guix! Alex Vong writes: > One solution would be to download the keyring from > and verify the signature in > the following way: > > $ gpg --keyring ./gnu-keyring.gpg --verify guix-1.0.1.tar.gz.sig > guix-1.0.1.tar.gz > Correct, the quick and "d