IRC channel logs


back to list of logs

<ArneBab>bavier: it got further! Now it says "RUNPATH validation failed"
<bavier>ArneBab: that's a good start
<ArneBab>what does it mean?
<bavier>ArneBab: I assume there's some more output? that message usually means there's an issue with library or executable RUNPATHS, e.g. that the needed shared libraries cannot be found in the embedded RUNPATH
<bavier>how to fix it would depend on the particular issue
<ArneBab>/gnu/store/amml16ndirnw8w3qfkmpa3y874xbnzf8-gdal-2.2.4/lib/python3.7/site-packages/osgeo/ error: depends on '', which cannot be found in RUNPATH ("/gnu/store/b7fqhszxl02g6pfm3vw6b3cjz472qrly-python-3.7.0/lib" "/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib" "/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib" "/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib/lib/gcc
<bavier>ArneBab: ok, so the python plugin needs a runpath entry added to point to the output libdir. I don't know how to do that off the top of my head.
<rekado>ArneBab: to temporarily fix this you may have some success setting LD_LIBRARY_PATH to the location of
<civodul>Hello Guix!
<civodul>roptat: i found a typo in the word "copyright" in fr.po for shepherd
<roptat>Ah thanks
<nixo_>civodul: Hi, I got julia 1.1.0 working! Could you help me in linting it before opening the PR? Files are here:
<nixo_>there's also libGR, Plots.jl is working well with it
<civodul>yeah, congrats nixo_!
<civodul>at first sight julia.scm LGTM
<civodul>when you submit, please make sure to minimize "silent" changes compared to the current julia.scm
<civodul>like avoid reformatting the whole package in the same patch
<civodul>that will make it easier to see what the important changes are
<nixo_>Yeah I'm using emacs's guix-devel-mode and it did everything by its own
<civodul>maybe you used guix-scheme-mode?
<civodul>guix-scheme-mode is actually meant to format auto-generated files
<civodul>it's not really meant to be used as you edit code
<civodul>confusing :-)
<civodul>for libgr, you'll need a synopsis and description :-), a comment explaining what fix-zeromq is for, and a comment explaining why you added gcc-8, i'd say
<nixo_>civodul: Oh ok! yes I'll try to minimize changes. What to do with the llvm patches? they are inside the julia src repository. Right now I have them in the patches folder
<civodul>nixo_: it's not clear that Julia really needs these; they don't seem to be Julia-specific, are they?
<nixo_>(about guix-scheme-mode: This buffer has been indented by ‘guix-scheme-mode’ and is a mess again)
<civodul>so i'd say let's try to use plain llvm-6 for Julia
<nixo_>civodu: yes, they are julia specific. With plain llvm-6 it does not work (even using 6.0.0 and not 6.0.1)
<civodul>ok, though from the names at least some of them look totally unrelated (NVPTX, AArch64, etc.)
<nixo_>civodul: maybe here:
<nixo_>The only Julia-specific patch is the lib renaming (llvm-symver-jlprefix.patch), which should not be applied to a system LLVM.
<nixo_>They say other patches _can_ be applied to system llvm, others are generic llvm bug fixes
<civodul>well anyway, consider adding a link to the discussion above (on rather than :-)) and i guess you can send the patches for further discussion
<nixo_>civodul: julia patch sent!
<rendaw>Hey! Is there some way to disable root login? AFAICT root is always created with an empty password (!!), and in fact the password entry in (user-account ...) is ignored for the root account
<rendaw>I feel bad about spamming bug reports so I wanted to confirm here first if possible
<rendaw>I've spent an hour googling and an hour or two more code diving FWIW
<civodul>thanks, nixo_!
<civodul>rendaw: indeed, root is created with an empty password, and you're supposed to change that after installation :-)
<civodul>the 'password' field is ignored for root?
<rendaw>civodul: Yeah... the account-service has a check for uid 0 and uses creates a hardcoded shadow file with an empty password for root - none of the fields are consulted
<rendaw>That's what I was afraid of :(. The issue is that with disk-image the system is read only so you _can't_ change the root password after the system's been created (at least, without a lot of ugly hacking)
<rendaw>AFAICT the "activation service" execution order isn't clearly defined, so if I create a "change root password" activation all I can do is hope that it will run immediately after the "create shadow file" activation
<civodul>rendaw: if you add your own root account explicitly, i believe you can choose whatever initial password you want
<civodul>there's no such hardcoding
<civodul>it's just that (gnu system) provides a default if you didn't specify a root account
<civodul>search for "%root-account" in (gnu system)
<rendaw>civodul: When the accounts are actually created with useradd, the config is ignored (gnu/build/activation.scm line 128)
<rendaw>So you can override the default root user-account config, but it doesn't matter because none of the fields are used anyway
<rendaw>I mean, AFAICT (from reading the code and experimenting with a system)
<civodul>rendaw: in current master, useradd is no longer used
<civodul>could it be that you're looking at an older version?
<rendaw>Ah hmm, let me check. I just did guix pull but I haven't updated the source
<rendaw>Good idea!
<rendaw>civodul: It works! I guess I was working with a (quite) old version! Thanks so much!
<civodul>rendaw: cool, yw!
***Guest13107 is now known as sturm
<sturm>Hi folks, any idea why LibreOffice never seems to be available as a substitute, but builds fine for me, albeit slowly?
<roptat>I guess it's just slow on our build farms too
<roptat>mh... that might be something different, hydra says there are some dependencies failing
<sturm>thanks roptat, interestingly both those libcmis and libepubgen packages seem to build ok on my laptop, but it looks like they're failing tests on Hydra - something to do with getrandom
<roptat>maybe it's not deterministic? it doesn't fail here either...
<davidl>Do anyone have an example shell script package using the trivial build system?
<davidl>I have a git-repo with bash-scripts I want to package but am a little stuck at using a build-system for it.
<roptat>look at scala-official
<roptat>it's more that one shell script, but I hope it helps
<davidl>roptat: thx, Ill check it out
<roptat>basically, I extract the archive manually, I copy the content to the output and I modify the one shell script so it refers to bash with its store path
<davidl>roptat: it looks like almost exactly what I need =)
<roptat>cool :
<roptat>it's hard to type on my keyboard today...
<nixo_>is guix pull working for you on latest master? I have an error in (resolve-interface (gnu packages maths) #:select _ # _ # ?)
<roptat>no problem on my side
<roptat>I just pulled to 93c5c6d
***Noctambulist is now known as Sleep_Walker
<nixo_>roptat: well that's interesting. Maybe it's broken my _current_ compute-guix-derivation? is /gnu/store/48c1pap301irnsrfxfa940q3hi7j1x29-compute-guix-derivation
<roptat>I don't know which one it used
<roptat>maybe try to pull to an intermediate guix if you're pulling from an old one, or pull to a previous guix (or roll-back)?
<brendyyn>does symlink behave differently to ln -s ?
<brendyyn>civodul: I see that guile-gcrypt only implements a couple hashes required for guix, would you welcome it if I were to add in functions for all the other hash algos?
<sturm>How would one go about troubleshooting a shepherd "Throw to key" error like this: I can't see anything useful in shepherd.log
<sturm>(it's likely an issues in my service config where I'm trying to enable the postgis extension, but I'd like to see what error message postgresql is actually giving)
<nixo_>rotpat: rolled back lot of generations, none of them is working :/
<roptat>I mean guix pull generations, right?
<nixo_>I was rolling back the system. What's guix pull generations?
<nixo_>ahh there are guix pull generations too. (guix pull -l)
<roptat>it's probably not the right term
<roptat>but guix pull creates generations in a separate profile
<roptat>and you can roll it back with "guix package -p ~/.config/guix/current --roll-back"
<roptat>(-p is for --profile)
<nixo_>In the meanwhile I posted the output here. It happens with everything so the channels here should not matter:
<roptat>have you tried without the extra channel?
<nixo_>roptat yes
<nixo_>tried all generations, nothing to do
<roptat>then I'm afraid I don't know how to help you more than that... if no one knows how to help here, could you send an email to
<roptat>or even as suggested, to bug-guix@?
<rekado>nixo_: so, you tried this without a channels.scm file?
<rendaw>Any way to make shepherd retry forever if a service is failing? With maybe a backoff?
<nixo_>rekado: yes, both for root and for my main user
<civodul>brendyyn: that would be welcome, sure!
<nixo_>rekado: proof here:
<civodul>brendyyn: currently Guix is almost the only user of Guile-Gcrypt, so anything that can make it more useful for others is welcome
<brendyyn>civodul: Ok im only a novice hacker still so when i get around to itll ill make some patches and ask for feed back if you arent busy.
<civodul>sure, np
<brendyyn>I also have a project idea. I want to implement multihash for guile, and then extend it to generate strategies for calculating multiple hashes by only reading files once and piping them. for example you could say you want the ipfs hash, guix hash, and some other software archive hash of a git repo simultaneously. it could be useful for linking together different P2P methods of sharing software and verifying
<brendyyn>the different hashes represent the same files
<rekado>nixo_: to me this looks like disk corruption. Where does that long string of NULL come from?
<nixo_>rekado: no idea. I feared the same but it's btrfs I hoped to receive some checksome warning somewhere
<nixo_>but I have a sata error (failed command: WRITE FPDMA QUEUED)
<kmicu>nixo_: could you check that disk’s health with btrfs scrub or hdparm?
<nixo_>kmicu: sure
<kmicu>(A btrfs should be scrubbed every month.)
<nixo_>It's a new system, less than a month
<nixo_>but thanks I didn't know
<civodul>the Shepherd 0.6.0 is in the house!
<kmicu>nixo_: s/hdparm/smartctl (I always forget those are different programs).
<nixo_>kmicu: SMART overall-health self-assessment test result: PASSED, total bytes scrubbed: 50.88GiB with 0 errors
<kmicu>nixo_: Great. Could you try btrfs scrub to repair corrupted blocks? (Assuming there are any cuz maybe the issue is not realated to disk at all).
<nixo_>kmicu: already done, see the end of the previous message
<brendyyn>Well done on shepherd
<kmicu>nixo_: Oh, sorry. I assumed that’s all smartctl’s (strange) message.
<brendyyn>Ok im quite stuck. I'm symlinking a directory in a build phase but the symlink simply doesn not appear in the output
<nixo_>kmicu: I don't know what to try know. I fear I need to live boot and reinstall
<kmicu>nixo_: did you try guix gc --verify?
<nixo_>kmicu: reading the store...; checking path existence... (that's all the output)
<nixo_>running verify=contents now
<kmicu>Dunno then. roptat pulled w/o issues and w/o a reproducible case it can be something specific to your setup.
<nixo_>uhuh, errors appearing
<nixo_>kmicu: ok this file is 180Kb of null bytes /gnu/store/cg70c17qf93ykkl0gg7409lcl5d6rngw-guix-8de1ad2/gnu/packages/maths.scm
<kmicu>That’s progress. Nice.
<kmicu>Now the question is how maths.scm got nullifed 😺
<nixo_>kmicu: yes! :) also, I know where problems are now ( but how to fix them? ...
<kmicu>Did you try guix gc --verify=repair,contents ? Maybe guix can self-heal.
<nixo_>kmicu: no luck. error: cannot repair path /gnu/store/***-guix-**
<pkill9>how do you refer to a variable defined in the module during the trivial-build-system?
<pkill9>it doesn't seem to findit
<kmicu>nixo_: not sure what’s better to do. Repairing store manually (files on filesystem and database entries) can take more time than reinstall OS from the config.scm.
<jonsger>civodul: how should I rephrase "used by the Guix System Distribution (GuixSD)" now? "used by GNU Guix System"?
<kmicu>nixo_: BTW did you run repair as root (with sudo)?
<civodul>jonsger: or simply "used by GNU Guix"
<civodul>you decide :-)
<civodul>meiyopeng, roptat: did you eventually find out what the problem is with the zh_CN manual?
<Copenhagen_Bram>could we start naming guix releases? I propose that they be named after Star Trek characters
<nixo_>kmicu: yess, guix gc --repair fails immediately if you are not root
<nixo_>is andras enge in the this chat?
<civodul>nixo_: not currently
<nixo_>he seems to be the one managing the bayfront (that if I'm right is the kgpe-d16, same as mine. Wonder if he had SATA problems too)
<nixo_>civodul: thanks, do you know his handle?
<nixo_>andreas maybe if it's the same as in the git repo..
<civodul>Andreas is rarely on IRC, so rarely that i'm not sure what their handle is :-)
<brendyyn>I notice that `touch' is defined in 3 or 4 different places
<rvgn>Hello Guix!
<nixo_>civodul: ok that's a pity
<rvgn>For using modem-manager, mentioning %desktop-services under operating-system services is enough? or should I also mention modem-manager-service-type??
<wednesday>no modem-manager-service is not in %desktop-services, but do you actually need it? Are you using a dialup connection? heh
<nixo_>civodul: sorry to bother again, but do you know if anybody is interested in finding a way on how to pack julia pacakges in guix? (as far as I know, there are serious determinism problems in julia: , but maybe we find a workaround)
<nixo_>kmicu: after a garbage collection guix pull worked .-. I'm a bit confused but happy
***richi238 is now known as richi235
<civodul>sneek_: later tell vagrantc what if Guix 1.0 had its official Debian package? :-)
<civodul>sneek_: botsnack
<civodul>hmm, broken!
<jonsger>civodul: it will have at least an official openSUSE one :)
<nckx>civodul: Who runs sneek?
<nckx>I'm pretty sure she's muted as ‘sneek_’ only.
<nckx>Not broken, censored!
<rvgn>wednesday But the guide mentions like this:
<rvgn>Scheme Variable: modem-manager-service-type
<rvgn> This is the service type for the ModemManager service. The value for this service type is a modem-manager-configuration record.
<rvgn> This service is part of %desktop-services (see Desktop Services).
<civodul>jonsger: really cool!
<civodul>nckx: it's run by dsmith of #guile
<rvgn>wednesday I need it for USB dongles.
<rvgn>wednesday Never mind. I figured it out. :)
<civodul>dustyweb: just stumbled upon this, which you might like:
<civodul>Shepherd in the news:
<civodul>with arguments as to how it compares to systemd, suggesting that people haven't really looked at it :-)
<rvgn>civodul Thanks for the info :)
<Blackbeard[m]>civodul: people likes to talk without knowledge
<nckx>in particular.
<Blackbeard[m]>I disagree, because this happens everywhere
<Blackbeard[m]>reddit, mastodon, twitter, facebook
<Blackbeard[m]>real life
<Blackbeard[m]>people is just like that
<Blackbeard[m]>reddit comments usually have at least one person who didn't even read the title properly
<nckx>HN is particularly egregious. I think my ‘in particular’ stands, but I wish it didn't. It further taints the word ‘hacker’.
<Blackbeard[m]>ok, fair
<Blackbeard[m]>do we have a guix wiki?
<Blackbeard[m]>I think it will be very helpful
<Blackbeard[m]>having a wiki like Emacs wiki
<Blackbeard[m]>with tiny scripts and advices
<Blackbeard[m]>that might not fit the manual
<nckx>Blackbeard[m]: You're not the first to ask. The folks who could plausibly sanction a ‘Guix wiki’ aren't big fans of wikis (I tend to agree but that matters not), but that doesn't stop anyone from creating their own ☺
<Blackbeard[m]>I understand.
<Blackbeard[m]>It is just that I have learned so much thanks to arch wiki or emacs wiki
<ArneBab>bavier, rekado: I now "fixed" it by setting #:validate-runpath? #f
<ArneBab>now I can finally move forward with the paper
<Blackbeard[m]>stuff that I'll probably would have never learned otherwise
<nckx>Blackbeard[m]: I understand too.
<bavier>ArneBab: good short-term fix, sure
<shcv>nckx: what are they in favor of, as far as publicly facing (and possibly edited) documentation?
<nckx>shcv: …that?
<nckx>Edited docs?
<Blackbeard[m]>so as noob, not computer scientists, I don't have all the time or tools to learn all this awesome things
<Blackbeard[m]>and wikis make it easier
<nckx>I can't really speak for Ludo or Ricardo (the maintainers who could decide to have an official wiki) but the general preference is towards edited docs over wikisnippets.
<shcv>nckx: where are they hosted, and how do users contribute?
<shcv>I just looked, there doesn't seem to be a documentation link from the guixsd homepage
*nckx is noob and not CS but point taken. Easy for me to say after years of Guix and knowing most of said trix.
<nckx>shcv: Help.
<nckx>At the top. has a more up-to-date manual than (even though they look like the same site) for tedious reasons.
<nckx>Last time I compared them, at least.
<shcv>ah, yeah, I guess "help" should have been an obvious link...
<shcv>in one sense I think it is good to keep everything in the info docs, so they can be accessed offline from the system itself
<shcv>but it also makes it a lot harder as a user to contribute helpful instructions on how to deal with some specific piece of hardware etc.
<shcv>less obvious where to put the information (can't just add a page as easily), and there's a few extra hoops to jump through to contribute with GNU in the first place
<nckx>shcv: Users can contribute by checking out the repository and editing doc/guix.texi, but nobody who just submits a nicely rewritten/improved chunk of text will be chided for not knowing git.
<nckx>shcv: Which hoops? git send-email, that's it.
<Blackbeard[m]>let's say I want to create a wiki entry for privoxy, how to start with Shepard, configuration and everything
<nckx>(People who just send an email with ‘the docs suck!!!’, well…)
<Blackbeard[m]>I don't think that would be a good fit for the manual
<nckx>Blackbeard[m]: You're right. It would make a nice blog post ;-)
<Blackbeard[m]>but it might for a wiki
<nckx>(I don't think blog posts are better than wiki entries, but we do have the former.)
<nckx>Anyway, I seem to have made the impression that I care strongly (or weakly) about wiki's or none, which I don't. Most wikis turn to trash, but some don't, and the Arch wiki is a reasonable (if overhyped) example.
<nckx>If Guix were to get one, more power to the wiki editors ☺
<Blackbeard[m]>but a blogpost lacks the ability to look for other people thoughts
<Blackbeard[m]>like this
<Blackbeard[m]>EmacsWiki: Book Marks
<nckx>Blackbeard[m]: I'm not arguing against wikis. But the current options are a) a blog post on the Guix Web site or b) host your own wiki. A popular & well-run b) would be a far more powerful argument than anything anyway.
<Blackbeard[m]>Emacs wiki allows discussions and user snippets
<Blackbeard[m]>I understand
<nckx>I've read at least 6 ‘hey Guix should have a wiki! I need a place to post a few notes.’ posts over the years, but nobody who's *created* and is willing to maintain one. If the Guix maintainers are worried that a wiki would turn into an unmaintained wasteland after 4 pages, I can't blame 'em.
<nckx>Out-of date wiki's I *do* dislike ☺
*nckx → should be working.
<ArneBab>bavier: yes — thank you again for getting to this point!
<bavier>ArneBab: np; good luck with the paper!
<ArneBab>thank you! If you’re interested in the content: the discussion version is already online
<ArneBab>and reviewer 1 actually read the supplement (and saw the cthulhu reference :-) — now I can tell that I used an elder god to check whether the reviewers actually checked in detail ;-) ).
<dustyweb>sneek later tell civodul yes I'm very interested in ctsrd despite not understanding it :)
<dustyweb>sneek_: later tell civodul yes I'm very interested in ctsrd despite not understanding it :)
<dustyweb>hm hm
*kmicu dedicates to nckx a paraphrased Joe Armstrong’s quote “Yes, wiki is better than no wiki, but not better enough to justify the maintenance burden.”
<rvgn>Question: Are upower and udisks services added into Guix System just by including "%desktop-services" in the system config?? Or should I also include scheme procedures for upower and udisks??
<Blackbeard[m]>nckx: that's fair
<dongcarl>is package inheritance recursive?
<dongcarl>as in, if I just want to change (source (origin (method
<dongcarl>can I just specify that in my inherited package?
<dongcarl>Or do I have to specify the whole `(source` block?
<nckx>dongcarl: You have to specify the whole replacement field, source in this case.
<dongcarl>nckx: I see
*nckx not sure ‘recursive’ is the right word here.
<nckx>rvgn: Take a look at the definition of %desktop-services to find out.
<nckx>If you don't have a source checkout, see /gnu/store/*-guix-*/share/guile/site/2.2/gnu/services/desktop.scm .
<rvgn>nckx Thanks
<rvgn>nckx A doubt. libvirt can also used on client-side right? For running VMs by regular desktop users?
<rvgn>bavier to me?
***vup2 is now known as vup
<nckx><rvgn> bavier to me?
<nckx>In fact that's the only use case I know.
<rvgn>nckx Okay
<g_bor>hello guix!
<user_oreloznog>Hi g_bor! o/
***jonsger1 is now known as jonsger
<divansantana>how can I be sure my build server is building using all it's cpus?
<divansantana>its running guix system.
<vagrantc>though not every build can make use of parallelism
<dongcarl>Hey all, trying to do `gcc -m32` in a guix environment with gcc and binutils installed. Seems `ld` is not happy about it.
<divansantana>vagrantc: lol. And that answer helped... Seems to be working.
<divansantana>while building linux, I see lots of [make] <defunct> and [sh] <defunct>. Suppose that is normal.
<g_bor>dongcarl: there was a mail on the list recently on this topic, let me have a look...
<dongcarl>g_bor: Oh yay
*dongcarl needs to reply to his mailing list posts
<g_bor>This is a quote from Ludo's answer:Our GCC toolchain does not support ‘-m32’. Instead, to build a 32-bit
<g_bor>program on a 64-bit machine, you would do something like:
<g_bor> guix environment --ad-hoc gcc-toolchain -s i686-linux --pure
<dongcarl>g_bor: Ah cool... which mailing list post?
<dongcarl>g_bor: Ah thanks
*dongcarl is grateful
<davidl>Is anybody working on porting guile-bash to work with guile@2.2 (currently only works with guile@2.0)?
<pkill9>how do you build a g-expression in the guile REPL?
<pkill9>i created a simple gexp at 'build-exp' and run (derivation->output-path (gexp->derivation "the-thing" build-exp))
<pkill9>then i get guix/derivations.scm:597:28: In procedure derivation->output-path:
<pkill9>In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): #<procedure 1cb39c0 at guix/gexp.scm:708:2 (state)>