IRC channel logs


back to list of logs

<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'm trying to build a piece of software ( under my Guix System, and I'm not sure I'm doing it right -- it's not finding the libraries to link to. Here's the pastebin of the compile:
<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>ecbrown, yes
<malaclyps_on_tou>so is actually a binary (it's not compiled) -- should I (can I?) patch it to find the correct libraries?
<ecbrown>i don't know
<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.
*rekado_ –> zzZ
<ecbrown>rekado_: odd, not on my system
<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
<quiliro>guix package -I lua
<quiliro>shows it?
<quiliro>he/she not in the chatroom any more
<raingloom>heyy. it's late and i'm too tired to figure out how to send a patch, but i just packaged an instrument tuner:
<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>Sorry, I have fingerets
<TuLithu> Guix
<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
<sneek>Got it.
<malaclyps>how can I work out the sha256 hash for an origin taken from a git-fetch method?
<bandali>how about guix hash -rx .
<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
<malaclyps>bandali: ohh that makes sense
<malaclyps>bandali: thank you!
<bandali>malaclyps, cheers :)
<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?
<pinoaffe>im trying to package , but its build scripts look for and fail to find boost.python, which should already be available
<civodul>pinoaffe: does our 'boost' package actually provide boost.python?
<ng0>unless you package you probably don't, or do they ship it together with main boost?
<efraim>I don't know about boost.python specifically, but it does have python2 bindings
<efraim>And not python3 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)
<ng0>pkgsrc now defaults to python3.7 where possible, but from the looks of it this boost build with either version. apparently there used to be problems according to the commented block you see at the bottom:
<gnu_srs1>(09:24:49) srs: Hi, how to import modules, e.g. I need GUILE_LOAD_PATH=/.../scheme-bytestructures to run guix?
<efraim> we're apparently still python2 only
<pinoaffe>civodul: nope, it doesn't
<pinoaffe> < I packaged it myself
<pinoaffe>so I might be doing something wrong
<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
<pkill9>oh nice
<nixo_>I'm writing the package definition now because the daemon is looking for shared libraries in /usr/local
<nixo_>pkill9: it runs (still need to veify if it works)
<civodul>pinoaffe: ah well, perhaps we just lack boost.python then
<civodul>sneek: later tell what do you mean by "input validation"?
<sneek>Will do.
<civodul>sneek: later tell apteryx what do you mean by "input validation"?
<sneek>Got it.
<civodul>to efraim and the Rusty people here:
<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)
<gnu_srs1>I edited gnu/packages/bootstrap.scm to point to and ./pre-inst-env guix package --bootstrap 2>&1 | tee ../bootstrap.log worked.
<gnu_srs1>But the hash entry is not correct.
<rekado>here is a chunk of my old patch:
<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?
<roptat>gnu_srs1, if you want, you can use*, that's where I put mine
<rekado>“boostrap” or “bootstrap”?
<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>I think I got that url wrong..
<roptat>it's supposed to have i586-gnu before the date
<roptat>so, my base url is
<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>yes, testing is necessary.
<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
<roptat>so nobody knows?
<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
<roptat>thanks :)
<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 ^^'
<civodul>surely :-)
<civodul>you could rpctrace it
<rekado>rpctrace was not helpful with the segfault investigation, unfortunately
<roptat>it almost imediately froze the system
<rekado>here’s some rpctrace output:
<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
<civodul>you're at least one step further
<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