IRC channel logs


back to list of logs

<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]>yeah i just saw that :) thanks
<alextee[m]>Defaults timestamp_timeout=-1
<alextee[m]>like this maybe
<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
<lfam>Okay :)
<nothingmuch>so, nckx suggested i rename python-compiledb to compiledb since it's a command, not a library
<lfam>Yeah, I would agree
<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
<sirgazil>bandali: thanks, it works.
<nothingmuch>well, it's more of a general question - i'm more than happy to clean that up while i'm at it
<nothingmuch>but i don't know if anyone actually wants that
<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
<nothingmuch>ah for compiledb it's obvious
<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>thanks, that clarifies things
<lfam>Glad to hear it!
<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
<goldenshimmer>Cool, thanks!
<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) :-)
<guix-vits>Hi Guix.
<Blackbeard>guix-vits: hi :)
<Blackbeard>I just send my first patch
<Blackbeard>Let's hope it works
<Humanoid>I got this error on a guix pull "too many redirects or authentication replays"
<lfam>Humanoid: What URL?
<Humanoid>It uses this: Updating channel 'guix' from Git repository at ''...
<Humanoid>Should I change the url?
<lfam>No, that's it
<lfam>It works for me
<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?
<lfam>It should use its own
<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>Can you paste the entire command run on <>?
<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>Or `guix --version`?
<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 <>? I'm not sure where to go from here
<lfam>Please include the answer to the questions I asked here
<Blackbeard>Humanoid: did you just install it?
<Humanoid>No, it was a while back.
<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
<Blackbeard>I am not sure but I would try that
<guix-vits>Blackbeard: "pull as root on On-top; do not pull as root on System"
<guix-vits>lfam: ^ ?
<lfam>I don't understand
<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
<guix-vits>Blackbeard: yes, i'm wrong.
<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?
<Blackbeard>Humanoid: please do
<Blackbeard>guix package - u . -n
<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.
<Blackbeard>Humanoid: guix package -u .
<Blackbeard>Sorry missed the -n
<Blackbeard>guix-vits: you mean on a different distribution
<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?
<Blackbeard>Are you doing this as root or your user?
<Humanoid>Yeah, guix pull is still giving me the exact same error.
<Humanoid>I'm doing everything as a regular user.
<Blackbeard>Can you please do $ sudo -s
<Blackbeard>and then try guix pull
<Humanoid>Running "guix pull" as root is working.
<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!
<Blackbeard>Humanoid: wonderful :)
<Blackbeard>I am getting an error
<Blackbeard>Source not archived on Software Heritage
<Blackbeard>How can I fix that :/
<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>Weird it was working a couple days ago :/
<guix-vits>Blackbeard: what URL it is?
<Blackbeard>here is my package definition
<Blackbeard>I am getting this
<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: permanent redirect from to
<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>ngz but how ?
<Blackbeard>it doesn't have a mirror here
<guix-vits>Blackbeard: use httpS :)
<Blackbeard>guix-vits: that doesn't change the problem
<Blackbeard>it was https and I changed it to http to see if that fixed the error
<Blackbeard>the whole URL is wrong
<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>ngz: mirror worked too :)
<Blackbeard>now I am only getting this
<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>Also, there is a
<ngz>war going on at the moment to decide if base32 should be on the same line as the string...
<Blackbeard>oh, so what do you suggest I should do?
<Blackbeard>the same line?
<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 ;)
<Blackbeard>I am just trying to be a friendly contributor
<ngz>In any case, your package looks good.
<Blackbeard>wonderful :)
<Blackbeard>now it is time to build for hours :)
<ngz>Note the license should probably be license:gpl2+
<ngz>AFAICT, in ".c" files, there is "(or any later version)"
<Blackbeard>what happens if the COPYING only says v2
<ngz>Good question. I usually trust source code files.
<Blackbeard>ok good thinking
<Blackbeard>fixed :)
<ngz>Another nitpick: you can put the `origin' on the line below `source'
<Blackbeard>ahh yes
<Blackbeard>now I can put the string in the same line as base32
<Blackbeard>ngz I will do as you suggested as a thank you
<ngz>np. Please send your patch to when you think it is ready, or if you need more advice.
<Blackbeard>yes :)
<Blackbeard>I sent one already earlier
<Blackbeard>this one I will send it after I build it in more platforms with qemu
<Blackbeard>I want to package more games
<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?
<guix-vits>probably ?
<Blackbeard>I like overpass so tomorrow I'll look into that
<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.
<Blackbeard>that's great :)
<ngz>Got to go. Bye!
<Blackbeard>ngz good night :)
<civodul>Hello Guix!
<PurpleSym>Hey Ludo!
<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>hmm, i've been using it for months without issue
<rekado>check that /etc/guix/acl exists
<Blackbeard>civodul: hello ٩(◕‿◕。)۶
<guix-vits>is this "ok" indentation (abstract of contribution rules): ?
<nothingmuch>ah, i see why... unintended consequences
<nothingmuch>tl;dr - i'm on debian in qubes, and my /rw/config/rc.local script broke due to changing paths
<nothingmuch>and it's what's supposed to authorize it on boot
<nothingmuch>rekado: thanks!
<civodul>guix-vits: that's not how Schemers would usually indent it :-)
<civodul>you can check the examples in the manual
<civodul>or the Guix source tree
<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
<civodul>oh, quite an endeavor :-)
<efraim>grep define-public only lists 42 packages, probably half are python2- variants
<janneke>Hello Guix!
<civodul>hey janneke!
<janneke>hey civodul!
<guix-vits>Hi janneke. Hi jstierhof; can you post this './configure'? Possible that can be solved by '(substitute*' or something alike.
<efraim>so close, ran out of RAM at 98%
<guix-vits>efraim: If you packaging Win98, it's normal. Use --keep-failures.
<efraim>quantum-tetris anyone?
<guix-vits>efraim: Do you have more than 4GB RAM?
<efraim>guix-vits: 4 GB ram, 4GB swap
<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
<guix-vits>Blackbeard: ^ (take no offence, please)
<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 (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>guix-vits: Sorry, here it goes
<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 doesn't
<civodul>oh, "make check" says we have precisely 1000 tests
<jstierhof>guix-vits: Total file is to large, but this is the part that is failing
<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>if this option is mandatory?
<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.
<rekado>I’ll have to work around that.
<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: ah. Seen the second paste now...
<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: Can you share a link to this package?
<nly>sure, 1 sec
<guix-vits>nly: probably by sending this patch to .
<guix-vits>as "attachment"
<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>PS: Please use double spacing after '.'
<guix-vits>`guix lint some.scm`
<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>not yet, 1 sec
<nly>guix-vits: build fails with guile-next
<rekado>nly: does the configure phase fail?
<rekado>this doesn’t look right:
<rekado>why GUILE_PROGS 2.0.14…?
<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)
<nly>rekado: i have a fix:
<nly>patch sent
*rekado updates to use a faster mumi
<divansantana>where is openjdk 8? :)
<divansantana>Perhaps it's not needed. Having issues with some java software(jitsi) and wondering if it's because of the openjdk version.
<rekado>divansantana: icedtea-8
<rekado> should now be much faster
<rekado>much faster search, faster loading of front page, more accurate search.
<jonsger>rekado: I'm impressed :)
<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`
<nly>guix-vits: nice
*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))
<rekado>jonsger: yay!
<guix-vits>what about this: ("guile" ,guile-next) -- wrong?
<jonsger>the search is now amazing
<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
<civodul>yeah, it's a little bit crazy
<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.
<guix-vits>Krafter: what `info` command gives?
<janneke>civodul: that's impressive!
<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) ?
<efraim>i'd go with the first
<anadon>Hello, World!
<guix-vits>Hi anadon.
<Kimapr>hello everyone
<Kimapr>i'm installing guixsd on a flashdrive from qemu
<guix-vits>Hi Kimapr; cool.
<Kimapr>no errors yet
<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.
<civodul>that's me :-)
<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)
<anadon>civodul: ^_^
<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
<guix-vits>Kimapr: `herd start cow-store /mnt` ?
<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.
<civodul>right, that too :-)
<anadon>Are Golang programs still hard to package?
<guix-vits>Kimapr: can you post the flashdrive partition table to (`lsblk`)?
<Kimapr>it no longer exists
<Kimapr>well, now it's just one efi partition and one ext4 partition
<guix-vits>anadon: look at :)
<civodul>anadon: i think it's not "hard" per se, but there used to be few Go packages available
<anadon>That is massive.
<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
<Kimapr>one 40-50GB another one 4GB
<guix-vits>... (setenv "USER" "homeless-dude") ... -- sexists. It should be a homeless-person :)
<Kimapr>then you discriminate non-persons
<guix-vits>Kimapr: how to discriminate an discriminative term?
<Kimapr>uh, i didn't mean that, i meant those who are not persons
<guix-vits>an primer? :)
<Kimapr>inanimate objects?
<Kimapr>primitive lifeforms?
<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>not just seems, it IS offtopic
<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>and only one flashdrive
<Kimapr>tried to look with gparted
<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.
<guix-vits>Kimapr: is GRUB installed to HDD?
<Kimapr>yes, but i won't use it
<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>on a flashdrive
<Kimapr>it's building XDG MIME database right now
<Kimapr>so i guess it almost finished
<rekado>oh, okay.
<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>hi mfg
<guix-vits>Hi mfg.
<civodul>mfg: what does "guix describe" return?
<civodul>there were a couple of bugs in this area that have been fixed
<civodul>notably <>
<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
<guix-vits>There was some Ubuntu page...
<Kimapr>uh idk, i found a way, and i'm doing this way
<Kimapr>works fine - so i don't fix it
<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
<guix-vits>Kimapr: probably this page:
<mfg>i'll test some things
<mfg>Hm, okay. I'm back
<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
<guix-vits>o/ nckx
<nckx>I've no backlog so I assume there are no problems or bugs and I wasn't pinged. Great!
<civodul>hey, nckx!
<nckx>Yo yo.
<nckx>civodul: Nice, you've reported the wrap-script bug I encountered yesterday. Thanks! Please continue.
<civodul>heheh :-)
*janneke finds test-guild-compile fails on the hurd -- seems another kill-related thing
<janneke>and gcc-5 does not compile...oh my
<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.
<alextee[m]>does guix have a vnc client?
<mfg>thx nckx :(
<alextee[m]>oh guix search brought up something
<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
<mfg>solved it anadon
<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>anadon: e.g.
<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)
<Blackbeard>Hello :)
<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.
<anadon>Hello, Blackbeard
<guix-vits>Hi Blackbeard.
<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
<nothingmuch>see also comments in guix/describe.scm
<nothingmuch>so i think this is working as intended
<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"
<civodul>see for '--ad-hoc'
<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
<nckx>mfg: Why the ☹ earlier?
<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 <>? I want to try reversing the order of the logs so the latest logs are at the top
<civodul>hi lfam!
<civodul>lfam: it's
<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?
<mfg>adding this to your fshrc or however it is called should work ?
<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
<lfam>Use your judgement
<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
<vagrantc>for 5.6.x
<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.
<efraim>vagrantc: IMO that's ok
<janneke>vagrantc: yes, please do!
<Blackbeard>Is there a '(license:apache)
<Blackbeard>I did a grep but I didn't find apache in license
<Blackbeard>Just some URLs
<bavier>Blackbeard: you might be looking for license:asl2.0
<Blackbeard>bavier: ah thanks :)
<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 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 to be found
<jvshahid>It finds a bunch of libraries but the following two " => not found" and " => not found"
<jvshahid>What should I set LD_LIBRARY_PATH to?
<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>There is a release of 2019-05-02
<efraim>sure, why not
<civodul>hey, cbaines
<cbaines>hi :)
<Blackbeard>But the one before was 3 years before
<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
<Blackbeard>lfam: ah ok
<Blackbeard>So launchpad has to be
<lfam>It could be possible to use Git tags from Github
<Blackbeard>There are none :/
<Blackbeard>So I guess that settles it :)
<Blackbeard>It is ok
<Blackbeard>I learned how to do git