IRC channel logs


back to list of logs

<castilma>can someone reproduce this? $ export GUIX_BUILD_OPTIONS=--substitute-urls=\\; guix build; results in : guix build: error: unknown package
<castilma>directly on the command line it works.
<reepca>Apteryx: (sorry for delay in answering) it's from the squeak-vm package, all I could find related to the package was "squeak" and "".
<dustyweb>wonder how hard it would be to get Nothing To Hide packaged...
***that_guy_ is now known as nliadm
<efraim>I'll have to try armhf packages on my aarch64 boards, never actually tried, but I believe it is at least partially board/distro dependent
<pmikkelsen>hi guix
<civodul>Hello Guix!
<jonsger>#28378 is the same package as #28285
<civodul>jonsger: indeed, i'll merge the two entries
<jonsger>civodul, don't forget to do it in flashing-tools.scm
<civodul>i'm not doing anything other than telling people to work together :-)
<janneke>sneek: later tell pmikkelsen: not running gnome, but with latest master i get upon sudo -i: sudo: pam_open_session: System error; sudo: policy plugin failed session initialization. user is in group wheel
<sneek>Got it.
<janneke>sneek: botsnack
<civodul>ACTION prolly has a fix for the elogind/libcap thing
<efraim>If I set cores=0 for the daemon, will it offload everything or use all available cores?
<civodul>i always forget, but it's written somewhere in the manual :-)
<efraim>Section 2.5, 0 means use all cores
<efraim>Max-jobs=0 means offload all
<civodul>ah right
<efraim>In the interest of throwing ideas into,the wind, the kernel, busybox, uboot, and I'm sure others, accept a config file for building, we should probably generalize this type of build option
<civodul>efraim: i think we should start by generalizing that of the kernel
<civodul>adding an API to generate a kernel .config file essentially
<efraim>It might be enough of a start to make the config an input and add a phase like (copy-file (assoc-refs %inputs "my-config") ".config") so 'make config' will read the config in its default location
<efraim>But I do like the 'add these flags to the bottom' thing we have going for the kernel
<janneke>civodul: is the elogind/libcap causing my sudo breakage?
<ng0>hi! I've been meaning to fix "make dist" for gnURL so that the receipe can drop autotools. We had this issue many months back where shebangs were left in some autotools (or otherwise build-process related) files. Has this been fixed?
<ng0>*actually more correct: /gnu/store/… shebangs
<Steap>$ guix import pypi six
<Steap>guix/build/download.scm:425:6: X.509 certificate of '' could not be verified:
<Steap>Am I the only one getting this, or is the pypi importer broken?
<catonano> Steap: this is what I get
<castilma>Steap: have you installed nss-certs and exported the corresponding env variables? (assuming you are not running guixsd)
<Steap>let me try that
<castilma>see $ info guix X.509
<Steap>nah, still can't use the importer
<Steap>catonano: ok so this works for you :)
<castilma>Steap: it doesn't work on my guixsd installtion, too.
<Steap> here is what I get
<Steap>catonano: do you have any tls-related packages installed?
<ng0>"guix pack" is so cool. magic :)
<ng0>I don't know very much about mingw32. are those binaries really executable on native Windows (which versions?) or does it require some tools in windows to run them?
<civodul>janneke: i don't know if it's related, i couldn't reproduce the sudo problem you mentioned
<civodul>efraim, janneke: i've just pushed the elogind patches
<ng0>oh. /gnu/store/q87cg01m7sksk17yjyahjxrmic86mqvj-make-boot0-4.2.1.drv for i686-mingw32 failed its build. I wanted to test this crossbuild guix pack.. is this failure new or is someone looking into it already?
<civodul>ng0: try --no-grafts, it's a bug
<ng0>cool, thanks
<ng0>okay, now that's a real build failure from what I understand:
<ng0>Checking for i686-w64-mingw32-gcc...
<ng0>Please use win32/Makefile.gcc instead.
<ng0>** ./configure aborting.
<ng0>for zlib
<ng0>I haven't kept up with anything beyond x86_64 :)
<ng0>*kept up to date
<ng0>I'm in between phone calls, otherwise I'd check for myself.
<catonano>Steap: I don't know, are gnupg and openssh tls related ?
<Steap>catonano: I donno :(
<Steap>I wouldn't say so
<catonano>Steap: I'll paste the whole list of installed pacages or you, give me a minute
<catonano>Steap: here it is
<Steap>no idea why this works for you though :(
<efraim>Maybe something with environmenal variables?
<Steap>I donno :(
<Steap>I don't know Guile and its libs
<ng0>Steap: could you run "env" and paste it somewhere
<Steap>so I don't really know why this would be happening
<ng0>*paste its output
<ng0>ACTION -> phone
<efraim>When I want it to 'just work' I do 'guix environment guix -- guix import pypi foo'
<Steap>efraim: yeah I could do that, but you've got to admit it's not ideal
<civodul>Steap: i missed part of the discussion, but did you check ?
<efraim>Clearly its all the colors that make it work
<Steap>civodul: when I installed nss-certs, I don't think I was told about SSL_CERT_DIR nor SSL_CERT_FILE
<Steap>just about GIT_SSL_CAINFO
<Steap>oh, works with those 2, thanks!
<efraim>Would it work if you sourced .guix-profile/etc/profiles?
<civodul>it may not be enough
<Steap>all the required exports are not in ~/.guix-profile/etc/profile
<Steap>it is missing the two SSL_ variables
<civodul>right, because they come with OpenSSL, which isn't directly installed usually
<Steap>yeah but this looks like a bug
<Steap>I mean, I installed nss-certs, still could not reach PyPI
<Steap>as a user, it feels like a bug
<Steap>not to be told about the variables that matter
<civodul>it is
<civodul>that said, there's no substitute to reading the manual
<civodul>on GuixSD it works out of the box, but on other distros it's harder to get the right behavior out of the box
<cehteh>uhm yes :D
<cehteh>something totally borked in that vm (yes i typed pull not pu[[)
<cehteh>today new server hardware with ecc ram should arrive,
<civodul>cehteh: could it be that you selected the wrong keyboard layout, either in the emulator or in GuixSD itself?
<civodul>looks like a mismatch somewhere
<cehteh>no, the system is just unstable, just for funny reference
<cehteh>earlier anothre build had some segfaults
<cehteh>having problems since some time and they are increasing, time to replace the hardware
<cehteh>unfortunally i think i cant go with guixSD yet, i'll reserve some space for a later installation but install debian for now
<civodul>but you wrote you think it's a hardware failure, right?
<civodul>if that is the case, any distro is going to fail no?
<cehteh>i replace the hardware
<shwsh>hey guix people
<shwsh>how has gnome without systemd been?
<civodul>it's been okay!
<civodul>there are a few glitches here and there, but the major functionality works well
<shwsh>nice, i've been porting gnome to devuan, and it's been good
<shwsh>though gnome-session won't start for a minute or so :/
<shwsh>is that an elogind thing or just my problem
<civodul>i don't think we've had this kind of problem
<civodul>note that we don't use GDM yet (wingo gave it a stab just a couple of weeks ago)
<civodul>i don't know if it makes a difference
<shwsh>i'm using lightdm, tried getting gdm to work, and it failed :(
<shwsh>what's guixsd like? how much time do you spend maintaining your system
<civodul>maintaining GNOME support for example?
<civodul>that was mostly a one-time effort
<shwsh>i mean, like day to day support, is it like arch where you pacman -Syu everyday?
<shwsh>everyday computer updating stuff
<civodul>well, one should upgrade regularly (with 'guix system reconfigure')
<civodul>i'd say at least once a week to get the security updates
<civodul>now you can't end up in a broken state due to a partial upgrade, which is reassuring
<civodul>sometimes you can have a dependency of GNOME, say, that fails to build
<civodul>but that's pretty much the worst that can happen
<shwsh>wow, you have unprivileged packages too
<efraim>I feel like this is an appropriate time to say 'come to the future! We have cookies.'
<shwsh>nah, i'll stick with my "stable" and "free" master-race-tier distro, debian tyvm
<shwsh>plus, doesn't guix require guile, how easy is that to learn?
<shwsh>i can see it looks like lisps
<ng0>relatively okay. I knew only a bit of lisp 3 years ago
<ng0>I still wouldn't say I know guile, but I definitely know more guile than 3 years ago and I have goals which motivate me to learn more
<ng0>working on the system is an interesting stuydy and improve project
<ng0>does "guix pack" understand "--quiet" ?
<shwsh>i'm sure you could learn more bout linux if you just install /g/entoo
<ng0>not really
<ng0>I had Gentoo for years.. discussions on OS are just pointless anyway
<ng0>Gentoo is cool when you have just one computer. when you actually want to work with it and require debugging, good night.
<ng0>ACTION doesn't miss 30 VMs
<ng0>civodul: I think guix pack --quiet would be useful, that build in guix pack gets passed a "--quiet" switch
<civodul>ng0: yes, that's a good idea
<civodul>(maybe "2> /dev/null" works in the meantime?)
<ng0>it should work
<ng0>I'm trying to script away parts of work.. and maybe not fix "make dist" of this but just let my script + guix tools do this for me
<ng0>I think I need to fix make dist though
<reed_>Hi all, I have a basic question about config.scm files. By looking at the packages list on how can I figure out what `use-modules` command to add to the top of my config.scm file for a particular package?
<ng0>you have the list locally via guix package --search curl for curl for example. And you could use guix package -A curl for the filename (module) of curl
<civodul>reed_: shows how to sidestep the whole module name issue
<civodul>using 'specification->package'
<reed_>Thanks, that seems to have worked!
<reed_>So I added guile-git to my system.config because guix was telling me I needed it to run a `guix pull`. But after I ran the system reconfigure, it is still saying that I need to install guile-git
<ng0>when I need /usr/bin/file just for a moment in an "guix environment" is there a way I don't know about to create this symlink in the environment?
<ng0>haven't looked at the script, maybe it can be "fixed" by just removed the /usr/bin/ part
<civodul>ng0: use "guix container -C" and then make the symlink manually
<civodul>er, "guix environment -C"
<ng0>with an unattended script.. hm. I'll look into the script this script executes
<ng0>ah.. my mistake, I can -- commandstuff to create symlinks
<ng0>my problem is a generated configure file
<ng0>I'm thinking of either extending my script or trying a guix package to run what I want
<ng0>although package definition is problematic because of patch-shebangs but also helpful because of patch-shebang.. maybe something else
<elpogo>anyone know of any tools to display the DOT output of 'guix graph' in a 256 color terminal?
<efraim>Graphviz has the 'dot' binary
<efraim>As far as display the output ... I'll have to think a bit
<elpogo>i'm running it on a remote server. don't want to transfer pdf/ps files back and forth. if possible, i'd rather just see the graph in the terminal itself
<elpogo>does the dot binary have an option to display the graph on the terminal?
<elpogo>i checked the supported output formats in the dot manual, doesn't have what i'm looking for
<efraim>elpogo: maybe something from here can help
<efraim>Maybe to svg to libcaca?
<efraim>I would try cacaview or img2txt from libcaca
<efraim>i looked at the blis commit, authored by ludo@inria, committed by ludo@gnu
<Apteryx>libcaca; what a crappy name!
<efraim>there's also libass and thefuck
<ijp>efraim: as weird as it might seem, until now I had never noticed that .ASS is 'ass'
<ijp>it's like my brain hasn't parsed it properly in nearly a decade
<Apteryx>efraim: eh
<lfam>Don't forget about 'assword'
<lfam>I wonder why I am often building expat in the last weeks
<civodul>elogind breakage!
<civodul>i can't log in, now we have to do something :-)
<Apteryx>This is with slime or gdm?
<civodul>this is with slim, but the problem is in elogind
<ng0>good I haven't reconfigured in a while
<pmikkelsen_>civodul: i had a problem yesterday where i couldnt log in too, not even in tty1. the update to 232.4 fixed it for me, but i havent tried master yet
<sneek>Welcome back pmikkelsen_, you have 1 message.
<sneek>pmikkelsen_, janneke says: not running gnome, but with latest master i get upon sudo -i: sudo: pam_open_session: System error; sudo: policy plugin failed session initialization. user is in group wheel
<civodul>"Cannot determine cgroup we are running in: No data available"
<pmikkelsen_>yes that is it, the excact same error as i got.
<pmikkelsen_>I will try tomorrow, but i have to go now, bye!
<cbaines>I think I've got a bit confused with derivations... I have multiple machines, with supposedly the same code running, but they generate different derivation files. I'm looking at two .drv files, for the same package, with different contents, but the same value for the output, which I didn't think was possible?
<civodul>cbaines: it's possible due to fixed-output derivations
<civodul>with fixed-output derivations, there's an infinite set mapping to a single output store item
<civodul>e.g., there are many ways to fetch a file with a given hash
<cbaines>I think I'm looking at the derivation for a package build, would the above still apply?
<cbaines>Ok, maybe things are not as odd as I was thinking, I seem to be getting consistent output paths on multiple machines
<ng0>q: are .so files, for some reason, created in a phase after "build" with gnu-build-system?
<ng0>i get .lo .la right after build when I insert a "breakpoint"
<slyfox>normally 'make' is supposed to link .so files from .lo files
<ng0>basically I need to adapt what this introduced:
<ng0>copy src/gns/nss/ to $out/lib/nss/ or somewhere
<ng0>(I don't like the solution one bit… but yeah.)
<ng0>I'll take a look at the gnu-build-system in the morning
<ng0>yeah, this is happening after the phase "build"