IRC channel logs


back to list of logs

<nckx>That's another one that should be safe to change, or at least make a bit more clear (sure, ‘tabulation’ is correct, but not how we actually talk).
<Cairn>I guess you're right
<nckx>Please do change both, if you want. I just wanted to avoid you thinking you had to change every error in that list to an active instruction.
<nckx>Some are coy for a reason.
<Cairn>Hehe, yeah. I was just considering where direct instructions work and where they're unnecessary.
<Cairn>I see "formatting: alright" as an empty warning. What's that about, haha
<vagrantc>i do find lint suggestions without a way to override of suggest them can despoil the signal to noise ratio sometimes
*vagrantc also finds vagrantc's grammer a bit off
<vagrantc>and spelling
<Cairn>Yeah sorry, I don't quite understand that sentence vagrantc
<vagrantc>e.g. guix lint provides no means to override the suggestion, and if it is not appropriate, then the suggestion just becomes noise
<Cairn>Ah, I see
<nckx>vagrantc: Traditionally, the answer to that is to add more noise: linter comments! \o/
<nckx>I am, I hope it's obvious, not a fan.
<vagrantc>e.g. for a partucular case, it might make sense to ignore the override, but then it is not documented, and the next person who runs guix lint on it will get the same noise and re-evaluate weather it is appropriate, and the next person, etc.
<nckx>warning: linter comment ‘ignore-long-linter-comments’ is way too long.
<nckx>vagrantc: True.
<vagrantc>oh, yeah, i guess you could add a comment why you think it doesn't apply ... at which point, it should just be programmatic and ignored
<nckx>That's my own reasoning for ‘should this code be commented or not’, so I guess I'm inconsistent.
<PotentialUser-89>I'm still struggling with this. If i am building a package definition for a rust app: A, that depends on another rust app: B. Niether A nor B are on A references B with {git = ..., rev=...} syntax. I was able to build the package for B. How do I reference B in the package definition for A? When I do it the same way I have been
<PotentialUser-89>referencing normal rust packages, it doesn't work. It's still searching for B at the git reference which obviously is not available
<nckx>That = will it cause each future reader to stop and think.
<vagrantc>hmmm... this sounds like a bug in guix lint; I know what to do about bugs!
*vagrantc fires up the kitchen sink
<nckx>I actually tried M-x kitchen-sink just in case I missed an easter egg.
<Cairn>You ever tried `M-x zone`?
<Cairn>Learned about that one recently.
<nckx>(PotentialUser-89: You're not being ignored, I don't think anyone currently here knows either…)
<PotentialUser-89>nckx: lol. good to know
<jesse->pashencija[m]: tethering through usb worked great, Guix System is running now. next step is to get my wireless card to work, but at least i can start tinkering
<nckx>PotentialUser-89: I recommend the help-guix@ mailing list to reach more people at the expense of speed, but a slow answer is better than, er, fast silence I guess.
<nckx>And welcome, judging by your default name :)
<nckx>Cairn: The first random pattern was extremely underwhelming, but now it's obviously deleting mails from my inbox.
<nckx>So thanks.
<PotentialUser-89>nckx: Alright. I may do that.  Though I've also never used a mailing list before. I might dig into the build-system code myself first. And you judged correctly. thanks for the welcome
<Cairn>nckx: <3
<nckx>Cairn: If you're talking about tests/lint.scm: that's the name of the test: the linter should not flag anything wrong with a ‘perfect’ package.
<Cairn>Oh, I see.
<vagrantc>opted for a mail to guix-devel rather than a bug ...
<nckx>After some reconsideration, I'd support such a feature.
<vagrantc>acrow: that is looking great!
<acrow>vagrantc: Glad it helps.
<mitchell>hello guix. I am tryng to get set up on an ubuntu distribution. I needed to place the store on it's own partition which meant creating /gnu and making an fstab entry. I then ran the script (with a slight modification so it doesn't abort on the existance of /gnu). However now my builds which are not substitutes fail due to permission errors. After much googling it appears this can be caused by messing with the store by
<mitchell>hand. I double checked that /gnu was owned by root:root and /gnu/store is owned by root:guixbuild. The systemd jobs responsible for remounting the store ro are happy and the daemon is being run with the proper arguments
<mitchell>any ideas?
<Gooberpatrol66>so I have linux checked out and am trying to run "make menuconfig" on it in a guix shell and i'm getting "/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include/bits/local_lim.h:38:10: fatal error: linux/limits.h: No such file or directory"
<Gooberpatrol66>I don't even know why it's looking inside /gnu/store for headers because as far as I can tell I only installed build tools in the environment
<Gooberpatrol66>I tried installing linux-libre and linux-libre-headers; didn't work
<Gooberpatrol66>Any idea what to do?
<mitchell> `find $(guix build linux-libre-headers) -iname "limits.h"` yields a result on my system
<mitchell>How are you running your guix shell?
<mitchell>On my system `guix shell -D linux-libre ncurses -- make x86_64_defconfig && make menuconfig` works
<mitchell>in the linux 5.18 sources
<mitchell>actually i lied, the combined command like that doesn't work. Running each make command in the shell does work
<Gooberpatrol66>mitchell: running guix shell --manifest=packages.scm on gentoo
<mitchell>Any particular reason to use a manifest? shell -D <package> will place you in an environment with the given packages build environment. You need ncurses as well to run menuconfig which is not required normally at build time so it needs to be included as well
<Gooberpatrol66>mitchell: i'm actually building android, so...there's not a package definition for that
<Gooberpatrol66>mitchell: that command says it's unable to find ncurses headers
<Gooberpatrol66>i had that error and fixed it with make clean, but it's not fixing it now
<Gooberpatrol66>I might have to build this outside of a guix shell, because it puts a bunch of "/gnu/store" in my environment variables
<mitchell>If I were you I would write an android-linux package that captures the build requirements. Then you can use guix shell -D on that package. You want your environment variables pointing into the store because you want to ensure you are targeting the correct stuff. Which variables do you think are wrong?
<mitchell>is android very different than upstream? I've never built it
<mitchell>You might be able to just inherit the linux-libre package and swap out the sources if you're lucky
<Gooberpatrol66>mitchell: I expect any environment variable that points menuconfig into /gnu/store for headers to be wrong, seeing as I didn't install any linux headers through guix (at first)
<mitchell>You shouldn't be using any linux headers from guix. They should all be in the source tree
<anhj>good morning guix!
<Gooberpatrol66>mitchell: it's possible that command you posted would work for menuconfig, assuming I didn't get a ncurses error
<mitchell>That command i posted was wrong. You cant do it in one line like that (or at least i dont know how to). But you should be able to run menuconfig in shell spawned by `guix shell -D linux-libre ncurses`
<Gooberpatrol66>mitchell: yeah, i meant, broken up
<mitchell>Did you run make *_defconfig? does android do that?
<Gooberpatrol66>mitchell: yes it does
<Gooberpatrol66>mitchell: is that relevant for ensuring menuconfig runs?
<Gooberpatrol66>mitchell: thought it affected which config options were set
<mitchell>i just checked, it doens't affect it
<Cairn>Package outputs... 🤯
<Cairn>Can't figure them out!
<nckx>Gooberpatrol66: $C_INCLUDE_PATH ?
<mitchell>Cairn: They're just variables that you can use to fine tune your package build artifacts
<Cairn>If only I was able to see them as that simple.
<mitchell>Cairn: Like if you could pass make a variable to control where documentation goes you might use a `doc` output so that guix users could decide if they want to install the documentation
<Cairn>I know what flags I'd like to pass for different outputs. I'm struggling to figure out how to make separate outputs that use those separate flags.
<mitchell>Now as far as I understand the compiler needs the kernel headers in order to build itself. You may need to recompile gcc to use the android headers.
<mitchell>Cairn: Just add build phases
<Cairn>Sorry, I'm sorta just venting though. I'll keep trying to figure them out.
<mitchell>like add one before 'build that takes in the outputs keyword. Then search to see if whatever output is present and do whatever with it if it is. If it exists it will resolve to a store path
<nckx>WDYM by ‘separate flags for separate outputs’.
<Cairn>Oh shoot, that was a question for me wasn't it nckx
<mitchell>like (let ((doc (assoc-ref outputs "doc"))) (if doc (invoke "make" "doc" (string-append "DOC_OUTPUT=" doc)))) or something like that.
<nckx>We don't really do the conditional.
<mitchell>oh how should it be?
<nckx>Just without the if.
<Cairn>Ok, so just look at this:
<Cairn>It's got three different possibilities. I can build for SDL for example.
<nckx>mitchell: And in your made-up example, you'd just make DOC_OUTPUT a regular make-flag, and (apply invoke "make" "doc" make-flags).
<nckx>Cairn: Right. So. This is why I asked my question.
<mitchell>nckx: I see
<nckx>If you're running (the equivalent of) ‘make clean’ during the package build process to create each ‘output’, that's not really what outputs are for.
<mitchell>You might also make 3 separate packages for each different build type
<nckx>They are to split one(ish :) build into different component parts.
<nckx>Not to build completely different builds of the package.
<nckx>As mitchell once said: a separate package is more appropriate here.
<nckx>You can still get all the DRY you want with inheritance, mostly.
<nckx>Don't Repeat Yourself. Programming advice that some confuse for religion.
<mitchell>You can make a function that contains most of the package and call like like (map harmonist-interface '(sdl browser))
<nckx>I don't get it.
<Cairn>So it's better (in this case) to have "harmonist" and variants with "-sdl" and "-wasm" instead of outputs with ":sdl" and ":wasm"?
<nckx>Cairn: Both would have a /bin/wasm, right?
<ml_2>Hello. Is there a good way to source my personal packages from local git directories? "git-fetch" using "file://" doesn't seem to work, presumably because the build is isolated from the rest of the filesystem. I've been able to make it work by using a local-file source and adding a build phase that checks out the correct commit, but it's not a very clean solution.
<mitchell>you need "file:///"
<mitchell>with 3 /
<Cairn>nckx: Not sure, sorry. The hypothetical's running away from me.
<nckx>Well, if so, that's a clear sign that outputs aren't the right fit.
<mitchell>the syntax is "file:// <uri>"
<nckx>Also, there's a remarkably well-named ‘git-checkout’ procedure for local Git checkouts.
<nckx>It obviously needs more publicity.
<mitchell>nckx: And ssh-agent checkouts i learned today
<ml_2>mitchell: I'm pretty sure I had 3 slashes, but I'll try again just in case, thanks.
<mitchell>So if you have repositories with access control you can use `git-checkout` and ssh-agent to get at them
<nckx>The former enables the latter.
<mitchell>ml_2: they also need to be absolute paths
<Cairn>nckx: Can you think of an example of a package that has multiple versions with different build flags?
<nckx>There are plenty, but ermm…
<mitchell>Cairn: linux-libre
<mitchell>gcc too. I learned a lot from the gcc packages lol
<nckx>Cairn: glib{,-with-documentation}, cups{,-minimal}, …
<nckx>I tried to choose realistic packages, because different flags usually imply different other things, too.
<Cairn>mitchell: Since you brought up linux libre... Why is it not a singlularly-named package that uses the "version" mechanism? Like why not "linux-libre@5.18"?
<ml_2>fatal: '/home/ml/files/info/desk/emacs-ml-init' does not appear to be a git repository
<ml_2>SWH: revision "a31e2d00815998742538470bd780cb2daa2c6361" originating from file:///home/ml/files/info/desk/emacs-ml-init could not be found
<mitchell>Cairn: Because different .config's yield vastly different programs
<ml_2>But I can confirm that creating an empty repo and running `git fetch file:///home/ml/files/info/desk/emacs-ml-init` does work.
<ml_2>So that's why I think git-fetch doesn't work with file:// urls.
<nckx>It doesn't.
<Cairn>I don't understand
<mitchell>ml_2: I remember now. I set up a cgit service and got my local repositories that way. Another way I learned to use guix during testing was to define a test package that did a source transformation like ((options->transformation '((with-source. "")))). Then I could guix build, and more importantly guix system with test code.
<mitchell>guix makes kernel module development way less trecherous
<ml_2>mitchell: I haven't really looked at transformations yet, but it might be cleaner than my current approach. Thanks!
<the_tubular>Is there a way guix can help protecting from all the licensing mess happening ?
<the_tubular>Or that happened yesterday
<mitchell>ml_2: here's an example of how I do it. Maybe there's a better way
<mitchell>the_tubular: What happened?
<the_tubular>Tea, from gitea was packaged in like 14 different distro's package manager as 'MIt' While it uses a dependency with no license
<mitchell>lol. Well I don't think anything can get merged into guix proper without a license
<pkill9>yeah it can help because all packages are vetted for licenses and bundled libs
<singpolyma>the_tubular: guix or Debian or anyone with sane policies can't have that happen
<singpolyma>Every dep gets it's own package
<mitchell>If it's packaged in guix you can be reasonably sure its properly licensed
<the_tubular>I think debian was in the list ...? I'm not sure anymore
<mitchell>Perhaps in debian they were letting the package download stuff at build time
<the_tubular>Humm no, debian wasn't in the list AFAICT
<the_tubular>Nix was though ...
<mitchell>thats surprising
<pkill9>can yo upass store paths to `guix environment`?
<Noisytoot>Parabola was in the list too
<ml_2>It looks like Nix does download the dependencies at build time, unless I'm misunderstanding something. There are no dependencies specified here:
<nckx>I mean, things won't improve from here:
<nckx>My (Sway) clipboard is doing that cool thing where it randomly ignores ^C again. It was better for a while.
<apteryx>nckx: sounds infuriating
<nckx>It's what has slowly driven me mad.
<nckx>sneek: later tell jts: I think I've trawled through every single ‘rtl8812au’ project on GitHub (I'd say beyond, but really, it always ends up on GitHub). They all have firmware files, even if the names change. Sorry.
*apteryx revives x200 libreboot hardware project
<nckx>sneek: later tell jts: I've requested removal from H-node. Such a pity, they even explicitly documented a Guix System configuration…
<sneek>Got it.
<nckx>apteryx: Oh right, you were affected too IIRC.
<apteryx>by the rtl8812au fiasco? yes
<mroh>I feel guilty adding rtl8821ce-linux-module.
<apteryx>eh, don't be. it was reviewed and added in good faith, and when a problem was found, it was (will) be acted upon. Such is our pledge to the FSDG
<nckx>Don't be.
<nckx>mroh: I added rtl8812au-aircrack-ng-linux-module. :o)
<apteryx>nckx: ah, the Guix config snippet on h-node was mine :-p
<nckx>Aren't we a bunch.
<raghavgururajan>`su` works for everyone?
<Cairn>raghavgururajan: Works for me
<mroh>do we have any tools to check for large arrays in source code? Something like these "rtlxxx disaster" is hard to avoid w/o, no?
<mroh>or better: large binary arrays that gets executed...
<oriansj>mroh: it is an open problem in bootstrapping, it is freaking crazy how much generated crap is even in GNU packages
<oriansj>we spent months of effort just figuring out how to bootstrap Guile without using generated files, only for the next release of Guile to effectively throw all of our work into the trash.
***califax_ is now known as califax
<oriansj>psyntax.pp bootstrapping if you feel like looking at it:
<oriansj>basically at this point, if humans aren't actively concerned about actually providing source code and ensuring it can be bootstrapped; then we have a serious cultural problem.
<nckx>raghavgururajan: If this is about the same error you posted previously, make sure you're invoking the right /run/setuid-programs/su (‘type su’).
*nckx → 😴💤
<mroh>oriansj: yea, it becomes very serious the more Im thinking about it...
<oriansj>well the good news is; we have a trusted bootstrapped core: which includes GCC, binutils, Guile, Perl and more.
<oriansj>and a kernel: which is being worked on to solve the Linux bootstrapping problem too
<oriansj>lots of smart and capable people on #bootstrappable and we love teaching those who wish to learn more and better
<KarlJoad>sneek: later tell nckx I am not using the "split" cuirass version. I know berlin uses the newer mechanism to scale better. Mine is using just the default build assignment system. The host node is the build node. The failure happens during the `guix pull` step, because something was not fully initialized.
<KarlJoad>sneek: later tell nckx I can provide the configuration if you want to see it, but I will have to PM it to you.
<sneek>Will do.
<vivien>Hi guix, seems down, and I can’t install anything :(
<vivien>I’m in the installation medium, so how do I deactivate it from here?
<vivien>I tried with --no-substitutes, but the amount of things to compile is insane
<anhj>vivien: it seems eerything is down, at least for me too, maybe try a mirror for substitutes?
<vivien>Oh OK
<vivien>I can’t change the guix daemon configuration though, so I’ll just recompile everything.
<cbaines> and both seem up to me
<cbaines>are you still having problems accessing them vivien, anhj ?
<anhj>let me try again
<vivien>Oh it’s back
<Christoph[m]>Also, there's a second server:
<vivien>Christoph[m], I know, but I can’t change the daemon configuration in the installer
<vivien>If does not respond, the installation just stops.
<vivien>Well it does not stop, it just waits indefinitely
<vivien>Even if bordeaux is up
<Christoph[m]>That sounds like a bug, doesn't it? What if I want to install from a local server in order to save bandwidth?
<vivien>I have to say, I’m not using the installer as intended
<vivien>I first generated the configuration file with the graphical installer, and then I switched to the command-line to actually install it
<vivien>So maybe there’s something I missed
<vivien>But I have never seen an option to configure the substitutes, either in the graphical installer, nor in the command-line installation process
<Christoph[m]>And do you really have to say --no-substitutes if the substitutes are unavailable? I always thought that compilation starts automatically.
<vivien>It waits
<vivien>substitute: updating substitutes for ''... 0%
<vivien>repeat every seconds or so
<Christoph[m]>Ah, maybe compilation starts as soon as confirms that there is no substitute, but it waits for that confirmation first.
<vivien>Maybe there’s some timeout and I’m too impatient to wait for it
<vivien>but I would say it’s at least a minute
<rekado>there’s network maintenance
<rekado>between 5am and 9am UTC+2
***Dynom_ is now known as Guest2254
<rekado>a package using rust-openssl-sys fails to build because it encounters “extern crate openssl_src;” but doesn’t know that crate.
<rekado>I’m guessing that the downstream package tries to build a bundled copy of the openssl sources
<rekado>how can I make it use our openssl package instead?
<florhizome[m]> i would look how the package bundles openssl and the try to substitute it there i guess
<rekado>this is specific to rust, I think
<rekado>the rust-openssl-sys package has openssl as an input and it is patched to use it.
<rekado>this works fine
<efraim>is 'extern crate openssl_src' in rust-openssl-sys or on the other package?
<rekado>it’s in rust-openssl-sys
<rekado>and if I read this correctly it is behind a feature switch
<efraim>did you include openssl and pkg-config as inputs?
<efraim>I haven't looked at the patch for rust-openssl-sys in a while
<rekado>it’s only downstream packages that don’t work
<rekado>FWIW I have a similar problem with rust-lzma-sys and rust-xz2
<rekado>they build fine on their own, but users of these packages will complain about missing directories that contain the lzma or xz sources
<efraim>its hard to test since we don't have the package graph for crates :/
<efraim>rust-bzip2-sys-0.1 is a fun way to take care of obstinate bundle crates
<jgeerds>Heh, I didn't know that GNU hosts its own sourcehut instance ( Anyone know more about this? Are there any migration plans?
<VesselWave>Hello everyone! I made a package definition for alacritty@0.10.1 and for it's dependencies. And merged it localy with guix channel How do I test, it can be built in terms of this channel?
***Dynom_ is now known as Guest8548
<nckx>jgeerds: Nope.
<sneek>nckx, you have 2 messages!
<sneek>nckx, KarlJoad says: I am not using the "split" cuirass version. I know berlin uses the newer mechanism to scale better. Mine is using just the default build assignment system. The host node is the build node. The failure happens during the `guix pull` step, because something was not fully initialized.
<sneek>nckx, KarlJoad says: I can provide the configuration if you want to see it, but I will have to PM it to you.
<nckx>KarlJoad: I'm away for the day, but what is the 'something'? Any clues?
<rekado>something caused a rebuild of the rust bootstrap chain
<rekado>building rust 1.39.0 up to 1.57.0 on berlin now, so that we can build librsvg 2.50.7
<efraim>are you sure? I built my manifest after the icecat bump and didn't have to rebuild rust
<efraim>maybe the filesystem mountings aren't correct?
<rekado>oh, could be that berlin doesn’t use itself for substitutes
<rekado>hmm, no idea how to make it work
<rekado> --substitute-urls=http://localhost:3000 isn’t enough
<rekado>maybe authorize its own signing key
<rekado>yup, that was it
<rekado>nckx apteryx efraim FYI: I just reconfigured berlin and (manually) authorized its own signing key, so we can use the substitute cache.
<supdood[m]>Anyone in here messed around with guix foreign install on Devuan?
<efraim>heh that would do it
***wielaard is now known as mjw
<antipode>rekado: What's the downstream package?
<antipode>Maybe it requests the 'vendored' feature.
<rekado>I’ll check if it contains “vendored” anywhere
<antipode>If so, the Cargo.toml of the dependent could be patched to remove the 'vendored' feature from the list of requested features.
<rekado>it doesn’t contain the string “vendor” at all
<antipode>Maybe by one of the other dependents?
<antipode>I'll try looking at gcs ...
<rekado>it has this: [target."cfg(all(unix, not(target_os = \"macos\")))".dependencies.openssl-sys]
<rekado>and below that “optional = true”
<antipode>Nevermind, "gcs" is a feature, not a dependency ...
<rekado>antipode: your comment has already helped me. I see that for libz-sys the file requests a “static” build, which explains the other problems I had.
<pkill9>I wanna make a guile script you can either call as a program, or import as a library
<pkill9>it will have much power as such
<lilyp>pkill9 the usual way to do this is to define a main method and then do the exec guile dance
<antipode>Maybe you can separate it in two parts: a Guile module to be installed and used as library containing most of the functionality, and a script to be installed in $PREFIX/bin that uses that library to do most things except CLI parsing.
<pkill9>lilyp: what's the exec guile dance>?
<pkill9>antipode: I kinda want it to be able to all be in a single script when it comes to running it directly as a program
<pkill9>so that I can easily jsut copy it and modify it for debugging/extending etc
<lilyp>#!/bin/sh\nexec guile "$0" -e main "$@"\n!#, where \n are actual new lines
<lilyp>maybe you want a -- after main
<pkill9>ah nice
<antipode>pkill9: To make it self-contained, such that there is only a single file to copy to share it with other people or copy to other machines, to only have a single file to back-up, etc.?
<pkill9>for debugging/extending
<lilyp>another way of writing the second line is guile -e main -s "$0" "$@", which keeps the shell arguments in the same order
<antipode>I don't see how a single file helps with debugging and extending but ok.
<pkill9>because I can quickly modfy adn run it iteratively
<pkill9>and not worry about where the libraries are
<pkill9>eg how my environment is set up
<pkill9>less state basically
<antipode>Right, not needing to add "-L." or such.
<antipode>It's possible to determine the location of the script at runtime (something with port-filename?) -- assuming you've set up things such that there is a relationship between the locations of the script and its modules on the filesystem, you could then add the right locations to %load-path automatically.
<antipode>Might not be worth the complexity in your case though.
<vldn>is it possible to guix pull from a local directory?
<vldn>via a channel definition with a local path instead of an url?
<antipode>vldn: IIUC, sure.
<pkill9>nice the shebang worked
<antipode>"/home/foobar/etc" is a valid URL IIUC, if not try "file:///home/foobar/etc"
<vldn>ty :)
<attila_lendvai>any reason why this change is not merged:
<vldn>is there a reason between a guix pull to a profile path or a guix package -m to a profile path? i remember breaking something in the past..
<vldn>reason = difference :D sry
<Cairn>Morning Guix
<tricon>Cairn: Top o' the mornin' to ya.
<Cairn>I'm having a hard time understanding the build systems, but I just have a small question I'd like to solve. The go build system has the "#:build-flags" option. Is that flag also used for tests?
<Cairn>I'm guessing it is, but I can't find how that phase is defined. Does it just inherit everything in the build phase?
***stikonas_ is now known as stikonas
<KarlJoad>sneek: later tell nckx: Just checked because I had this issue a few months ago and pushed solving it to now. I have a syntax error "invalid field specifier" on the (list (machine (operating-system %system))) part of a deploy.
<apteryx>nckx: would you mind restarting ? I'm away from my main machine.
<VesselWave>Hello everyone! I made a package definition for alacritty@0.10.1 and for it's dependencies. And merged it localy with guix channel. How do I test, it can be built in terms of this channel?
<rekado>apteryx: that one says “succeeded” right now
<two[m]>hi, in there is this code... (full message at
<podiki[m]>two: sourcing the profile sets up all the needed env variables so that you will use guix properly (e.g. latest guix you get from guix pull, anything you install to be in your PATH)
<podiki[m]>you can look at the file to see it, for the one you pasted, ~/.guix-profile/etc/profile will just be a short script
<two[m]>podiki[m]: thank you, i know what the profile does, i wanted to know why is there a semicolon and a backslash?
<podiki[m]>as a way of showing the two separate lines to paste directly I guess?
<podiki[m]>; as in end of command, \ as in continues to next line
<two[m]>wouldn't a newline have the same effect?
<two[m]> * does it behave differently from a newline have the same effect?
<two[m]> * does it behave differently from a newline?
<podiki[m]>no, I don't think so
<podiki[m]>anyway, the point is to source that profile, however you want to do it
<podiki[m]>(i mean the backslash here doesn't matter, but usually you need it for multi line commands when pasting, if I remember correctly)
<podiki[m]>so \<newline> is a continuation; here a bit redundent with the ; I guess
<podiki[m]>err backslash new line (if that got escaped on your client)
<podiki[m]>i.e. it escapes the newline so the command you are writing will continue to be parsed (here it didn't matter)
<two[m]>> you need it for multi line commands when pasting
<two[m]>you don't, newlines are kept in pasted text, but the commands are executed after you press enter
<two[m]> * > you need it for multi line commands when pasting
<two[m]>you don't, newlines are kept in pasted text, but the commands are executed after you press enter
<raghavgururajan>sneek, later tell nckx: Oh you're right! Interesting, some package installed su in my home-profile.
<sneek>Will do.
<podiki[m]>probably depends on your terminal, but sure, usually newlines are kept in my experience
<podiki[m]>anyway, nothing to worry about
<two[m]>del key doesn't work in guix shell --container
<two[m]>is that a known bug?
<two[m]>s/that/the/, s/a/bug/, s/known bug/reported/
<two[m]>s/is that a known bug?/is the bug reported or has a known fix?/
<podiki[m]>likely you need coreutils in the shell
<unmatched-paren>two[m]: Try setting `export TERM=xterm-256color`
<two[m]>thank you
<two[m]>could that be inherited from the host? would that break reproducibility?
<nckx>sneek: later tell lfam: We definitely do want to set CONFIG_INITRAMFS_PRESERVE_MTIME=y.
<sneek>Welcome back nckx, you have 2 messages!
<sneek>nckx, KarlJoad says: Just checked because I had this issue a few months ago and pushed solving it to now. I have a syntax error "invalid field specifier" on the (list (machine (operating-system %system))) part of a deploy.
<sneek>nckx, raghavgururajan says: Oh you're right! Interesting, some package installed su in my home-profile.
<unmatched-paren>The latter
<two[m]>probably not but there might be a weird build script that dumps env into about window or debug data...
<unmatched-paren>two[m]: Yeah, it probably won't break reproducibility in practise too much
<unmatched-paren>but anything that could break it in theory must be dealt with
<unmatched-paren>that means no inheritance of environment variables
<podiki[m]>guix shell has options to preserve things from the host
<unmatched-paren>Yes, true
<unmatched-paren>guix shell --container -E TERM
<linj>unmatched-paren: is there any interest in pure evaluation in guix community?
<unmatched-paren>linj: what do you mean by that?
<unmatched-paren>guix build environments are all pure and contained
<unmatched-paren>and guix shell has options for both
<unmatched-paren>guix shell --pure --container
<linj>oh, that's good
<linj>just see your discussion of env vars and reproducibility
<unmatched-paren>builds are a bit like pure functions
<unmatched-paren>for the same inputs they will always in theory produce the same outputs
<linj>I don't mean build
<unmatched-paren>in practise, there are sometimes issues like timestamps and random numbers embedded in the build
<unmatched-paren>what do you mean then?
<linj>in nix, there are two stages: 1. evaluation of nix expression into foo.drv and 2. build foo.drv
<linj>I mean the evaluation stage
<linj>not sure what the guix part of it though
<unmatched-paren>ah, well
<unmatched-paren>guix is a wee bit more abstract
<unmatched-paren>there are three phases, I guess
<unmatched-paren>(1) "compile" a high-level object like a <package>, <local-file>, or <origin> to a gexp (2) evaluate the gexp into a derivation (3) build the derivation
<unmatched-paren>something like that
<linj>then my question that is the first two phases pure, i.e. not changed but something like env vars
<linj>but -> by
<unmatched-paren>i think they might not be containerized, but they aren't affected by the environment
<linj>ok, I get the idea
<acrow>Another good day to be working with guix!
<Cairn>Hey, should I use the most recent version tag, or the most recent "release" version? The linter said that I can use the most recent version tag, but that's not the version listed in the "release" section of github...
<unmatched-paren>Cairn: Most recent tag
<unmatched-paren>GitHub releases are annoying
<unmatched-paren>they always obscure the actual tags
<efraim>I have a go package I want to run tests only when building with go and not gccgo, any suggestions on how to detect which "go" I'm using?
<antipode>two[m]: AFAIK IRC does not have multi-line messages (IIUC it's different for Matrix)
<efraim>what about
<efraim>this message?
<efraim>doh, I thought I could make it work with shift+enter for a new line
<unmatched-paren>I think there are a few fancy clients that pretend to support multiple lines, but actually just send several messages
<antipode>linj: In principle, you could do #$(current-time) in a phase or such to make a different derivation each time "guix build the-package-or-a-dependent" is run.
<unmatched-paren>efraim: Hmm, looks like the GOVERSION var looks like this with gc:
<unmatched-paren>but this with gccgo:
<Cairn>Got it, thanks unmatched-paren
<unmatched-paren>go1.16.5 gccgo (GCC) 11.3.0
<unmatched-paren>(tested with `guix shell go gccgo`)
<antipode>but like, why would you do that
<antipode>Would easily be caught by package review
<unmatched-paren>efraim: Also, GOROOT and GOTOOLDIR differ based on the compiler used
<efraim>I'm hoping to put something in #:tests?, so not sure I can use GOROOT
<unmatched-paren>efraim: #:tests? only accepts a constant anyway, iirc
<unmatched-paren>you'll want to replace 'check
<efraim>right now I'm trying to write out (= (package-version (this-package-input "go")) (package-version go))
***mark__ is now known as mjw
<unmatched-paren>Hmm, maybe you can use #$(this-package-input "gccgo"), and if it's false, run tests
<unmatched-paren>s/constant/external value/
<unmatched-paren>so no gexps
<unmatched-paren>so (replace 'check (lambda* (~
<unmatched-paren>so (replace 'check (lambda* (#:key tests? #:allow-other-keys) (when (and tests? (not #$(this-package-input "gccgo"))) ...)))
<efraim>I'll probably go with that, but I'm going to keep on trying this first :)
<efraim>so far #~(equal? "1.17.11" #$(package-version go)) works
<unmatched-paren>Oh, so it does accept a gexp, cool
<unmatched-paren>Agh, anyway, (this-package-input) doesn't run at build time...
<unmatched-paren>silly me. Anyway, you should be able to do #:tests? (this-package-input "gccgo")
<efraim>yeah, (this-package-input "go") keeps on evaluating to false
<unmatched-paren>Sorry, it's actuall:
<unmatched-paren>silly me. Anyway, you should be able to do #:tests? (not (this-package-input "gccgo"))
<unmatched-paren>Argh, I copied the whole message :P
<efraim>(this-package-input "gccgo") always evaluates to #f in #:tests?
<vivien>Compiling qt is not a whole lot of fun
<unmatched-paren>vivien: I can imagine :)
<antipode>efraim: go-build-system has a #:go argument, right?
<unmatched-paren>efraim: Hmm. I guess the input is inherent to the build system
<antipode>Maybe you can check if it contains "bin/go" or "bin/gccgo" or such.
<unmatched-paren>Ohh, yes
<Cairn>I've already gotten some opinion on this, but I just wanna check. Should I add myself to the copyright section if I'm just adding some packages?
<unmatched-paren>Cairn: Yes.
<efraim>antipode: yeah. gccgo is called as bin/gccgo
<unmatched-paren>No need for real name, though.
<efraim>worth a try
<Cairn>unmatched-paren: Cool, thank you
<vivien>If it contains rust, qt and libreoffice, you are allowed to shout "bin/go!" and win a prize.
<antipode>librsvg now builds with antioxidant-build-system
<unmatched-paren>vivien: Bonus points if it also depends on Haskell via Pandoc.
<efraim>might need false-if-exception for search-input-file
<unmatched-paren>antipode: Oh, nice, that seems like an important milestone! :D
<unmatched-paren>efraim: no need for search-input-file
<efraim>oh nice and librsvg!
<unmatched-paren>you'll probably need a phase though
<unmatched-paren>antipode: Hmm, no, doesn't look like there's a #:go
<unmatched-paren>Oh, wait, there is one for lower
<efraim>(replace 'check (lambda* (#:key tests inputs #:allow-other-keys #:rest args) (when (and tests? (not (false-if-exception (search-input-file inputs "/bin/gccgo")))) (apply (assoc-ref %standard-phases 'check) args)))
<unmatched-paren>efraim: No need for the #:rest args
<unmatched-paren>also, replace `inputs` with `go` in the lambda
<efraim>the args was the easiest way to invoke %standard-phases 'check
<efraim>when replacing go with gccgo, the label is still 'go'
<unmatched-paren>I see.
<unmatched-paren>Try replacing (not ...) with (string=? (package-name go) "go").
<unmatched-paren>After replacing `inputs` with `go`.
<unmatched-paren>(replace 'check (lambda* (#:key go #:rest args) (when (string=? go "go") (apply (assoc-ref %standard-phases 'check) args)))) should work
<efraim>#$(package-name go) is checking the absolute package go
<unmatched-paren>Oh, yes
<unmatched-paren>but it will check the go used by the build system if you remove the ungexp
<unmatched-paren>(replace 'check (lambda* (#:key go #:rest args) (when (string=? (package-name go) "go") (apply (assoc-ref %standard-phases 'check) #:go go args))))
<unmatched-paren>^ amended to fix two mistakes I noticed :)
<efraim>unbound variable: pacakge-name
<unmatched-paren>of course, `go` will be a path...
<unmatched-paren>sorry :)
<unmatched-paren>Hmm, i guess this could work
<unmatched-paren>(string=? go #$go)
<efraim>I think I'm going with (unless (false-if-exception (search-input-file inputs "/bin/gccgo")) (apply ...
<VesselWave>Hey everyone! I cloned guix main repository and made changes to some packages. How do I test they can be built?
<mbakke>VesselWave: use './pre-inst-env' as outlined in :)
<VesselWave>mbakke: I don't have that file how do I get it? Make?
<mbakke>VesselWave: you need to run './bootstrap' and './configure --localstatedir=/var' beforehand ... also 'make -j $(nproc)' to speed things up a bit in the long run
<mbakke>I recommend reading that manual section ;)
<vivien>Before that, be sure to run "guix shell -D guix"
<vivien>To have all build dependencies ready
<VesselWave>Thanks a lot!
<VesselWave>BTW I made a package definition for alacritty 0.10.1, previous version had a bug: transparency could be turned on
<unmatched-paren>Oh, huh, so that really was a bug?
<VesselWave>Yes I updated it. It will be my first contribution to guix
<unmatched-paren>nice :)
<unmatched-paren>Do you know how to send patchsets to the mailing list?
<VesselWave>No, but packaging tutorial by Andrew Tropin is great source
<unmatched-paren>I haven't seen that one
<vivien>Some time ago, someone complained that the download page contains the phrase: "GNU Guix can be installed as an additional package manager on top of an installed Linux-based system." I think this is indeed not clear. Maybe "on top of any system running the Linux kernel" would make sure that the thing that matters is the kernel, not the system.
<vivien>What do you think?
<vivien>Au passage, en français on dit « fondé sur » et pas « basé sur »
<vivien>(parce qu’on parle des fondations, pas de la base)
<VesselWave>Thank you. Should I split every update of package to separate commit and separate patch?
<unmatched-paren>every new package too
<VesselWave>And how do I sign the commits?
<unmatched-paren>you don't need to do that unless you're a committer
<unmatched-paren>the patches will be applied by one of the committers
<unmatched-paren>The -${n} flag of git format-patch and git send-email sends the last n patches, so no need to run them for each patch
<VesselWave>Andrew Tropin broke guix pull for several hours because of sign issues. I saw it from last commit at that time
<unmatched-paren>I think the wrong key had been accidentally used or something
<VesselWave>it shoud be like -${9}
<unmatched-paren>no, -9
<unmatched-paren>${n} is a shell variable :)
<VesselWave>OK, thank you!
<unmatched-paren>You can also use a commit spec instead of -${n}
<unmatched-paren>e.g. HEAD^ uses the latest commit
<unmatched-paren>it basically sends all commits after the spec
<unmatched-paren>but -${n} is far more intuitive
<davidl>to package anything for node t takes a grandiose effort to bootstrap the node bundle tools like rollup etc.
<davidl>I have a recursive importer written in Bash. Still, everything is a recursive dependency and I need to find earlier versions to bootstrap significant packages.
<yewscion>Do You have a link to Your recursive importer? I'd be interested to see the process.
<davidl>yewscion: it's not refined work fyi. Just temporary to get some packages working together. Completely ignores the license field for example.
<davidl>s/everything is a recursive dependency/everything is a circular dependency/g
<davidl>(second time mixing up recursive and circular)
<nikola_>Hare defer is not finalized yet right
<nikola_>Wrong chat
<yewscion>davidl: Thanks!
<jpoiret>unmatched-paren: I like working on branches that have origin/master as upstream
<jpoiret>then I can just HEAD..origin/master
<unmatched-paren>jpoiret: Oh, that's a nicer way.
<apteryx>for your info, if you use a Guix System mahcine and it starts throwing TLS certs errors on git clone operations, make sure use-pam? is #t for your openssh-configuration. It causes /etc/environment to be sourced for non-login SSH sessions, which contains GIT_SSL_CAINFO and SSL_CERT_DIR, among others
<jackhill>vagrantc: re: scummvm games: what if I wanted to charge an unreasonable copying fee. That I'm allowed to do so for all our other packages except scummvm-games seems like a potentially interesting distinction?
<vagrantc>jackhill: potentially
<vagrantc>jackhill: though getting a definition of reasonable from a court would be an adventure
***justache is now known as justDeez
<vagrantc>"it's reasonable that you would want to profit greatly from this transaction!" :)
<pkill9>does anyone know of a decent laptop they can recommend for running guix?