IRC channel logs
2025-03-05.log
back to list of logs
<vagrantc>that didn't use u-boot either, so just good for build testing anyways <vagrantc>ACTION was very happy linux-libre@6.13.4 had a substitute ... but sure enough, 6.13.5 got good and merged. :) <apoorv569>mange: Ah! I thought I didn't need it.. I checked the list.. there are some packages I don't think I will need ever.. <apoorv569>about the rules.. I checked online I missed the multiport module part apparently.. <apoorv569>-m multiport --dports 80,443 should do it right? <mange>I don't know, I'm not familiar with iptables. I'm just telling you what "herd status iptables" told me. :) <apoorv569>oh! it gave you error --dport 80,443 is wrong? <apoorv569>I'll try multiport if it doesn't work then I'll do separate rules.. <mange>Once I added %base-packages iptables started giving useful error messages (rather than complaining about the obviously-correct "*filter" at the start). <apoorv569>so from your findings, you modprobe is what is causing the issue? <apoorv569>perhaps I just add modprobe package in the list? <apoorv569>no wonder I had to add those modules manually <mange>The only one I'm confident you definitely need is modprobe. If you want to reduce it to a minimal set I'd recommend experimenting with it using "guix system vm". <mange>Maybe you can just use %base-packages-linux? <mange>I don't know if you'd also need %base-packages-networking for what you're doing. <apoorv569>oh I didn't knew about these variables let me check these.. <apoorv569>interesting.. I'll test what I need by remove one by one.. but first I'll test the config with %base-packages <vagrantc>civodul: clearly we are talking about ae30bf6332fe42e146ae3f950fa88d6e48afcfda but strangely i did not see it until 6e41ca397dd2810ee78bce8fdd11da5ba09c8fd4 <mange>Last night I tried to recursively import a Go package and it span for *hours* (I didn't end up letting it finish). I had a look at how Nix does things and according to https://nixos.org/manual/nixpkgs/stable/#sec-language-go they do a two-phase build. First they run a derivation to grab the dependencies using "go mod vendor" (with a known hash for the whole thing), then they have a second derivation to build the pac <mange>Has anyone tried anything like this in Guix? It means that they don't list dependencies explicitly in their package definitions, but the builds fetch what they need in a "reproducible" way (assuming upstream is still there). <CriticOnPoint>as i see dependencies in packages definitions are being pointed out as names and versions <CriticOnPoint>how to ensure, that i'm pointing out to specific and unique building process using source and building flags, i thought that's the whole point of hash addressing, but it seems that you can't address with hash <CriticOnPoint>so in case when package definition has been tampered with it will produce different results <mange>In Guix, output filenames are /gnu/store/{some-long-hash}-{output-name}. The hash bit is a hash of everything that goes into the recipe (called a "derivation") for that output. If any of the inputs change, then the hash changes. <mange>Sources are pulled with known hashes (which are embedded in the package definition's "source" field), and everything else is hashed based on the commands in the derivations after that. <CriticOnPoint>ok, how to define dependency on package, let's say i need gawk build with some custom flags, and i'd like to refer to this exact process of building gawk, name, version or where can it be found, in guix central repo or some custom channel first, doesn't matter <mange>You refer to a package by its Scheme definition. So you would need to have a definition of gawk with the recipe you want, and you would refer to it in the inputs list of your package. E.g. (define-public my-custom-gawk (package ...)) (define-public my-package (package ... (inputs (list my-custom-gawk ...)))) <mange>Yes? I'm not entirely sure what you're asking. <CriticOnPoint>when i have few channels defined the on found first willbe used, so chnaging prioritiesof channels couldlead to different results? <CriticOnPoint>i mean, if someone would swap the receipe or change it i wouldn't know <mange>If you're getting them from the CLI, or from specification->package, then you can get different results (and Guix will print a warning message). If you're using a scheme variable then there should be no ambiguity. <mange>If you use something like my example above then the my-custom-gawk is actually a scheme variable containing a package, not a package name. <mange>Guix package definitions are scheme code. <CriticOnPoint>my-custom-gawk instructs guix to find package definition of mentioned name and use it, right <CriticOnPoint>so if package definitin change my package dependeing on my-custom-gawk will also change and i won't be informed <mange>I feel like we might be operating at a level of detail that is unhelpful. I'm not really understanding your fundamental concern. Are you worried that someone can "poison" a channel and violate your expectations about what packages you're using? <CriticOnPoint>yes, with every package there is uniqie hashing, but name dependencies don'tuse it, right? or am i missing something <apteryx>sneek later tell civodul in commit dd64f441d3, I introduced a configuration option to invoke udevd with --debug, which causes more verbose output to go to stderr; oddly this seems to hang shepherd, or oiat least the boot. Could writing to stderr this early during boot be problematic from some shepherd logging point of view? <sneek>apteryx, you have 1 message! <sneek>apteryx, lilyp says: I did have GIO modules related crashes that result in a one-liner immediately on program launch; if it's not that then no <apteryx>lilyp: resolved by reboot, and my commit dd64f441d3 with debug? #t for udev-configuration was causing my system to hang for reasons I don't understantd. I'll probably revert this commit for now. <mange>The hashes are used to look up the precise version of the build *result*. So when a recipe references my-custom-gawk, the build will look up the my-custom-gawk result that matches, according to its hash (and name+version). <mange>This is particularly useful for substitutes, where you can ask a server "have you already built my-custom-gawk matching this recipe?" and then fetch a pre-built "substitute" rather than building it yourself. <CriticOnPoint>as i understand it: so they are actually used to find proper binary <mange>It's not always a binary, but the "output" of the build, yes. The hash of the recipe is used as part of the key to find the output. This is true of the whole tree, so a change in a core package will change the hashes of everything that recursively depends on it. <CriticOnPoint>but on the level of declaring dependency with name and version i can't guarantee that build output will be consistent (cause i'mnot reffering by hash but by human friendly name and version)? <mange>If you want to fix a specific version of a package you can kind of do that using inferiors/time-machine, but it's a lot more involved. <mange>Generally I don't think you want to do that, though, because you want to get updates if/when your dependencies change. Maybe not in gawk's case (it seems to depend on utf8 locales, libsigsegv, and bash), I'm not sure. <CriticOnPoint>can i use, instead of let's say my-gawk-1.2 use here-goes-hash-my-gawk-1.2 somehow? <mange>No, because the hash is one-way. Knowing the recipe we can easily calculate the hash, but knowing the hash doesn't let us calculate the recipe. <CriticOnPoint>yes, but this is exactly my point, i would refer to very specific receipe of particular hash, when i do only name and version i'm skipping allthe uniqueness of how dependecy was buil <mange>I don't understand the objection. Guix has a library of package definitions that you can refer to by name+version (called a "specification"), or that you can look up by scheme variable name. This means we don't have to inline every definition each time we use it (e.g. instead of writing (package (name "bash") (inputs ...) (arguments ...) ...) each time, we can just say "bash". <mange>If you want to pin something down outside of the library that Guix provides, you can provide your own package definition that is as precise as you want it to be, with whatever dependencies you want it to have. <mange>Guix having a name => package lookup doesn't lose you any power, it just means you can build off the work of other people (and get updates from them, too). <mange>If you want to refer to a very specific recipe of your own then you need to write that recipe and refer to it directly. <mange>I'm probably going to disengage from this conversation pretty soon, though. I feel like we've gone around a few times and aren't making much progress. :) <mange>I'm sorry that I don't understand what you're disappointed by. Maybe you could explain (with some code in a paste?) what you were expecting to be able to do? <CriticOnPoint>nah, it's ok, it seems the underlying principles are a bit different from what i imagined <CriticOnPoint>i've seen this before, not a new concept but great that someone has actually made it <mange>Actually, sorry, Guix doesn't work like that. I misspoke. <CriticOnPoint>i know what you mean but under the hood you are still using names to receipe to locate hash, so it's like dns in the middle <mange>But even in Unison the idea isn't that you actually work with the hashes yourself, the hashes are used to track things under the hood. In Guix we don't need the indirection because we're in one process/address space, so we can just use pointers to rich objects (e.g. package definitions). <mange>But the hashes let us be more precise about the outputs of the builds. <apteryx>is 'GNOME Xorg' still a desktop session I can login into? <apteryx>seen in make check-system TESTS=basic: /run/current-system/profile/etc/profile.d/bash_completion.sh: line 10: shopt: progcomp: invalid shell option name <mange>Sounds like it can't find a usable firewall backend. :) <apoorv569>I just updated my system config recently and it was working fine before updating.. didn't change anything in the config just updated.. <apoorv569>this is from my personal system BTW not the other config I was trying in VM <apteryx>is the inability to change GNOME's theme in our new GNOME 46 caused by #73520? <apteryx>apoorv569: it's been reported already <apoorv569>is this intentional or a bug? do I have to now add some firewall service/package to my system profile? <apteryx>a bug I'd think; at least it should work out of the box <apoorv569>I see.. guess I'll stick with guix system vm then.. I was testing in a VM I created my self because I didn't wanna pollute store with bunch of vm scripts.. <apoorv569>telegram-desktop package fails to build on latest pull <apteryx>apoorv569: reverting commit bd30b8506687d8ada63d163ee21c0b95f659d97a fixes it <apoorv569>what line exactly does this? I don't see anything in the patch that makes sense to me that could cause firewall realted issue <apteryx>it just updated libvirt, to a version that has apparently new unmet requirements <apoorv569>unmet as guix cannot provide that? missing package or something? <apteryx>apoorv569: haven't investigated that part :-) it could be that the original libvirt patch carried from Nix is still useful/needed also <apteryx>hako: I'm investigating the jami test failure with /var/run -> /run. The fact it runs in a container probably has to do with it <apteryx>I think for services dabbling with /var/run in containers, it's best to rewrite these to use /run and share /run/something <hako>so making this change to all documentation, services and tests? <apteryx>I think jami is the only place I've seen things fail <apteryx>so maybe there aren't other cases, but we should look <apteryx>hako: that wasn't enough. there must be an ordering problem in the activation scripts or something <apteryx>I think these run very early and do not care about dependencies <apteryx>so if the jami activation script runs before /run becomes a tmpfs, this would be an issue <hako>needed-for-boot? is set to #t <hako> /run is mounted by initrd, earlier than activation <apteryx>hako: ah, good to know! so that can't be the issue <apteryx>next I'll take a peek in the VM of the %jami-os OS: $(./pre-inst-env guix system vm -e '(@@ (gnu tests telephony) %jami-os)') -nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22 <hako>After seeing #76698, I'm thinking of use invoke instead of primitive-load for activation scripts so that activation environment won't be changed <apteryx`>hako: I've pushed the main change to make /run a tmpfs, but not the symlink /var/run -> /run <apteryx>apoorv569 couldn't revert the upgrade to libvirt, as it broke virt-manager, perhaps others <apteryx>we'll have to figure out the root cause and fix it <hako> /run can't have no-suid I think? <hako>there's /run/privileged/bin <mange>Is there an easy way for me to write a custom fixed-output derivation which has network access, but runs some scheme code to generate the output? <mange>Hmm. Do all fixed-output derivations have network access automatically? If so, that's handy for me! <mange>I'm digging through build.cc and it looks like it, so I'm going to go with that assumption and forge ahead. If I'm wrong, let me know (but I might have already found out by experimentation). <mange>For those of you playing along at home: it worked! It seems that fixed-output derivations automatically have network access. Neat! <attila_lendvai>simple-scan: common/utils.c 245: unable to load library libm.so: /gnu/store/hw6g2kjayxnqi8rwpnmpraalxi0djkxc-glibc-2.39/lib/libm.so: invalid ELF header (it's a text file) <attila_lendvai>same error with xsane. looks like scanning on guix is borked altogether... <apoorv569>apteryx: no worries.. I rolled backed to prev system gen for now. <Rutherther>attila_lendvai: invalid elf header is not very common, that seems like it could be disk corruption <Rutherther>although wait... substituting that path, libm.so really is a text file <apoorv569>only thing that is not working for my server config if wireguard now.. <apoorv569>I have a file in /etc/wireguard/private.key which is my own key not a newly generated one. <cbaines>andreas-e, thanks for looking at the machines, I've finally got around to replying to your emails <apoorv569>is it the `(local-file` for public it doesn't like.. <mange>What do you mean local-file for public? As in you're setting your peer public keys like (public-key (local-file "..."))? If so, I don't think that works. The public-key field has to be a string. <apoorv569>yes it was.. change all public-key to the string.. <mange>If you still want to use a local file you can use something like (with-input-from-file "filename" read-line). <apoorv569>mange: Yes I thought I could place the keys in files and read them.. <andreas-e>cbaines: Thanks, I have replied just now. Will give redeploying with a higher max-parallel-uploads a try. <apoorv569>yea that could work.. but I deleted all files now :/ <apoorv569>actually I'll copy the files back again and try with-input-from-file <apoorv569>with-input-from-file needs absolute path? then it might not work for me.. <apoorv569>I wanna keep files related to config in the config src.. and path can change depend on the system I am. <mange>You can use (current-filename) to get the location of the current file, and presumably you could construct a path from that somehow, but strings are easier. <apoorv569>Yea.. I'll keep it simple.. don't wanna complicate for a simple thing. <apoorv569>like in docker compose you can use container name in another container in the stack to resolve its IP .. doesn't seem to work here. <Rutherther>that is a docker compose thing, not docker thing, that it provides the host file <mange>I don't think you can do that with the "default" or "host" networks, but I think any other network can. <mange>It might be that docker compose is the thing that sets that up, but I *think* docker itself does it on other created networks. <apoorv569>then ATM it is not reproducible as oci-container service doesn't let you create network. <mange>You can create a network with "docker network create $name", but I don't know if there's an easy way to do that in a Guix config. You could add a one-shot shepherd service to do it, and mark it as a requirement for your oci-container-configurations. <apoorv569>I think docker compose does that because it always creates a new network for every stack doesn't use default <apoorv569>it creates like docker_default then starts adding _1 _2 etc for other stacks <apoorv569>one-shot service might do it then I guess for now. <mange>The good news is that this isn't too hard to add to your configuration. You don't need to pull in docker compose, you can just create a docker network and link it up. <mange>Yeah, that's the idea. You could do it with a bit less code using (simple-service 'nginx-proxy-manager-docker-network shepherd-root-service-type (list (shepherd-service ...))). <mange>I would also personally call the shepherd service docker-network-$network-name, but that's just personal preference. <mange>Oh, and actually the start/stop don't look right. For a one-shot service you can just have start be #~(lambda () (system "docker network create npm-guix")), and then you can change stop to destroy the network, too. <apoorv569>why destroy the network? this would mean we have to create network every time service starts? <mange>If I had a service like that, I would expect "herd stop $service" to destroy the network. <mange>It's not necessary, it's just a convenience. <mange>Actually, now that you mention it, I'm not even sure that the "stop" action of a one-shot service can be run. <mange>Your call, depending on how you want it to work. <mange>Classic, yeah. I think Shepherd services run in an empty environment, so you need to be more explicit about things. <flypaper-ultimat>apoorv569: how about (start #$(lambda () (system* #$(file-append docker-cli "/bin/docker") "network" "create" "npm-guix"))) <apoorv569>flypaper-ultimat: yea that's what I was trying to do.. thanks! <apteryx`>odd, Qt 5 insists on having QT_QPA_PLATFORM=wayland even when XDG_SESSION_TYPE=wayland <apoorv569>about the environment in `oci-container-service-type`.. do I hardcode my passwords in the service definition? I don't like that? it cannot read .env files like docker compose so that's out of the way as well.. any suggestions? <apteryx`>hako: I thought /run and /var/run were orthogonal topics other than when we symlink the later to the former? <apteryx`>why would dbus be broken by simply mounting /run as a tmpfs <Ingarrr>Hello, anybody an idea how 'guix home' might break the login-capabilities from a foreign distro? My latest home generation (only difference: a guix pull) sends me into a login-loop (software: lightdm), rolling back from a different tty fixes everything <Ingarrr>any pointers to debug this are appreciated <Rutherther>Ingarrr: so you did ONLY guix pull, no guix home reconfigure or something like that? <Ingarrr>sorry, indeed, I did a 'guix home reconfigure', giving me the broken generation <Ingarrr>and switching forth & back between these generations, gives me the issue or not (reproducably) <Rutherther>Ingarrr: okay, then that makes sense. There are a lot of ways this can happen so it's best to see the error printed out <Ingarrr>Rutherther: There is no error when trying to log in, when entering the password, lightmd just loops back to the same screen after a few seconds. I've identified the issue somewhere between 48f5a66 and 6315f in guix, and a log line (journalctl) which I only see when login fails, is 'Mar 05 14:42:13 thijs-Galago-Pro lightdm[22822]: pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by user "thijs"' <Rutherther>Ingarrr: I don't believe there is no error, that you don't see it doesn't mean it's not there. Try logging as root in tty and switching user (don't forget to use login shell) <apteryx`>guix refresh: warning: downgrading 'libvirt' from 10.10.0 to 10.10.0 oops <Ingarrr>Rutherther: If I log in on a different tty (eg. ctrl+alt+F6, gives me a terminal), then I don't have any issues, it's how I got the logs & how I do 'guix home roll-back'. It's only when using the graphical login, that I get send back to login... Logging in as root is disabled on my system. I'm not sure which logs or errors I can retrieve? <Rutherther>Ingarrr: okay, I thought you couldn't login at all not just through lightdm. Did you try logging into other wms? debugging gui errors like this is usually next to impossible with no error logs and usually is something unexpected in the state (that is if you are using a full fledged DE, if a lightweight WM that usually doesn't happen) <Ingarrr>Rutherther: True, all look around some more about how to get error logs... Although I still find it somewhat strange that a different guix version messes with my display manager. <Rutherther>I wouldn't expect it to mess with the display manager, but with that the display manager is starting, the DE <PotentialUser-4>emacs-next requires webkit2gtk-4.0 2.41.91 but we provide 2.44.1, somebody might want to fix that (not me, i will get instantly rejected because apparently my provided copyright notice isn't good enough for a GNU project?!) <cow_2001>other than writing packages, installing packages, and using `guix home`, what are some other things i could use a side installation of guix for? :| <cow_2001>(going out for a moment to cover a thing with tarpaulin. be back in a bit) <df>it looks like a lot of examples (and the autogenerated operating-system config) use a pattern like (append (list ...) %default-stuff) - is there a reason not to use cons* instead? <ieure>df, Nope, have shifted most of my stuff to `cons*' and appreciate the shallower nesting. <unmush>easier to change things around or introduce another list with append, more obvious what it does <df>ok, but when most stuff is literally following the above pattern I think cons* is clearer, and I could always change back to append if things get more complex <unmush>also many people, whether we like it or not, don't know or care that lisp uses single-link nodes for constructing lists; many other programming languages use "lists" that are actually dynamic arrays. <df>that page claims that %base-services contains an instance of mcron-service-type... <df>based on examining the source, looking at the var in the repl, and looking at herd on a running system, I disagree <df>who's wrong, me or the doc? :D <df>I still haven't really got my head around service extensions, so I could be missing something - for example, something like package-database-service-type appears to implicitly add an mcron-service-type <df>which I assume would not be duplicated if you then added a file-database-service-type instance as well <wakyct>I feel like the cookbook may not be up to date for some articles <wakyct>cow_2001 what is a 'side installation' of Guix? <df>yeah, in theory the manual is more likely to be up to date because it's the devel version built (presumably) from the latest source <Rutherther>df: it extends the service. It's right that the service can be added if it isn't in services already, but if it is, no second instance is added, just the existing instance is extended - meaning the extend function is called with original argument and new argument returned by the function in extensions <Rutherther>if this happens, the default config will be extended <df>Rutherther: ok, so it'll add it if it's not already there? <gerogaga>Is there a log kept somewhere for guix pull errors? I'm trying to pull from the emacs-team branch (and downgrade) but it fails to build a package cache and doesn't give me a log location. <df>I'm also a bit confused by the need for simple-service when the two -database-service-types mentioned just call service-type directly, but I think this is because I don't fully understand guix-style structs yet <Rutherther>gerogaga: the log should be findable even if it doesn't tell you the location, you just need to know the derivation it is trying to build, then the log is in /var/log/guix/drvs/{first two letters of hash}/{rest of the name - without the first two letters} <df>oh... I guess simple-service creates both a service-type and a service in one shot <gerogaga>I'd only recommend using simple-service for things you don't plan to reuse. <Rutherther>df: simple-service creates a service that will extend the service you give it as an argument. So you can put in multiple simple-services extending the same service. You can't put multiple service entries with the same service type, so you won't be able to do the other way multiple times. That being said, sometimes you need the second way because not all services support extending every part of their config <Ingarrr>I have gnucash installed in 'guix home', which needs ~/.guix-home/profile/lib/gio/modules/libdconfsettings.so. <Ingarrr>But apparently, my desktop environment of my foreign distro is now also depending on the version in .guix-home/, instead of the global version in /usr/lib/, probably because the .guix-home/ version is mentioned first in a search path or other env-var. <Ingarrr>Does anyone know how to fix this? Because this makes it impossible to update to the latest guix commit, because of breaking changes, crashing my DE. <Rutherther>Ingarrr: as a workaround, use gnucash out of a guix shell without installing it. As a long term solution, hard to say, probably will be easiest to wait for this https://lists.gnu.org/archive/html/info-guix/2025-02/msg00002.html. You could try prepending /usr/lib to the respective search paths, but that will probably break gnucash instead. Another local fix would be to make a separate package that will launch gnucash with the env vars from a wrapper... <Rutherther>... instead of putting them to the guix-home profile. <Ingarrr>Thanks for the options! Was searching way too long on this, appreciate it <anemofilia>Is anyone else experiencing strange behaviour in the hackage importer? <anemofilia>Just did a "guix import hackage -r stack" and got back a "Syntax error: unexpected end of input <anemofilia>Guess I'll have to write a cabal2guix at some point <Rutherther>"guix import hackage -r stack@3.3.1" works. It's only the 9.9.9 version that doesn't work <arjan>since updating to shepherd 1.0.2 the DISPLAY environment variable set by the home x11-display service seems to be unavailable for my other home shepherd services, could this be a regression? <Kimapr>i have just tried to send a patch by email but it seems to not have arrived <Rutherther>Kimapr: if it's your first, it can take longer time. Also possible someone will have to accept it (to prevent spams) <tschilp>Hi guix! I'm enjoying the fresh gnome 46 very much, but noticed that since I updated system and home to f3064b765a5bbbff72bf2fd0e5fa6ecc4b1136f0 yesterday, the screenshot/screenrecord functionality stopped working (the one you can call by pressing 'Print' on the keyboard, on wayland and xorg). I had this earlier, and adding ~(service home-dbus-service-type)~ and ~(service home-pipewire-service-type)~ to my home config fixed it at a <tschilp>point. Now the utility comes up, but the video button does not appear and the 'normal' photo button is not clickable. Have there changed dependencies with the new ~%base-home-services~? Any ideas how to debug? <sneek>Welcome back tschilp, you have 1 message! <sneek>tschilp, ieure says: I pushed a fix for pantalaimon, someone had sent a patch around a week ago. <Kimapr>Rutherther: i see, and yeah it is my first time i've ever sent a patch by email so i might have messed up at least several things <tschilp>ieure: thanks for the note about pantalaimon -- I haven't been around for a while and just read it ;) Will be trying soon! <Rutherther>Kimapr: as long as you've sent an e-mail to guix-patches@gnu.org, it should arrive sooner or later <ieure>tschilp, Cool, hope it works for you. <ieure>tschilp, Nice! Thanks for reporting back. <dariqq>and if not it is probably worth reporting <civodul>sneek: later tell apteryx i can reproduce the hang when running ‘eudev --debug’ but i have no idea why it happens; my reading of eudev is that it causes it to log to /dev/console <PotentialUser-4>ieure, on webkitgtk: could've made it more clear your statement was more sarcastic so you wouldnt've gotten my hopes up checking the patch mailing list :P <ieure>PotentialUser-4, If you have a bug report, please email your report to bug-guix@gnu.org. <ieure>PotentialUser-4, I wasn't being sarcastic, I was befuddled that you'd drop a bug report in here and then immediately quit. <PotentialUser-4>i do not have a bug report, i have patches to submit but i unfortunately cannot, because maintainers have previously rejected me because of insufficient information in copyright notice <ieure>PotentialUser-4, Guix doesn't require any of that. <ieure>Feel free to send your patches. <PotentialUser-4>well that's strange, because a maintainer closed a patch because of that. <PotentialUser-4>think the email was sent to me privately (??? at least not on the mailing list frontend) but i can go fetch it from the pile of mails i have <Rutherther>the e-mails sent to debbugs aren't really on a mailing list <ieure>PotentialUser-4, I'm wondering if we're talking about different things. Most GNU software requires you to assign copyright to the FSF and have your employer sign a waiver of rights (if you work as a programmer). Guix does not require that. <Rutherther>ieure: employer? like if one was working on guix in their job? <ieure>Rutherther, No, if you work as a programmer at all. <Rutherther>so even if you work on FSF sw in free time, employer has to sign a waiver of rights? <ieure>I sent a patch to EMMS which couldn't get accepted because my employer wouldn't sign the waiver. I ended up rewriting it from scratch while I was in between jobs, nearly two years later. <PotentialUser-4>actually no, seems like there was a misunderstanding on the maintainer's part (i think, after rereading that specific email), all good, i'll go send a patch myself then <Rutherther>ieure: so you had to rerwite it because the first one was treated as sort of having (at least partial) copyright ownership by your employer? <ieure>Rutherther, I don't believe they actually did have a claom, nor do I think they'd ever attempt one, but the FSF guidelines want free & clear ownership, and won't deal with even the potential of another claim. <Rutherther>ieure: yeah I would also think that your company cannot have any claim if you don't work on it at work time <tschilp>dariqq: yes I recall, it was you, who helped me getting this going :) Could you point me in the right direction how I would check for ~#$gnome-shell /share/gnome-shell/org.gnome.Shell.Screencast~? <ieure>Rutherther, I agree, however, it's standard language in employment contracts for basically every US company. <ieure>Rutherther, In the days when you signed a piece of paper, I'd cross it out, initial, and sign. None of the electronic systems everyone uses now let you do that. <Rutherther>ieure: sorry, I don't understand, what's standard language in those contracts? <ieure>Rutherther, Giving the employer ownership of anything you produce during the term of employment. <dariqq>tschilp: if you are using gnome46 right now it should be at /run/current-system/profile/share/gnome-shell/org.gnome.Shell.Screencast . the file should start with some very ugly javascript to set environment variables <Rutherther>oh really? okay... well that definitely crosses US out of the countries I would consider moving to :) <dariqq>( i dont have a usable guix near me rn to check myslef) <ieure>Rutherther, Surprised that even makes the list given where this place is right now. <Rutherther>tschilp: btw have you updated guix home as well, or just guix system? <tschilp>So 2 reconfigures (I actually had a little parentheses battle to get ~%base-home-services~ into the right place) <tschilp>dariqq: I'm just reconfiguring again, but I can't recall any strange messages from yesterday/the day before yesterday <dariqq>tschilp: it wont change anything. Something seems wrong with the gnome-shell package definition. I'll investigate tomorrow <tschilp>dariqq: you are right, it still looks the same. Cool! <tschilp>Maybe somehow connected -- if I click the 'Extensions' App, it does not show anything but a 'Something went wrong -- we are very sorry, we could not create a list of installed applications. Make sure, that you are logged into GNOME and then try again' (roughly translated from German ;)) <dariqq>tschilp: the extensions app probably has the same problem <dariqq>sneek later tell tschilp: There was a commit earlier today to fix this c695de0d04f16c2f21d2386823b3c2a3ad2f7517 <apoorv569>should I put coturn in gnu packages networking? <mra>howdy! is there a "standard" for how long it's polite to wait before bumping a patch that i'm waiting for review on? <mra>I'm still waiting for someone to take a look at the patch I sent to 41602, but I don't want to muddy up the mailing list unnecessarily <ieure>mra, Not really, use your judgement. <ieure>I understand that's an unsatisfying answer. <mra>ieure: all good! i just don't want to be a bother <divya>ieure: ekaitz: If I'm updating the version of a patch submitted by someone else, can I also review that patch, or do I have to review it by someone else? The patch is quite old, so not sure if the original submitter would still be around. <lilyp>divya: it is understood that your modification counts as review, but someone still has to review your code ;) <reyman>I search info about conda into guix, this include miniforge ? or miniforge need to be installed from scratch using installer ? <divya>Okay lilyp, understood. I found someone else to review it, if any of you committers are around, we'd like you to take a look as well. <divya>It's been a while since it has been under the rug. <PotentialUser47>is it possible to define a new package in a manifest.scm file? It seems to work if I use packages->manifest but fails when I use specifications->manifest. I have to use specifications->manifest since I need to pin a specific version of another package with the @ver syntax <Rutherther>PotentialUser47: no you don't need to use specifications->manifest for this new package. Just make two manifests and contatenate them with concatenate-manifests. And no, you cannot use specifications in a manifest, because specifications are loaded from modules from load path, the path your manifest is in is not inside a load path, and manifest is not a module <Rutherther>s/you cannot use specifications/you cannot refer to packages from manifest via specifications/ <Rutherther>also you don't need specifications even for the other package, you can always refer to the symbol that holds the package with that version. Specifications are just a convenience, they don't open up more possibilities <jfred>Hmm. I just noticed that "guix shell" sets GUIX_ENVIRONMENT to the profile dir but "guix shell --search-paths" doesn't include GUIX_ENVIRONMENT as one of the variables to set. Is there any convenient way to get the profile dir when using "--search-paths"? <lilyp>jfred: I don't think you'd need this, but you can run `guix shell … -- sh -c 'echo $GUIX_ENVIRONMENT'` <jfred>ahh good point, yeah that should work <Rutherther>and then a one liner to get the search paths as well: " guix shell ... -- sh -c 'echo export GUIX_ENVIRONMENT=$GUIX_ENVIRONMENT; cat $GUIX_ENVIRONMENT/etc/profile'" <potatoespotatoes>Hi all -- does anyone know how to add a package into the kernel to be loaded as a kernel module? Do I need to do anything special? <vagrantc>potatoespotatoes: there are a number of out of tree kernel modules in guix, i think you want to look at the packages in gnu/packages/linux.scm that use linux-module-build-system ...