Can't develop on foreign distro - core dump linking error
Hi, after happily developing guix on a foreign distro for quite some years (well, I had some issue now and then but was always able to recover), I'm no longer able to do so: - "make" fails when linking guix-daemon with "undefined reference to `__twalk_r@GLIBC_PRIVATE'" - ./pre-inst-env guix --help dumps core Any ideas? I tried make distclean ; bootstrap ; ./configure ; make with no success. Environment: guix 50812aaeb6c8c736a73547b781b8e47b8b345ed1 guix package --manifest=$PWD/develop-profile.scm --profile=$PWD/.develop-profile active this profile make distclean ; bootstrap ; ./configure ; make -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Can't develop on foreign distro - core dump linking error
Have you tried building in a Guix container? See 'bullet proof' in my guix-notes. On Sat, Jan 02, 2021 at 11:00:27AM +0100, Hartmut Goebel wrote: > Hi, > > after happily developing guix on a foreign distro for quite some years > (well, I had some issue now and then but was always able to recover), > I'm no longer able to do so: > > - "make" fails when linking guix-daemon with "undefined reference to > `__twalk_r@GLIBC_PRIVATE'" > > - ./pre-inst-env guix --help dumps core > > Any ideas? > > I tried > > make distclean ; bootstrap ; ./configure ; make > > with no success. > > Environment: > > guix 50812aaeb6c8c736a73547b781b8e47b8b345ed1 > > guix package --manifest=$PWD/develop-profile.scm > --profile=$PWD/.develop-profile > active this profile > make distclean ; bootstrap ; ./configure ; make > > -- > Regards > Hartmut Goebel > > | Hartmut Goebel | h.goe...@crazy-compilers.com | > | www.crazy-compilers.com | compilers which you thought are impossible | > >
Re: Discussion: How to package rust crates now and in future?
Hi Pjotr, Am 19.12.20 um 07:42 schrieb Pjotr Prins: > They are talking about librification of the language > https://rust-lang.github.io/compiler-team/minutes/design-meeting/2020-03-12-shared-library-for-types/ > which may lead to a wider idea of libraries. For your needs static libraries would suffice. Anyway: Unfortunately this feature did not make i to the 2021 roadmap, AFAICS. I'd be happy enable building crates when rust has some notion of library. Until then I strongly propose to not build intermediate creates per default. > The language may still be changing - but I think it has gotten to the > point that they can't change too much without hurting large software > projects. It probably is a bad idea to mix different compilers to > build crates in one software stack. Maybe I am misreading your idea, > but we either have a 1.40 build or a 1.46 build. Unfortunately this is not just an idea, but a sad reality :-( As of today, the rust used by cargo-build-system is still 1.45, while some crates (e.g. sequoia) require 1.46 language features. So in fact we already/currently have a mixed stack. Maybe this is just since nobody did update default rust to rust 1.46?! Anyhow, my argument about rebuilding without any use still holds: When upgrading rust, all crates will be be rebuild (which is part of guix's concept) and the results are thrown away right away - which is a wast of time and electrical power. >>6) This not only effect berlin, but also every user out there requiring >>a rebuild for some reason. This will lead to a very, very bad user >>experience - practically kicking out users with less powerful >>equipment. > The Rust user experience is that Rust builds all crates or installs a > single (static) binary. Even for Guix developers, the default is to > use cargo because of the insane number of dependencies it typically > pulls in. We package dependencies when we want to deploy, not to > develop. I assume you are referring "Rust user" to someone using rust for developing some rust software? I'm referring "user" to someone using Guix for managing their system. > The user here is a guix user, of course. So between compiler versions > we rebuild the stack and then distribute binaries. No rebuilds get > triggered normally. I think the use case you are referring to is users > as developers (right?) who are actually used to waiting for cargo. I > wait for cargo when I start a new Guix development environment. FMPOV there is not much difference between a user and a developer here: If substitutes are not available, a user - and this includes developers - needs to build the packages. And even as a developer I don't want to build the whole stack myself, but use substitutes - like I want to use pre-built libraries for other languages. My point is another one: While for programming languages supporting (static) libraries the number of compiles is O(n), for rust – assuming #:skip-build #f – it is O(n*(num_average_dependencies+1)) - since each crate needs to compile all of its dependencies, even if 20 other creates did this already. To give you some numbers: sequoia 0.20.0, while directly depending on only 55 crates, pulls in more then 430 crates (in words: four hundred and thirty) and compiles about 280 (in words: two hundred and eighty), including some duplicates compiles. Assuming each package depends on one other crate (which is a low assumption), this will be 2*n=860 compiles. Assuming each compile takes 30 seconds, and half of the packages need rebuild, this is more the 3,5 hours - right away into the trashcan. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Discussion: How to package rust crates now and in future?
Am 18.12.20 um 19:26 schrieb John Soo: > I think probably keepijg ci on for most crates makes sense if we can > work instead towards real shared libraries. This discussion (FMPOV) is about how handle crates until rust supports (static or shared) libraries. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [RFC] Package of Nomacs
I can get the package to build using the following steps: git clone https://github.com/nomacs/nomacs.git cd nomacs mkdir build cd build guix environment --ad-hoc cmake make gcc libraw exiv2 libtiff opencv python quazip qtbase qtsvg qttools pkg-config git cmake "../ImageLounge" "-DCMAKE_BUILD_TYPE=RelWithDebInfo" "-DCMAKE_INSTALL_PREFIX=/gnu/store/fiwxb6mlwhvnr49f9ydbhbam\ wp4bzb8b-nomacs-3.16.224" "-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE" "-DCMAKE_INSTALL_RPA\ TH=/gnu/store/fiwxb6mlwhvnr49f9ydbhbamwp4bzb8b-nomacs-3.16.224/lib" "-DCMAKE_VERBOSE_MAKEFILE=ON" "-DENABLE_TRANSLATIO\ NS=true" "-DUSE_SYSTEM_QUAZIP=true" "-DENABLE_OPENCV=true" make -j 8 ./nomacs For some reason that is different than when `guix package --from-file` runs. Den fre 1 jan. 2021 kl 23:02 skrev Rovanion Luckey < rovanion.luc...@gmail.com>: > Hi Leo and thank you for explaining. And hi again guix-devel. > > I've now rewritten the file according to your comments except that its > still its own file/module, something I'll fix later. > > Now I'm stuck trying to figure out a build error after going from the > tarball release through url-fetch to the non-recursive git-clone download. > CMake finds the package OpenCV when it runs, removing OpenCV from the > package inputs results in an error from CMake (as expected). But the build > fails during the build phase with the following error: > > > make[2]: *** No rule to make target 'opencv_core-NOTFOUND', needed by > 'libnomacsCore.so.3.16.0'. Stop. > > I've not found any relevant mentions of opencv_core in the source code. I > tried adding monkeying about with the CMakeLists a little to no avail. Also > looked at what Debian does to their package but found nothing that I > thought to be relevant: > https://sources.debian.org/src/nomacs/3.12.0+dfsg-3/debian/ > > I've attached the new package source. >
Re: [RFC] Package of Nomacs
Hello Rovanion, Am Samstag, den 02.01.2021, 15:43 +0100 schrieb Rovanion Luckey: > I can get the package to build using the following steps: > > git clone https://github.com/nomacs/nomacs.git > cd nomacs > mkdir build > cd build > guix environment --ad-hoc cmake make gcc libraw exiv2 libtiff opencv > python quazip qtbase qtsvg qttools pkg-config git > cmake "../ImageLounge" "-DCMAKE_BUILD_TYPE=RelWithDebInfo" "- > DCMAKE_INSTALL_PREFIX=/gnu/store/fiwxb6mlwhvnr49f9ydbhbam\ > wp4bzb8b-nomacs-3.16.224" "-DCMAKE_INSTALL_LIBDIR=lib" "- > DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE" "-DCMAKE_INSTALL_RPA\ > TH=/gnu/store/fiwxb6mlwhvnr49f9ydbhbamwp4bzb8b-nomacs-3.16.224/lib" > "-DCMAKE_VERBOSE_MAKEFILE=ON" "-DENABLE_TRANSLATIO\ > NS=true" "-DUSE_SYSTEM_QUAZIP=true" "-DENABLE_OPENCV=true" > make -j 8 > ./nomacs > > For some reason that is different than when `guix package --from- > file` runs. That doesn't say much, because `guix environment` provides little isolation. You might try with pure environments, but the better way of replicating the build environment is using `-K`. I have yet to look at your package definition (pardon me), but do you notice anything strange between the Makefiles you generate on your own vs. the Makefiles you generate in `guix build`? Regards, Leo
Re: Staging branch
Hi there, Is staging not running in ci?It looks like the last time it ran was just before the rustfmt output of rust (commit 48926b5).Did changing rust@1.46 somehow keep ci from running on staging? Maybe I am missing something. Any clues? John
Re: Staging branch
On Sat, Jan 02, 2021 at 08:59:03AM -0800, John Soo wrote: > Is staging not running in ci?It looks like the last time it ran was just > before the rustfmt output of rust (commit 48926b5).Did changing rust@1.46 > somehow keep ci from running on staging? It is supposed to be running, but something has broken. This does happen from time to time...
Re: Packaging elm-compiler 0.19.1
Hi John,
On 12/31/20 10:51 AM, John Soo wrote:
I’m not 100% sure how guix handles the ghc “boot” libraries but I
think time is installed alongside ghc. Doing guix environment --pure
--ad-hoc ghc -- ghc-pkg list gets me time-1.9.3. So I do think the
version bounds should be satisfied without any other dependency. Mind
sharing more of the package definition?
I think that elm-compiler is built with GHC 8.6.5, not GHC 8.8.3. When
I run `guix environment --pure --ad-hoc ghc@8.6.5 -- ghc-pkg list`, its
output contains `time-1.8.0.2`. I tried changing the definition of
`ghc-8` in `haskell.scm` from `ghc-8.6` to `ghc-8.8`, but then
`integer-logarithms` fails to build. Maybe I have to upgrade to the
latest LTS Haskell.
Here is the full package definition:
(define-public elm-compiler
(package
(name "elm-compiler")
(version "0.19.1")
(source
(origin
(method git-fetch)
(file-name (git-file-name name version))
(uri (git-reference
(url "https://github.com/elm/compiler/";)
(commit version)))
(sha256
(base32 "1rdg3xp3js9xadclk3cdypkscm5wahgsfmm4ldcw3xswzhw6ri8w"))
(patches
(search-patches "elm-compiler-disable-reactor.patch"
(build-system haskell-build-system)
(arguments
`(#:phases
(modify-phases %standard-phases
(add-after 'unpack 'update-constraints
(lambda _
(substitute* "elm.cabal"
(("ansi-terminal >= 0\\.8 && < 0\\.9,")
"ansi-terminal >= 0.8 && < 0.10,")
(("containers >= 0\\.5\\.8\\.2 && < 0\\.6,")
"containers >= 0.5.8.2 && < 0.7,")
(("http-client >= 0\\.5 && < 0\\.6,")
"http-client >= 0.5 && < 0.7,")
(("language-glsl >= 0\\.0\\.2 && < 0\\.3,")
"language-glsl >= 0.0.2 && < 0.4,")
(("network >= 2\\.4 && < 2\\.7,")
"network >= 2.4 && < 2.9,"))
#t)
(inputs
`(("ghc-ansi-terminal" ,ghc-ansi-terminal)
("ghc-ansi-wl-pprint" ,ghc-ansi-wl-pprint)
("ghc-edit-distance" ,ghc-edit-distance)
("ghc-file-embed" ,ghc-file-embed)
("ghc-filelock" ,ghc-filelock)
("ghc-http" ,ghc-http)
("ghc-http-client" ,ghc-http-client)
("ghc-http-client-tls" ,ghc-http-client-tls)
("ghc-http-types" ,ghc-http-types)
("ghc-language-glsl" ,ghc-language-glsl)
("ghc-logict" ,ghc-logict)
("ghc-network" ,ghc-network)
("ghc-raw-strings-qq" ,ghc-raw-strings-qq)
("ghc-scientific" ,ghc-scientific)
("ghc-sha" ,ghc-sha)
("ghc-snap-core" ,ghc-snap-core)
("ghc-snap-server" ,ghc-snap-server)
("ghc-time-compat" ,ghc-time-compat)
("ghc-unordered-containers"
,ghc-unordered-containers)
("ghc-utf8-string" ,ghc-utf8-string)
("ghc-vector" ,ghc-vector)
("ghc-zip-archive" ,ghc-zip-archive)))
(home-page "https://elm-lang.org";)
(synopsis "Programming language for Web applications")
(description
"This package provides Elm, a statically-typed functional programming
language for the browser. It includes commands for developers such as
@command{elm make} and @command{elm repl}.")
(license license:bsd-3)))
--
Matthew Kraai
Reconfigured on staging
I've reconfigured my desktop on staging. Almost everything is working.
I'm running enlightenment on wayland, launched from sddm.
In icecat, if I maximize the window the graphics stretch instead of
resizing to the new window size. Then even if I switch back to "windowed
mode" I can't see the different tabs I have open. It's likely this is an
already existing problem with icecat on enlightenment/wayland, I ran
into it at least once before reconfiguring on staging, when I was trying
out wayland.
econnman doesn't start. I'm not really sure where the error is. Since
I'm using ethernet it doesn't affect me much, but it should be working.
I've attached the error if anyone wants to take a look at it.
(ins)efraim@3900XT ~$ econnman-bin
ERROR:dbus.proxies:Introspect error on :1.3:/: dbus.exceptions.DBusException:
org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 3 matched
rules; type="method_call", sender=":1.166" (uid=1000 pid=8069
comm="/gnu/store/bvd09gb8ka642jzgxd2lpqlpdp160gn0-python")
interface="org.freedesktop.DBus.Introspectable" member="Introspect" error
name="(unset)" requested_reply="0" destination=":1.3" (uid=0 pid=644
comm="/gnu/store/627ni6jawbqj2pd9a33i8ss1471rj4il-connma")
CRITICAL:root:Failed to get ConnMan Properties:
org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 3 matched
rules; type="method_call", sender=":1.166" (uid=1000 pid=8069
comm="/gnu/store/bvd09gb8ka642jzgxd2lpqlpdp160gn0-python")
interface="net.connman.Manager" member="GetProperties" error name="(unset)"
requested_reply="0" destination=":1.3" (uid=0 pid=644
comm="/gnu/store/627ni6jawbqj2pd9a33i8ss1471rj4il-connma")
CRITICAL:root:Failed to GetServices(): org.freedesktop.DBus.Error.AccessDenied:
Rejected send message, 3 matched rules; type="method_call", sender=":1.166"
(uid=1000 pid=8069 comm="/gnu/store/bvd09gb8ka642jzgxd2lpqlpdp160gn0-python")
interface="net.connman.Manager" member="GetServices" error name="(unset)"
requested_reply="0" destination=":1.3" (uid=0 pid=644
comm="/gnu/store/627ni6jawbqj2pd9a33i8ss1471rj4il-connma")
CRITICAL:root:Failed to get Services: Rejected send message, 3 matched rules;
type="method_call", sender=":1.166" (uid=1000 pid=8069
comm="/gnu/store/bvd09gb8ka642jzgxd2lpqlpdp160gn0-python")
interface="net.connman.Manager" member="GetServices" error name="(unset)"
requested_reply="0" destination=":1.3" (uid=0 pid=644
comm="/gnu/store/627ni6jawbqj2pd9a33i8ss1471rj4il-connma")
CRI<8069>:eina_log efl/dbus_mainloop/e_dbus.c:252 e_dbus_timeout_data_free()
unknown log domain -1, original message level was: DBG
(ins)efraim@3900XT ~$ sudo !!
sudo econnman-bin
Password:
No protocol specified
No protocol specified
Traceback (most recent call last):
File
"/gnu/store/m5jjhhi5k6qs41rham62lfv9gz7mqy4g-econnman-1.1/bin/.econnman-bin-real",
line 1496, in
win = Window("econnman", ELM_WIN_BASIC)
File "efl/elementary/window.pxi", line 45, in
efl.elementary.__init__.Window.__init__
File "efl/elementary/object.pxi", line 111, in
efl.elementary.__init__.Object._set_obj
File "efl/evas/efl.evas_object.pxi", line 198, in efl.evas.Object._set_obj
File "efl/eo/efl.eo.pyx", line 254, in efl.eo.Eo._set_obj
AssertionError: Cannot set a NULL object
--
Efraim Flashner אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: Reconfigured on staging
On Sat, Jan 02, 2021 at 09:01:23PM +0200, Efraim Flashner wrote:
> I've reconfigured my desktop on staging. Almost everything is working.
> I'm running enlightenment on wayland, launched from sddm.
>
> In icecat, if I maximize the window the graphics stretch instead of
> resizing to the new window size. Then even if I switch back to "windowed
> mode" I can't see the different tabs I have open. It's likely this is an
> already existing problem with icecat on enlightenment/wayland, I ran
> into it at least once before reconfiguring on staging, when I was trying
> out wayland.
Just switched to enlightenment/X, problem disappeared completely.
> econnman doesn't start. I'm not really sure where the error is. Since
> I'm using ethernet it doesn't affect me much, but it should be working.
> I've attached the error if anyone wants to take a look at it.
>
>
> (ins)efraim@3900XT ~$ econnman-bin
> ERROR:dbus.proxies:Introspect error on :1.3:/: dbus.exceptions.DBusException:
> org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 3 matched
> rules; type="method_call", sender=":1.166" (uid=1000 pid=8069
> comm="/gnu/store/bvd09gb8ka642jzgxd2lpqlpdp160gn0-python")
> interface="org.freedesktop.DBus.Introspectable" member="Introspect" error
> name="(unset)" requested_reply="0" destination=":1.3" (uid=0 pid=644
> comm="/gnu/store/627ni6jawbqj2pd9a33i8ss1471rj4il-connma")
> CRITICAL:root:Failed to get ConnMan Properties:
> org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 3 matched
> rules; type="method_call", sender=":1.166" (uid=1000 pid=8069
> comm="/gnu/store/bvd09gb8ka642jzgxd2lpqlpdp160gn0-python")
> interface="net.connman.Manager" member="GetProperties" error name="(unset)"
> requested_reply="0" destination=":1.3" (uid=0 pid=644
> comm="/gnu/store/627ni6jawbqj2pd9a33i8ss1471rj4il-connma")
> CRITICAL:root:Failed to GetServices():
> org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 3 matched
> rules; type="method_call", sender=":1.166" (uid=1000 pid=8069
> comm="/gnu/store/bvd09gb8ka642jzgxd2lpqlpdp160gn0-python")
> interface="net.connman.Manager" member="GetServices" error name="(unset)"
> requested_reply="0" destination=":1.3" (uid=0 pid=644
> comm="/gnu/store/627ni6jawbqj2pd9a33i8ss1471rj4il-connma")
> CRITICAL:root:Failed to get Services: Rejected send message, 3 matched rules;
> type="method_call", sender=":1.166" (uid=1000 pid=8069
> comm="/gnu/store/bvd09gb8ka642jzgxd2lpqlpdp160gn0-python")
> interface="net.connman.Manager" member="GetServices" error name="(unset)"
> requested_reply="0" destination=":1.3" (uid=0 pid=644
> comm="/gnu/store/627ni6jawbqj2pd9a33i8ss1471rj4il-connma")
> CRI<8069>:eina_log efl/dbus_mainloop/e_dbus.c:252 e_dbus_timeout_data_free()
> unknown log domain -1, original message level was: DBG
> (ins)efraim@3900XT ~$ sudo !!
> sudo econnman-bin
> Password:
> No protocol specified
> No protocol specified
> Traceback (most recent call last):
> File
> "/gnu/store/m5jjhhi5k6qs41rham62lfv9gz7mqy4g-econnman-1.1/bin/.econnman-bin-real",
> line 1496, in
> win = Window("econnman", ELM_WIN_BASIC)
> File "efl/elementary/window.pxi", line 45, in
> efl.elementary.__init__.Window.__init__
> File "efl/elementary/object.pxi", line 111, in
> efl.elementary.__init__.Object._set_obj
> File "efl/evas/efl.evas_object.pxi", line 198, in efl.evas.Object._set_obj
> File "efl/eo/efl.eo.pyx", line 254, in efl.eo.Eo._set_obj
> AssertionError: Cannot set a NULL object
>
Checked this one on enlightenment/X, the dbus error shows up when I try
to launch it from the task-bar type thing, the error I got previously
with sudo remains (without sudo) when launched from the CLI.
--
Efraim Flashner אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: 02/03: gnu: libinfinity: Update to 0.7.2.
Efraim, guix-comm...@gnu.org 写道： gnu: libinfinity: Update to 0.7.2. Thanks! I noticed this update would break Gobby 0.5.0 (the latest release AFAIK) but I haven't tried building it again since. Is that fixed? Kind regards, T G-R signature.asc Description: PGP signature
Re: 02/03: gnu: libinfinity: Update to 0.7.2.
On Sat, Jan 02, 2021 at 08:08:48PM +0100, Tobias Geerinckx-Rice wrote: > Efraim, > > guix-comm...@gnu.org 写道： > > gnu: libinfinity: Update to 0.7.2. > > Thanks! I noticed this update would break Gobby 0.5.0 (the latest release > AFAIK) but I haven't tried building it again since. Is that fixed? > No, it's still not fixed, but gobby-0.5.0 needed libinfinity anyway and it was no longer building on master when I checked it before and after upgrading gsasl. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: 02/03: gnu: libinfinity: Update to 0.7.2.
Efraim Flashner 写道： No, it's still not fixed, but gobby-0.5.0 needed libinfinity anyway and it was no longer building on master when I checked it before and after upgrading gsasl. Interesting. Let's hope they release soon. Thanks! T G-R signature.asc Description: PGP signature
ZFS on Guix
Hi guix-developers,
I'm trying to get ZFS working on a test VM running Guix System.
Attempting to do a simple `guix install zfs` does not work, as I reported in
https://issues.guix.gnu.org/45401 , ZFS 0.8.5 is only up to kernel 5.9 but
latest guix has kernel 5.10.
I created a procedure to modify the base `zfs` package and compile it for a
different Linux kernel:
```scheme
(define (make-zfs-package kernel)
(package
(inherit zfs)
(name (string-append "zfs-for-"
(package-name kernel)
"-"
(package-version kernel)
"-version"))
(arguments
(cons* #:linux kernel (package-arguments zfs)
```
Then in my system configuration `.scm`, I selected a specific Linux and had its
module added to the boot and had it loaded in a Shepherd service:
```scheme
(define system-kernel linux-libre-5.4)
(define system-zfs (make-zfs-package system-kernel))
;; ...
(operating-system
(kernel system-kernel)
(kernel-loadable-modules (list (list system-zfs "module")))
;; ...
(packages
(cons* system-zfs
; ...
%base-packages))
;; ...
(services
(cons* (service kernel-module-loader-service-type
'("zfs"))
; ...
%base-services))
;; ...
)
```
As I documented here: https://issues.guix.gnu.org/45592#1
Now ZFS is loaded at boot (`lsmod | grep zfs` shows ZFS loaded), and `zfs
version` and `zpool list` don't error out.
However, when I created some extra space in the QEMU image and created a
partition `vda3`, I get an error in `zpool create tank vda3`.
The error is `cannot mount 'tank': Input/output error`.
I've also tried adding a new device to the QEMU boot as well, also the same
occurs.
Looking at a partition editor, the partition does get formatted as zfs, it just
won't mount.
Has anyone ever managed to get ZFS working on Guix? Any tips? Is it enough to
`modprobe` it in a system service or does it have to somehow be added to the
Linux command line? Maybe it only works on even older Linux-libre versions
than 5.4?
Thanks
raid5atemyhomework
Re: ZFS on Guix
Hi guix-developers,
I just did a an `strace -f zfs mount tank`, and got this interesting bit in a
child process:
execve("/gnu/store/a45p39mgqvfd8kjwibyr0q42klmw7gmf-util-linux-2.35.1-lib/bin/mount",
["/gnu/store/a45p39mgqvfd8kjwibyr0"..., "--no-canonicalize", "-t", "zfs",
"-o", "defaults,atime,strictatime,dev,e"..., "tank", "/tank"], 0x7ffee6ad7bf8
/* 29 vars */) = -1 ENOENT (No such file or directory)
The `/gnu/store` directory indeed does not contain a `/bin/mount` executable,
it only contains `include` `lib` and `share` dirs. So it looks to me that
maybe the `zfs` package needs some more modifications to get it working on
guix, since apparently ZFS userspace tools still go through `mount` anyway.
Trying to `mount` directly makes ZFS complain about requiring a "legacy"
mountpoint (there might be an option somewhere not shown by the `strace` that
suppress that complaint), and setting a legacy mountpoint makes `mount` error
with `filesystem 'tank' cannot be mounted at '/tank' due to canonicalization
error 2.` even though I give `--no-canonicalize`, though.
Thanks
raid5atemyhomework
Re: [RFC] Package of Nomacs
Hi again Leo! That doesn't say much, because `guix environment` provides little > isolation. You might try with pure environments, but the better way of > replicating the build environment is using `-K`. > Ran in a `guix environment --pure --container` and it still built successfully. > I have yet to look at your package definition (pardon me), but do you > notice anything strange between the Makefiles you generate on your own > vs. the Makefiles you generate in `guix build`? > Thanks for the idea. Made me realise that I could run the build steps on my own in the /tmp/ folders `guix build` generates with `--keep-failed`. And in doing so I got it to build even there. Figured that it then has to be some difference in the build steps and have now figured out that it is the flag "-DCMAKE_BUILD_TYPE=RelWithDebInfo" that is causing the issue. If I changed that to `Release` instead of `RelWithDebInfo` then the package builds successfully. And it also has plugins now! I will return with a revised version later. First I will try to package libpsd, an optional dependency of Nomacs.
Re: Packaging elm-compiler 0.19.1
Hi Matthew, Matthew Kraai writes: > I think that elm-compiler is built with GHC 8.6.5, not GHC 8.8.3. > When I run `guix environment --pure --ad-hoc ghc@8.6.5 -- ghc-pkg > list`, its output contains `time-1.8.0.2`. I tried changing the > definition of `ghc-8` in `haskell.scm` from `ghc-8.6` to `ghc-8.8`, > but then `integer-logarithms` fails to build. Maybe I have to upgrade > to the latest LTS Haskell. The haskell-build-system respects a #:haskell argument like so: (arguments `(#:haskell ,ghc-8.8 ...)) That way you don't end up bumping the default ghc for everyone while updating one package. I tried your definition with ghc@8.8 as above and some new packages were not in constraints. Can you go from there and update the "update-constraints" phase as you go? Maybe that will be enough. Thanks! - John
New Brazilian Portuguese PO file for 'guix' (version 1.2.0-pre3)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix' has been submitted by the Brazilian Portuguese team of translators. The file is available at: https://translationproject.org/latest/guix/pt_BR.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/guix/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/guix.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: Staging branch
Hi Guix,
Leo Famulari writes:
> It is supposed to be running, but something has broken. This does happen
> from time to time...
Ah well...
For what it is worth I have rebased on staging and reconfiguring my
system on it built successfully. Also my manifest built successfully.
I don't have many effected packages though [1].
Thanks again,
John
[1] My packages:
(define-public languages
'("agda"
"agda-ial"
"cedille"
"coq"
"idris"
"ocaml"
"purescript"))
(define-public utilities
'("aspell"
"aspell-dict-en"
"bpftrace"
"cups"
"direnv"
"docker-cli"
"dog"
"emacs-no-x"
"exa"
"fd"
"fish"
"fish-foreign-env"
"fzy"
"gdb"
"global"
"groff"
"make"
"pijul"
"pinentry"
"recutils"
"ripgrep"
"rlwrap"
"shellcheck"
"skim"
"time"
"tlsdate"
"tokei"
"tmux"
"unzip"))
(define-public browsers
'("icecat"
"lynx"
"ungoogled-chromium"))
(define-public desktop-tools
'("alacritty"
"alsa-utils"
"clipmenu"
"compton"
"dbus"
"dunst"
"garcon"
"libnotify"
"libreoffice"
"mpv"
"my-dmenu"
"pulseaudio"
"scrot"))
(define-public fonts
'("mkfontdir"
"mkfontscale"
"font-dejavu"
"font-iosevka"
"font-iosevka-term-slab"))
(define-public haskell-tools
'("ghc"
"hlint"
"hoogle"))
(define-public ocaml-tools
'("opam"))
(define-public rust-tools
'("rust"
"rust:cargo"
"rust:rls"
"rust:rustfmt"))
(define-public guile-tools
'("guile"
"guile-colorized"
"guile-readline"
"guile-syntax-highlight"))
(define-public pdf-tools
'("texlive"
"zathura"
"zathura-pdf-mupdf"))
(define-public xorg-tools
'("gcc-toolchain"
"ghc-dbus"
"ghc-xmonad-contrib"
"setxkbmap"
"xcape"
"xdg-utils"
"xdotool"
"xev"
"xfontsel"
"xinit"
"xinput"
"xlockmore"
"xmessage"
"xmobar"
"xmonad"
"xrandr"
"xsel"
"xsetroot"
"xwallpaper"))
(define-public emacs-packages
'("emacs-anzu"
"emacs-avy"
"emacs-cmake-mode"
"emacs-company"
"emacs-company-coq"
"emacs-company-math"
"emacs-counsel-projectile"
"emacs-csv-mode"
"emacs-cql-mode"
"emacs-dash"
"emacs-debbugs"
"emacs-dhall-mode"
"emacs-direnv"
"emacs-dired-git-info"
"emacs-diredfl"
"emacs-docker"
"emacs-dockerfile-mode"
"emacs-ediprolog"
"emacs-eglot"
"emacs-elfeed"
"emacs-elf-mode"
"emacs-elm-mode"
"emacs-emmet-mode"
"emacs-evil"
"emacs-evil-anzu"
"emacs-evil-commentary"
"emacs-evil-escape"
"emacs-evil-leader"
"emacs-evil-magit"
"emacs-evil-org"
"emacs-evil-surround"
"emacs-evil-tmux-navigator"
"emacs-f"
"emacs-fill-column-indicator"
"emacs-fish-completion"
"emacs-fish-mode"
"emacs-flycheck"
"emacs-flycheck-elm"
"emacs-flycheck-rust"
"emacs-forge"
"emacs-geiser"
"emacs-goto-chg"
"emacs-graphql-mode"
"emacs-graphviz-dot-mode"
"emacs-guix"
"emacs-haskell-mode"
"emacs-haskell-snippets"
"emacs-ibuffer-projectile"
"emacs-idris-mode"
"emacs-imenu-list"
"emacs-ivy"
"emacs-let-alist"
"emacs-magit"
"emacs-markdown-mode"
"emacs-merlin"
"emacs-multi-term"
"emacs-nix-mode"
"emacs-nodejs-repl"
"emacs-ob-restclient"
"emacs-origami-el"
"emacs-prescient"
"emacs-projectile"
"emacs-psc-ide"
"emacs-recutils"
"emacs-reformatter"
"emacs-restclient"
"emacs-rust-mode"
"emacs-s"
"emacs-slime"
"emacs-slime-company"
"emacs-sml-mode"
"emacs-solarized-theme"
"emacs-systemd-mode"
"emacs-terraform-mode"
"emacs-tuareg"
"emacs-vimrc-mode"
"emacs-web-mode"
"emacs-wgrep"
"emacs-which-key"
"emacs-xclip"
"emacs-xterm-color"
"emacs-yaml-mode"
"emacs-yasnippet"
"proof-general"))
