<apteryx>the name is a symbol; what failed? do you still have the error and the original version?
<apteryx>raghavgururajan: when we're done we'll have to update to 4.4.35 ;-)
<apteryx>it's probably a painless bump, I'll try it before it's tested ready to merge
<cdegroot_>The quote in the manual seems to be an actual quote. I couldn't get it to work - got scheme stack traces when I depended on nonguix as "(name 'nonguix)", tried various things, then "(name nonguix)" worked. Doesn't make sense.
<cdegroot_>(I didn't copy from the manual but from my channels.scm)
<tissevert>wow the flow of mail on guix-devel and guix-patch is impressive Oo
<brendyyn>tissevert: more more more! we should thank all reviewers
<tissevert>but I'm amazed how interesting all of the mail is : unpiling what got in since I signed up yesterday evening and I've already learnt at least 3 helpful things if I'm to ever submit any package
<tissevert>so yeah, thank you @reviewers for all the amazing work
<nixo_>zimon: I'll have a look at your julia patches again soon, I got stuck building julia 1.6, which build fine and work fine but there are a few failing tests .-. and running the test suite requires something like 6 hours
<nefix>Good morning! Is there a reason why Guix's Go package is at version 1.14 and not at 1.16? Is it just that no one has updated it yet? If so, how should I try to update it? Thanks!
<nefix>Also, I have a local package that I'd like to contribute to the main repos, how should I do it? Thank you :)
<brendyyn>nefix: i suspect it's just work to be done. 300 packages depend on go so it would involve testing all of them.
<lle-bout>civodul: watching your talk related to guix-explorer
*lle-bout needs to watch all other talks about GNU Guix in FOSDEM 2021
<cbaines>lle-bout, I think there was a backlog of package sources to build, but I think core-updates stuff is now at the top of the queue
<lle-bout>ungoogled-chromium's Picture-in-Picture mode is really nice in that I can pin a video to a corner of my screen and it moves in all my XFCE workspaces when I switch so it's just always there, so nice!
<nckx>Both are fine, I don't expect OOTB magic from cool quick hacks.
<nckx>(It's still compiling things(?), so 5 mins so far.)
<nefix>So, compiling Go 1.16 is throwing the following error: 'ld: cannot find crt1.o: No such file or directory'. It's failing a test that says 'Test that we can use the external linker with a host syso file that is embedded in a package, that is referenced by a Go assembly function.'. Does anybody have a clue?
<nefix>It seems to compile 1.15.10 correctly though :think:
<i1l>lle-bout: hi Guix. i remember Nix mirrors things from some repos, like ELPA or so (acc. to the manual). I mean, may Guix mirror the nodejs, in place of repro-builds, in a meantime? To make Node a tging in Fuix i mean.
<pkill9>it says right the in the package definition
<lle-bout>nckx: I don't think npm packages werent made to be built from source, more so that semver compliance isnt the most strict there, that there's lots of micro-dependencies meaning multiplication of packages, also package-writing practices and maintenance quality of them are some times rather poor because lack of clear guidelines and good tools in the community.
<lle-bout>It's a result of the individualist packaging philosophy
<lle-bout>Without community and collective maintenance of packages
<lle-bout>pkill9: the package definitions I posted in the issue just works so if you want to use it feel free
<nckx>Did you omit --localstatedir=/var deliberately when building Guix?
<nckx>It might be harmless, but only if all of your Guix installation follows suit.
<davidl>I have a package from centos that I can install with guix with some hassle of first manually downloading the package and unpacking and repacking it and moving patches in place. I need some help to replace the unpack step of the gnu-build-system. How do you do that correctly? I did with a modify-phases thing and a lambda, but when running guix build -f mypackage.scm Im still getting an error from tar
<lle-bout>nckx: I already built npm packages and bootstrapped from source, I think there's bigger problems in other areas of software. The problem is not that they were designed to not build from source (as if it were intentional), but that there has not been an active community of people checking this property and actually bringing the issues to the upstreams.
<lle-bout>nckx: you said they werent intended to be, they are, otherwise the source wouldnt even be released, it's just often they are only half-way into that process because it's extra effort some developers can't afford vs making the thing work for users.
<nckx>I had to comment out all your patches in order to build the package, because I don't have them. So I'm getting the error from the unpack phase, but you're getting it from patch-and-repack, since you're asking Guix to apply your patches to an .rpm file and it doesn't know how to (it tries to treat it like a tarball).
<nckx>I wonder what the least ugly way forward is... :)
<davidl>yeah, I couldn't find a good version of that package anywhere else. The patches come with the rpm so perhaps modify phases to just apply those, instead of storing them separately in Guix.
<davidl>I managed to set it up with email-passwords and TLSv1.2 on Guix, so I thought it would be nice to add this version of the package to Guix master.
<nckx>Something like that, but then you'll have to deal with the ugliness of getting them to the ‘build side’ yourself. It's not that hard, but it's something that (patches ...) magically does for you otherwise.
<nckx>davidl: If it's all buildable from source, go ahead!
<davidl>nckx: I will struggle doing it that way. The easiest way would be to upload a tarball git my own git repo and add the patches separately to Guix.
<cdegroot_>Is there some secret magic around channels I am missing? I've setup a channel, added a dependency I need, added a package, popped my pgp key on the correct branch, etcetera. Adding it to channels.scm gets it pulled but then trying to build the derivation I get an error, the log just says "(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (channel)) (value #f))". I've verified my setup a bunch of times (https://paste.debian.net/
<cdegroot_>1191211/) but can't find anything obviously wrong. The single recipe in the channel works if I feed it to "guix build"...
<soouul>whats the proper way to set up global environment variables?
<lle-bout>soouul: hello! I don't see stupidity! Actually it's not clear to me how we can do this, that is, add global environment variables. Depending on where you want them to apply, you could export them in your .bash_profile or else, as this source is sourced at login.
<nckx>I don't think there's interest in an official wiki. Too much work; wikis attract nonsense (see: any distro wiki), and keeping them sane takes a lot of work *on top* of writing submissions, and until then the submissions just sit there under guix.gnu.org being wrong.
<rekado_>there’s really nothing wrong with using the Libreplanet wiki for WIP progress snapshots. It won’t ever be official documentation and if anyone asked me I’d vote against ever elevating a wiki to ‘official’ status.
<rekado_>it really doesn’t need to have a home on the guix.gnu.org domain, which is where we take responsibility for content
<lle-bout>rekado_: I have a feeling that if things are not official people don't use them though.
<ennoausberlin>Hello. I try to create a package definition for python-asttokens but it fails with python-six unbound variable. What might be wrong?
<lle-bout>ennoausberlin: did you bring (gnu packages python-xyz) into scope?
<lle-bout>ennoausberlin: also share your package definition
<lle-bout>rekado_: I think the secret to good community resource is that knowledge about it must be very widespread (link on official GNU Guix website) and that there must be next to zero gate-keeping before edits are live.
<nckx>lle-bout: Well, yes, but that's because of what ‘official’ connotes to them: reliable, approved, curated. The former without the latter is (IMO!) meaningless bait-and-switch.
<lle-bout>guixy: there's also ddrescue package if that's interesting to you
<nefix>For the contribution, should I change the default to 1.16 or leave it at 1.14?
***jonsger1 is now known as jonsger
<ennoausberlin>le-bout: Now I get one line further and it fails for unbound variable python-pytest
<lle-bout>nefix: two steps separate, first submit, then discuss to change default, also changing default means lots of rebuilds so.. I already upgraded go on master for security reeasons with lots of rebuilds and it went fine though, as long as it doesnt break stuff I think it's OK to change the default
<brendyyn>nefix: to start with you should leave it. to change the default you need to test all the packages that it might break
<lle-bout>ennoausberlin: you can use 'guix search python-pytest' and look at the location field to figure out what module to bring into scope
<ennoausberlin>le-bout: Great advice! It now fails while building but at least the scheme package definition is fine.
<guixy>I just ran ddrescue. It didn't tell me anything about the targeted device other than that it seems healthy...
<guixy>I'm looking for what information it has. strings has revealed it has many long strings (over 100 characters long) that look like source code, (some guile scheme and some C) but I can't conclude anything about the structure...
<rekado_>I use testdisk for recovering deleted files.
<cdegroot_>TIL that a channe repo gets scanned recursively for scheme source code and "non-channel" .scm in there result in seriously dense build errors.
<cmack>good morning, I'm trying to boot the guix image from usb on an older non-EFI machine but without success. Is the image built with legacy bios support or do I need to build my own image for this?
<lle-bout>cmack: it is built with legacy bios support
<lle-bout`>civodul: the graph is too big some times it doesnt fit on the screen but there's workarounds
<lle-bout`>civodul: you should make a blog post about it!
<lle-bout`>civodul: or when it's within GNU Guix proper
<civodul>i'm sure with some more d3.js hacking we could improve graph rendering, when there are many nodes
<Whyvn>I am wanting to make a package that I need some clarifcation on to clear some confusion. The steps are: git clone, cd into cloned dir, mkdir build, cd build, cmake .. -DBUILD_STATIC_DEPS=ON -DBUILD_SHARED_LIBS=OFF -DSTATIC_LINK=ON, make -j$(nproc). Now i know there is a mkdir-p and also a chdir function, but i am confuesed by the cmake .., would I override the install phase and chdir back to root and then run cmake with the
<Whyvn>confgiure-flags and then chdir back into the build dir and run make with the configure-flags -j$(nproc)?
<lle-bout`>civodul: maybe also pretty rendering of generated executable Scheme files
<lle-bout`>Whyvn: I can't take arbitrary package requests and commit to doing them because there's lots to do in GNU Guix and I want to feel free to set my own priorities but this looks like an easy one to package
<cbaines>Before separating out the connection caching from the substitute related code in Guix, I was putting some of the errors in the Guix Build Coordinator down to shared cached connections, but now that's not an issue, it's clear that something's up with concurrent HTTPS connections in Guile
<Whyvn>lle-bout`: I had more of a question on the step sequence. with the moving back and forth through the directories. would i just override the install phase or is there other phases i need to condsider?
<civodul>d'oh, "guix weather" tells me we're at 95.2% for x86_64!
<civodul>i think it's never been this good, even for x86_64
<bone-baboon>lle-bout`: thank you for pointing out `xorg-server-service-type`. I will give it a try it.
<Rovanion>lle-bout`: The error messages in the bulid log was about `mkdir -p /etc/mail` failing so I went through the build scripts trying to find where it could possibly be doing that. And it seems to have worked.
<lle-bout`>soouul: yes, but beware if you use 'guix gc' the built binaries might break, that's why it's preferable to create a package definition or have a profile somewhere (which can also be used with environment) so that it's protected from garbage collection by being registered as a gc root
<lle-bout`>soouul: basically the built binaries will have absolute paths to /gnu/store/... in them, if you use 'guix gc' these paths might be deleted, so that's why the binaries could break
<lle-bout`>registering as gc root means the store items wont be deleted when using 'guix gc'
<soouul>wack, so basically i should just make a package myself?
<lle-bout`>The ways to register as gc root, is by including them in a profile
<lle-bout`>soouul: yes, you can write one with Scheme code or JSON even if you are at better ease with that, note however that JSON is less powerful and some things you will not be able to do with it.
<soouul>its a wayland utility so at that point, if i do end up packaging it, i might as well commit it? lmfao
<lle-bout`>soouul: for environment actually it's -l instead not -f
<lle-bout`>Whyvn: since you use a git-reference in your package definition, guix hash doesnt work, also you should use guix download rather, but for git there's no subcommand, so what I do is I run the build then copy the actual hash from the error and feed it in.
<lle-bout`>I am not sure of the technicalities of how git-reference is hashed and it seems there's no subcommand to reproduce that behavior.
<nckx>Well, I don't know what you were expecting, so can't say. It prints the value expected in the origin's hash field.
<lle-bout`>nckx: yes that is what I am talking about, I'll try again but it didnt work when I tried to do that, thanks. Also what about tarballs? Can I generate the hash without using "guix download" with guix hash?
<nckx>lle-bout`: It would still have been mentioned in the --help output. Anyway. It must have been a memorably frustrating experience not to receive answers here that you thought guix hash was broken for 3 years. Genuinely sorry about that.
<lle-bout`>nckx: this will be helpful, because I otherwise felt quite uneasy not being able to check the signature of tarballs or git tags if they exist before putting a hash in a guix package definition, even if it's still useful in TOFU mode
<soouul>how do i make it so the build system takes no arguments? #f is not working
<jx96>VGA output doesn't work with Guix + GNOME, but it works on other distros (including Parabola/Trisquel).
<nckx>oreoking[m]: Thanks. Your problem is with a third-party channel (maybe pkill9's, they are a regular here but not currently on-line) that is still using the removed qt@4. The owner needs to fix it.
<vagrantc>rhou[m]: The description should have sentences followed by two spaces. Like that <---. Not like this. Or this.
<jx96>Suspend with Guix System + GNOME is broken for some reason. Also works in other distros.
<rhou[m]><vagrantc "rhou: The description should hav"> so you have to put a space before a period?
<nckx>oreoking[m]: You could lock your guix channel to commit 0d8cea4f247272a36c307276253f014f271f1b56 in your channels.scm. You won't get security updates (if any) so don't forget to remove it as soon as the conflict is resolved.