IRC channel logs

2019-09-26.log

back to list of logs

<idnull>how can one fix that? https://paste.debian.net/1102608/
<idnull>ng0: can you be of help?
<ng0>too little information, too much focus spent today already, sorry
<idnull>now package looks like this: https://paste.debian.net/1102610/
<idnull>ng0: np
<ng0>looks generic enough if you share it on the list to get people to review it and help
<nckx>idnull: grep -i gnu/packages/*.scm for ‘rpath’ to see possible solutions.
<ng0>could be that you need a reference to wherever libxul is located, maybe reference icecat
<ng0>the pkg efiniton i meant, not package
<emacsomancer>hmm.. on a foreign distro and suddenly running 'guix' results in "guix: command not found", though the guix daemon is running
<vagrantc>is guix available in one of the PATH directories?
<emacsomancer>vagrantc: no, and I assume that's the issue
<emacsomancer>ok, I think I managed to reinstall 'guix' from root via an older version
<vagrantc>emacsomancer: shouldn't need to reinstall, just need to make sure it's available on PATH
<emacsomancer>vagrantc: I'm not sure how it's disappeared from PATH
<emacsomancer>I think I need to recreate the appropriate link
<vagrantc>depends on where you created it ...
<vagrantc>and how your distro sets up PATH on login
<vagrantc>emacsomancer: maybe you missed step 6: https://guix.gnu.org/manual/en/guix.html#Binary-Installation
***catonano_ is now known as catonano
<emacsomancer>vagrantc: PATH itself is fine. and I've had guix running on this machine for a year or so.
*vagrantc shrugs
<emacsomancer>I think .guix-profile is missing the appropriate link
<emacsomancer>vagrantc: I mean, things installed via guix other than guix itself still work
<emacsomancer>should I also create a symlink in ~/.guix-profile to /var/guix/profiles/per-user/root/current-guix/bin/guix ?
<vagrantc>what's your PATH set to?
<emacsomancer>/home/slade/.cargo/bin:/home/slade/.nix-profile/bin:/home/slade/.guix-profile/bin:/home/slade/.local/bin:/home/slade/.roswell/bin::/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/lib/plan9/bin:/opt/texlive/2019/bin/x86_64-linux
<vagrantc>so if you didn't link it in /usr/local/bin, it's not likely to be on path
<vagrantc> there's a new profile for the guix binary itself with recent versions ... but that's been quite a while now.
<vagrantc>or one of those other directories ...
<vagrantc>it's not typically in ~/.guix-profile/bin
<emacsomancer>ah, ok, created a new link in /usr/local/bin
<emacsomancer>I'm perplexed why this would have disappeared
*vagrantc too
*Digit wishes he was smarter, and/or guix total knowledge and understanding was installable in pill form, and/or he had the joyous graceful unimpeded love of learning it... and/or whatever other way to become one with the guix, rather than just an admiring bystander. ... maybe someone will "ubuntu-fy" it, n Digit wont need to know or be smart.
<oldosfan>nice thanks
<oldosfan>oops
<quiliro>rello
<quiliro>hello
<quiliro>sorry
<quiliro>booting from thisquel with english dvorak instead of spanish
<quiliro>i have a very bad problem, i cannot enter my user on guix;
<reepca>quiliro: harsh indeed! Can you log in as root, or not at all?
<quiliro>i do not hemembeh hoot passwohd
<quiliro>s/h/r/g
<quiliro>but i do not rave enchypted pahtitions
<quiliro>s/h/r/g
<quiliro>I rave guix system
<quiliro>s/h/r/g
<quiliro>raha
<quiliro>haha
<quiliro>sad but funny
<quiliro>when i try to boot with guix system live usb, it tries to boot from grub of hard disk even when choosing usb!
<reepca>quiliro: you mean like at the bios boot selection?
<quiliro>but it does not behave like that witr trisquel oh pureos live usb
<quiliro>yes reepca
<quiliro>i had this problem years ago too',.py
<quiliro>sorry
<quiliro>no py
<quiliro>what i did the other time is erase partition and reinstall
<quiliro>was*
<reepca>hm, odd that the live system won't boot. There should be ways of recovering the system in the event of the root password being forgotten. Looking online it looks like the usual advice is to modify the grub boot options when booting so that it just starts a root shell, then use passwd to reset the password from there.
<quiliro>by adding 'single' at the end of the kehnel line, <<<<right<<<
<quiliro>reepca:
<reepca>I'm not sure, the one guide I looked at worked by setting init=/bin/bash, but I doubt that would exist on guix system - /bin/sh might work, but I'm unfamiliar with the early-boot environment
<quiliro> https://linoxide.com/linux-how-to/boot-root-shell-prompting-password/
<quiliro>what to replace with bin/bash?
<quiliro>/bin/sh will not work with guix system
<quiliro>i am wrong it exists!
<quiliro>it even points to the store!
<reepca>aye, it's one of the special files %base-services arranges to create. IIRC they also recently added /usr/bin/env to make life easier.
<quiliro>will try thanks
<quiliro>b' back
<quiliro>found this https://quick-geek.github.io/articles/436938/index.html it might be interesting read!
<quiliro>hello- did not work
<reepca>hm, that's too bad - did it provide any useful messages about how it failed?
<quiliro>none i could notice...it just booted with gdm
<quiliro>or something similar but without the usual usernames
<quiliro>this happened after i tried to boot with older grub entries
<reepca>odd...
<quiliro>why would guix system use grub entries from the hard disk when booting from usb? i have another machine right now with the same problem
<quiliro>it happened to me a little more than a year ago....and i still haven't touched the machine because i want to recover those files....
<quiliro>rather, those bookmarks
<quiliro>and this would be a great opportunity to fix this problem
<quiliro>it is probably the same one on both machines
***Digitteknohippie is now known as Digit
<nckx>quiliro: There are several possible causes; one ‘interesting’ one is if both drives happen to contain the same unicode.pf2 file (see /boot/grub/grub.cfg for how this file is in fact used to determine the root drive!). There are many other ways to confuse GRUB.
<nckx>It's happened to me before even loading normal.mod (and hence grub.cfg), which means something can go wrong even before any Guix code kicks in.
<nckx>GRUB can fail in really cool ways.
<quiliro>saluton ...mi petas helpu min
<quiliro>mi ne povas eniri al mian Gikson
<quiliro>ĉu vi povas helpi min?
<quiliro>mi eniras al version antaŭan. do, la pasvortoj uzantaj ne funkcias poste!
<nckx>quiliro: Could you boot a(ny) USB system and clear the password(s) in /etc/shadow, then reboot your normal system, log in, and choose a new one?
*nckx → zzz, I'm afraid.
<quiliro>nckx: i tryed but the usb will boot from the hd's grub
***Digitteknohippie is now known as Digit
<lispmacs>hi, is everybody else able to build maxima on amd64?
<lispmacs>i get a build failure, but I was trying to build the version from last week so I am updating guix
<lispmacs>dies with "configure: error: unable to run gcl executable "gcl"."
<lispmacs>if I didn't need to go to bed, I'd figure out how to submit a bug report
<lispmacs>goodnight
<civodul>Hello Guix!
<jonsger>morning
<janneke>good morning
<ATuin>morning
<raghavgururajan>Hello Guix!
<civodul>nckx: i just noticed the Nixpkgs for nginx you mentioned at https://issues.guix.gnu.org/issue/37207
<civodul>maybe we should do this
<civodul>hmm
<civodul>why is the patch this big? :-)
<civodul> https://github.com/NixOS/nixpkgs/commit/9bc23f31d29138f09db6af52708a9b8b64deec64
<roptat>hi guix!
<civodul>hello roptat!
<civodul>Savannah is very slow when pushing
<civodul>gentlefolks, here's a funny thing for you to try: "sudo herd eval root '(setuid 1000)'"
<civodul>(at your own risk, of course)
<civodul>conclusion: PID 1 can run as non-root
<civodul>it just doesn't work very well afterwards
<roptat>civodul, my ISP cut my internet yesterday. they are lending me a 4G device for internet access, but of course I can't self-host anything on it
<roptat>so the overdrive will be done for a bit longer than I expected
<roptat>I'll send a message to the sysadmin list when it's up again with all the details
<civodul>roptat: ok thanks for the heads-up!
<civodul>it's commented out
<roptat>civodul, also it's broken, as I've written on the list
<roptat>for some reason the kernel disappeared
<civodul>uh :-)
<civodul>nckx: your overdrives are unreachable, could you take a look?
<civodul>crap mine is also unreachable
<roptat>did something bad happen to all of them?
<idnull>hello, can anyone provide a gtk-theme example package?
<roptat>arc?
<idnull>any theme, I want to package my gtk-2/gtk-3 theme. also, new moon is working, there are slight issues though
<roptat>yes, arc is a gtk theme we have in Guix
<roptat>maybe it's called arc-theme
<idnull>oh, thank you!
<efraim>oops, saved a file as '\' in my home directory
<idnull>eh, I need a different example though as I need only to copy files to add a theme
*Digit amused: https://joindiaspora.com/posts/16079421
*oldosfan manages to break guile installation somehow
<roptat>idnull, look for anything that uses the trivial-build-system then
<truby>I'm very close to having a fix for clang not finding C++ standard library headers, now the last header it can't find is <linux/errno.h>.. any idea where this header lives?
<truby>I assume I'm just missing a propagated-inputs dependency (so that this header actually gets put in the cpath)?
<mbakke>truby: that file comes from "linux-libre-headers", which should already be available (propagated from glibc)
<efraim>civodul: in %bootstrap-coreutils&co, the 'let' in the snippet, that's not actually needed, right? it seems to me it could just be 'begin'
<truby>interesting, if I ls the glibc include directory there's no linux folder in there
<truby>nor in the include directory for my profile
<mbakke>truby: there should be an entry for linux-libre-headers on CPATH or C_INCLUDE_PATH
<truby>those both seem to just be set to the profile include path
<mbakke>right, I guess you'll have to explicitly add glibc or linux-libre-headers to the profile to get it in that case
<truby>perhaps clang needs a dependency on gcc-toolchain as a whole, rather than just gcc
<truby>because on linux clang does assume you have a fully functioning gcc toolchain + as + ld + libstdc++ etc
<truby>(at least, by default. You can build a clang that doesn't have a dependency on any of these but it's usually not what you want, and almost definitely not what you'd want a clang package to do in this case)
<mbakke>truby: it would be nice to have a "make-clang-toolchain" procedure that takes care of all that stuff :-)
<truby>yeah, I was going to look at that next :) because I'd like to write a procedure where you can select each combination of things clang supports (i.e. which stdlib you want, which compiler runtime you want, which linker you want etc etc)
<truby>but first, I want to just get it finding the headers correctly in the configuration the clang package already builds!
<truby>which I have just done :D
<truby>where is gcc-toolchain defined?
<quiliro>Saluton Giksejo!
<quiliro> https://linoxide.com/linux-how-to/boot-root-shell-prompting-password/ ne funkcias por mi
<quiliro>mi provis kun /bin/sh
<quiliro>Ĝi ekzistas en Gikso.
<quiliro>Why would Guix System use GrUB entries from the hard disk when booting from USB? I have another machine right now with the same problem. When you boot from an older generation, existing user passwords do not work any more.
<quiliro>Mi provos https://stackoverflow.com/questions/11700690/how-do-i-completely-remove-root-password
<quiliro>Ĝis!
<truby>mbakke: I think the only way of making this work is to turn clang-from-llvm into make-clang-toolchain, because you need to patch the clang sources based on which toolchain options are being passed to you
<mbakke>truby: why does clang need patching?
<truby>otherwise it can't find the standard library headers (either for libstdc++ or libc++)
<truby>in the case of libstdc++ it looks for them in /path/to/crt0/../include/c++, and in the case of libc++ it looks for them in /path/to/clang/../include/c++
<truby>so we need to patch it to look for them in the actual path to the gcc or libc++ version you've asked for
<truby>(it already did the same so it can find libc correctly before I touched it)
<mbakke>truby: for libcxx, would it make sense to create a union of clang and libc++ in "make-clang-toolchain"? then "../include/c++" should work.
<truby>it uses the resolved path to clang, i.e. after hopping through every symlink
<truby>so unions don't help I think because they're symlink based right?
<mbakke>truby: unions are indeed based on symlinks
<truby>so I think there's no (easy?) way around just shoving in the direct path into the relevant place in clang. I mean, it's a pretty safe change
<mbakke>truby: patching in absolute references is fairly commonplace in Guix :-)
<truby>I noticed :-). I haven't done the patch for libc++ yet but it'll be very similar to the one I've added for libstdc++.
<truby>Before I start messing around with trying to write make-clang-toolchain should I put my current patch that just makes clang work the way it is expected to somewhere for review? it's pretty uncontroversial (I hope!) so might be better to get that added separately before I start rearranging the world heh
<truby>am I right in thinking the default gcc for building packages is 5.5? or am I getting the wrong compiler from somewhere...
<iv-so>yep, you are right
<quiliro>i have remove the second field of the root user from /etc/shadow But I cannot enter root user without password
<quiliro>s/remove/removed/
<iv-so>truby: you can override gcc toolchain through native inputs
<truby>ok, it's not super important for llvm atm, llvm 9 released this week does still build with gcc 5, but this will be the last release that does :-) is there a reason a newer gcc isn't used by default? just out of curiosity
<iv-so>idk
<truby>codegen on my platform (AArch64) has got significantly better since gcc 5, which is why I'm curious
<jonsger>somehow the build logs on ci.guix.gnu.org seem to be not complete: http://ci.guix.gnu.org/log/qbrmg5v4cx8wv502q4fv9ggwswxb16zf-python-astroid-2.1.0
<jonsger>mbakke: do you have an idea about this error https://paste.opensuse.org/view/raw/49867730 ? I get this in some python-* packages in the check phase. I'm on wip-gnome3.32 branch (on top of current core-updates)
<truby>I can't build guix from master on either of my systems atm, is anyone else seeing this? I get this error:
<truby>`en@quot.po:2846: format specifications in 'msgstr[0]' are not a subset of those in 'msgid_plural'`
***cosimone_ is now known as cosimone
<truby>actually can't build any branch so I am almost definitely the one at fault :)
<jonsger>truby: this should help for now http://issues.guix.gnu.org/issue/37505#2 :)
<quiliro>please help me solve my boot problem....i insert my usb with guix system and it is detected...but then grub uses the hard disk's grub entries
<quiliro>i cannot enter to any user because the passwords are not accepted...so i want to boot from usb to change root password in order to change all user passwords
<quiliro>the error when i log in is that the password is incorrect
<cbaines>quiliro, if the system is booting from the internal storage, rather than the USB stick, you may need to press a key during startup to change the boot device
<cbaines>Or enter the system BIOS/UEFI and change the boot order
<cbaines>Also, I've used the "init=bin/sh" trick before on Debian systems, but I'm unsure if that works on Guix
<madage>I've never done it on guix, but /bin/sh is a special file
<vagrantc>cbaines: the guix initrd doesn't respect init=
<vagrantc>at least, last i tried...
<idnull>is there gcc-ada package?
<vagrantc>would be nice if it did, for exactly these sorts of situations
<cbaines>vagrantc, right, good to know, I suspected that'd be the case
<vagrantc>my first guix system installation was dormant for quite a while ... and i of course forgot the password ... ended up using a debian-live image to boot
<vagrantc>and manually blank the password(s)
<quiliro>vagrantc: how can i manually blank the passwords on Guix System?
<quiliro>cbaines: i did set the boot device as the usb...and it in fact uses the usb as boot...but takes the grub entries from the hard disk
<quiliro>only way i can boot from usb us from another distro
<vagrantc>quiliro: boot to a live system, remove the "x" from the second column of the user in /etc/passwd, for example: root:x:0:0:root:/root:/bin/bash
<vagrantc>quiliro: of course, mount the partition, first :)
<quiliro>cool!
<vagrantc>quiliro: and be sure to set a password on first boot ...
<vagrantc>quiliro: or various other tricks along the same lines...
<idnull>it seems that there is no gnat for me
<idnull>speaking of Coreboot, I think that I can package cbfstool and friends
<vagrantc>look forward to it; can do more tests with diffoscope :)
<vagrantc>idnull: feel free to cc me on any patch review, whatever it's worth :)
<vagrantc>e.g. i can test it
<idnull>also, today (while I was trying to get New Moon working), crazy idea came to my mind: one can extract git tags and create new packages from those tags (I wanted it because there is no sqlite >=3.27 and Moon needs it else you can only have bundled one)
<idnull>also I'm too lazy to manually edit package version and sha :-)
<idnull>maybe I'm missing unstable repo somwhere. f.e. I need gcc-9.2 in order to test gdc and program in D
<quiliro>Saluton Gikso!
<quiliro>vagrantc: did not work
<quiliro>the x is restored
<quiliro>on root
<quiliro>should i do it on a wheel user?
<vagrantc>you might need to actually set a password ... which is a little trickier
<vagrantc>cut-and-paste a known password from an /etc/shadow file into the corresponding spot in the guix's /etc/shadow
<quiliro>how would that be without entering a user in Guix system?
<quiliro>all passwords are useless
<quiliro>no password works
<quiliro>you mean from another system?
<vagrantc>yes, from another system
<vagrantc>where you can easily generate an /etc/shadow entry...
<quiliro>vagrantc: could it not be Guix system
<quiliro>?
<vagrantc>quiliro: what do you mean?
<quiliro>i am using a live trisquel gnu now
<quiliro>i could change a user password and copy the entry on etc shadow
<vagrantc>should be fine ... add a user on the live system, copy the appropriate field(s) out of /etc/shadow into the /etc/shadow of the guix system
<quiliro>just the different part
<vagrantc>there's some chance they support different password hashing, but that's hopefully unlikely
<quiliro>would it be wrong to use an existing user?
<vagrantc>i'd recommend using an existing user that has wheel access or root
<quiliro>just change password and then copy the hash
<quiliro>on shadow
<quiliro>on an existing wheel user
<vagrantc>sure
<quiliro>will reboot to test now
<quiliro>vagrantc: it worked! :-D
<quiliro>i figured out why the users cannot log in
<quiliro>userid was changed
<quiliro>on /etc/passwd
<quiliro>it was caused by booting with an older grub entry
<refpga`>Hello, I'm trying to set up a keyboard layout using the following snippet: http://ix.io/1X4l but I get the following error: 102:55: Wrong type to apply: #<<keyboard-layout> name: "us" variant: "mac" model: #f options: ("ctrl:swapcaps")>
<refpga`>What might I be doing wrong?
<lprndn>refpga`: Not sure but maybe try: (keyboard-layout (keyboard-layout (keyboard-layout "us" ...)))
<refpga>Okay
<refpga`>lprndn:Still the same error: 102:72: Wrong type to apply: #<<keyboard-layout> name: "us" variant: "mac" model: #f options: ("ctrl:swapcaps")>
<refpga`>Now the column points to the third keyboard layout form.
<cbaines>refpga`, I think you might need xorg-configuration in there twice
<cbaines>as xorg-configuration is a record type, but also a field in the slim-configuration record
<cbaines>so the first occurrance will be the field, and the second will be constructing an instance of the xorg-configuration record to use
<lprndn>refpga`: yeah, that was a bad idea. sorry. the error means guile try to evaluate (keyboard-layout ...) as a procedure which apparently doesn't work
<refpga`>oh
<lprndn>cbaines is probably the one you should listen to haha
<refpga`>Oh yes. That was it.
<refpga`>Thanks
<cbaines>You're welcome :)
<refpga>How does one set up multiple layouts? Like the ones which can be switched using various keybindings like pressing both shifts together?
<refpga>Keyboard Layouts ^^
<refpga> https://wiki.archlinux.org/index.php/Xorg/Keyboard_configuration#Switching_between_keyboard_layouts
<refpga>I think I should try comma separated layout names.
<refpga>Nope, doesn't work.
<Parra>hello guys, I have one question, is it possible to install guix cmake-build-system dependencies before I install a package written by me that uses it?
<Parra>I've think about installing a dummy package before, but.. not sure if it's the best way of doing it
<lprndn>Parra: what do you mean by installing cmake-build-system?
<idnull>can anyone tell me why if i press ctrl+<- i see ;5D how can I fix this?
<Parra>lprndn: when I install my package from file, in a fresh guix install, it takes so long because it needs to download all build dependencies like cmake
<Parra>I want to know what dependencies are, in order to install them before for caching
<Parra>I'm using cmake-build-system but I don't know how to install its dependencies
<lprndn>Parra: Sorry if i'm beside the point but the store already act as a cache as long as you don't `guix gc`. If guix downloads cmake it's only because cmake package itself changed since the last time.
<Parra>ahh, so a pull should solve it?
<rain>anyone who knows Nix: what more do I need to do besides add it in my /etc/config.scm (and running guix system reconfigure) to be able to use it as an unprivileged user?
<sneek>rain, you have 3 messages.
<sneek>rain, nckx says: It's always helpful to include the actual error message in addition to your code: after downloading & building your package, Guix said: Wrong number of arguments to #<procedure assoc-ref (_ _)>
<sneek>rain, nckx says: which 1) is suspiciously relevant for a Scheme error message, what's going on!? and 2) immediately made the obviously wrong ‘(assoc-ref inputs "clang" "/lib"))’ obvious.
<sneek>rain, nckx says: Then (after much crunching) I get ‘mkdir: cannot create directory ‘/lib’: Permission denied’, which is a new & exciting but unrelated error 🙂
<rain>nckx, re:QtCreator, I figured it out in the end, QtCreator installs cleanly now. I'm still not totally used to reading Scheme and not having a type checker, which is how I missed the assoc-ref issue.
<lprndn>Parra: I would rather say that as long as you *don't* guix pull it actually shouldn't download anything twice. Do you workd from guix sources?
<refpga>Everytime I do a system reconfigure with or without guix pull, it downloads and compiles icecat. I don't know why.
<refpga>I mean, I did put it in the packages list...
<rain>(nevermind, i think i figured it out.)
<Parra>@lprndn: I'm trying to make a ci image for building a c/c++ project
<rain>(nvm, i haven't. the sourcing fails.)
<rain>(....oh, just a warning i guess..)
<lprndn>refpga: do you have access to any substitutes? did it finished compiling at least once?
<refpga>Oh yes, it finishes each time. And again if I do a reconfigure without guix pull, it will download and build the thing.
<Parra>@lprndn: and how can I update substitute manually?
<Parra>even downloading cmake previously it downloads again all packages...
<Parra>glibc-utf8-locales is already installed by me, and it's being downloaded again
<lprndn>refpga: hum :/ can you check if it actually is present in the store? we're actually out of my knowledge so just searching for hints here...
<Parra>with the same version
<lprndn>Parra: weird. :/ is it a recent guix pull?
<lprndn>Parra , refpga : your problems are weirdly similar. checking something. again, i'm really not an expert.
<lprndn>Parra: Just in case, dependencies of cmake-build-system should be findable in guix sources, I suppose.
<Parra>yeah I was thinking about that
<Parra>but I was guessing if there was a way of reference them easily
<lprndn>Parra: Not to my knowledge.
<bavier>ooo, boinc packages!
<bavier>though, the wording in the description probably could be better, wrt 'open source license'
<lprndn>Parra refpga : didn't find anything. I need to go so don't hesitate to ask on help-guix mailing list if the problem persist.
<Parra>the problem continues even installing the dependencies... I don't know what to do
<Parra>for cmake works but not for make
<mbakke>jonsger: that error does not ring a bell
<mbakke>where did you find that wip-gnome3.32 branch? :-)
<jonsger>mbakke: here https://notabug.org/kei/guix-gnome-updates
***jonsger1 is now known as jonsger
<vagrantc>trying to update to core-updates ... and still rebuilding lots of things... :)
<vagrantc>qtwebkit always takes forever
<truby>I find that guile takes a surprisingly long time to build
<quiliro>did you see my comment about guix system changing userids?
<quiliro>vagrantc: ^
<davidl>probably related to bug#37506 I am also having the issue that when having a (branch "master") in the .guix-channel for a dependency channel I get some error stacktrace when guix pulling. Im sorry that Im not able to provide more details on how to reproduce it at the moment.