If in my OS config I define some luks mappings, and define the
corresponding filesystems with dependencies on the mapped devices,
I get an error on 'guix system reconfigure'.
Example:
(operating-system
...
(mapped-devices
(list (mapped-device ... (target "root"
(file-syste
Although we don't want to support non-free software, perhaps it would
be nice to support booting Guix on VMWare without the user needing to
do anything extra.
While experimenting, I found out that if we just add the following
three Linux modules to the standard initrd, Guix can boot on VMWare
just
l...@gnu.org (Ludovic Courtès) writes:
> [...]
>
> There’s also the option of not compiling (gnu packages *) and instead
> evaluating them, but currently this is too costly in terms of memory
> and CPU.
>
> [...]
Can't we leave this to auto-compilation during normal use of guix?
Taylan
l...@gnu.org (Ludovic Courtès) writes:
> Above the ‘wrap-program’ call, there’s this comment:
>
> ;; Ignore user settings so that a bogus
> ;; GUILE_LOAD_COMPILED_PATH does not prevent use of
> ;; 'guix', notably when it contains entries pointing to
> ;; incompatibl
l...@gnu.org (Ludovic Courtès) writes:
> Hello Taylan,
>
> taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
>
>> taylan@T420:~$ guix package -r nano
>> [... snip ...]
>> 75 packages in profile
>> The following environment va
'guix package' commands keep giving me this output:
The following environment variable definitions may be needed:
export
GUILE_LOAD_COMPILED_PATH="/home/taylan/.guix-profile/lib/guile/2.0/site-ccache:/home/taylan/.guix-profile/share/guile/site/2.0${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPI
Luis Felipe López Acevedo writes:
> Instead of the current patch, however, I'd change the whole paragraph
> to something like this (a combination with the current first paragraph
> on Wikipedia):
>
> GuixSD (Guix System Distribution) is a distribution of the [GNU
> operating system][link] centere
David Craven writes:
> Please change to the GNU distribution. Or alternatively if you are
> going to say a GNU distribution provide a link to or an explanation of
> what it means.
I wanted to avoid a larger discussion, but OK, I haven't ever written a
comprehensive answer to such a question, so
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
> It would be better to be consistent with the home page and make clear
> that GuixSD is a GNU distribution, with Linux-libre being the default
> kernel for the foreseeable future.
Here's a patch to the g
David Craven writes:
>> Using accurate terminology on Wikipedia is an intention of mine, and
>> changing the About page (and the FSF's endorsed distros page) not to
>> call GuixSD a GNU/Linux distro would help in that regard, but it's
>> arguably a petty issue so I don't intend to bother others w
David Craven writes:
>> I don't think this is the place to discuss that particular issue at
>> large. That can be done on Wikipedia, or elsewhere.
>
>> I think the Guix project authors probably agree on GuixSD being defined
>> as a GNU distribution. The question is whether or not to make the Ab
David Craven writes:
>> It would be better to be consistent with the home page and make clear
>> that GuixSD is a GNU distribution, with Linux-libre being the default
>> kernel for the foreseeable future.
>
>> Background: Wikipedia has a policy to call GNU/Linux distributions
>> "Linux distributi
It would be better to be consistent with the home page and make clear
that GuixSD is a GNU distribution, with Linux-libre being the default
kernel for the foreseeable future.
Background: Wikipedia has a policy to call GNU/Linux distributions
"Linux distribution" because that wrong term is more com
Leo Famulari writes:
> I realized that we don't seem to be saving any of the entropy in the
> kernel's random pool [0] across reboots.
>
> This means that for some period after boot, /dev/urandom may not be safe
> to use. From random(4):
>
> ---
> If a seed file is saved across reboots as recomm
To speed up the compilation of the many Scheme files in Guix, we use a
script that first loads all modules to be compiled into the Guile
process (by calling 'resolve-interface' on the module names), and then
the corresponding Scheme files are compiled in a par-for-each.
While Guile's module system
l...@gnu.org (Ludovic Courtès) writes:
> taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
>
>> Yes, it still goes through the tests and fails at guix-environment.sh
>> with the same error. I repeated all steps from a new clone of master.
>>
>
l...@gnu.org (Ludovic Courtès) writes:
> taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
>>>
>>>
l...@gnu.org (Ludovic Courtès) writes:
> taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
>
>> If one runs distcheck from within the build directory of an out-of-tree
>> build (perhaps a strange combination), the guix-environment.sh test
>> fa
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
> A user's profile is typically under:
>
> /var/guix/profiles/per-user/
Correction: this should have been:
/var/guix/profiles/per-user//guix-profile
Taylan
Danny Milosavljevic writes:
> Hello,
>
> right now on the GuixSD from the website I have about 12 copies of
> icecat installed in /gnu/store but I can start none of them by typing
>
> $ icecat
>
> Why not?
In Unix-like systems, an executable needs to be in any of the
colon-separated directorie
Fixed in d80ee44237ac14f26d785c279b73610ea9d5f2d0.
Taylan
Fixed in 7e81a761e7c4843c016818bbf1637af9047e2028.
Taylan
Fixed in 90ea9863c8daa4cc91e8a972501e19058c70b81a.
Taylan
Fixed in a0a0b7162e497bf064eb06c07efd5da4cf95dbe2.
Taylan
Actually close the bug.
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
> (See the first "Dangling .so references" bug report for more
> information.)
>
> /gnu/store/a06qvbsj0g07dcxm9gbryfdzgvvwrc2p-samba-3.6.25/
>
> /gnu/store/a06qvbsj0g07dcxm9gbryfdzgv
l...@gnu.org (Ludovic Courtès) writes:
> 2. Upon rollback from P to N, keep all the generations, but use P+1
> for the next generation number. Doesn’t work, because rolling back
> from P+1 would bring you back to P instead of N.
Perhaps we can eventually move to an actual tree struct
FYI this applies to 1.0.2 as well.
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/rifn72fhlvsgkvlwyy0cfy61kqpbfv4i-libvpx-1.3.0/
/gnu/store/rifn72fhlvsgkvlwyy0cfy61kqpbfv4i-libvpx-1.3.0/bin/vp8_scalable_patterns
libvpx.so.1 => not found
/gnu/store/rifn72fhlvsgkvlwyy0cfy61kqpbfv4i
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/qyjv704xl5wd34ffhpmwp7q0kk4w7k51-vamp-2.5/
/gnu/store/qyjv704xl5wd34ffhpmwp7q0kk4w7k51-vamp-2.5/lib/libvamp-hostsdk.so.3.5.0
libgcc_s.so.1 => not found
/gnu/store/qyjv704xl5wd34ffhpmwp7q0kk4w7k51-va
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/hcg2g6bbmyhld7f3gb16jks3rgi40l1k-python-3.3.5/
/gnu/store/hcg2g6bbmyhld7f3gb16jks3rgi40l1k-python-3.3.5/lib/libpython3.so
libpython3.3m.so.1.0 => not found
/gnu/store/hcg2g6bbmyhld7f3gb16jks3rgi40l1
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/gr60544gq3pldjdkcw8j0n0wpz8gcawh-subversion-1.7.18/
/gnu/store/gr60544gq3pldjdkcw8j0n0wpz8gcawh-subversion-1.7.18/lib/perl5/site_perl/5.16.1/x86_64-linux/auto/SVN/_Core/_Core.so
libsvn_client-1.so.0 =
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/avl3a1b08kqqk5cjxnyf8i3kv5j6f4sx-ghostscript-9.14.0/
/gnu/store/avl3a1b08kqqk5cjxnyf8i3kv5j6f4sx-ghostscript-9.14.0/bin/gsc
libgs.so.9 => not found
/gnu/store/avl3a1b08kqqk5cjxnyf8i3kv5j6f4sx-ghostsc
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/bpx0znz8ip68lxn4f2vi79n5c6pnqjy0-serd-0.20.0/
/gnu/store/bpx0znz8ip68lxn4f2vi79n5c6pnqjy0-serd-0.20.0/bin/serdi
libserd-0.so.0 => not found
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/a4jmxg7sc21i0nv2xfabx2h3immpwb1z-wxwidgets-2.8.12/
/gnu/store/a4jmxg7sc21i0nv2xfabx2h3immpwb1z-wxwidgets-2.8.12/bin/.wxrc-2.8-real
libwx_baseu_xml-2.8.so.0 => not found
libwx_baseu-2.8.so.0 =>
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/a06qvbsj0g07dcxm9gbryfdzgvvwrc2p-samba-3.6.25/
/gnu/store/a06qvbsj0g07dcxm9gbryfdzgvvwrc2p-samba-3.6.25/lib/libnetapi.so.0
libtalloc.so.2 => not found
libtevent.so.0 => not found
libtdb
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/8fg04g7j0jgimas62p234aha6mb25szs-icecat-31.4.0/
/gnu/store/8fg04g7j0jgimas62p234aha6mb25szs-icecat-31.4.0/lib/icecat-devel-31.4.0/sdk/lib/libsmime3.so
libnss3.so => not found
libnssutil3.so =>
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/4afh9gyyqiab8pbvvxk3d3k02avm7mh5-gcc-4.8.4-lib/
/gnu/store/4afh9gyyqiab8pbvvxk3d3k02avm7mh5-gcc-4.8.4-lib/lib/libstdc++.so.6.0.19
libgcc_s.so.1 => not found
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/8clg7hsanjcq6vn6ngwlp99nafbkavgx-cdparanoia-10.2/
/gnu/store/8clg7hsanjcq6vn6ngwlp99nafbkavgx-cdparanoia-10.2/lib/libcdda_paranoia.so.0.10.2
libcdda_interface.so.0 => not found
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/3mvj75qj7nnq384a11qa660x4yzzn38n-sord-0.12.2/
/gnu/store/3mvj75qj7nnq384a11qa660x4yzzn38n-sord-0.12.2/bin/sordi
libsord-0.so.0 => not found
/gnu/store/3mvj75qj7nnq384a11qa660x4yzzn38n-sord-0.12.2/bin
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/2fn7myy7bvkqvfx9fksgygj2wi24yzqa-python-2.7.6/
/gnu/store/2fn7myy7bvkqvfx9fksgygj2wi24yzqa-python-2.7.6/lib/python2.7/lib-dynload/_codecs_iso2022.so
libpython2.7.so.1.0 => not found
/gnu/store/2fn7
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/3knv9nrzpq50yjl9711p6ivjjpr3493h-libcap-2.22/
/gnu/store/3knv9nrzpq50yjl9711p6ivjjpr3493h-libcap-2.22/sbin/getpcaps
libcap.so.2 => not found
/gnu/store/3knv9nrzpq50yjl9711p6ivjjpr3493h-libcap-2.22/sb
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/24zz6gxb2i1jm3miazwdy0pc1s1ybz63-openssl-1.0.1j/
/gnu/store/24zz6gxb2i1jm3miazwdy0pc1s1ybz63-openssl-1.0.1j/lib/libssl.so.1.0.0
libcrypto.so.1.0.0 => not found
/gnu/store/24zz6gxb2i1jm3miazwdy0pc1s1
(See the first "Dangling .so references" bug report for more
information.)
/gnu/store/1cs8vjcwqw91wy4l02c9k99s7fp17c14-lilv-0.20.0/
/gnu/store/1cs8vjcwqw91wy4l02c9k99s7fp17c14-lilv-0.20.0/bin/lilv-bench
liblilv-0.so.0 => not found
/gnu/store/1cs8vjcwqw91wy4l02c9k99s7fp17c14-lilv-0.20.
While looking into another issue, I happened to notice dangling .so
references in some executables in Guix packages. This is the first in a
series of bug reports for each such package. Some might be false
positives; Mark suggested I report them all so we have a list to go
through. It's also not
The other day I ran "guix package -d 1d" thinking it will preserve the
current generation, but it didn't. If I'm not mistaken, there's no
recovery from that either.
Any command that will delete even the current generation should probably
interactively warn/prompt the user by default, or fail, unl
Andreas Enge writes:
> It has been built before. For x86_64:
> "Last successful build 2015-01-16 13:52:19
> First brokenbuild 2015-02-05 13:07:42"
>
> Andreas
Oh never mind, I thought Guix would use an old binary substitute, but of
course that doesn't make sense (it wouldn't be an actual su
Andreas Enge writes:
> On Sat, Feb 07, 2015 at 09:45:22PM -0500, Mark H Weaver wrote:
>> In fact, this was my motivation for commit 710f3ce44, which removed
>> our last remaining user of gstreamer-0.10.x. However, we might want
>> to add some software in the future that still needs gstreamer-0.1
48 matches
Mail list logo
