<estraw>after that, i found out that various programs installed from Guix would segfault when i tried executing them, stuff like keepassxc and emacs
<estraw>in a move that may or may not have been stupid, i tried reinstalling Guix completely with the installer script. I got rid of all the builder users, groups, and the store and everything, and reinstalled
<estraw>now, the guix executable itself segfaults when i try executing it
<lfam>My guess is your environment includes something that is directing Guix software to use libraries from the host system
<Veera>brendyyn: yes I created autogen.sh phase. first it patches autogen.sh; then autogen.sh runs. and it creates a new configure with unpatched; so how to patch this configure script
<lafrenierejm>lfam: I've tried `guix import texlive moderncv` and `guix import texlive -a $archive moderncv`, which a bunch of different values of $archive. For example, "tex/latex/moderncv".
<lafrenierejm>lfam: Everything fails with an error on guix/build/utils.scm:652:6: In procedure invoke, with `arguments` like ("export" "--non-interactive" "--trust-server-cert" "-r" "49435" "svn://www.tug.org/texlive/tags/texlive-2018.2/Master/texmf-dist/source/tex/latex/moderncv/moderncv" "/tmp/guix-directory.4IOyjX")
<lfam>lafrenierejm: I don't have a working SVN setup, that could be related. If it were me I would look at existing packages in gnu/packages/texlive.scm and hosted on ctan.org and try adapting one of those
<brendyyn>the bootstrap phase runs it if it exists and there is no configure script already
<lafrenierejm>lfam: It appears that the texlive import doesn't support packages outside of the texmf-dist/source/ directory. Copying one of the other texlive packages that builds the URL manually _appears_ to have worked.
<lfam>apteryx, I think there is a `herd invalidate nscd` command
<reepca>though it does make me curious about how one would render a complex 3D scene in a terminal. I hear VLC can render video in a terminal, but unfortunately I can never find the option to enable it.
<guix-vits>rekado: result is `export LANG="" ...` in wrapper
<guix-vits>rekado: i think, i'll check which locales are broken in 1.6.0, and do `LANG="`[[ $LANG ~= zh* ]] && echo`" or smth alike (in wrapper). Do you want to see the definition?
<guix-vits>brendyyn, rekado: ^^^ this approach seem to work, but at least China people will need to use .neverball-real, or thier language settings (in $HOME/.neverball/neverballrc) will not work (1.6.0)
<rekado>I don’t understand why that is necessary. Do you mean that people with LANG set to zh_CN.* cannot use the wrapper?
<rekado>In that case: can’t we work around this in the wrapper itself?
<guix-vits>rekado: if one with LANG=zh_CN.utf8 start neverball (vanilla), then chars is "squares". Many other locales work well. If LANG="", then only English works.
<rekado>guix-vits: if you can find a value that works then the wrapper could simply reset LANG from zh_CN.* to a value that works.
<rekado>(if that’s how neverball sets the language internally)
<rekado>another approach would be to check how neverball configures the language and fixing it right there in the code.
<guix-vits>rekado: 1.6.0 is pretty old, so maybe it's fixed in git, need to see.
<wxie1>Hi, I tried to install guix-1.0.1, but the USB is not recognized by coreboot. Is any has the same problem?
<brendyyn>Anyone else find many gtk programs complain of not being able to load adwaita cursor theme despite it being installed?
***wxie1 is now known as wxie
<guix-vits>brendyyn, rekado: i found a compromise. instead of setting LANG="" for broken-fonts-locales, i can set them to en_US: this way GUI language settings aren't broken and changing the language in GUI brings desired results from every start (default behavior).
<mbakke>wxie1: I don't know about coreboot, but at least for libreboot there is an option to search for GRUB2 configuration on external media.
<rhou[m]><kmicu "Hi rhou last time I checked Guix"> Thanks for the reply
<guix-vits>i can't make guix: "firstname.lastname@example.org:4584: format specifications in 'msgstr' are not a subset of those in 'msgid_plural' /gnu/store/cdf88q6si537hkqimkr985rr4pmwj40c-profile/bin/msgfmt: found 1 fatal error"
<bricewge>guix-vits: Have you tried to `make clean`?
<guixer>guix-vits: awesome, that fixed the warning. Thanks!
<guix-vits>rekado, brendyyn: in freshest git-version of neverball camera behaves a lot better, but (game have a bundled fonts, and i have adobe CJK-fonts installed) with LANG=zh_CN.utf8 the fonts are steel "squares". So i'll keep default lang to "en_US.utf8" (in wrapper; this not prevent user's language settings from taking effect). Thanks.
<walafar>Hello to all! I am a new user of this system. I read from the manual how to update the system via the "guix pull" command and then enter "guix system reconfigurate / etc /config.scm". But I get an error: "
<sirgazil>brendyyn: I didn't get ibus to work on sway the same way it works on GNOME, but I worked around the issue, and could at least use it.
<guixer>Hej. I am trying to build certain software and I think I ran into some basic issue, that I can't figure out myself: /gnu/store/......0x0-coreutils-8.31/bin/install: cannot change permissions of ‘/etc/certaintool’: No such file or directory
<guixer>I think think I am missed to pass some --prefix arguments somewhere in my package definition
<nckx>guixer: Guix foo-build-systems pass --prefix (or the equivalent for foo) automatically. But some packages don't respect it, or need more convincing. I'd look at the Makefile (or equivalent) to find out which variable is actually passed to the ‘install’ command.
<sirgazil>Speaking of semver, alextee[m], packaged software comes from different project management cultures, so I think version precendence can't be checked using the the semver specification, right. Or am I missing something here?
<pkill9_>though it would be good to have this as a variable
<pkill9_>because sometimes it moves to different subdirs
<nckx>sirgazil: You'll have to special-case ‘rc’ and ‘-rc’ or other things will break; 2.0.1rc1 < 2.0.1 but 2.0.1p1 > 2.0.1 because versioning is hopelessly broken.
<alextee[m]>sirgazil: well, it works for most software. i don't think you can reliably compare versions with so many version schemes available unless you accomodate all of them. but even if it doesnt work properly for some packages, i still think it's good to have any of them being the "main" one
<guixer>nckx: I'll try the configure flags first, but I don't understand how to refer to the current build context/folder as a prefix: #:configure-flags '("--etcdir=<whichvariablehere???>/etc")
<rekado>brendyyn: ’what about all that gtk2 gtk3 cache path stuff’ — that’s probably no longer needed for ibus in GNOME.
<alextee[m]>sirgazil: actually, how does guix decide what package to install when you enter a package that has different versions? we should use the exact same logic
<rekado>brendyyn: these variables should be set automatically when a gtk application is installed.
<guixer>nckx: I tend to look at the scripts from slackbuilds.org usually. I do not build that often.. and the slackbuilds are usually quite simple and give me a good idea on how to build stuff
<sirgazil>alextee[m]: I think so, yes, instead of semver.
<rekado>(though it could be prevented from being set due to an old bug)
<guixer>nckx: But I should definately look into the proper workflows for building :)
<nckx>guixer: That's fine, so do I. Just remember that those are written by humans which can make silly mistakes/refuse to read --help text too 🙂 I've seen some… things in PKGBUILDs that really shouldn't exist.
<starcrATI[m]>Hey guixers, I have a problem with gpg ... I am not able to decript any of gpg encrypted files due to gpg not finding any pinentry program. Even tho pinentry is installed, and "pinentry-program /home/$USER/.guix-profile/bin/pinentry" is set in my .gnupg/gpg-agent.conf. Rebooting and reloading the gpg-agent doesn't help unfortunately. Does someone experience the same problem?
<sirgazil>By the way, alextee[m], when I designed the packages URL paths, I thought that Guix would maintain all older versions of packages, so I thought pages in paths such as package-X.Y.Z or package/X.Y.Z would be kept available.
<nckx>starcrATI[m]: Well it should 😛 No stale gpg-agent running with the old configuration, by chance?
<nckx>Right, ‘i’ was removed from the hex alphabet in 1985, try aa7f3ec.
<bricewge>starcrATI: What is the exact content of your ~/.gnupg/gpg-agent.conf?
<nckx>guix-vits: I don't spot anything serious. Haven't used the copy-b-s myself yet. Unserious things: ‘( "a" "list" )’ → ‘("a" "list")’; same for ‘) ))’ → ‘)))’ &c.; did passing all those setenvs directly as make arguments not work?; please use ‘.utf8’ locales unless this actually breaks something; did you run ‘./pre-inst-env guix lint neverball’ already?
<bricewge>starcrATI: The first entry looks good. Maybe try removing the second one.
<starcrATI[m]>> liberdiko: starcrATI: Rereading the conversion, if you followed nckx advice you should have tweaked the pinentry-program a bit: use your home and use pinentry-gtk-2 or pinentry insteadn of pinentry-tty
<starcrATI[m]>I had it always point to the correct guix path for pinentry
<wxie>mbakke: It finds the grub.cfg, but during booting it says it could not find the kernel ..., please load the image first...
<starcrATI[m]>lfam: It seems like that GnuPG on Guix did not like that I had another pinentry-program specified in the second line of gpg-agent.conf for non-guix systems ... it was "pinentry-program /usr/bin/pinentry" when I removed that line, it worked on Guix. So I guess the specified pinentry program for Guix System in the first line got overridden by the second line. After that, I put the line for non-guix systems into the first
<starcrATI[m]>line. It works now on Guix System and a Debian system I tested it on. Therefore, the debian GnuPG seems to not be affected by the second pinentry-program for guix systems in the second line of gpg-agent.conf
<lfam>Alright... at the moment the Guix GnuPG package is subtly broken for users on foreign distros, as you found
<lfam>I think I should revert the commit that introduced the issue
<lfam>You shouldn't ever need to do tell it about /usr/bin/pinentry on foreign distros. That should work automatically
<guix-vits>ah, also i do need to add #t to some phases.
<nckx>If (invoke "make" … "CC=…" "DATADIR=…") worked, we can make this package more idiomatic by making them #:make-flags, adding make-flags to the lambda arguments, and using (apply invoke "make" "-j" (number->string (parallel-job-count)) make-flags). That's a nice-to-have detail, though 🙂
<nckx>You can run the Shepherd as yourself and run user services (on both Guix Systems and non-), but that doesn't currently integrate with Guix at all. There would be no benefit over writing (say) systemd services apart from 3000% more brackets (yay!).
<nckx>there was little integration on systemd's end back whenever.
<lfam>The shepherd is currently very simplistic. The goal is to make it integrated like systemd, but there is relatively little energy being spent on that
<nckx>If there is now, that's good I guess. How do they integrate, lfam?
<lfam>nckx: They can depend on system-level services, and other things like mounts, timers, etc. The logging is all integrated in journald. Systemd automatically manages authentication when a user tries to manage system-level services that require privileges
<nckx>guix-vits: Could you expand that just a bit more? ‘Also included is Neverputt, which is a foo that putts bars.’
<guix-vits>nckx: it's time to go raid the Debian again. they has a lot of beutiful descriptions :)
<apteryx>hey, I recently my ibus-daemon started defaulting to US keyboard layout instead of dvorak (listed as the first keyboard layout when I check ibus-setup). How can I control the default keyboard it uses?
<guix-vits>nckx: "Also included is Neverputt, which is a 3D miniature golf game."
<sirgazil>raghavgururajan: I've been able to package software from GitHub before, but, for some reason, I haven't been able to lint/build a package I started yesterday because of github limits for request from anonymous users or something like that.
<NieDzejkob>aidenholmes: Hi, former Qubes user here. You won't see the approach to minimize the trusted code base over here, but modulo 0days, guix environment --container could do some of what you want
<efraim>kinda OT here, but I'm looking to host somewhere between 15-30 GB of (mostly) photos & videos for my child's daycare, as an alternative to the 15GB max of google photos, any suggestions? I was thinking mediagoblin but I'm unsure about other options
<Blackbeard>efraim: web hosting? I use syncthing but not sure that's what you want
<nckx>Thanks everyone. I'm doing much better now 🙂 Just take this seriously and take care of each other.
<guixer>lfam: in the build phase, there is some autoreconf going on, then it changes to a subdir and runs ./configure. Directly after that I receive this error. Could it be, that /bin/sh is not available in the environment?
<rhou[m]><NieDzejkob "6 is quite a small number, to be"> I wanted it to it on my USB stick
<NieDzejkob>see info "(guix)Proceeding with the Installation"
<rhou[m]><NieDzejkob "rhou: you did remember to run co"> I saw this in the install.scm file
<guixer>lfam: I am still on the shebang patching. I followed your advices and found the parts to patch shebangs after certain phases. It seems to be like you said, that the 'configure' file is autocreated in the same phase it is executed. I could not find /bin/sh or /bin/bash in the source files. Only occasion I found is in configure.ac: configure.ac: AC_P
<guixer>ATH_PROGS(BASH, bash). Could that be the line which creates the shebang for configure file?
<guixer>It would be nice to debug the build process.. is there a possibility to run the build phases manually and to trace which command creates certain files at runtime?
<guix-vits>guixer: i'm not a dev. You're probably can `guix environment --pure --ad-hoc x y z`, and run things manually.
<guix-vits>guixer: to not run everything from scratch, you can use `guix build X -K` -K mean keep failed, you can see the failed build in /tmp.
<fishyfriend>it seems i had all the keys already, perhaps i started this setup earlier and forgot. maybe it's a "me" issue and not the manual...just wanted to raise this since, i'm a fairly new user and it confused me
<NieDzejkob>bandali: huh, I was under the impression that git-authenticate.scm was supposed to be only modified by ludo
<fishyfriend>bandali: the instructions are for verifying the commit history of git-authenticate.scm using `git verify-commit', prior to actually using git-authenticate. they listed one key but it seems they should also include yours now
<fishyfriend>should i send a patch do this? or is it better left alone till another fix is in place?
<mbakke>I think I understand the issue with 'moc' and have attempted to patch it so that it ignores the GCC _GLIBCXX_VISIBILITY macro. I'll bring the issue upstream tomorrow.
<mbakke>Guix should probably come with some sort of addiction warning like the cigarette packs.