<maximed>with #~`,((string-append ...) ...), you're trying to somehow use the result of string-append as a procedure
<maximed>rust+cargo+crates.io: While it's great to have a system for not having to update everything at once when doing an incompatible update of a dependency, you often don't have to do that, please don't do 29 different incompatible 0.XX releases and forget to update dependents to the new API
<maximed>18 done, 27 to do (some of which require changes to source code for new dependencies)
***yewscion is now known as yewscion-away-g
***yewscion-away-g is now known as yewscion
<fnstudio>hm... i've tried using guix system like this: guix system image -L . -e "(use-modules (my-oses)) my-base-os" but it doesn't work: error: '(use-modules (my-oses)) my-os' does not return an operating system or an image
<fnstudio>if i try the exact same code in a file and run: guix system image -L file.scm, then that works
<fnstudio>am i misunderstanding the way -e (--expression) should be used?
***yewscion is now known as yewscion-away-g
<patched[m]>Is it possible to build a package without checking the hash? I'd like to skip this for definitions of local packages.
<nckx>PotentialUser-90: Take this with a grain of salt as I'm not a KDE user, but I don't think KDE packaging or integration in Guix have changed significantly in quite a while. So whatever was true then is probably still true now. There simply aren't (m?)any KDE users that contribute to Guix. Chicken & egg & all that.
<PotentialUser-90>nckx: I appreciate the help. I like shiny looking things so KDE works for my purposes, but I was interested in it's approach to packages and apps not included in the Trisquel repos. I'm a casual user who mostly just needs browsers, mail and office stuff. Thx
***yewscion-away-g is now known as yewscion
<vagrantc>does python-build-system not support #:parallel-build? #f ... ?
<vagrantc>i get Unrecognized keyword: #:parallel-build? ... when adding it to the patchwork package definition
<unmatched-paren>The developers quickly realised that just attempting to boot the Linux kernel compiled for Apple silicon's processor architecture (AArch64) would be challenging, as it involved working out the functionality of proprietary Apple code used in the boot process. The work was time consuming and took most of the year, including submitting pull requests to the main Linux kernel developers to keep development in sync and avoid regressions. However, i
<unmatched-paren>t subsequently led to a thorough and comprehensive explanation of the previously undocumented boot process, which Martin and others published on GitHub.
<nikola_>Hello, I'm new to guix and i was just playing around with it in a VM
<nikola_>Now I'm thinking about installing it to real hardware
<nikola_>Are there any resources like tutorials to help me learn the proper way to manage the system
<fnstudio>nikola_: did you have the chance to look at the official docs?
<ardon>Hi Guix, I'm constantly getting this error "[GSSH ERROR] Channel opening failure: channel 67 error (2) open failed" when invoking `guix deploy'. As I pointed out a few days ago, if I re-run the command a few times it will eventually go through, but it's quite annoying. I should also add that when this happens I notice sshd-PID processes popping up in `herd status'. Has anyone else experienced this or know what might be the root of the
<fnstudio>nikola_: (disclaimer: i'm not an expert) i think there can be packages installed globally and those only need to be updated once - but individual users may have additional packages installed in their paths and those will have to be updated separately
<jpoiret>as long as you use sudo, you can use your own user's guix, but with root privileges
<jpoiret>basically, the workflow would be: `guix pull` to update your copy of the Guix software (in the ~/.config/guix/current/ profile), `sudo guix system reconfigure /path/to/config.scm` to update your system generation with your new Guix copy, and `guix package -u` to update your user-installed packages (in the ~/.guix-profile/ profile)
<jpoiret>steps 2 and 3 are independent and can be swapped
<jpoiret>or you could do one but not the other (although there might be issues if eg we update the glibc)
<ulfvonbelow>nikola`: I assume you refer specifically to your user profile (~/.guix-profile) and your 'guix pull' checkout (~/.config/guix/current)? You'll probably want to keep guix itself pretty early in the search order, but the user profile you could probably move farther back. The ideal solution would be to have your profile generated such that ~/.guix-profile/etc/profile appends rather than prepends, but I'm not sure how to do that.
<nikola`>The script /etc/profile.d/guix.sh always prepends the guix path
<DynastyMic>Greetings, I want to download Allegro CL on Guix, however I run on the following error:
<nikola`>So when i move it out of profile.d i get my normal config
<DynastyMic>Isn't it possible on guix to just decompress the installation and run with ./ ?
<nikola`>Should i just manually source guix.sh when i need it
<nikola`>I have to start the daemon manually anyway
<ulfvonbelow>'guix package --search-paths -p <profile>' emits the environment variables that profile defines. --search-paths takes an optional parameter (one of 'exact', 'prefix', or 'suffix') that indicates where in the search paths those environment variables should go
<ulfvonbelow>"exact" replaces the search paths altogether, "prefix" puts guix directories at the front of the search order, and "suffix" puts guix directories at the end of the search order
<nikola`>Is it ok if I manually source guix.sh when i need it
<ulfvonbelow>and (re)installing a bootloader definitely sounds like a system-wide action
<rchar01>it is an error after guix system delete-generations
<rchar01>is it sth wrong with deleting generations?
<ulfvonbelow>when you say an error "after" guix system delete-generations, do you mean that the error message shows up after you press enter to run 'guix system delete-generations', or that after you ran it the first time, the error now shows up no matter what you try to do with 'guix system'?
<ulfvonbelow>I'd say try to run 'sudo guix system delete-generations'
<rchar01>after running the command: guix system delete-generations
<rchar01>What is the purpose of guix pull and guix upgrade, should I run both to upgrade the system (get the latest packages)?
<ulfvonbelow>generally speaking, 'guix pull' gets updated package definitions (as well as an updated guix), while 'guix upgrade' replaces your user profile (~/.guix-profile) with one populated using the newly-obtained package definitions.
<abrenon>I'm afraid I won't be of much help in that area, sorry : /
<Guest2477>vagrantc I realized, I tried to install the system for an hour by passing traffic through TOR, but since it often changes bridges, this causes short-term Internet outages and an installation error, I will try to try through VPN
<maximed>mitchell: propagation is suboptimal for $various_reasons and can often be avoided by adding a phase that replaces an invocation of a program by the absolute path (try a combination of 'substitute*' and 'search-input-file')
<lechner>vagrantc: Should they have gone there instead?
<maximed>mitchell: (for symbiyosys): the makefile runs "gcc" to compile things. However, when cross-compiling (with guix build --target), the cross-compiler TARGET-gcc is required (where TARGET=aarch64-linux-gnu or such)
<maximed>johnjaye: Well, if substitutes are available and grafts aren't complicating things, then it's first downloading, then building
<maximed>but in some situations, you can have the latter
<maximed>johnjaye: do you want to built everything from source (very slow, but possible)
<unmatched-paren>Pretend there's a make target for each download and build. The builds depend on the download and their dependencies. Now imagine you're running the makefile with -j8, like maximed said.
<johnjaye>i don't know what i want. i just ran the commands unmatched said.
<unmatched-paren>vagrantc: i dunno. i've just seen that being reported, and vaguely remember it happening to me at some point -.o.- either way, i still think a .deb option would be overkill, although some `guix-bootstrap` executable would be nice to have for a similar purpose
<maximed>vagrantc: the problem is that there sometimes are important changes to the daemon, leading to bug reports in bug-guix@ that (IIUC) result in ‘your daemon is ancient’
<unmatched-paren>johnjaye: i'm not entirely sure why you're running it in a loop; might be missing context from earlier. you probably have substitutes disabled, which would make the download take a lot longer of course
<maximed>(though maybe that was for _really_ ancient like 1.1.0, maybe not 1.3.0)
<johnjaye>no this is 1.3. just tell me exactly what to type
<johnjaye>the hardest part i believe is that when it reads commands it doesn't read them like a human would. i'm just speculating. but i think like when you read an ip address say you don't read it in a monotone
<vagrantc>jgibbons[m]: seems more appropriate question for firstname.lastname@example.org
<unmatched-paren>the former sounds like someone dislikes chmod and is saying something along the lines of `chmod schmod`... :P
<johnjaye>like one nine two dot one six eight dot. i think you put stress on the number syllables so it sounds more natural. so it sounds jarring when when the numbers and the punctuation are given equal volume
<sneek>vagrantc, maximed_ says: I've made a list at https://paste.debian.net/1243366/, possibly some of them are already in Debian's 'guix package' though. I guess I could give switching to Debian's guix a try ...
<johnjaye>red and blue make the most sense for high contarst
<nckx>maximed_: That depends entirely on what ‘Debian patches’ means? E.g., they probably patch <https://bugs.gnu.org/47229>, but check, and I doubt anyone's going to stick their neck out with a ‘yep’.
<nckx>unmatched-paren: I just don't understand where they come from? The Web site, the ISO file name, the manual, the installer, the boot process, all say ‘System’. 15 minutes (or fine, hours) later: ‘hooray I have finally installed Guix esdee’.
<vagrantc>i've pushed 15 commits recently, two of which didn't fix everything, one of which fixed three packages ... 15-2+3 ... 16 fixed packages ... out of 22086 packages ... 16/22086*100 ~= 0.07 ... you're right!
<vagrantc>more than three times the influence i thought!
<mitchell>why are the --system arguments not triplets like the --target arguments
<mitchell>armhf-linux system vs arm-linux-gnueabihf target
<vagrantc>not sure, but guix picked different architecture names than what gcc would represent ... some of the features do not necessarily directly map to gcc triplets
<nckx>mitchell: Because that's what Nix used. Perhaps a better question for #nixos, though the only authoritative person is probably Eelco.
<vagrantc>what are the pros and cons of modifying source using a snippet in the source of a package definition vs. a phase in the arguments ?
<mitchell>I know this one! Snippets modify the source as returned by 'guix build --source' which should be buildable on a foreign distro without guix. Therefore you should not use snippets to embed store names. Only use them to modify things like bundled projects and non-free aspects
<mitchell>Use phases to patch sources with store names
<maximed>mitchell: They are also used for non-bundled things and free things.
<maximed>E.g., in case of a security fix to apply a patch
<maximed>... actually, that's patches, not snippet
<vagrantc>so ... using a phase will allow you to use the same tarball, whereas a snippet (or patches?) will actually generate a new tarball?
<vagrantc>i've noticed occasionally some packages generate what appear to be multiple source tarballs in the process of building them ... linux-libre and maybe u-boot?
<maximed>Though for some simple fixes I found writing a snippet more convenient than a patch or phase (in antioxidant)
<maximed>(technically dependency updates but whatever)
<mitchell>from section 19.4.5 "The boundary between using an origin snippet versus a build phase to
<mitchell>modify the sources of a package can be elusive. Origin snippets are
<mitchell>typically used to remove unwanted files such as bundled libraries,
<mitchell>nonfree sources, or to apply simple substitutions. The source derived
<mitchell>from an origin should produce a source that can be used to build the
<mitchell>package on any system that the upstream package supports (i.e., act as
<mitchell>the corresponding source). In particular, origin snippets must not
<mitchell>embed store items in the sources; such patching should rather be done
<mitchell>using build phases. Refer to the ‘origin’ record documentation for more
<maximed>nckx: For a more concrete situation, some time in the past I added MINETEST_MOD_PATH to Minetest, with a patch.
<maximed>This patch was Guix-specific, but would also build on other systems.
<maximed>This patch was added to the 'patches' field of 'origin', and not a phase.
<nckx>Right. So it shows up in --source, when ideally it wouldn't, but that's just how patches are implemented. There is no concept of Guix-specific patchen and not-.
<maximed>nckx: I don't follow with ‘when ideally it wouldn't’.
<maximed>It's portable source code, and it adds something nice.
<nckx>Ideally, guix build --source foo returns FSDG compliant code, not Guix specific code. In practice Guix-specific patches sneak in as an implementation detail: there's no 'apply-extra-guix-patches phase.
<mitchell>why not a 'native-patches' field to the origin
<kennyballou>I guess my question is realy: is there a way to specify the file mode to `computed-file`? I cannot seem to change the file during activation because the store is read-only, etc.
<ulfvonbelow>kennyballou: after a store item is built, it is immutable. Regardless of what you set its permissions to during the building process, it will always end up with write permissions off for all users. If you need the config file to be writable, you'll have to copy an initial version to a non-store location where it can be found.
<kennyballou>ulfvonbelow: I don't really need the file to be writable. I would simply like to modify the permissions so that I can start a service that performs a permissions check. Thank you for the confirmation. I was thinking that there's no way to do this because it essentially violates the principle of the store.
<vagrantc>also, because of the design, updating packages that directly or indirectly are used to built everything ... end up getting put into staging or core-updates, depending on how much has to be rebuilt when they are updated
<vagrantc>but merging those branches tends to be challenging
<nckx>johnjaye: Hm, I'm not sure how to measure or answer that. Most work is probably maintenance & integration work: making packages work together, not segfault, actually start a full DE, etc. Some of that work is necessary because Guix does some things differently, sure, but… I think that it's the majority of work in *most* distributions?
<johnjaye>that makes sense. debian is probably similar
<vagrantc>the rebuild cycles are definitely harder debian
<nckx>So the possible implication (not saying it's yours) that ‘guix weird = more work’ isn't true. Plus, some of the weirdness actually helps save time. That's why it exists at all, after all.
<vagrantc>guix sacrafices some conveniences for arguably more correctness (e.g. not assuming a "minor" library update is compatible with the old one)
<nckx>The rebuild cycles are definitely long, but I don't know if they cause more human-hours in the end. It's more that we're a tiny team in comparison and honestly not very disciplined about it all…
<nckx>That's a high-level answer. Maybe you meant: when adding a new package. I'd say yes, but that's the only ‘creative’ part of packaging anyway 😛 The rest is just copy-pasting descriptions, URLs, and dependencies.
<nckx>So writing phases to adjust the build system to Guix can be 0% of the effort (well-behaved autotools) or 16,000% compared to the rest of the <package> boilerplate, it's not really that meaningful and depends heavily on the package.