Re: A few thing we might consider hosting

I was aware of the discussion thread, however I could not find out what the current state is? Do we plan to modify this behaviour in the next release? The core-updates thing makes sense, thanks. 2017-12-03 8:19 GMT+01:00 Gábor Boskovits : > Ok, thanks for clarification. > I

Re: A few thing we might consider hosting

Ok, thanks for clarification. I 2017-12-03 0:29 GMT+01:00 Leo Famulari : > On Sat, Dec 02, 2017 at 05:28:51PM +0100, Gábor Boskovits wrote: > > Sometimes while working in guix I run into problems because: > > 1. a tarball was removed or modified upstream > > > > It would be

Improving Elixir support

I am forwarding this from the bug tracker because I believe it is of general interest to those working on Elixir/Erlang. http://lists.gnu.org/archive/html/bug-guix/2017-12/msg00019.html

Re: A few thing we might consider hosting

On Sat, Dec 02, 2017 at 05:28:51PM +0100, Gábor Boskovits wrote: > Sometimes while working in guix I run into problems because: > 1. a tarball was removed or modified upstream > > It would be great to have the ability to install the latest release in all > the supported ways on all supported

Re: gcc-ddc

>> I guess I can do something like add an environment variable >> GUIX_INSTALL_DIRECTORY, or something like that... > > What's different about GUIX_INSTALL_DIRECTORY than the usual: PREFIX? The value of that variable would not be embedded in the binary. It is looked up at runtime, so the

Re: Installing some packages results in "incomplete deployment"

I agree with that. It would however mean additional metadata on the packages. If there is consent, that this is a good idea, we could find out what additional information is needed, and how to integrate that. It could be done like test, or strip-binaries... Then if we have the current behaviour as

Re: Installing some packages results in "incomplete deployment"

On December 2, 2017 4:50:04 AM EST, Chris Marusich wrote: >Hi, > >Some Guix packages exist which are not intended to be installed into a >user's profile. For example, android-udev-rules's description says: > >_Simply installing this package will not have any effect._ It

A few thing we might consider hosting

Sometimes while working in guix I run into problems because: 1. a tarball was removed or modified upstream It would be great to have the ability to install the latest release in all the supported ways on all supported architectures, and have the ability do guix pull without problems. Last time I

Re: gcc-ddc

Ok, I will do that. I can eliminate differences in the wrappers easily, then I will look into the libtool patch. It seems, that the la files are causing the checksum difference in cc1 and cc1plus, because if I remove libraries from the checksum, then they agree. I also checked the same things

Re: gcc-ddc

Gábor Boskovits writes: > Aside from these libtool files we can now say, that this ddc project > succeeded. Wait... The libtool's .la files are now the only files that show any difference, even when gcc is compiled into it's own prefix? That's amazing!!! > I've contacted the libtool

Re: Installing some packages results in "incomplete deployment"

I agree with this. I would add a few more to the list of states I would like to see managed in some standard way. One of these is hardware state, for example do some automated action if a raid array degrades, or a disk removed/added... Another on that would be great to have is some way to manage

Installing some packages results in "incomplete deployment"

Hi, Some Guix packages exist which are not intended to be installed into a user's profile. For example, android-udev-rules's description says: _Simply installing this package will not have any effect._ It is meant to be passed to the `udev' service. Still other packages do not work if