Re: syslogd can't be started when running Guix in Docker

Hi Konrad, On July 2, 2019 5:16:40 PM UTC, Konrad Hinsen wrote: >Hi everyone, > >I am exploring the possibility of running Guix under macOS via Docker. >First I ran 'guix system docker-image` on a minimal system >configuration, which I then transferred to the Mac and started. >Overall it works a

syslogd can't be started when running Guix in Docker

Hi everyone, I am exploring the possibility of running Guix under macOS via Docker. First I ran 'guix system docker-image` on a minimal system configuration, which I then transferred to the Mac and started. Overall it works admirably well. There are however a few services that don't work, in parti

Re: Suggest another way of importing GNU Guix GPG key

On Sun, Jun 30, 2019 at 11:44:04AM +0200, Giovanni Biscuolo wrote: > This means we should quckly patch Guix manual: I've no time to propose a > patch today, I'll work on this tomorrow > > We also nees to address this for **all** guix contributors: we require a > GPG signed commit, so each and ever

Re: distinguishing between applications and libraries

Ricardo Wurmus writes: > A good reason would be that the package *cannot* be used for anything > else (e.g. when it’s a custom variant of a library that would > otherwise be bundled but we decided to build it separately). Ah, that's good to know for something else I'm packaging. :) > We hid “gc

Re: distinguishing between applications and libraries

Hi, On Tue, 2 Jul 2019 at 15:35, Robert Vollmert wrote: > > On 1. Jul 2019, at 23:48, Ricardo Wurmus wrote: > >> - `guix search` would ignore library packages by default > > > > I think it’s valid for users to want to install libraries. For Python, > > for example, installing modules that don’t

Re: distinguishing between applications and libraries

> On 1. Jul 2019, at 23:48, Ricardo Wurmus wrote: >> - `guix search` would ignore library packages by default > > I think it’s valid for users to want to install libraries. For Python, > for example, installing modules that don’t provide any executables > appears to be the norm. The idea wou

building faust programs

Hello guix! I tried compiling faust programs under guix environment: guix environment --ad-hoc faust pkg-config gcc-toolchain jack2 alsa-lib gtk+@2 It seems that both FAUST_INSTALL and FAUST_LIB_PATH needs to be exported in order to compile programs. Do we need a wrapper of some kind? (with: FAUS

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

Ivan Petkov writes: > [...] > I tried building some of the crates and most of the errors I saw were > something > like “failed to select a version for the requirement `foo = ^0.6 > candidate versions found which didn’t match: 0.8.5”. > > Please note that the crate importer always picks the lates

Re: distinguishing between applications and libraries

Pierre Neidhardt writes: > Ricardo Wurmus writes: > >> To completely hide a package from the UI use “hidden-package” or >> “(properties ((hidden . #t)))”. > > This is great, didn't know that! Is it in the manual? Sadly, there are a lot of Guix API things missing from the manual. I’d love to

Re: distinguishing between applications and libraries

Hi Jakob, > But since we're having this conversation now, I'd like to ask: does it > make sense to use 'define-public' for dependencies like that? I'd be > adding a lot of 'go-github-com-...' packages like those in > 'gnu/packages/syncthing.scm'. I’d use define-public for all packages unless th