<vagrantc>hunch is changes in kernel configuration options that didn't get migrated over ... at least BACKLIGHT_LCD_SUPPORT was removed and it's replacement wasn't added... <vagrantc>but i would think it would still boot even without an LCD screen... *ecbrown is looking for a lua.pc or a reasonable guix substitute. <ecbrown>guess lua does not provide lua.pc, so it's not being found by pkg-config <malaclyps_on_tou>I've tried putting the nss package before and after "--ad-hoc" in the environment <malaclyps_on_tou>I read that "gcc-toolchain" contains a linker wrapper that puts in the correct rpath -- maybe that's not working in this case? <ecbrown>i only see the output with nss before. is it identical? ***ilya-fedin[m] is now known as ilya-fedin
<malaclyps_on_tou>so libcef.so is actually a binary (it's not compiled) -- should I (can I?) patch it to find the correct libraries? <ecbrown>always though of guix as an environment where pretty much everything needs to be compiled, otherwise, how is anything ever found <ecbrown>but i'd wait for someone with more knowledge to respond <ecbrown>On my own question, i do wonder why lua.pc is not generated. looks like there are patches in lua.scm to make this happen... <rekado_>malaclyps_on_tou: I recommend removing the bundled pre-built binaries and building them from source. <rekado_>ecbrown: lib/pkgconfig/lua-5.3.pc exists <rekado_>perhaps you need to adjust the pkg-config call. <ecbrown>i.e. i ran guix package -i lua@5.3 and looked in ~/.guix-profile/lib/pkg-config, and don't see it. see a bunch of others for packages i installed <ecbrown>i will be damned. i just installed lua-5.3.pc on my debian+guix machine, but it is not on my guixsd machine <ecbrown>something fishy. on the debian machine, i do guix package -r lua, and the lua-5.3.pc file remains <apteryx>rottlog serivices works, but pollutes the mcron logs with: /gnu/store/ab6k68m6cc10svkb4c6c7s73c7h9vrxd-rottlog-0.72.2/sbin/rottlog: line 1596: sendmail: command not found <tidux>well I isolated that problem in GNOME as tweak-tool not picking up the extensions <tidux>copying them to ~/.local/share/gnome-shell/extensions/ still didn't get tweak-tool to see them, but manually invoking gnome-shell-extension-tool from a terminal let me activate them <TuLithu>I am interested, as you can all possibly surmise, ddr <TuLithu>Would anyone tell me what advantages Guix has over other operating systems? <TuLithu>Please don't tell me I have to install Gnome <TuLithu>Once I've done the base install with a minimal "desktop," about how much ram will Guix be using? 100MB? 300MB <TuLithu>I don't like bulky code eating my memory. Can anyone tell me? <gnu_srs1>How to do this: roptat: the doc says you need to update (gnu packages bootstrap) <gnu_srs1>How to import a modules, e.g. I need GUILE_LOAD_PATH=/.../scheme-bytestructures to run guix? <apteryx>sneek: later tell TuLithu about 300 MiB of RAM for a barebone install using ratpoison + some services <malaclyps>how can I work out the sha256 hash for an origin taken from a git-fetch method? <malaclyps>bandali: right, but what am I hashing -- git-fetch points to a git address and a commit, not a file? <bandali>malaclyps, i think you’d be hashing an entire directory structure of a checkout <bandali>you git clone, cd into it, and run the above <bandali>disclosure: i haven’t peeked under the hood to see how guix hash exactly works <gnu_srs1>Hi, how to import modules, e.g. I need GUILE_LOAD_PATH=/.../scheme-bytestructures to run guix? <efraim>I think I just did GUILE_LOAD_PATH=... ./pre-inst-env... when I was working on powerpc <PotentialUser-53>hi, i have set my timezone correctly in my system configuration, but when i run `date` it is about 4 hours off. how may i correct the time? <pinoaffe>does someone know cmake find_package works in combination with guix? <civodul>pinoaffe: does our 'boost' package actually provide boost.python? <efraim>I don't know about boost.python specifically, but it does have python2 bindings <janneke>do we have an open bug wrt changed uid,gid and services that don't start (gdm, tor), i could not find one <ng0>hm. our devel/py-boost, which from the looks of it is what you mean as the python bindings, does now support python3, so if you haven't tried it with python3, maybe give it a shot efraim? <efraim>ng0: that would be a nice change, I'll have to try it out with the package I was trying last year (on my phone atm) <gnu_srs1>(09:24:49) srs: Hi, how to import modules, e.g. I need GUILE_LOAD_PATH=/.../scheme-bytestructures to run guix? <apteryx>wouldn't it be nice to have predicates on guix records, so that input validation can be automated? <nixo_>hello everybody! :) Have you ever tried pipewire? I'm trying to build it under guix, but before loosing much time I wondered if you think is a viable replacement for pulseaudio <pkill9>i looked into building pipewire but it requires libsystemd for sd-bus i think <nixo_>pkill9: I just built it without any problem <nixo_>guix environment --ad-hoc autobuild meson gcc-toolchain pkg-config dbus valgrind glib gstreamer alsa-lib libx11 sdl gst-libav gst-plugins-base eudev ninja libva sbc <nixo_>I'm writing the package definition now because the daemon is looking for shared libraries in /usr/local <civodul>pinoaffe: ah well, perhaps we just lack boost.python then <civodul>sneek: later tell what do you mean by "input validation"? <civodul>sneek: later tell apteryx what do you mean by "input validation"? <ZillaThe4>my tty is being spammed with output from system services, such as ntpd. does anyone know how i can redirect that output? <efraim>civodul: I'm testing them now by linting the refresh option of ~450 crates <efraim>well, new plan, Throw to key `gnutls-error' with args `(#<gnutls-error-enum A TLS fatal alert has been received.> handshake)'. <gnu_srs1>Hello again: I have now cross-built the bootstrap binaries for i586-pc-gnu. Should the *.xz or .tar out untarred files be installed in <gnu_srs1>The built Hurd box at guix-1.0.1/gnu/packages/bootstrap? <pinoaffe>civodul: well I packaged boost.python myself, and set it as a dependency of nextpnr, but the build scripts can't find it, so either my package is wrong or the build scripts are, and I have no clue how to find out which one it is <efraim>civodul: guix/import/crate.scm:200:31: In procedure crate->guix-package: <efraim>In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): #f <gnu_srs1>Looking at gnu/packages/bootstrap for other architectures have only the binary files: bash mkdir tar xz <efraim>and after 'make clean && make clean-go' guix import: error: failed to download meta-data for package 'rust-blas-sys' <gnu_srs1>Secondly how to make the built guix find them: ./pre-inst-env guix build hello? Or should *.drv files be created first?? <efraim>civodul: looked like I had a typo before, it's working great except for when I have a tls wrapping error <rekado>gnu_srs1: the usual way to port Guix to other architectures is to edit the targets that download / unpack the generated bootstrap tarballs. <rekado>gnu_srs1: I have an old patch here somewhere <rekado>this hasn’t been done for the Hurd yet, presumably because we don’t offer official bootstrap binaries yet. <rekado>(and I didn’t commit the patch because at least of my binaries segfaults on the Hurd) <rekado>the patch no longer applies, because of changes to how the bootstrap binaries are prepared, but it should give you some ideas <rekado>you can compute the hash with “guix hash” <roptat>stupid question, how do you build the bash, guile-2.0.9.tar.xz, mkdir, tar and xz from the bootstrap directory? <roptat>I built the bootstrap-tarballs, but they don't seem to be what I need <gnu_srs1>The only output I got was: ;;; note: source file guix-1.0.1/gnu/packages/bootstrap.scm newer than compiled guix-1.0.1/gnu/packages/bootstrap.go <rekado>Guix used to unpack them in a Makefile target. <rekado>this has changed somewhat recently; now it’s done elsewhere. <gnu_srs1>I rebuilt the bootstrap .xz-files, Do I need to host a web server to use an url? <gnu_srs1>After that I stumbled on: /pre-inst-env guix build hello --verbosity=10000 --keep-failed --log-file 2>&1 | tee ../build-hello.log <roptat>oh, I think I understand from your patch <gnu_srs1>rekado: Your patch is almost the same as the changes I started to make. However can I specify a local directory instead of an url? <gnu_srs1>Or maybe somebody could host them somewhere: binutils-static-stripped-2.31.1-i586-pc-gnu.tar.xz <gnu_srs1>gcc-stripped-5.5.0-i586-pc-gnu.tar.xz, glibc-stripped-2.28-i586-pc-gnu.tar.xz <gnu_srs1>guile-static-stripped-2.0.14-i586-pc-gnu.tar.xz, static-binaries-0-i586-pc-gnu.tar.xz <rekado>you might also be able to use a “file://” URL. <rekado>I host a bunch of bootstrap binaries from my last attempts on berlin. <rekado>but I suggest using yours (if they differ) to see if the segfault in tar has gone. <roptat>it's supposed to have i586-gnu before the date <roptat>and they are in (i586-gnu)/20190901/* <roptat>so, what's the new way to get the binaries in (gnu package bootstrap *)? <civodul>roptat, rekado: if there's a commit from which we can build these tarballs, i'm happy to build & upload them! <civodul>i guess we need to change make-bootstrap.scm to use Guile 2.0, right? <roptat>civodul, don't we need to test them before? <roptat>I need to create the bash, mkdir, tar and xz binaries in gnu/packages/bootstrap/i586-gnu but I don't know how to do that? <roptat>the manual hints to (gnu packages make-bootstrap) but I don't know what to do with it... <rekado>according to my notes my bootstrap binaries include a segfaulting “tar” <rekado>this works: /gnu/store/dqlhjyvg0n8v1kdvwfpliqy46n7kpjqb-bootstrap-binaries-0/bin/tar cvfa hello.tar.xz /tmp <rekado>but as soon as “--mtime=@0” is passed “tar” segfaults <rekado>roptat: if you just need to dump them there you can simply unpack the static binaries tarball. <rekado>I haven’t looked at this yet; in the past this was just handled by a Makefile target. Is this still the case? <rekado>sorry for my unhelpful half-knowledge here <roptat>I can't find anything that seem to be relevant in Makefile <rekado>then I guess you can just unpack this by yourself <rekado>the tarball contains a lot more than you need <gnu_srs1>roptat: You just have to extract them from static-binaries-0-i586-pc-gnu.tar.xz <civodul>roptat: yes, we need to make sure they actually run :-) <roptat>trying to build hello now, the output is very empty, but my processor is running like crazy <roptat>so I guess it's doing something ^^' <rekado>rpctrace was not helpful with the segfault investigation, unfortunately <roptat>it almost imediately froze the system <rekado>(and other notes about problems that should be fixed) <gnu_srs1>I'm also building hello, seems to take a long time: 95.8 17.2 15:07.87 guile-2.2 <gnu_srs1>rekado: When did your segfault in tar happen, and how did you notice? <rekado>while building something, I don’t recall. <rekado>(with the unexpected reboot of berlin my Hurd VM died as well, so I can’t look it up either) <rekado>gnu_srs1: it will take a very long time to build hello. <rekado>the bootstrap binaries are just used for the bootstrap, so new independent versions of guile, glibc, gcc, coreutils, binutils, etc will have to be built first. <rekado>this only has to be done once, but it’s a very expensive build. <rekado>the crash happened when attempting to build (or rather: unpack) GNU Make 4.2.1, but I can’t say when this happened in the big picture. <civodul>rekado: oh but that's natively, right? <civodul>to me we're still at the point where we need to cross-build bootstrap binaries and ensure that they work <rekado>that’s the cross-built bootstrap tar, though. <rekado>so … I guess that means that the bootstrap binaries produced in May 2019 don’t work correctly. <civodul>maybe we should gather details in a bug report