*nckx wonders how many GNOME+Guix users actually use GDM if that's been broken for what feels like years. <jackhill>It seems I looked at this in July of last year… <dstolfa>nckx: i use sddm only because wayland, but i would switch back to gdm if it had wayland for sure <Xanderificnl_>Oh that's cool. Also very useful, you actually seem to have dealt with the problems we only just discovered <nckx>Xanderificnl_: Are you sure ‘python’ is available? <Xanderificnl_>If you look down the log, you'll notice the traceback which is from python <jackhill>Xanderificnl_: sorry I wasn't able to save you time :) <nckx>‘python’ is provided by the python-wrapper package; is it present? <nckx>dstolfa: Or we just theme SDDM to look like GDM and nobody need know our shame. <Xanderificnl_>Yes, I started the environment with: guix environment guix --pure --ad-hoc help2man git strace guix wget python python-wrapper <dstolfa>nckx: but screen lock doesn't work :( <nckx>Xanderificnl_: There isn't. <Xanderificnl_>Yeah it is, I already googled the issue and found a suggestion (from IRC log!) to include python-wrapper. So I'm like: "weird." <nckx>Xanderificnl_: Wait. That output is from a Guix build, not a manual build by you. It has nothing to do with your ‘guix environment’. <nckx>Why are you messing around with pure guix environments? <nckx>There might be some confusion adding spice to your life. <Xanderificnl_>i.e. to update sway from a previous version + it's dependencies <nckx>Which part of the manual? <Xanderificnl_>"The easiest way to set up a development environment for Guix is, of course, by using Guix! The following command starts a new shell where all the dependencies and appropriate environment variables are set up to hack on Guix:" <nckx>(To address some of it above: the ‘python’ package variable is python 3, which provides a ‘python3’ executable. It does *not* provide a ‘python’ alias for that. That's provided by the very thin ‘python-wrapper’ package.) <singpolyma>It implies you can/should run make authenticate in the environment, which of course you cannot <nckx>But I don't understand why you're adding python? Guix doesn't need python, and you don't seem to be building Guix but Sway. <Xanderificnl_>You know, you're right. I probably just got my tabs confused. <Xanderificnl_>See, when I read this: "If you want to hack Guix itself, it is recommended to use the latest version from the Git repository:" I'm thinking: "The OS/packages/etc." <Xanderificnl_>but from what you're telling me, it probably is just `guix`? <nckx>Well, at great risk of confusing you further: ☺ <singpolyma>So far I always work out of tree and use guix build because I haven't really figured out how working in tree is supported to work <Xanderificnl_>So, should I escape the pure environment and retry the build from there? <nckx>and assuming you're editing the ‘sway’ package definition in a guix git checkout: you do want to run in a ‘guix environment guix’, so you can ‘run guix before it is installed’ as the manual calls it. But this is just to provide some stuff that *guix* needs to run (Guile, dependencies of Guix's ./configure, GNU make, etc.). There's also little sense in making it --pure and I'd actually recommend against it. <Xanderificnl_>Ah, so just using the environment without the pure flag. That makes sense, so other tools from the general env are available. Right? <nckx>But when you invoke ‘your’ guix, using ‘./pre-inst-env guix’, so you can build your sway@1.6.1, it is built in a completely different environment, containing only the inputs of the sway package definition. <Xanderificnl_>(and yes, that's exactly what I'm doing. I've managed to resolve _a lot of dependencies_ sofar.) <nckx>It's more like your building a package on a big build server using ssh from your laptop, the build returns an error that it's missing python, so you install python on your laptop? <Xanderificnl_>Yeah, I'm following what you're saying. So, running an unpure env, and then running the ./pre-inst-env will work, or do I need to drop the pre-inst-env too and just use the unpure environment itself? <nckx>I would keep it: ‘guix environment guix -- ./pre-inst-env guix build sway’. <lfam>singpolyma: We are happy to help you get the in-tree development environment working if you want. I find it comfortable and convenient at least <singpolyma>lfam: yeah, I need to spend time here and get it working eventually so I can contribute once I get something working :) <nckx>Xanderificnl_: The vital thing was to understand that the guix environment you're in and from where you're invoking ‘guix’ never has any influence whatsoever on what the sway build sees. <lfam>Alright. It *should* be as simple as `guix environment guix` and then `./bootstrap && ./configure --localstatedir=var && make`. Then you can do things like `./pre-inst-env guix build my-package` <nckx>Which it seems that you do. <lfam>Anyways, you should be able to get assistance with that here at pretty much any time of day <Xanderificnl_>So what's the difference between what I did and what lfam said besides using a pure environment? (I did do the bootstrap, configure & make). <Xanderificnl_>(trying to understand. Getting caught up in environment confusion.) <nckx>That you were adding python-wrapper to the environment of the shell you were hacking in, in what seemed like an attempt to get the sway build (performed in daemon jail) to see it? <Xanderificnl_>Before I realized it should've been an input. So, to reiterate. I need to leave all environment, besides the general/global one; and try it w/ $ guix environment guix -- ./pre-inst-env guix build sway <nckx>If you have no *need* for a pure environment and don't know exactly why you're in one, yes, I would leave it; you're making your life in that environment more spartan for no reason. <nckx>As is undoubtedly obvious I need to go sleep now. o/ <Xanderificnl_>Yeah, the reason was more or less: the manual told me it was the easiest way <iskarian>lfam, was there a change in the 5.13 kernel update that changed where kernel modules go? <iskarian>I have them in "/lib/modules/5.13.14-gnu/extra", and that's the kernel it's building with, but it thinks they are for the wrong version <iskarian>Okay, it looks like it's "-gnu1" now. Let's see if that works <lfam>What are you observing specifically <lfam>It's set to "/run/current-system/profile/bin/modprobe" in our configs <iskarian>I think the `uname -a' for our 5.13.14 is "Linux gnu 5.13.14-gnu1" instead of "Linux gnu 5.13.14-gnu" <iskarian>I can see that in the module builder, "lib/modules/build/include/config/kernel.release" is "5.13.14-gnu1" <lfam>Yes, that reflects an update to the revision of the deblobbing process that transforms Linux->linux-libre <lfam>Does something else need to be adjusted on our end? <iskarian>I can change it manually, but is there a way to autodetect that from the linux-libre package definition? <lfam>The package definition does specify this version... beginning with 5.13.14 <lfam>Previously we had never experienced this type of update so "-gnu" was hard-coded <lfam>The revision is in a public variable "linux-libre-5.13-gnu-revision" and this was introduced in commit a185a02f544d8091be7310022761ac33bd9aed9a <iskarian>Hmmm. I see it. It's not as easy as just doing (package-version linux-libre) like before <lfam>Are you having trouble with something provided by Guix? Or is it something external? <iskarian>Are there examples of kernel module packages in Guix? <lfam>I had considered whether to add a variable (as I did), or to put this revision into the package version <lfam>The latter would be what upstream prefers. However we disagree about some things and I didn't realize how this could break things for users <lfam>I think of these kernels as a basic transformation / patching of upstream Linux, but I know the direct upstream team at linux-libre would prefer we modeled our packages as if linux-libre was the upstream <iskarian>I suppose I could always just have the package read kernel.release and use that, since that's authoritative <lfam>Or we could change what I did to work better for you <lfam>It's definitely tricky... there are a lot of use cases to satisfy <lfam>I don't really think of these kernels as having an upstream in the traditional way. Like, if you wanted to contribute to kernel development or report or search for bugs, you go to Linux <lfam>But we don't offer Linux <lfam>So it's hard for me to say that the version is "5.13.14-gnu1" <lfam>The version is really 5.13.14 and then some parts are removed *dstolfa tends to agree with lfam that the upstream is in fact linux mainline and that guix simply applies the deblob scripts whose upstream is linux-libre. <lfam>But on the other hand, Guix is a GNU project, so linux-libre is our kernel. <lfam>Personally I don't think there's an answer that is obviously the right one <lfam>Maybe it would have been better to rename linux-libre-5.13-version to linux-libre-5.13-upstream-version, also add the gnu-revision variable, and then concatenate them to create linux-libre-5.13-version <lfam>I did think about stuff for a little while but I made the decision quickly in order to keep up with new releases <lfam>We don't go out of our way to break 3rd-party channels or packages, but I do think we shouldn't break them wantonly <iskarian>To be fair, the issue is probably because I'm manually doing the install phase--there's no script <lfam>I'm sorry we broke your thing <iskarian>A script would probably detect kernel.release automatically <iskarian>no worries, I just swapped "-gnu" for "-gnu1" :) <lfam>It will probably break again because e.g. 5.14's deblob revision is "gnu" <lfam>Like, they fixed the older deblobbing scripts before releasing 5.14, so there's no need for a revision there <lfam>Also, I'm interested in handing the work of maintaining the linux-libre packages to somebody else <lfam>It's not a ton of work but it does require attention at least once a week <lfam>I have some scripts to automate some parts of the process <lfam>If anyone is interested, please let me know. I'm happy to keep giving advice about it in the long term <iskarian>I'm wondering if it would be worth it to add a #:kernel-release argument to linux-module-build-system, or if it would be overengineering <lfam>GC Warning: Out of Memory! Heap size: 3401 MiB. Returning NULL! <lfam>That seems excessive vagrantc <lfam>I noticed some complaints about memory use recently <lfam>iskarian: I don't have a strong grasp on how all of our kernel stuff works. If you think it's a good idea, it probably is <lfam>A different error in each link, right vagrantc? <lfam>Or does "mmap(PROT_NONE) failed" also reflect an OOM condition? <iskarian>lfam, I'll try to take a look at how the kernel-module-build-system is used and see if it would be, but it's kinda far down the list for now <iskarian>Hmmm. The default behavior of "guix system delete-generations" is to delete all except the current. Would it be better to do nothing without an argument? <iskarian>For example, I was just trying to figure out what arguments it took, thought "oh, maybe invoking it with no arguments will show a 'delete-generations'-specific help" ....aaaand they're gone <lfam>I feel like this must have been discussed before <lfam>In some ways, it's consistent with `guix package -u`. But that's not a destructive operation <lfam>`guix package -d` also deletes everything <lfam>It's weird that I never did this by accident <lfam>I mean, it does what it says on the box! <lfam>It deletes the generations <iskarian>If we're going to change it, I'd like to see no action without an argument, or at least a "Are you sure you want to delete all old generations? y/N" <iskarian>A search doesn't turn up any previous discussion, but I'm probably just missing it <Xanderificnl_>makes sense, destructive options shouldn't default to yes imo <lfam>It could be compared to `rm` <lfam>I mean, it is definitely bad if somebody accidentally deletes all your old generation, but what else would `guix package --delete-generations` do? <lfam>I mean, not if somebody does it to you, but just if somebody does it to themselves <lfam>But if it's happening a lot, that's a problem too <iskarian>Following that analogy, the current behavior would be equivalent to "rm ./*" <lfam>Yes, that's one way to look at it! <lfam>Hey, maybe that's how rm *should* work ;) <iskarian>Well, I had to bump the VM's memory to 10G to be able to build Zig without thrashing swap, so why not? <lilyp>If you don't have the ram, use rem instead :P <voroskoi[m]>aarch64 state on ci is killing me, building everything on rpi4 is not fun :-/ <iskarian>voroskoi[m], it seems the FileNotFound is occuring with the behavior.zig test, and based on the strace I *think* it's not finding "libs.txt" <voroskoi[m]>in test/tests.zig i just comment out the aarch-gnu abi <iskarian>either that, or it's trying to open "/dev/null" <voroskoi[m]>right now i am running -Dskip-non-native -Dskip-release just to find out if that works <voroskoi[m]>-Dskip-non-native passes the behavior tests, but it is still running, so there might be other issues <iskarian>voroskoi[m], you might be onto something with libc; removing -lc from the actual test invocation makes the behavior tests pass <iskarian>it was specifically the "behavior-x86_64-linux-gnu-Debug-c-multi" test; I think we compile a lot of our stuff without multilib, so hmm <voroskoi[m]>btw -Dskip-non-native failed on "libc headers note" in compile_errors.zig, disabling it for now to see what else comes up <iskarian>okay, *that's* interesting! Adding --dynamic-linker to the invocation makes it succeed. <iskarian>What's odd is that with the same compiler, I'm able to build a test program and *it* has the proper dynamic linker <Xanderificnl_>So -- sway 1.6.1 + all its dependencies have been built. I'm pinching myself to see if I'm imagining this. <Xanderificnl_>That wasn't nearly as hard as I imagined (though, to be fair, I mostly just changed a couple of versions, checksums, and did some minor changes.) <lfam>sneek: later tell Xanderificnl_: That's great! Usually that's how it goes <singpolyma>ruby-build-system supports #:test-target to run rake spec instead of rake test, etc. What if there is no Rakefile but there are tests that can be run with some other command entirely? <iskarian>singpolyma, you would replace the test phase and use `(invoke "test-binary" "--example-flag")' <iskarian>search for "(replace 'check" for examples <singpolyma>If I am inside a guix environment and I run guix package -i should I expect that package to appear in the environment? It sems to go into ~/.guix-profile which is not my default profile but also it does not show up in the environment <singpolyma>Ah, I guess I can source the ~/.guix-profile into the environment? Is ~/.guix-profile just "a profile for whatever you just did" ? <lfam>~/.guix-profile is the default profile used by `guix package` <lfam>`guix environment` doesn't interact with it at all <lfam>`guix environment` is designed for temporary, ephemeral environments <lfam>Whereas `guix package` is for more durable things <lfam>`guix package` is kind of like installing a package on a normal distro <lfam>And `guix environment` is more a tool for trying things out or doing development <singpolyma>so what's the difference between ~/.guix-profile and ~/.config/guix/current ? <lfam>The latter is the profile used for `guix pull` <singpolyma>can I have a `guix environment` that has the dependencies from package a, but also has packages b and c? If I switch to --ad-hoc it tries to pull in a and not just its inputs <lfam>Both `guix package` and `guix pull` create profiles, but the `guix pull` profile is just for Guix itself, not for the packages that you install <lfam>I think the command-line arguments are supposed to be positional <lfam>So for example, `guix environment hello --ad-hoc borg` <lfam>It provides the development environment of hello, but not hello itself. Plus borg <lfam>So, the order of arguments matters <lfam>There's another neat trick: <lfam>`guix environment hello -- guix build --no-substitutes hello` <lfam>Use substitutes for the development but make sure to build the package from source <lfam>I mean, "Use substitutes for the development environment ..." <lfam>It doesn't actually use that environment, like, in your shell. But the first half ensures the dependencies of hello are in your store <lfam>It's a trick for splitting up build actions in a group of things to be substituted and things to be compiled locally <lfam>Into two groups, that is <iskarian>voroskoi[m], I've narrowed down the issue to occurring when zig "cross-compiles" to the same architecture. When in "cross-compile mode", Zig uses standard interpreter paths, so we get e.g. /lib/ld-linux-x86-64.so.2; and then it tries to run the result, but it fails because that doesn't exist <iskarian>I'm not sure if it's better to not attempt to run the result of *any* cross-compilation, or mess with the interpreter... ***j is now known as jess
<dhruvin>Hello guix! I understand that the `requirement' field in shepherd-service specifies a list of services (names) to start before starting the service in question. But it won't actually wait for completion of any one-shot service specified in that list. Is it correct? <voroskoi[m]>iskarian: as zig is quite immature anyway i do not see it as a big issue <iskarian>I think their binaries are supposed to be qemu-compatible; their test framework will automatically run incompatible binaries under qemu if you have it <dhruvin>Yes, I read the code of (shepherd service) module. If the start defined on a service is not forking, one could effectively make services that require it wait before starting. <ss2>hello, is there any further documentation how a store item is prepared, and then put into the store? <ss2>I'm trying to build a package, but it is now trying to write directly into the store -- which is obviously wrong --, and now I'd like to know how to modify this installer that it installs into the proper directory. <nckx>Good morning, Guix. Hi muradm. <nckx>ss2: There is no staging area. Packages do install directly into the store (the equivalent of ‘make prefix=/gnu/store/eee-foo-1 install’), but only their own store directory is made writable. So either your package is installing outside of its allocated slot into another, or something else is going on. <nckx>(Of course this is virtualised, but from the POV of the package build it's what happens.) <maximed>The file system became read-only, can I somehow do something about that? <sneek>Welcome back maximed, you have 1 message! <sneek>maximed, iskarian says: If you're looking for things to optimize, maybe look at 'generate-checksums' in cargo-utils, that seems to take a *while* <nckx>sneek: later tell maximed: Buy a new drive :( <nckx>sneek: later tell maximed: I'd start by shutting down, booting a live rescue system, and running ‘smartctl -T long /dev/sda’ (this won't finish in minutes). Also btrfs scrub the file system. <dstolfa>also i agree with nckx this looks like either a dead disk or a dead btrfs (probably the former) <dstolfa>replacing that might just magically fix the problem <nckx>sneek: later tell maximed: But ‘ata1: hard resetting link’ means your OS thinks the hardware's croaking, and IME at least it's the prelude to ‘this system is going to be the weirdly unreliable one for the rest of its life’, so for your own peace of mind I'd still consider replacing the drive if you can afford it, even if everything comes back clean. The cheaper solution is to check your cables & connections, although that's never fixed it for me. *dstolfa likes Ryan's proposal on the mailing list <nckx>(╯°□°）╯︵ CUPS: Printers Error: Unable to get printer list: Success <robin>cups: the environmentally-friendly printing system *dstolfa notes that linux-libre has the same error message <nckx>Guile. Let's not accuse linux-libre of more than it already does. <nckx>I wish this were my roundabout way of announcing I'd ported Guix to my printer but alas. <dstolfa>nckx: ah, is that guile being like: error: Success.? :) <nckx>The finalization thread of success is Guile. <dstolfa>i thought it was a kernel message. it only appears for a split second so i never have time to see what it is, i just see an error: Success. TIL ***iyzsong- is now known as iyzsong
<ss2>nckx: okay, thanks for the clarification. <nckx>Did you figure out what happened? <ss2>yes, but I haven't figured out yet how to modify the installer. <ss2>I'm packaging CHICKEN eggs, and am stuck at chicken-doc. <pkill9>i realise after using archlinux how much guix has spoilt me, lol <pkill9>guix pull pulls in a tonne of dependencies <adfeno>Hi there, how to make icecat use system's ALSA ? <adfeno>Currently it seems to use PulseAudio through "pulse-rust". <maximed>nckx, dtolfa: A reboot ‘fixed’ it for me, though presumably the hardware is still croaking <sneek>maximed, you have 3 messages! <sneek>maximed, nckx says: Buy a new drive :( <sneek>maximed, nckx says: I'd start by shutting down, booting a live rescue system, and running ‘smartctl -T long /dev/sda’ (this won't finish in minutes). Also btrfs scrub the file system. <sneek>maximed, nckx says: But ‘ata1: hard resetting link’ means your OS thinks the hardware's croaking, and IME at least it's the prelude to ‘this system is going to be the weirdly unreliable one for the rest of its life’, so for your own peace of mind I'd still consider replacing the drive if you can afford it, even if everything comes back clean. The cheaper solution is to check your cables & connections, although that's never fixed it for <maximed>Checking cables & connections seems difficult because I don't have the right type of screwdriver and the wrong type didn't succeed in unscrewing all the screws <nckx>I'm glad it's ‘‘fixed’’ but I envy your ability to sleep 😉 <maximed>I'm not doing anything important lately, but I'll probably be switching to a different computer soon *dstolfa mumbles something about RAIDZ and multiple disks and quickly hides <dstolfa>maximed: did smartctl say anything useful if you ran it btw? <maximed>dstolfa: I don't have a live system to boot, so I couldn't try that <maximed>or can "smartctl" be run while the file system is mounted? <dstolfa>i think it can, assuming that the smartctl binary doesn't get corrupted by the broken drive <dstolfa>it's likely more reliable to run it on a live system, but i believe you can just run it <nckx>Reliability won't be affected, only performance (both of the check and any system I/O whilst the test is running). <nckx>These tests are intended to be run while the machine is in use. <nckx>That's all smartd does: schedule these tests and log the results. <dstolfa>nckx: by reliability being affected, i mean that i'm not sure if smart tools have any notion of checksumming themselves as they run to make sure that the ELF file is not corrupt in some weird way by the broken disk that's storing it <nckx>But since this is btrfs that's basically what happens. <dstolfa>ah right, forgot that maximed was running btrfs <g_bor>iirc rekado sent job openings earlier to some of the ml. <g_bor>Which one was that, I don't want to send it somewhere were it does not belong. <g_bor>My new company has some openings now. <g_bor>also, at work I can only access my new email, so I just subscribed to the info and the devel ml, in case someone wonders if it is spam:) <nckx>g_bor: Thanks for the heads up :) Should be OK for guix-devel@. <g_bor>sneek: later tell roptat that it seems that some of the Hungarian translations are not created, and it looks like I have not enough permissions to create them <robin>i was poking around linux-boot.scm too, funnily enough. had to frob some settings under /sys from initramfs since guix doesn't use the usual pile-of-shell-scripts system (and not enough user-accessible hooks to replace them tbh) <robin>also updated looking-glass-client and i can see why it hasn't been updated in years...it's very technically impressive, but there's a lot of random static linking going on and the author doesn't know how to use gl extensions properly <robin>"/sys/bus/pci/devices/.../driver_override" (to vfio-pci; normally a vfio-pci.ids=... kernel arg should be enough, but amdgpu was still taking over the card for some reason, and trying to change that post-boot resulted in kernel segfaults) <robin>...to do pcie passthrough for VMs <robin>it's not a very good package (static linking etc.), but it probably had the same problems before so i might as well submit it <nckx>robin: And this must be done in the initrd? <robin>(a modprobe config file could've also fixed the driver override problem, but pulling that into initramfs is more work than writing a few lines of scheme) <robin>nckx, yes, it has to be done very early, before the kernel/gpu module's had a chance to initialize anything <robin>in theory it should be possible to change post-boot, also by poking around in /sys, but most gpus aren't well-behaved wrt that sort of thing <nckx>Yes, let's not put modprobe into the initrd :) <nckx>The current system is very ad hoc indeed (the EXT2FS_NO_MTAB_OK setenv you probably saw is another golden example). It would be nicer to have the concept of system services available much earlier, as systemd does. <roptat>sneek, later tell g_bor there's no need for specific permission, you just need to be connected to be able to translate <sneek>Welcome back roptat, you have 1 message! <sneek>roptat, g_bor says: that it seems that some of the Hungarian translations are not created, and it looks like I have not enough permissions to create them <roptat>sneek, later tell g_bor all the suggestions I see seem to come from "Anonymous", which suggests you are not connected <g_bor>anyone has problems connecting using the kiwi irc? <sneek>Welcome back g_bor, you have 2 messages! <sneek>g_bor, roptat says: there's no need for specific permission, you just need to be connected to be able to translate <sneek>g_bor, roptat says: all the suggestions I see seem to come from "Anonymous", which suggests you are not connected <g_bor>I can consistently work around the issue by trying to connect, and after the connection error ticking the ssl box. <g_bor>If I tick ssl in the first place I get an xhr poll error, and it does not work any more without reloading the site <g_bor>roptat: how do I do the connect? <g_bor>I am logged on using my fedora account. <g_bor>I can also work on translations that exists, so on the glossary, the packages and the guix itself, but the cookbook and the manual seem to be missing <gcrypt-hasher>I'm getting that error after I try to bootstrap a new guix tree <gcrypt-hasher>I didn't try Ludo's suggestion because it requires guix system .... <maximed>gcrypt-hasher: Do you have Guile-Gcrypt installed on your foreign distro? <maximed>and do you already have guix installed? <jpoiret>can i keep build trees for successfully built packages ? <maximed>If guix is alraedy installed, you can do "guix environment guix" followed by the usual ./bootstrap and make, and then "./pre-inst-env guix build ..." <jpoiret>i guess i'll just spuriously make it fail so that i can look at the build tree <maximed>gcrypt-hasher: Are you running "./pre-inst-env ..." from within the environment? <Guest92>Hi, I'm trying to write a package definition for Promela, but the command is not found. What am I doing wrong? (replace 'install <Guest92> (lambda* (#:key inputs outputs #:allow-other-keys) <Guest92> (let ((out (assoc-ref outputs "out"))) <Guest92> (invoke "make" "INSTALL=cp" (string-append "DESTDIR=" out) "install")))) <maximed>nckx: Weet je hoe je ‘verboden vertalingen’ kan verwijderen op translate.fedoraproject.org? <roptat>Guest92, looks correct, what command is not found? <maximed>De ‘download’ -> ‘download’ verboden lijkt mij een beetje overdreven <maximed>Guest92: is the package for 'spin' in native-inputs? Or is 'spin' what you are trying to build? <Guest92>'spin' is the name of the binary (it's promela/spin) <Guest92>here is my full package definition (define-public promela <Guest92> (commit (string-append "version-" version)))) <Guest92> (file-name (git-file-name name version)) <Guest92> (base32 "0mf8bisl27dysnfhy9nmhnrk6bw3cx9zsv8nf1r982fry1fx1fvn")))) <Guest92>spin is the proof verifier and promela is the language (kind of like gcc and C) <maximed>Guest92: are you sure it is ‘spin’ that is not found? <maximed>I'd think it is 'configure' that is not found <maximed>because Spin doesn't have a 'configure' script <maximed>(unless (delete 'configure) is used) <Guest92>I'm able the guix install, but I can't find the binary <maximed>Guest92: do you mean that "guix install -f the-package.scm" succeeded without error messages? <nckx>maximed: I thought you added that? <nckx>maximed: If you don't find it, it's because I think I just did :) <nckx>If you do, I failed, and you must do it. <maximed>Guest92: maybe run "find $(guix build -f the-package.scm)" <maximed>though possibly in an unexpected location <Guest92>"find: ‘spin’: No such file or directory" Maybe it just doesn't copy to destdir <maximed>Guest92: what is the output of "echo find $(guix build -f the-package.scm)"? <maximed>(I'd expect something like "find /gnu/store/[many letters and numbers]-promela-6.5.2") <Guest92>maximed /gnu/store/7k4abb2r4lrdbhhqybmc4sf7x8ylcsqi-promela-6.5.2 <maximed>Guest92: then you can run ‘find /gnu/store/7k4abb2r4lrdbhhqybmc4sf7x8ylcsqi-promela-6.5.2’ to find out where everything has been installed <Guest92>(returns /gnu/store/7k4abb2r4lrdbhhqybmc4sf7x8ylcsqi-promela-6.5.2) <maximed>Guest92: seems like something went wrong during installation <maximed>'cp' doesn't create the parent directories <maximed>maybe you need "INSTALL=install -D" instead of "INSTALL=cp"? <Guest92>maximed /gnu/store/32n4nzja3iab1b52fkjs08zmjp42cz4j-promela-6.5.2/bin/spin <roptat>is spin a binary or a shell script? <roptat>if it's a binary, what does "ldd .../bin/spin" tell you, if it's a shell script, what's the first line? <Guest92>linux-vdso.so.1 (0x00007ffde9dab000) <Guest92> libgcc_s.so.1 => /gnu/store/f0ca0lf64bw08srv1bj7gkg6ag0sbdb2-gcc-7.5.0-lib/lib/libgcc_s.so.1 (0x00007fed23c11000) <Guest92> libc.so.6 => /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 (0x00007fed23a54000) <Guest92> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/ld-linux-x86-64.so.2 (0x00007fed23c2c000) <Guest92>linux-vdso.so.1 (0x00007ffde9dab000) <iskarian>dstolfa, do you mean "named environments"? <iskarian>I like the idea; in fact I have aliases e.g. for an augmented "guix environment guix" <iskarian>But I wonder where the dividing line comes down between what should go in "guix environment" vs "guix profile" <dstolfa>iskarian: i guess it's the same dividing line of app containers vs multi-purpose containers, except it's drawn very explicitly? <dstolfa>in solaris/illumos/freebsd it's already a sort-of-drawn line with single-purpose "service" containers (zones, jails) vs full blown fat containers that have a full userland in them <iskarian>I thought environments built profile hooks the same as profiles, is that incorrect? <dstolfa>the may -- i don't really know. but i don't think it really matters. it's more of a user abstraction rather than anything else <iskarian>Hmmm. In fact, there is "guix environment -p path/to/profile" <iskarian>I suppose this is essentially a shorthand? <iskarian>Ah, though it would make sense for the named environment to actually save certain "guix environment" options, such as "--preserve" or "--system" <iskarian>Is there currently a scheme-level way to define environments, like how we have such a thing for "operating-system" <iskarian>maximed, I thought 'manifest' simply was... a package manifest, that it didn't contain any meta information like "--preserve" or so on? <maximed>Guest92: Does /gnu/store/32n4nzja3iab1b52fkjs08zmjp42cz4j-promela-6.5.2/bin/spin run? <maximed>you can do "guix environment --manifest=... --preserve=..." though <maximed>Guest92: promela seems to run fine, but you might want to check $PATH <maximed>it should contain $HOME/.guix-profile/bin <Guest92>maximed indeed it contain $HOME/.guix-profile/bin <Guest92>but bin doesn't contain any link to spin <maximed>Guest92: did you run "guix install -f the-package.scm" <maximed>If you do, spin should be added to ~/.guix-profile/bin <maximed>make sure the file evaluates to the package <maximed>(e.g. ‘(define-public promela (package [...])) promela’) <CaptainDrewBoy>Hello! Looking for some help installing guix sd. I'm doing a manual install and need a bit of help with the wifi. The guide says I need to get an ip address, but the given command did not work for me (I suppose my ip is not given out via dhcp). What should I do? <CaptainDrewBoy>TL;DR: Doing a manual guix sd install, how do I set the ip address without the manual's dhclient command <oriansj>CaptainDrewBoy: ifconfig $interface ${IP_ADDR} broadcast ${BROADCAST} netmask ${NETMASK} up or ip address add ${IP_ADDR}${NETMASK} dev $interface <oriansj>or do you mean in your guix configuration? <CaptainDrewBoy>oriansj: In your message there is a bit saying ${IP_ADDR}. Is this a shell variable, or am I meant to enter an IP address in there? I don't know what IP to enter if the latter is true <the_tubular>I don't understand. Guix just rebuilt a lot of thing and it says there was 1 commit since my last guix pull <oriansj>CaptainDrewBoy: it is a shell way of expressing provide your value here. for example: ifconfig eth0 1.2.3.4 broadcast 1.2.3.255 netmask 255.255.255.0 up <oriansj>if you are not comfortable with setting a static IP address, I suggest dhclient (for ethernet connections) or iw (for wireless connections) <oriansj>CaptainDrewBoy: iwctl; then station list (to get the name of your wireless device); then station scan (to find your wifi you wish to connect to) then station $device connect $wifi (it will prompt for password) and then you are done <pkill9>you can urn guix on any other distro as a package manager <dstolfa>GNUHacker: guix works perfectly on (almost) any distro <dstolfa>i say almost because sometimes SELinux is a problem <GNUHacker>how can I install guix pm in Trisquel distro? <oriansj>dstolfa: a proper SELinux policy fixes that plenty quick <CaptainDrewBoy>GNUHacker: The easiest way is the shell script lying around somewhere on the Guix website <dstolfa>oriansj: could you please share one that does? <dstolfa>i usually have to work around it in annoying ways <oriansj>the_tubular: guix rebuilds itself and its dependencies when you do guix pull <oriansj>dstolfa: well it works for all distros except Guix that use SELinux <dstolfa>that's not to say it's not useful, it's just that i wouldn't call that "fixing plenty quick", given that you need to keep fixing it and it removes some useful features *dstolfa wishes selinux was easier to make work with guix <oriansj>the_tubular: yes but usually it is small and fast <oriansj>ensuring it has everything it needs to work after it is updated. <oriansj>Updating Guix and updating the list of packages in guix is effectively the same thing as guix is a scheme program. <the_tubular>If guix is updating why does it say that there's only 1 new commit ? <oriansj>the_tubular: imagine you wrote a program and checked it into git. And you updated that program by doing a git pull. <oriansj>it just also builds after you do that git pull <the_tubular>Yes, but isn't that commit the new package that was added ? <the_tubular>It says : Authenticating channel 'guix', commits 9edb3f6 to 547256f (1 new commits)... <the_tubular>And a bit latter : New in this revision: 1 package upgraded: blanket@0.4.1 <oriansj>well and possibly some other things as well <oriansj>such as additional security fixes for guix <oriansj>like any other git commit, what it contains isn't really limited <the_tubular>Umm, maybe I was wrong, but I usually try to seperate commit if a change has nothing to do with the other one <oriansj>So it could be a change that touched 500 different definitions, 4 of which are things guix depends upon. <the_tubular>As long as there's changes, I'm happy. It means guix is healthy :) <oriansj>breaking guix doesn't actually mean you have an issue because all the other previous working versions are still there too (until they are garbage collected) <oriansj>I certainly have but I tend to abuse guix for my own twisted desires <the_tubular>I gotta learn to use guix better. I'm still very new to the project and I learn slowly what it is capable of <oriansj>actually the idea isn't to use guix better it is getting guix to serve you better <oriansj>have it do the things you care about in a way that makes your life better <dhruvin>Another, and hopefully last issue while building an image for sourcehut builder: guix system image --image-type=qcow2 --image-size=16G ... creates a partition.img in the store of size 16G. I can't build guix qcow2 image inside a guix vm of same disk size. I could omit --image-size, resize qcow2 after it's created, and call resize2fs in a service. Any other ideas? <podiki[m]>was thinking of taking core-updates-frozen for a spin...what's the procedure, pull with that branch, system reconfigure, reboot? (fingers crossed) <Soheil[m]>How can I turn on the keyboard backlight in Guix System?