Re: Guix on macOS
On 12/10/2017 05:29, Chris Marusich wrote: But before I begin, I wanted to know: has anyone done this already? Is there interest? Interest, yes, from at least one more person: me. But I suspect this is a really big effort, in particular to boostrap the whole system based on Apple's XCode, which is all you can count on initially on a Mac. In other words, the issue is not porting the package manager but porting the package definitions. Konrad.
Re: 01/01: gnu: red-eclipse: Add store "data" package path as default.
Kei Kebreau skribis: > Leo Famulari writes: > >> On Tue, Oct 10, 2017 at 08:26:31AM -0400, Kei Kebreau wrote: >>> kkebreau pushed a commit to branch master >>> in repository guix. >>> >>> commit 42abb842f64f5dd7834cabd445a5f4d01f1e68a4 >>> Author: Adonay Felipe Nogueira >>> Date: Sun Aug 20 15:28:20 2017 -0300 >>> >>> gnu: red-eclipse: Add store "data" package path as default. >>> >>> * gnu/packages/games.scm (red-eclipse): Remove extra spaces. Make >>> version >>> respect documentation. >>> [arguments]: Add "prefix" to make-flags. Add >>> "add-store-data-package-path-as-default" phase. Improve "copy-data" >>> phase. >>> >>> Signed-off-by: Kei Kebreau >>> --- >>> gnu/packages/games.scm | 110 >>> ++--- >>> 1 file changed, 68 insertions(+), 42 deletions(-) >> >> [...] >> >>> @@ -133,6 +133,7 @@ >>>#:use-module (gnu packages gnuzilla) >>>#:use-module (gnu packages icu4c) >>>#:use-module (gnu packages networking) >>> + #:use-module (guix build utils) >>>#:use-module (guix build-system gnu) >>>#:use-module (guix build-system haskell) >>>#:use-module (guix build-system python) >> >> This module import created an ambiguous reference to 'which': >> >> WARNING: (gnu packages games): `which' imported from both (gnu >> packages base) and (guix build utils) >> >> I don't know if it will be a problem in practice. > > It looks like Ludovic took care of this in commit > db9c49f4999d4e5f6eb0565a6a80892131c55670. Thank you for the > notification, though. Right, I had overlooked Leo’s message. It was indeed a problem in practice, which prevented evaluation: packages such as ‘crawl-tiles’ were getting the procedure instead of the package as an input, which is invalid. Ludo’.
Re: Guix on macOS
Hi Chris, Chris Marusich skribis: > I want to get Guix working on macOS. I recently had a need to do this, > and I was sad to find that although Nix works on macOS, Guix isn't quite > there yet. The manual makes it sound like this should be fairly > straightforward, and I intend to give it a shot [1]. But before I > begin, I wanted to know: has anyone done this already? Is there > interest? I've checked the email lists, and I didn't find much > discussion about this. First of all, it’s never been a goal of Guix to run on non-GNU systems. Now, I have nothing against it in principle, as long as (1) this can be achieved in a maintainable way, and (2) the targeted user-land software is free and buildable from source. I suspect macOS fails criterion #2. Back in the day (not sure if that’s still the case), Nix would bootstrap using the system’s compiler and C library (which meant that things were likely to break in subtle ways on macOS upgrades.) As for criterion #1, to me, that pretty much means sticking to the GNU libc. From my experience on Nixpkgs, having to deal with different C libraries is a real burden. It also leads to a situation where you have second-class systems because they use an alternate libc and it’s not uncommon for packages to fail to build against that libc. To put it differently: it’s already difficult enough to have *one* OS working. I’m afraid this is not the answer you were looking for. WDYT? Ludo’.
Re: Guix on macOS
On Wed, 11 Oct 2017 20:29:57 -0700 Chris Marusich wrote: > Hi Guix, > > I want to get Guix working on macOS. I recently had a need to do > this, and I was sad to find that although Nix works on macOS, Guix > isn't quite there yet. The manual makes it sound like this should be > fairly straightforward, and I intend to give it a shot [1]. But > before I begin, I wanted to know: has anyone done this already? Is > there interest? I've checked the email lists, and I didn't find much > discussion about this. Hey Chris, I'm interested! My workplace hands out laptops running MacOS, and while I don't use one, and most people using them do development in a Ubuntu VM, I'd love to have the option to help my colleagues use Guix on their machines. > I know a lot of developers who use macOS as their primary workstation, > and most of them use a combination of Homebrew [2] and manual > installation for package management. It'd be great if Guix were easy > to use on macOS! Not only is it the best package manager (of > course! :-)), but it would be a great way to encourage the use and > growth of free software among this group of people. > > Additionally, if you're interested in helping out, please let me know. > To facilitate the work, I'm temporarily renting a Mac from MacStadium > [3] (it's just a weak little Mac Mini [4] for now), and it would be > trivial to give interested parties administrative access (via VNC and > SSH) to facilitate the work. I'd be interested in helping out, but I have never seriously used MacOS, so this would be quite a learning curve. Thanks, Chris pgp1XAi0uGMho.pgp Description: OpenPGP digital signature
Re: Guix on macOS
Ludovic Courtès writes: > Hi Chris, > > Chris Marusich skribis: > >> I want to get Guix working on macOS. I recently had a need to do this, >> and I was sad to find that although Nix works on macOS, Guix isn't quite >> there yet. The manual makes it sound like this should be fairly >> straightforward, and I intend to give it a shot [1]. But before I >> begin, I wanted to know: has anyone done this already? Is there >> interest? I've checked the email lists, and I didn't find much >> discussion about this. > > First of all, it’s never been a goal of Guix to run on non-GNU systems. > Now, I have nothing against it in principle, as long as (1) this can be > achieved in a maintainable way, and (2) the targeted user-land software > is free and buildable from source. > > I suspect macOS fails criterion #2. Back in the day (not sure if that’s > still the case), Nix would bootstrap using the system’s compiler and C > library (which meant that things were likely to break in subtle ways on > macOS upgrades.) > > As for criterion #1, to me, that pretty much means sticking to the GNU > libc. From my experience on Nixpkgs, having to deal with different C > libraries is a real burden. It also leads to a situation where you have > second-class systems because they use an alternate libc and it’s not > uncommon for packages to fail to build against that libc. To put it > differently: it’s already difficult enough to have *one* OS working. > > I’m afraid this is not the answer you were looking for. WDYT? > > Ludo’. Is there a way to maybe run Guix in some sort of namespaced or some variant of "virtualized" or "contained" way that we could recommend for OSX users, without having to bend over backwards to accomodate a different libc and etc? - Chris
Re: Guix on macOS
Ludovic Courtès writes: > First of all, it’s never been a goal of Guix to run on non-GNU systems. > Now, I have nothing against it in principle, as long as (1) this can be > achieved in a maintainable way, and (2) the targeted user-land software > is free and buildable from source. > > I suspect macOS fails criterion #2. Back in the day (not sure if that’s > still the case), Nix would bootstrap using the system’s compiler and C > library (which meant that things were likely to break in subtle ways on > macOS upgrades.) > > As for criterion #1, to me, that pretty much means sticking to the GNU > libc. From my experience on Nixpkgs, having to deal with different C > libraries is a real burden. It also leads to a situation where you have > second-class systems because they use an alternate libc and it’s not > uncommon for packages to fail to build against that libc. To put it > differently: it’s already difficult enough to have *one* OS working. I’m quoting all of what Ludo wrote here, because I absolutely agree. I investigated this in 2014 and once again in 2015 as I had access to some Macs at the office, but the very fact that there is no legal way to build the software in freedom makes this whole business very unattractive. I also looked at PureDarwin and the defunct OpenDarwin, as well as inofficial ports of the GNU C library to macOS — none of these roads looked promising as the software is hardly even buildable. The only way I could see this working is to support a mechanism for package graph sections, i.e. a way for a user to cheat and “graft” a section of a package graph onto a binary blob that the user says is equivalent. Obviously, that’s crude and we would sanction a hack as an official misfeature. We’d lose all guarantees that we’re working hard to provide. It would be regrettable to “support” Guix on macOS if that thing running on macOS hasn’t really much in common with Guix on GNU. Christopher wrote this: > Is there a way to maybe run Guix in some sort of namespaced or some > variant of "virtualized" or "contained" way that we could recommend for > OSX users, without having to bend over backwards to accomodate a > different libc and etc? In order to use the Hypervisor framework that macOS 10.10 and higher provide we would need to use Xcode, so we couldn’t even build a tool like that without relying on proprietary software. But we don’t have to build a tool like that, because it already exists in the form of virtual machine applications (or even Docker for Mac). The best we could do on macOS is to run applications in a GNU virtual machine and try hard to make them blend in. That’s not really appealing, neither technically nor practically, in my opinion. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: 01/04: gnu: mesa: Disable imx driver for armhf-linux.
mba...@fastmail.com (Marius Bakke) writes: > mbakke pushed a commit to branch master > in repository guix. > > commit 2a087882b1cb2e40e7b63580c675b58a5cfa1b96 > Author: Marius Bakke > Date: Thu Oct 12 18:57:30 2017 +0200 > > gnu: mesa: Disable imx driver for armhf-linux. > > * gnu/packages/gl.scm (mesa)<#:configure-flags>: Don't build imx driver. What is the rationale for this change? Although "guix refresh -l mesa" is failing to work for me at the moment, I'm fairly sure that this change will entail a massive rebuild on armhf-linux. In general, this kind of change belongs on another branch. Mark
