<lfam>Ohhh I didn't realize it was on Guix <lfam>There may already be a configuration parameter available <lfam>You should be able to do it by creating your own sudoers-file in config.scm and adding the timeout there <alextee[m]>is there an example somewhere of this? i don't want to overwrite the default config, i want to append to it <sirgazil>I do I list the packages installed in some specific profile? <lfam>It's like: `guix package --profile=/home/lfam/.config/guix/current --list-installed` <bandali>sirgazil, `guix package -p path/to/profile -I' <sirgazil>Let me see... (I tried with -I first and didn't work) <nothingmuch>in genreal what's are the considerations for renaming/splitting packages? <lfam>nothingmuch: There needs to be a reason for it <nothingmuch>lfam: if you are Leo Famulari, that actually relates to your feedback WRT 39966 <nothingmuch>so, nckx suggested i rename python-compiledb to compiledb since it's a command, not a library <nothingmuch>separately, your suggestion to remove shutilwhich seems trivial - very simple substitute* <lfam>If it's an end-user application it doesn't need the "python-" prefix <nothingmuch>but i also noticed there is only one dependency on whichcraft, which is basically the same thing <nothingmuch>and *that* in turn is used by python-cookiecutter, which is also a tool and not a library <nothingmuch>(which incidentally only requires it for versions of python <= 3.3) <lfam>Use your judgement here. As long as the packages are free software and work then they are basically fine <nothingmuch>well, it's more of a general question - i'm more than happy to clean that up while i'm at it <lfam>If it's a program that a person runs on the command line, it doesn't need the python- prefix. If it's a Python module or library, then it does. In general... <nothingmuch>so, i guess it's more... what is the maintenance philosophy given that guix and packages are coupled and guix has good support for channels/inferiors <lfam>What do you mean by maintenance philosophy? Like the external API for channels? <nothingmuch>i mean, is it actually hlping anyone if i take the time to also remove/cleanup whichcraft and/or rename python-cookiecutter <lfam>I would leave them alone unless there are reports that people are having trouble finding them <nothingmuch>i can see it as a positive (cleans up/simplfies packages) or as a pain <lfam>We don't go out of our way to rename things (change the API) but we explicitly do not maintain any sort of promise of naming stability for channels. Linux-style. If one wants stability for the stuff on a channel, it needs to be part of Guix <nothingmuch>any preference re patching compiledb vs. just removing the python2 variant of shutilwhich? a small substitute* seems cleaner to me but most of the other patching i see is more strictly concerned with environment compatibility <nothingmuch>the main reason i think substitute* is cleaner is since it's completely redundant with a whichcraft, which in turn is kind of needlessly depended on by cookiecutter and nothing else <nothingmuch>will go with that for now, less code = better code. thank you for the feedback so far! <nothingmuch>when is it appropriate to substitute* in a snippet vs. new phase after unpack? <lfam>nothingmuch: Snippets are just for fixing freedom issues in upstream source code, so that `guix build --source` returns freely distributable source code <lfam>We need to avoid the Guix tools offering nonfree code to users ***jonsger1 is now known as jonsger
<goldenshimmer>Hi! I'm trying to figure out the basics of writing a package definition. I started with the example from the manual, and have put my new module in a git repository, and added it as a channel. I'm now trying to debug it by editing it, then running "guix pull" (it has a syntax error). <goldenshimmer>Can I skip the "Computing Guix derivation" step when pulling? It makes trial-and-error debugging quite slow. Is there a better way to debug? Can I get more verbosity in the .drv.bz2 file in /var/log (mainly looking for a line number)? Thanks! <lfam>goldenshimmer: It's easier to build from Git and described in the manual section Contributing <lfam>After you're sure your package is good, you can move it back to your channel (or, ideally, contribute it to Guix) <lfam>It will take a few minutes to build the development environment but subsequent work will be more efficient <lfam>Let us know if you have any questions about getting it set up! <reepca>rekado: I'm not working on it currently, but the project I am currently working on should be done by the end of March, at which point I intend to resume working on it. <nckx>That's great news, reepca. <goldenshimmer>Got the Git environment all set up. Way past my time for bed to poke at it much, but running the package build using ./pre-inst-env in the git repository worked! Evidently the problem was with my channel configuration or something, rather than the module itself. This seems like it will be a much easier way to work, indeed. Thanks again! <apteryx>bandali: No news from that issue I opened with Emacs. So I sent a message today in one of the related thread that we should just proceed with the workaround (and life) :-) <Humanoid>I got this error on a guix pull "too many redirects or authentication replays" <lfam>It sounds like something is fishy with your connection to the git repo <Humanoid>Is it using its own private code of git? Or is it using the one from my devuan distribution? <Humanoid>Yeah, it's using its own. I tried renaming the one from my distribution, and it still was able to run git. <Humanoid>I'm able to access that url with my web browser. <Humanoid>I'm also able to clone the repository using my host distribution's git. <lfam>It would be great if the error message was more descriptive. I guess we need to figure out what piece of code is emitting the error <Humanoid>Its from git, here's the full line: "guix pull: error: Git error: too many redirects or authentication replays" <lfam>Right, but is it guile-git, libgit2, Guix? <lfam>Humanoid: My copy of Guix says "guix pull: error: verbose: unrecognized option" <lfam>Can you do `guix describe`? <Humanoid>Even if I remove the "--verbose" it outputs the exact same thing. <lfam>I googled the error message. It's from libgit2 <lfam>How did you install Guix? <Humanoid>I've followed the manual to install it over Devuan. I also documented every step. <lfam>If nobody else chimes in soon, can you send a message to <help-guix@gnu.org>? I'm not sure where to go from here <lfam>Please include the answer to the questions I asked here <Blackbeard>Humanoid: when was the last time you did a 'guix pull' that worked? <Humanoid>Back when I installed it. And then I didn't use it for a while until now. <lfam>One more thing you could try. You said you were able to clone the Git repo just with Git. Try pulling from the local copy of the repo <Humanoid>I believe I installed it around November 15th, 2019. <lfam>You should be able to do `guix pull --url=/home/you/src/guix` or maybe you'll have to add 'file://' <Humanoid>Or at least the last time I used it, since that's the date on my notes.txt file. <lfam>Obviously not ideal but maybe it's a bug in the guile-git stuff that we fixed since then <Blackbeard>Maybe doing a guix pull and update packages as root would work <guix-vits>Blackbeard: "pull as root on On-top; do not pull as root on System" <Humanoid>guix pull --url=<my local git directory>, is working so far. <lfam>Great. Hopefully it's some bug we fixed and you can go back to the normal way afterwards <lfam>A lot has happened since November <Blackbeard>guix-vits: I suggested that because this is on devuan not Guix system <Humanoid>Ok, so I completed the "guix pull --url..." from my local git, but then running a regular "guix pull" still gives the same error. <Humanoid>Do I have to "guix package -u" in between? <guix-vits>is `guix` automatically added to user's profile after first `pull`, or the system's profile `guix` is used? <guix-vits>(just wonder if there is need for the `system reconfigure`?) <Humanoid>I upgraded all installed packages with "-u" and it didn't fix it. <Humanoid>The only package that was upgraded was glibc-locales. <Humanoid>It seems the "guix" command is not part of a package. <guix-vits>Blackbeard: i'm not sure what i'm mean, honestly :) <Humanoid>Why does it tell me that 2 packages will be upgraded, but the version is the same? <Humanoid>If I just use "-u" with the ". -n", it tells me one package will be upgraded, but doesn't actually do anything, since I've already upgraded it. <Blackbeard>Humanoid: ok and guix pull is giving you the same error? <Humanoid>Yeah, guix pull is still giving me the exact same error. <Humanoid>After running "guix pull" as root, now I'm able to run "guix pull" as a regular user. <Humanoid>So running "guix pull" as root fixed the problem. Maybe there are some files there that the user doesn't have permission to update. <Humanoid>I'm sharing the same profile between the regular user, and root user. <guix-vits>In Guix System it's easier (if i get it right): <guix-vits>`pull`; `sudo [-E] guix system reconfigure <config>`; `-u` <Blackbeard>Humanoid: yes because of your systems permissions <Blackbeard>Make sure to run guix package -u after you guix pull as root <Humanoid>It looks like everything is working now. Thanks! <rekado>Blackbeard: that’s not an error. <rekado>this should automatically trigger an archive job on Software Heritage ***apteryx_ is now known as apteryx
<dftxbs3e>Using HTTP2 in both GNU Guix as a client and HTTP2 in the artifact server would certainly help speed up installation time. <Blackbeard>rekado: ohh you are right. Seems like the error is because the URL on sourceforce is redirecting me <Blackbeard>gnu/packages/games.scm:10211:12: barrage@1.0.5: all the source URIs are unreachable: <Blackbeard>gnu/packages/games.scm:10211:12: barrage@1.0.5: source not archived on Software Heritage <ngz>Blackbeard: You probably need to use a sourceforge mirror URI. <Blackbeard>it was https and I changed it to http to see if that fixed the error <ngz>You need to turn this into a sourceforge mirror URI <ngz>Probably mirror://sourceforge/lgames/barrage/barrage-1.0.5.tar.gz <Blackbeard>ngz: hey that fixed the error, just the software heritage remains, let me change to mirror <Blackbeard>gnu/packages/games.scm:10211:12: barrage@1.0.5: source not archived on Software Heritage <ngz>It is only a warning. <ngz>Mind the space at the beginning of your description. <ngz>war going on at the moment to decide if base32 should be on the same line as the string... <ngz>I'm on the side of "use the same line". But importers, and, e.g., lfam, disagree :) <ngz>So, I cannot suggest anything. Choose your enemies wisely ;) <ngz>In any case, your package looks good. <ngz>Note the license should probably be license:gpl2+ <ngz>AFAICT, in ".c" files, there is "(or any later version)" <ngz>Good question. I usually trust source code files. <ngz>Another nitpick: you can put the `origin' on the line below `source' <Blackbeard>now I can put the string in the same line as base32 <ngz>np. Please send your patch to guix-patches@gnu.org when you think it is ready, or if you need more advice. <Blackbeard>this one I will send it after I build it in more platforms with qemu <Blackbeard>there are not many other things I need, and the wish list is kinda hard :/ <Blackbeard>I am not sure why some fonts are not packaged though, I will try to package those from the wishlist <ngz>Yes, Guix is too serious with all its Bioconductor packages. We need more games! :) <ngz>What wish list are you referring to? <Blackbeard>seems like my package is building without problems in all architectures :) <ngz>I started packaging ufoai and secret-chronicles games (which are not in the list), but I do not have time to finish them for now. Probably in a few weeks. <nothingmuch>my computer shutdown due to losing power, and i am now unable to run guix environment on a manifest that worked with this same version of guix before` <nothingmuch>i'm not finding any promising results on the web for this error output: <nothingmuch>substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable <nothingmuch>guix environment: error: getting attributes of path `/gnu/store/sji2sqfh4x9b6vb9kp6qk0l5ci8h55h2-libtool-2.4.6.tar.xz': No such file or directory <rekado>you probably did not authorize the build farm <rekado>that’s what the ACL error means. <rekado>to repair your store after power loss run ‘guix gc --verify=repair,contents’ as root. <nothingmuch>tl;dr - i'm on debian in qubes, and my /rw/config/rc.local script broke due to changing paths <civodul>guix-vits: that's not how Schemers would usually indent it :-) <civodul>you can check the examples in the manual <nothingmuch>hmm... i really should look into making a proper guix system templatevm at some point <efraim>one of these days I keep on meaning to return to openstack.scm and repackage the whole thing <efraim>grep define-public only lists 42 packages, probably half are python2- variants <guix-vits>Hi janneke. Hi jstierhof; can you post this './configure'? Possible that can be solved by '(substitute*' or something alike. <guix-vits>efraim: If you packaging Win98, it's normal. Use --keep-failures. <efraim>i closed icecat, last I saw I had about 200 MB left between the two <efraim>DE and other open programs generally take about 350MB <rekado>guix-vits: is there a conversation I’m not seeing? <guix-vits>i'm just saw Blackbeard desiring to package some more games... <janneke>hmm, a fresh core-updates -- i could try rebasing on that <guix-vits>jstierhof: Please, use paste.debian.net (pastebin is behind Cloudflare's captchas) <guix-vits>Above paste is "I try to build software which requires libx11 and the Intrinsics.h from libxt, however, they are not found by default and I can only specify --x-includes for one directory. Does anyone know how to deal with that? Thanks!" <jstierhof>I just realize that this will most likely not help. There are lots of, let's call them subprojects, with there own ./configure <jstierhof>let me just find out which is the failing one <janneke>does someone have a znc service for guix? i'm still running it by hand <civodul>oh, "make check" says we have precisely 1000 tests <jstierhof>I also tried to replace 'configure such that it calls ./build_dir/configure but here it fails because some files still have a "#! /bin/sh" shebang <guix-vits>shebang can be patched (there is an procedure for this)... about --x-includes: <guix-vits>there is --includedir and --oldincludedir ..? <guix-vits>also: there is option "with-x", so, in the worst case an --without-x can be passed. <rekado>huh, mu does not seem to find anything for a query containing a dash. <rekado>so searching for ‘r-minimal’ yields nothing, whereas ‘r minimal’ is fine. <jstierhof>shebangs should be patched, that's why I do not understand why it fails here. Without X11 support works, but is not going to work for me in the end <jstierhof>Well, I'll leave it here for now. Thanks still <guix-vits>jstierhof: 'ac_prev=includedir ;;' and 'ac_prev=x_includes ;;' -- same variable is sourced (seems so). <guix-vits>maybe it actually can use a different dirs for x-stuff? <guix-vits>jstierhof: looks like there should be used ''(substitute*'' to change all these `if test -d ...` to `x_includes=/include` (probably) <nly>how do you add/request a new guile package? <guix-vits>nly: probably by sending this patch to guix-patches@gnu.org . <nly>thanks guix-vits. no requirement for guile-x.0-foo variants? cool <guix-vits>nly: patches are reviewed, so anyone can send a patch. <guix-vits> semi-citation\: "and be ready to wait either less or more than 1 day". <nly>cool, that's reasonable :) <guix-vits>nly: did you tried to build it with guile-next, by chance? <nly>guix-vits: build fails with guile-next <rekado>nly: does the configure phase fail? <nly>rekado: ah, that must be the current version of Guile in my environment at some time. *nly checking the manual for correct usage of GUILE_PROGS <guix-vits>rekado: failed build log (changes: `("guile" ,guile-next)`) <rekado>guix-vits: don’t just replace guile with guile-next. <rekado>you need to do this for all packages recursively, including guile-gcrypt in this case. <rekado>guix-vits: see package-for-guile-3.0 in (gnu packages guile) *rekado updates issues.guix.gnu.org to use a faster mumi <divansantana>Perhaps it's not needed. Having issues with some java software(jitsi) and wondering if it's because of the openjdk version. <rekado>issues.guix.gnu.org should now be much faster <rekado>much faster search, faster loading of front page, more accurate search. <rekado>it’s still talking to Debbugs more than I want, but most expensive operations are now done locally. <guix-vits>rekado, nly: it's builded successful with `(package-for-guile-3.0` *jonsger already closed two bugs because using new mumi is so much fun :) <guix-vits>rekado: (define-public guile3.0-gcrypt (package-for-guile-3.0 guile-gcrypt)) <guix-vits>what about this: ("guile" ,guile-next) -- wrong? <Krafter>Hi. I recently installed Guix on my Linux mint machine. Unfortunately it wrote to the infopath env var and now I can't access info directory. <rekado>Krafter: can you tell us what exactly you did? <rekado>merely installing Guix will not touch your INFOPATH variable. <civodul>git shortlog -s --since=last-month| wc -l ⇒ 76 <jonsger>12.5k commits since 1.0.1. I guess 1.1.0 will become the biggest release <jonsger>what is missing for the release? what are we waiting for? <Krafter>rekado: I downloaded the install script from the link in the manual and installed. <Krafter>Also I grepped my home for infopath and found nothing. <Krafter>guix-vits: info now only gives manuals added with Guix. <rekado>Krafter: are you sourcing ~/.guix-profile/etc/profile? <guix-vits>Krafter: try to login in some tty, and check again, please. <rekado>how do you make the packages available that have been installed with Guix? <rekado>Guix will set INFOPATH when a profile contains packages that have an INFOPATH search path specification. <rekado>but you still need to actually load that etc/profile file yourself. <rekado>it won’t just modify your environment. *guix-vits ("guile" ,guile-next) or ("guile-next" ,guile-next) ? <Kimapr>i'm installing guixsd on a flashdrive from qemu <Kimapr>i decided to do that because i failed to install guix to flashdrive i'm booting from <anadon>Yay! Ludovic got back to my email. And I know I've been chatting with him on here a bit, I just don't know what his username is. <Kimapr>for some reason when i try to mount a partition it says it's mounted or mount point is busy <guix-vits>civodul is really cryptic nick (i'm not stiv) <Kimapr>deleting the partition, doing some wizardly magic and creating it again fixes that <Kimapr>but then guix system init can't find the efi partition by uuid <Kimapr>after fixing that by identifying efi partition by hardcoded path it complained about device not having free space <Kimapr>but the partition i tried to install to was ~50 GB big <Kimapr>uhm, i don't understand you. yes, i ran that command <Kimapr>interestingly though i had no problems installing guixsd from flashdrive to hdd <anadon>Whoa, guix's packaged version of singularity is 2.6. What's going on with that? <civodul>anadon: Singularity 3.x is a rewrite in Go, and i think that was hard to package back then <rekado>I guess nobody uses it so nobody bothered upgrading it. <anadon>Are Golang programs still hard to package? <guix-vits>Kimapr: can you post the flashdrive partition table to paste.debian.net (`lsblk`)? <Kimapr>well, now it's just one efi partition and one ext4 partition <civodul>anadon: i think it's not "hard" per se, but there used to be few Go packages available <anadon>OK, not as bad as it first looks. <Kimapr>flashdrive partition table used to be all guixsd installed partition + 2 ext4 partitions after it <guix-vits>... (setenv "USER" "homeless-dude") ... -- sexists. It should be a homeless-person :) <Kimapr>then you discriminate non-persons <Kimapr>uh, i didn't mean that, i meant those who are not persons <Kimapr>well, not like they are going to use a computer anyways... <guix-vits>homeless-primitive-lifeform ... i like it XD <civodul>guix-vits, Kimapr: i'm not sure how this discussion started but it seems off-topic :-) <Kimapr>i'm not sure if it's good, but i don't see any partition tables on flashdrive with gnome-disks even though i created one with qemu <Kimapr>maybe it's because it is in use by guixsd installed <guix-vits>Kimapr: DVD-drive is present on this computer? <guix-vits>Why not boot from DVD, then do this flashdrive things? <Kimapr>i have no dvd disks to flash guixsd installer on <Kimapr>it stuck scanning /dev/sdb (the flashdrive) <guix-vits>Kimapr: try `fdisk /dev/sdb`; enter m to see a menu. Best tool for partitioning, i'm think. <guix-vits>Also, GRUB can boot from .iso; worth to try. This way you can load system from HDD. <Kimapr>i already used cfdisk to partitionate flashdrive <apteryx>is our init ram disk currently able to access network? I'm starting to think about the boot on NFS scenario. <Kimapr>because the flashdrive is supposed to be booted on different computers <rekado>guix-vits: are you familiar with how Guix System is installed? I’m trying to figure out what the goal of the questions is. <guix-vits>rekado: GRUB's `loop guix.iso`, boot from HDD; install to USB-flash. <rekado>I don’t know what this means and why you think this is necessary. <rekado>Kimapr: can you tell us how you’re trying to install Guix System? Are you using the installer disk image? <Kimapr>i'm installing it through a qemu virtual machine <Kimapr>it's building XDG MIME database right now <Kimapr>did anyone tried installing guixsd on real hardware through qemu? <dongcarl>So I've thought a bit about the mingw-with-pthread vs mingw-without-pthread thing... And I think that it is reasonable to expect the default toolchain to have C++ threading support if C++ is indeed supported... So maybe I'll switch the default <dongcarl>Will probably make people's experiments cross-compiling to windows go much smoother as well <dongcarl>Also, for those who cross-compile to windows: I'm going to test mingw-w64 7.0.0 locally then bump it in Guix. The _FORTIFY_SOURCE feature might be useful <mfg>Hi guix o/ I was just trying to `guix pull' and got: Migrating profile generations to '...' -- guix pull: error: symlink: File exists: '...'. Why does guix try to migrate my profile generations? <civodul>mfg: what does "guix describe" return? <civodul>there were a couple of bugs in this area that have been fixed <guix-vits>Kimapr: yet i'm think that mount guix.iso from GRUB using `loop`, booting from that .iso, and installing to USB is simplier that do this from quemu. Or you're already done with this? <Kimapr>i don't know grub commands very well <Kimapr>and didn't know it can boot from iso <Kimapr>uh idk, i found a way, and i'm doing this way <mfg>civodul: yes i'm just reading 36785. <mfg>guix describe: error: failed to determine origin <mfg>hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version string is <mfg>i'll test some things <mfg>just tried to load a older system generation, but this makes no difference... <mfg>Do older generations still contain the same guix? <nckx>mfg: Guix isn't taken from your system profile. <nckx>‘guix pull’ creates a separate profile just for Guix. <nckx>Older Guixes are available from /var/guix/profiles/per-user/$USER/current-guix-*-link <nckx>I've no backlog so I assume there are no problems or bugs and I wasn't pinged. Great! <nckx>civodul: Nice, you've reported the wrap-script bug I encountered yesterday. Thanks! Please continue. *janneke finds test-guild-compile fails on the hurd -- seems another kill-related thing <mfg>nckx: i see. how do i rollback guix then? <nckx>mfg: I'd do so by manually linking /home/nckx/.config/guix/current to /var/guix/profiles/per-user/$USER/current-guix-$working-link <nckx>Well, *I* wouldn't, because I've ‘solved’ your issue before by simply deleting the already-existing directory you elided above. <anadon>`guix describe: error: failed to determine origin` -- what? <nothingmuch>anadon: on debian i get that when invoking guix by symlink (e.g. i have ~/bin/guix -> ~/.config/guix/current/bin/guix) but but the correct version is reported if invoked directly <nothingmuch>sorry, corret version is always given, full information is only available invoking it directly <anadon>nothingmuch: `$ /gnu/store/8251610p3h1wdd37lw4d4xsahvq5zhm3-guile3.0-guix-1.0.1-14.c2f9ea2/bin/guix describe <anadon>guix describe: error: failed to determine origin` <mfg>i had the exact same thing half an hour ago, manually setting the symlink from ~/.config/guix/current to /var/guix/profiles/per-user/$(USER)/current-guix-$(LAST_WORKING)-link <nothingmuch>anadon: i get that too invoking by FQ path for /gnu/store/*guix-$version/bin/guix, but i do get the correct output for profiles <anadon>Shouldn't this be something that is correct by default? Modifying it could have knock off effecs later on. <nothingmuch>i didn't look into how guix describe works, but based on this i think it's a property of the profile, not just the program? <nothingmuch>(note that's just an arbitrary version out of my store, i didn't try them all) <anadon>I think I'll hold off for one of the dev's. I'm guessing this is a symptom of something else going wrong. <Kimapr>oof, installation process almost finished but i accidentially quited <Kimapr>good that it doesn't start all over again from start <Kimapr>it only starts copying to /mnt again <nothingmuch>anadon: guix/scripts/describe.scm will look at where the program lies, if it's in a git checkout directory or a profile, it can report that metadata, otherwise it fails <Kimapr>cool. now gnome-disks sees the partition table made in qemu <anadon>nothingmuch: Then it sounds like my installation is a little borked. <mfg>one question about guix environemnt: When i use it like `guix environment gcc-toolchain' why does `which gcc' doesn't find it? <civodul>mfg: you probably want to use "guix environment --ad-hoc gcc-toolchain" <mfg>Hm this also gives me `gcc not found' after running `which gcc' <mfg>running `guix environment --ad-hoc gcc-toolchain -- which gcc' gives the correct output, are there any files i need to source? <mfg>well it seems like $GUIX_ENVIRONEMNT/bin is not in my PATH... <mroh>mfg: try "type" instead of "which" (which is an external prg, type is bash internal...) <mfg>mroh: i use zsh, which seems to be a builtin <mfg>speaking of zsh, this seems to be the problem `guix environment --ad-hoc gcc-toolchain -- bash' works just fine ... <anadon>civodul: Should I move the thread as is in full to bugs? <civodul>anadon: no, please keep the email to bug-guix focused on the CentOS issue <jsoo>Any idea why guix environment exits after the first command in the environment? <jsoo>(Pardon me, in fish shell) <mfg>where/when does bash set the new GUIX_PROFILE variable when running guix environment? this seems to not be happening with zsh <mfg>because manually doing it works <mfg>nckx: because it was such a simple solution ;D <nckx>Ah, the good kind of ☹ 😉 Glad it worked. <lfam>Where's the code that creates <logs.guix.gnu.org>? I want to try reversing the order of the logs so the latest logs are at the top <civodul>rekado should add a copyright notice there <lfam>Thanks civodul. I figure we usually want the latest log <jsoo>mfg: seems like I might have the same problem in fish. I also notice that installing fish-foreign-env does not make fenv available in fish <lfam>I should know this... are UNIX sockets available in the build chroot? <lfam>I just read Build Environment Setup which describes the build environment, but it doesn't mention networking. Is the lack of networking in the build environment documented in the manual? <jsoo>mfg: I think it might but fish is not posix compliant so you there is a function called fenv that is defined in fish-foreign-environment that would allow the sourcing of the profile. I haven’t been able to test it because fenv doesn’t seem to install correctly <vagrantc>updated the kernel for pinebook pro ... some ugly hacks involved ... ok to rebase and push to wip-pinebook-pro? <mfg>jsoo: hm okay i never used fish <lfam>vagrantc: The wip branches are okay to rewrite history, yes. You'll need to delete the remote branch and push a new one, though <lfam>Force pushing should be disabled <vagrantc>lfam: also curious if ugly hacks are ok on wip branches ... or if they should still be "clean" <vagrantc>e.g. the kernel package is still 5.5.x, even though the actual kernel built is 5.6-rc4+patches ... for reasons <lfam>It stands for "work in progress" so I think it's okay as long as it doesn't violate the FSDG. You don't want to mess things up for people though, so it should at least work <vagrantc>trying to balance making progress and not duplicating work with ... wow, this is *ugly* :) <vagrantc>it's borderline with the FSDG as i'm using the linux-libre deblobbing scripts from 5.5.x which probably need an audit <anadon>Looks like I'm going to have more time to spend on here. Work is likely going to send everyone to work from home starting Monday. We've been stress-testing systems for it yesterday and today. <Blackbeard>I did a grep but I didn't find apache in license <bavier>Blackbeard: you might be looking for license:asl2.0 <efraim>can I feed user shepherd an s-expression for a start command? <jvshahid>Hi everyone. I'm trying to use a binary on GuixSD that is linked against libgcc_s.so.1. gcc-toolchain doesn't seem to be linking this library in my guix profile, desptite the fact that the gcc package in /gnu/store has it. Is that intentional? <cbaines>jvshahid, what does ldd say about the binary? <cbaines>you might need to set the LD_LIBRARY_PATH for libgcc_s.so.1 to be found <jvshahid>It finds a bunch of libraries but the following two "libgcc_s.so.1 => not found" and "libstdc++.so.6 => not found" <cbaines>I'm no expert, but maybe the directory containing those files it's not finding? <civodul>efraim: the #:start slot must be a procedure, such as one returned by make-forkexec-constructor <efraim>civodul: the guile repl says this is a procedure: (gexp->script "fc-cache-frv" #~(apply execl #$(file-append fontconfig "/bin/fc-cache") "-frv")) <civodul>yes, but conceptually, it's a monadic value in %store-monad <efraim>ah, and there's my downfall again <civodul>IOW, it's not something you should consider as a "regular" procedure <Blackbeard>Ok so for widelands they changed from launchpad to github <civodul>efraim: perhaps you want to use program-file instead of gexp->script? <Blackbeard>Should I go with the official release or with git? <Blackbeard>I thought guix was more rolling release like and I went with git. But now I am not sure <efraim>shepherd didn't like gexp->script or program-file <Blackbeard>Arch goes with git. Flatpak and debian use launchpad the stable version <Blackbeard>Personally I would prefer git. But I don't know an specific commit to chose or why <mfg>How is the documentation of guix generated? i like the style and thought about using it myself - is this possible? <lfam>Blackbeard: If they make numbered releases, we also use those unless there is a reason not to <lfam>I mean, we *always* use those <lfam>It could be possible to use Git tags from Github