<nckx>I ask because I'm stuck at 1.2 GHz and even an automated ‘run’ won't be much fun 😛
<attila_lendvai>nckx, civodul: thanks! i think i'll just pick a number for now, and set it as default for uid in the config to keep it stable. later on, when a stable mapping is added, the default can be deleted.
<nckx>It'll use CPU cycles I now sorely need to… switch browser… tabs… and stuff.
<nckx>Assuming f3b64ad54ed7067094d752921f85341cdc0722fe is ‘good’ and 37186ec462dc574477af195aa07fea3fe1ed07a2 is ‘bad’ you can tell git bisect this, and then use ‘git bisect run’ to invoke ./pre-inst-env guix build gajim, roughly. You might need a bit more but that's the gist.
<nckx>raghavgururajan: Gajim builds fine here on commit 37186ec462dc574477af195aa07fea3fe1ed07a2.
<nckx>raghavgururajan: Please share the .drv file name that fails to build.
<dissent>hey guix. could someone help me find information about adding substitutes to the package definition?
<zamfofex>dissent: You mean to packages in a different channel?
<zamfofex>I don’t think substitutes are part of a package definition, by the way.
<dissent>zamfofex: how to say... substitute for... redirecting comands?
<dissent>for packages that point to the FHS that isn't there in guix.
<dissent>this can be found in `(modify-phases...)`
<zamfofex>Ah. It depends, I think. It might make sense to patch the source, or to create a symlink or dummy file of some kind. Maybe even just setting up the correct build flags or environment variables is sometimes enough.
<zamfofex>dissent: If you can give more details about your case, I might be able to help.
<bae>I'm interested in running Guix when I get a new computer. Do I need to make sure to buy hardware that is compatible with Guix?
<acrow>While trying to build something I need to verify that libgconf-2.so.4 is present. How should I approach that?
<acrow>bae: the answer is obviously, yes. What more specifically are you concerned about?
<acrow>In my experience most generic hardware will work more or less well. With the exception of wifi which will almost certainly be a problem with newer commodity machines.
<acrow>My experience is not very great. Others may be able to provide more concise guidance. Good luck. Guix is worth the extra effort.
<acrow>bae: One additional point. HW is an issue if you want to run GuixSD but I think you can almost entirely avoid the problems by using either a virtual machine or just deploying it on a foreign distribution. GuixSD is fun though.
<acrow>Duh!, well maybe he will come back. I guess I have that effect on people. :(
<cehteh>when i want to remove some huge subtree i usually mv subtree .subtree.delete; rm -rf .subtree.delete & ... (from C/Rust whatever, just example) overall the deletion will still take its time but progress in the background and if done right this is atomic and wont collide with other things that access the original dir
<cehteh>may even queue/batch such delete processes instead starting them parallel
<rekado_>there are only 47395 directories in /gnu/store/trash
<cehteh>deletion can take extremely long time on some filesystems/access patterns
<cehteh>and having concurrent IO, possibly multiple delete jobs in parallel wont improve it
<cehteh>would be nice if someone package that for guix
<mbakke>nftables is not too bad IMO ... not quite PF though :)
<attila_lendvai>i didn't think this through, but i was hoping that there was a well-known firewall service enabled by default, and my service could offer a config to automatically open the relevant ports on it. but that won't work for obvious reasons.
<abrenon>I noticed that I didn't get into the same environment (as in, different id in /gnu/store) by running guix shell with the packages names and by storing those packages in the manifest and running guix shell alone
<attila_lendvai>civodul, the problem is that the system doesn't know which directories the service is writing to. i guess it can try to be smart and cover most cases by chown'ing the usual dirs
<vivien>On core-updates-frozen, I can’t start nautilus. Using the terminal, I get: GVFS-WARNING **: 12:43:02.509: The peer-to-peer connection failed: Timeout was reached. Falling back to the session bus. Your application is probably missing --filesystem=xdg-run/gvfsd privileges.
<vivien>The wierd thing is, when I reconfigure my home, it works again until I reboot.
<minikN>Hello, is there an easy way to add additional values to /etc/bluetooth/main.conf when using bluetooth-service?
<abrenon>civodul: it's not that important, I don't have any specific need to understand this difference, I was just curious if there was an obvious reason for it I had missed in my understanding of how profiles were built
<civodul>abrenon: in general it's possible to obtain the same result from the command line and with a manifest, but there could be things like package spec resolution that explain differences
<rekado_>so, uhm, could we stop it and then time a plain rm -rf /gnu/store/trash?
<kwjc>hey, so I've been playing a game called old school runescape using the FOSS client RuneLite. I've had really shoddy performance in the past. Typically the game would run fine, then magically drop down to single digit frames per second for up to 10 seconds at a time. There was at one point, where the game ran perfectly. Some combination of guix system updates, and openjdk update.
<civodul>rekado_: i don't think so; problem is that i think this "rm -rf" is optimal
<civodul>like when you strace it, there's no waste
<kwjc>but after doing a 'guix pull' and 'guix package -u' it went back to that broken state. right now it is running perfectly again. However, I hesitate to update my system because it could go back to that unplayable state.
<kwjc>is there some way to update my guix system to get the latest security update without affecting openjdk?
<kwjc>nvm I suppose 'guix package --upgrade . --do-not-upgrade' will more than likely do the trick
<rekado_>kwjc: you can also specify this particular openjdk variant in a manifest
<kwjc>thanks rekado_! i'll definitely be looking into that
<constfun>hello, how can I test the core-updates-frozen branch against live hardware? i've tried various permutations of guix time-machine/pre-inst-env etc and nothing seems to succeed when running system reconfigure.
*nckx .oO …maybe because there isn't an RPC to do so.
<jpoiret>constfun: what do you mean that it doesn't seem to succeed?
<nckx>constfun: Time-machine should do it if you don't have any extra channels. What exactly do you run and what goes wrong?
<constfun>i do have extra channels, thats part of the issue im sure
<jpoiret>you can test core-updates-frozen by `guix pull -p ~/.guix-cuf -b core-updates-frozen` and then use `~/.guix-cuf/bin/guix system reconfigure`
<jpoiret>constfun: then, you should look into using a channels.scm file that modifies the default guix channel
<constfun>jpoiret: ah thank you, I'll try these things
<jpoiret>then you can use `guix pull -p .guix-cuf -C channels.scm` if you want to keep it contained in a separate guix profile
<nckx>constfun: As more building blocks to play with, you can use file:// URLs in channels, and you might need to use --disable-authentication if you check out one without setting up the keyring branch (which is a bit tedious when just testing something).
<nckx>In case you need to patch actual packages/code to work with c-u-f.
<bricewge>nckx: Ah... Now its behavior makes sense
<attila_lendvai>how can i get "error: connect: /var/run/shepherd/socket: No such file or directory"? the dir is empty. the only unusual thing is that it's in a VM that got suspended with my laptop, and its time jumped.
<constfun>nickx: thank you, i was trying both these things too, but `sudo guix time-machine --url=/local/path --channels=.config/channels.scm --disable-authentication -- system reconfigure /etc/config.scm` failed with an exception (i can gather details if that would be instrumental). my system requires newer core-packages (so is my theory) so my first
<constfun>attempt was to patch guix (first using local url, then pushing up to a channel to replace default-channels etc), then I realized that core-updates already has everything that i need...
<constfun>nckx: thank you, i was trying both these things too, but `sudo guix time-machine --url=/local/path --channels=.config/channels.scm --disable-authentication -- system reconfigure /etc/config.scm` failed with an exception (i can gather details if that would be instrumental). my system requires newer core-packages (so is my theory) so my first attempt
<constfun>was to patch guix (first using local url, then pushing up to a channel to replace default-channels etc), then I realized that core-updates already has everything that i need...
<nckx>People mistype it so often I think my brain just greps for ‘n...’ with 2 or more of [ckx] because I didn't notice the typo.
<jpoiret>attila_lendvai: sometimes it takes a bit of time for shepherd to initialize its socket
<nckx>constfun: Right, I don't think there's much we can do without some specific errors. Also, if you're using any unsupported channels that will complicate matters. You won't be denied help just because you use them or other such nonsense, but we can hardly dive deep into debugging them either.
<cybersyn>hiya guix, I've noticed that typically (rnrs io ports) is used instead of, say, (ice-9 whatever-ports). are the former the preferable way to do io in guile?
<attila_lendvai>cybersyn, generally it's always better to use standard libs when it doesn't matter
<attila_lendvai>jpoiret, i'm seeing it again. i think it's due to some errors in the service start scripts that shepherd doesn't tolerate well.
<zamfofex>kwjc: I’ve been trying to use the Hurd for over a year now. Unfortunately, I can’t seem to get networking functional in my hardware. I’m not sure what the problem is, unfortunately. See: https://issues.guix.gnu.org/51770
<cybersyn>attila_lendavi: its confusing to me because the rnrs documentation is in the r6rs section of the manual, so my intuition would tell to stay away from r6rs unless I plan on working with some r6rs libraries. the docs also appear to confirm this: "These R6RS libraries are mostly useful to users who want to port their code to other R6RS systems."
<civodul>so i'm now running 3 "rm" processes in parallel, just to see
<rekado_>civodul: re rsync: something about first obtaining a list of files to delete in order
<civodul>rekado_: as opposed to interleaved scandir/unlink?
<cehteh>you may really implement what i saied earlier, making deletion a background job detached and not locking anything
<cehteh>civodul: *few* rm processes may speed things up but not significantly and there is a good chance that this causes even more seeking and get far less things done
<cehteh>i may have an idea how things could be freed most efficiently, but that would need a lot work: 1st pass walk all dirs to be deleted, store inode/num_links/size for each item; then 2nd pass sort by size and prioritize the files where all hardlinks are to be deleted
<cehteh>aka first free the biggiest files which will really free disk space, everything else is just metadata and wont free much space while needing lots of turnarounds
<cehteh>esp files which have hardlinks out of the to-be-deleted set wont free anything noticeable
<cehteh>.. proof of concept: find /gnu/store/trash -printf "%s %i %n %p\n" | sort -rn | less got the idea?
<roptat>I can try to send a message to guix-devel later, see if anyone is interested. Can we get the guix-days@ alias running again?
<roptat>I think the plan would be to have two days on a bbb instance (we'll have to find someone who's willing to host us), before or after fosdem (that's not clear)
<roptat>if I remember from previous years, we always had a few talks, and a lot of free discussions on topics that popped up during the day, so we could ask for a few talk proposals, prepare a few discussion sessions and go unprepared for the rest of the event ^^
<roptat>ok, let's wait for people to express interest
<civodul>i also really enjoyed the talks about people's projects last year
<roptat>me too, I think we should have some talks like that this year too
<roptat>we could have a slightly different format. I like the idea of prerecorded talks, but I took part in a conf where they had that *and* a 5-minute presentation before the Q&A for everyone to remember the main points of the talk
<civodul>ah sure, i guess a live executive summary can't hurt
<roptat>ok, I'll send a message to guix-devel with some details, and we can all discuss them
<roptat>I think we should start advertising the event soon
<roptat>so people have time to prepare talks if they want to, etc
<roptat>ideally, talks are released one week before the event (I can still use my server to host them this year, until we find a more suitable long-term storage)
<constfun>nckx: jpoiret: thank you both for the help, definitely learned a better way to do things. indeed the main problem was my extra channel, but it turns out they also have a core-updates channel that fixes the incompatibilities. now i can run my favorite distro on the new hardware, very happy here. what mailing list do I watch to know when
<Zambyte>Hi, I'm trying to create a guix.scm file for a package, but it requires setuid. I have found the info in the manual on adding setuid to programs using the system configuration; is there a way I can do this interactively from the guix repl? I am using guix on a foreign distro right now, so I don't think making a system config to add this package is ideal for me right now
<Zambyte>Alternatively, maybe they is/could be a way to do something like `sudo guix build -f ./guix.scm` to allow for the package to be built with setuid
<roptat>you could have outdated and vulnerable setuid binaries in the store
<roptat>singpolyma, it's not setuid in the store; it gets setuid after it is copied to a special directory, so only that version is setuid, not the gazillion previous versions that are still sitting in the store waiting to be attacked :)
<roptat>and that's done with the setuid-programs of your operating-system configuration
<singpolyma>roptat: ah, so there's like a post install script basically?
<roptat>it's not postinstall, it's a special service in the system config, that's why you can't get setuid on foreign distros
<tex_milan>roptat: installed package foo that depends on nss-certs with guix install, some time left, run guix pull, everythink is up to date, add the package to guix home and run guix home reconfigure and it tries to rebuild nss-certs. I would not notice but building nss-certs takes ages mostly because it runs its tests.
<tex_milan>roptat: sorry I said nix but it should have been guix
<roptat>tex_milan, ok. to me it sounds like nss-certs was updated with guix pull?
<nckx>Including services, which is why it might build packages that you didn't add to (packages …), even transitively.
<tex_milan>So guix system reconfigure and guix home reconfigure do upgrade packages, but guix pull just updates guix, and guix upgrade upgrades packages in default profile unless told wht profile to update
<opalvaults>Is there anyone who has gotten sof-firmware working on guix? It's the last thing that's not working on my X1 thinkpad (I bought a wifi usb dongle) but it doesnt' appear that linux-libre/guix allows sof-firmware?
<opalvaults>Here's a link detailing that the folks at linux libre said it's g2g?
<GNUtoo>In that case someone probably needs to send patches to add a package for it in Guix
<nckx>unmatched-paren: Well, in a way, but it does a lot more (authentication, building). I'd compare it to ‘apt-get update’ (or is it upgrade? well, one of those) rather than git at a high level.
<opalvaults>I could be misunderstsanding. Would really appreciate any advice. I want to use this distro but all of my hardware is a bit modern. willing to go the extra mile with usb dongles and such, but I can't do anything about the sound-card
<nckx>You mean the wording? Because I do think the paradigm makes sense.
<opalvaults>Up to now they've also been blocking the Sound Open Firmware (SoF) support only now to realize that in fact Intel's open-source DSP/sound platform does meet their requirements. Sound Open Firmware was announced last year for providing more open-source firmware and is being used by all new/future Google Chromebooks. With Linux 5.2 there was a big
<opalvaults>SoF addition and now that's cleared for working in the GNU Linux-libre 5.2 kernel.
<nckx>Unless you specify a custom kernel version in your system configuration, simply running ‘guix pull’ followed by ‘guix system reconfigure <your system.scm>’ will upgrade your entire system, including the kernel.
<opalvaults>reminds me of podman defaults to user space containers
<unmatched-paren>as in: near immunity to dependency hell, configurable with scheme, shutdowns during updates won't break everything, you can submit packages really easily, etc etc :)
<nckx>Well, it's not really for security, and it might not be ‘moar secure’. GNU doesn't really fetishise security as much as some other distros. It's important, but it's not the reason for everything.
<nckx>They aren't isolated containers, just symlinks on the regular file system.
<unmatched-paren>also guix's grub provides an option to rollback your packages and configuration, which has saved me several times
<opalvaults>sorry, i miscommunicated, i just meant that the default user space level concept when it comes to package installation is fairly similar to a lot of good habits coming out of other distributions.
<nckx>What it does give you is low-overhead package dependency isolation (not against determined human attackers).
<vivien>Dependency hell is not an easy thing to get rid of. See libsoup in core-updates-frozen.
<opalvaults>nckx, what does it mean to fetishise security? if you don't mind me asking. That it's not GNU's main focus when creating a free software distro?
<unmatched-paren>i guess if your computer is running any gnu/linux at all it's automatically many times more secure than most (e.g. windows) computers; although more security is always good, sometimes i do feel that people are excessively paranoid
<roptat>we still have many packages with CVEs, and we just don't notice...
<roptat>I don't think we can claim security in that sense :p
<nckx>Good question. It was quite off-the-cuff. We do take security seriously! But we're not interested in creating a locked down system, which is very much the direction ‘the industry’ is taking. Such a system is by definition ‘more secure’ by some definitions, but it's not one GNU seems interested in making. And I'm glad of it.
<unmatched-paren>take qubes. from what i've heard it runs a ton of VMs to isolate everything :P
<lilyp>On the notion of "more secure = better", people invent whole programming languages on some notion of "security" only for programs written in it to still churn out CVEs.
<nckx>I'm not really talking about ‘CVE’s here, that's just… yeah, we need more people to fix more of those ☺
<opalvaults>I think it depends, but I generally agree with you unmatched-paren. I think a great habit is user-level package isolation and separation from system configuration. It creates a pseudo-immutability that I think that even Fedora is starting to take notice with their weird distro.
<roptat>(just noticed we have *all* CVEs listed for log4j :p)
<cehteh>rekado_: i just write some notes down and push it to github
<lilyp>and even then, you can get vms and containers for free in Guix :)
<nckx>I mean, ‘security’ is often an abuse of ‘freedom’ everywere else; computing isn't immune from that. But I drift.
<opalvaults>nckx, really interesting! thanks for your input. What do you think of systemd-homed and home encryption on boot? Is that something that GUIX would be able to achieve? I really do appreciate encryption, and good security practices. I'm unsure what counts as fetishising :P
<nckx>Qubes is great, I just wish I didn't have to give up Guix. Someone smash them together & make them kiss, thx.
<cehteh>rekado_: #+TITLE: rmrfd: The Data Incinerator :)
<nckx>FTR I don't think so either opalvaults. I haven't used systemd(-homed) so it wouldn't be fair to have an opinion. On the surface, it doesn't seem like a bad idea.
<opalvaults>if anyone is interested: systemd-homed(8) is a systemd service providing portable human-user accounts that are not dependent on current system configuration.
<opalvaults>It achieves portability by moving all user-related information into a storage medium, optionally encrypted, and creating an ~/.identity file that contains signed information about the user, password, what groups they belong to, UID/GID and other information that would typically be scattered over multiple files in /.
<opalvaults>This approach allows not only for a home directory portability, but also provides security by automatically managing a home directory encryption on login and locking it if the system is suspended.
<unmatched-paren>yeah (see the eudev and elogind efforts to extract udev and logind from systemd)
<opalvaults>dang. if it's not one thing it's another. Okay does anyone have any advice on how to fix error: symlink: Permission Denied "/var/guix/profiles/system-2-link.new" when doing an guix pull reconfigure /etc/config.scm?
<florhizome[m]>i think the argument about creating unnecessary dependence and monoculture is pretty valid. and i really like guix approach better - just wrap everything in guile ;) i don't think it's evil though but esp. for guix i would like for as many independent solutions to exist
<unmatched-paren>obviously, it won't stop destructive filesystem changes, but your packages are 100% recoverable
<unmatched-paren>opalvaults: also, the system doesn't upgrade in the "watch your system slowly break down as we replace a bunch of critical system files!" way that others do; it creates a new generation, loads the stuff in there and then switches to it at the last moment
<unmatched-paren>that way, if an upgrade fails or your computer shuts down while the update is going, everything will be fine because you're still on the old generation
<opalvaults>That's a dream coming from more bleeding edge distros. That's really, really cool. Thanks for the info! :)
<unmatched-paren>of course, most of this works the same in nix; guix is basically a better, 100% free software nix fork
<opalvaults>that's the sticking point for me. 100% free software done in scheme no less
<unmatched-paren>yes, guix can be as bleeding edge as it want because of these things
<vivien>You should still watch out for grub though, I’m not sure grub install is atomic
<lilyp>power outage can still hurt your guix, though
<unmatched-paren>if the worst does happen, you can still do an old-fashioned live usb chroot to recover it, right?