<nckx>raghavgururajan: You there? <nckx>sneek: later tell raghavgururajan <Regarding commit f3b64ad, the check phase fails> Afraid I have no idea what you're talking about. <attila_lendvai>nckx, that's quite unfortunate. is this planned, or on some TODO? *attila_lendvai can't find anything in the issue tracker <nckx>I think it's occurred to everyone that it's something we eventually want, but no, I don't think so. <attila_lendvai>how come services that have state in e.g. /var/lib don't break down regularly when someone changes their config? <nckx>For Guix service groups/users, an explicit central registry would be better than a cache. For user-supplied names, I think it's fine (better, even) to always require explicit numbers. <nckx>So I should revise my answer to ‘cache no, but something, yes’. 😛 <attila_lendvai>yeah, 'cache' is not the right term here, but i wanted to remain concise <nckx>No idea attila_lendvai. Removing a service just isn't that commen. <apteryx>civodul: oh, sorry, I'm just getting back to it, haven't caught up with mails yes :-) <civodul>attila_lendvai: see (gnu build accounts) for the UID/GID allocation mechanism <raghavgururajan>nckx: Hey o/. Seems like the custom phase that was removed, is still required. <sneek>Welcome back raghavgururajan, you have 1 message! <sneek>raghavgururajan, nckx says: <Regarding commit f3b64ad, the check phase fails> Afraid I have no idea what you're talking about. <nckx>Are you sure you're on the right commit? <nckx>guix time-machine --commit=f3b64ad54ed7067094d752921f85341cdc0722fe -- build gajim ? <nckx>…is what I'd have run if time-machine worked here, but I can build gajim@1.3.3 from git just fine too. <nckx>Are you comfortable with git bisect? <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>I could SSH into berlin but I think it's decided to dedicate its time exclusively to it's new hobby, collecting garbage. <attila_lendvai>err... except that my service generates n users and groups. it'll be a hack... but not today. gn! o/ <nckx>raghavgururajan: It's a way to most efficiently (and often automatically) answer ‘which commit between A and B changed behaviour X?’ <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>the_tubular: It's certainly spotless now! <nckx>Make sure to try f3b64ad54ed7067094d752921f85341cdc0722fe on your machine first. <nckx>It could always be non-deterministic. <nckx>3 successful test runs on f3b64ad. <nckx>Oh, x86_64, 8 cores by the way. <nckx>raghavgururajan: You'll have to rebuild Guix between each invocation because some ABI mismatches were introduced. *raghavgururajan gotta run some errands <nckx>Heh: * burst[m] has quit (Quit: Client limit exceeded: 20000) <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. <zamfofex>dissent: If I download that file, I can run `bash fff` and it seems to just work. ***jonsger1 is now known as jonsger
<dissent>zamfofex: indeed. i guess the next question is, will all of the functions also work? <zamfofex>dissent: If `fff` invokes executables in a PATH‐relative way, then users will have to install those dependencies themselves, unless you add them to the propagated inputs of the package. <zamfofex>It seems nontrivial to patch the occurrences in the Bash script to make them point to the absolute paths in the store. <zamfofex>You could use patches or snippets for it, but you should be careful to avoid also replacing things that aren’t meant to be command names. <zamfofex>Like, with `file`, if you just replace it with a snippet, it’s possible that the script contains variables with that name. <nckx>You also forgot a ‘fucking’ 😉 <nckx>I mean really! Basically trivial! <nckx>(Also happened to notice a typo, ‘its’.) <dissent>back to my original question... is there information about conjuring such magic in the reference manual/cookbook? <nckx>zamfofex: There's another option, wrapping, but it would modify $PATH by design which is problematic in scripts that themselves act as a user shell — which fff does. <nckx>I don't recommend recommending propagation, it's quite nasty to deal with the conflicts it inevitably causes. <apteryx>by the way, I do not get fancy video mode loading in GRUB (that's nothing new) -- on a desktop using the nouveau driver. Is this expected? <apteryx>it's just the old ncurses-like blue on black <apteryx>compared to a nice Guixy background on other laptops equipped with Intel GPUs. <apteryx>what, now: error: file '/@root/boot/grub/i386-pc/terminal.mod' not found <apteryx>is there a way to scrollback in grub rescue? <nckx>and I doubt $pager exists there either. <apteryx>hmm. Seems I managed to get grub-install to write weird things under /boot/grub <apteryx>there are lots of files but many of them appear suffixed by ~ <apteryx>the system hard locked following reconfigure, I guess that did it <apteryx>I've been having these locks after attempting to enable DBUS_VERBOSE, it seems. <apteryx>i'll need to boot on some other medium and find the commands on guix-devel to chroot, then reconfigure from there <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. :( <apteryx>nckx: I don't recall :-/. Now I managed to dd the latest iso to some stick (it took a lot of time to download) <apteryx>the key is sourcing a profile from under your user /var/guix/per-user/$user/etc/profile in the chroot and starting a daemon <nckx>raghavgururajan: Are we running a different number of tests? *apteryx finally reconfigured the thing from the chroot to fix GRUB... way to kill what could have been a productive evening ***Xenguy_ is now known as Xenguy
<apteryx>acrow: you answered well! I have the same experience as you <apteryx>(Guix System working on most hardware, with the usual gotcha: wifi, and perhaps GPU if you are on a desktop and using modern GPUs) <nckx>It's odd but I'm not really in the mood to waste more time on its oddness. *apteryx wonders how much time they have before DBUS_VERBOSE=1 fills the HD with logs <apteryx>nckx: restarting elogind is the thing that likes to hard lock the machine (kernel panic) <raghavgururajan>nckx: `guix time-machine --commit=f3b64ad54ed7067094d752921f85341cdc0722fe -- build gajim` works. <opalvaults>Running a newer thinkpad, has anyone run into getting 'Dummy Output' in the sound settings? <opalvaults>I seem to remember this being a problem last time I booted Guix on this computer but I can't remember how I fixed it. <opalvaults>running guix environment --ad-hoc alsa-utils and then alsamixer shows sound as okay <tex_milan>opalvaults: I have T14s rev1 AMD and no problems with sound. But must run on vanilla Linux. <opalvaults>tex_milan, good to hear it's not just me. I don't want to run the non libre linux kernel however. hoping there's a fix. <tex_milan>opalvaults: well on my laptop libre linux hungs up during boot... <opalvaults>It looks like it's not picking up my sound card. In Alsamixer it doesn't show any sound cards/chips <opalvaults>Guix doesn't compile the linux-libre kernel with sof-firmware? <opalvaults>okay so dmesg shows error: sof firmware file is missing you might need to download it from [link] <ns12>Hi, is it safe to delete all the /tmp/guix-build-* directories that were created using "guix build --keep-failed ..."? <ns12>I am thinking of doing "rm -rf /tmp/guix-build-*" to free up disk space, but is it safe to do that? <rekado_>they are only copies of failures for you to inspect. <ns12>rekado_: Okay. Thanks for the reassurance. <rekado_>civodul mothacehe I'm still waiting for the GC lock to be released. <mothacehe>rekado_: i wrote an email about it this morning <mothacehe>it will probably run for a few more days given how fast things are removed <rekado_>I'll ask my colleagues about the storage. Maybe there's something they know. <mothacehe>great thanks! i'm not sure what's the current size of /gnu/store/trash. I could pause the GC to run a "du" command but i prefer to let things go. <cehteh>is it the scanning or the actual removing which takes so long? <cehteh>in the later case there is an easy fix <mothacehe>i don't know for the scanning, but the removing has been running since yesterday 04:00 <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 <cbaines>I did try using network storage/NFS for /gnu/store some years ago, and I think the additional latency really slows some operations <rekado_>what's slow, I think is deduplication <cehteh>rekado_: but putting that in the background possibly ionice on safely renamed dirs would not block anything else <rekado_>well, not having enough space is a practical blocker ;) <cehteh>at startup it may even check if there are .*.delete dirs stale from some reboot and restart deleting them <rekado_>the number of dirs just dropped to 47201 <cehteh>yes but freeing constantly would give enough headroom without blocking everything else or? <rekado_>mothacehe: /gnu/store/.links is massive <cehteh>its not that you need ALL space at once? <rekado_>I wonder if it is accessed during this phase <mothacehe>no this phase is just about removing recursively /gnu/store/trash <cbaines>I wonder if waiting on I/O is the limiting factor, but performance could be increased if the deletion was happening in parallel <cehteh>to some degree, but when its spinning platters then its most likely starving on ioqueues already <cbaines>each individual operation might be slow, but many parallel operations might get the overall process to be faster <cehteh>only marginally, because the filesystem has to ensure consistency which means every metadata operation has at least write to the journal ***wielaard is now known as mjw
<cehteh>rekado_: iostat -m 5 and watch whats the current load <rekado_>rMB/s and wMB/s are suspiciously low; %util is always near 100 <cehteh>its spinning platters and no ssh cache right? .. then thats 'normal' <cehteh>still zillion of seeks are magnitudes slower than data transfer <cehteh>i have good experience with dmcache on ssd, but in case of a guix build machine this may not help overly much i think, the 'working set' of data is just too huge <rekado_>is there a chance that the *file system type* is partially to blame here? <cehteh>older xfs was pretty bad with such metadata, iirc thats got better meanwhile <cehteh>i think its just that we nowadays are spoled by SSD speed on most of our work, while data grows and grows and spinning platters are not dramatically faster than 10 years ago <cehteh>i would recommend to implement deletion in the way i sketched earlier, then it can safely run in the background possibly ioniced <rekado_>(we've already logged our request for funds for SSDs of twice the size; but no idea if it will get approval) <cehteh>i would add SSD's as dmcache yes .. but i really have no idea if that works well on a build machine because there isnt so much it can cache <rekado_>we planned to go big and replace *all* the disks with SSDs <civodul>mothacehe: what i don't get is why the "rm -rf while lock taken" that's taking so long <cehteh>40TB on ssd ... with redundancy? :) <civodul>these are leftovers from the previous interrupted GCs, right? <mothacehe>yes and according to rekado there are only 47201 directories in /gnu/store/trash <cehteh>my backup system works in a similar way hardlinked trees of rsync backups, deleting stuff takes a lot time *civodul cleared web site update processes: sudo kill $(guix processes |recsel -e 'ClientCommand ~ "-update"' -P ClientPID) <mothacehe>don't think so because it actually removed 100MiB over 24 hours <cehteh>more like unix history, to delete a dir you have to recurse into it and delete every entry <cehteh>and when things are hardlinked (are they?) it wont free much until the link count goes to zero <rekado_>but: we're competing with other departments for funds, so not clear if this'll be approved. <cehteh>yeah i think this should approached with better/optimized software <jonsger>couldn't Guix spend some SSDs to your department rekado_ ? <cehteh>if ssd's get approved the better, but you can release the lock and delete stuff in the background and have some kind of cleaner daemon <civodul>(scandir "/gnu/store/trash") is fast <civodul>the number of entries *is* decreasing, just slowly <cehteh>civodul: its the recursing into the dirs i bet <cehteh>just list one dir flat should be instant <cehteh>do a du -a "/gnu/store/trash" and it'll take hours to days <attila_lendvai>i don't find anything about a firewall service in the docs. i assume it means there's no firewall support yet for guix OS config? <civodul>oh true, the firewall thing above must predate iptables-service-type <attila_lendvai>i wish i could continue my life without learning iptables syntax/model, though... :) *attila_lendvai is busy making notes <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. <vivien>I’m neck deep into administrative nonsense right now, but I will try again today :) <civodul>these two are often at the top in CPU usage <mothacehe>yeah but not the GC process is completely IO bounded I guess. iotop shows that 99% of the IO is done by the GC process. <jonsger>I'm still at my dayjob, but maybe I can try later today... <civodul>mothacehe: that's not a lot, but i wonder if it could be slowed down by these other things (pg does appear in iotop sometimes) <attila_lendvai>is there an example where a shepherd service is user-services agnostic? wrt service home directory and whatnot... <mothacehe>civodul: in think that pg storage is on sda1 not sdb1 <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 <civodul>abrenon: it depends on how the manifest is written; the command-line interface does (specification->package the-package-name), which resolves to the highest version number of the package <civodul>that could be a difference compared to the manifest <abrenon>but I don't understand how the versions could differ, I haven't specified any so shouldn't they all be the most recent as per my latest "guix pull" ? <attila_lendvai>wrt services and unstable uid allocation: does it sound reasonable to unconditionally chown -R the files in the start script to the service-user? <attila_lendvai>or alternatively hash and mod the user name to allocate a stable uid from the service, and let the user deal with any accidentall clashes? <civodul>abrenon: it's hard to answer that in the abstract; perhaps you could post a reduced example so we can take a closer look? <civodul>attila_lendvai: so "unstable" as in: you reconfigure with a service, you remove that service and reconfigure, you re-add that service and reconfigure <civodul>and in the last step, the UID for the service is different from that in the first step <civodul>some services like gdm already do that <attila_lendvai>civodul, yes. or you add a new service that causes a shift in the user-id allocation (not sure if this is an actual risk) <civodul>and i thought we could do it systematically <civodul>there cannot be shifts in the UID allocation <civodul>the only risk is cases like i described above <attila_lendvai>civodul, good. then it's only a risk when the service is removed/readded <civodul>that's because previously-used and relinquished UIDs are not reused <civodul>but you're right, we should revive that "chown -R" discussion! <attila_lendvai>so, unconditionally chown'ing at start is not a crazy idea then... <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. <vivien>Oh nevermind it’s just very slow <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 <civodul>abrenon: at first sight the manifest should be equivalent to, say, what "guix shell qemu samba" builds <civodul>at least when using just the official 'guix' channel <civodul>(otherwise it depends on whether additional channels also provide "samba" and "qemu") <abrenon>yeah of course, it's still there but I'm not using the other repos as far as I know <civodul>minikN: right now that doesn't seem possible, but it's a shortcoming we should fix <abrenon>(I had given it a spin because of my wifi card, but since the network at my university doesn't work properly, I couldn't use it anyway) <rekado_>civodul: also /var/cache is on the same storage. So nginx and guix publish(?) probably also contribute to slowness. <civodul>we're at 38K entries in /gnu/store/trash now <civodul>there seems to be lots of guix-web-site-* store items, which contain lots of small files (for package pages) <civodul>maybe just an impression: only 60 of them <mothacehe> assuming linear speed, we should be done removing the trash directory content in 8.45 hours <vivien>Ah gnome-maps is another one of those packages requiring libsoup 2 <civodul>mothacehe: that's crazy, it's never been this bad, right? <mothacehe>for the last year, the overall GC process was taking around 6 hours <civodul>those guix-web-site-* store items contain on the order of 20K directories + 20K packages (one of each per package) <rekado_>too bad we don't know when it started getting so bad. Perhaps since the last reboot? Kernel regression? <mothacehe>so yeah i don't know what's causing those poor performances <civodul>rekado_: i think this particular instance is much worse than previous ones a few days ago <civodul>your bug report mentioned 9h for instance, which is terrible, but a tiny fraction of what we're seeing here <mothacehe>i think it was 9 hours when i wrote the emailed <civodul>over the last few weeks i observed ~8h generally <kwjc>good morning, evening, or night everyone! <mothacehe>have to get my car out of 1m of snow, see ya! <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>i can't see how it could be made faster <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 <bricewge>I'm trying to use a custom substitution server from a foreign distro (Debian) as a non-privileged user. <vivien>I’m not sure you can do that bricewge <bricewge>I've added --substitute-urls in the systemd service <vivien>Oh so that’s not unprivileced, did I miss something? <vivien>But, only root can edit the systemd service, right? <nckx>You need privileges to add new substitute server keys, no way around that. <nckx>Then like vivien I don't understand what you call unprivileged. <bricewge>But `guix weather` doesn't seems to be using thoses susbstitutes servers <vivien>You might need to restart the guix daemon service <bricewge>nckx: ie. With my user profile, not my guix root profile <bricewge>vivien: I've done that, following the manual <vivien>If you authorize a substitute server, it will be available to all users <nckx>I think I remember a bug about guix weather not checking configured substitute URLs. <vivien>Every user on the system will try to get substitutes from the URL you configured ***rgherdt_ is now known as rgherdt
<bricewge>Looks like it doesn't check the last substitute URL <nckx>My guix-daemon is running with 5 substitute URLs. ‘guix weather hello’ checks only the 2 default configured substitute URLs. <nckx>(In my case they are not listed first, so I don't think it checks the default list at all. Still!) <bricewge>So the bug has been fixed, it checks more than 1 substitute server, but not all :/ <bricewge>Yup, changing the order don't fix the issue <nckx>Well, it doesn't consult the daemon, it just checks ‘all’ hard-coded defaults, but that does not sound desirable. <nckx>So that bug was fixed, yes, but not yours. <nckx>Is this a deliberate choice? I can't imagine why (‘security’, whatever… hardly sounds plausible). <nckx>civodul: Very low-priority ping ☺ <bricewge>nckx: How do you envision a user could specify its default `substitute-urls` (other than specifying it through the arguments)? <florhizome[m]>I defined a service in a different schemefile that’s symlinked under GUIX_PACKAGE_PATH but it’s not found when trying to “guix system build” <florhizome[m]>I export the service and configuration record definition in the service file, and I have it in use-modules in the os declaration. <florhizome[m]>I previously got a few errs that I evened out about the file so it’s definitely being read but I can’t declare the service in my os record :/ <bricewge>Yeah, I don't see the security issue here <nckx>bricewge: I'm not sure if GUIX_BUILD_OPTIONS applies here or should, weather is a corner case ‘build option’ ☺ <nckx>bricewge: No, me neither, I was just bringing it up pro forma. <bricewge>Ok I'll try the environment varible or write a bug/feature report <civodul>nckx: "guix weather" uses a separate set of substitute URLs because it doesn't go through the daemon <civodul>so it's more a bug than an intended choice <nckx>I didn't know that interesting implementation detail. <nckx>Is that itself a feature? <nckx>It could still query the daemon even if we don't actually use the connection for anything else, right? <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 <nckx>There is no RPC to do so. <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 <nckx>For some values of sense, but yes ☺ <nckx>We obviously need to get the listening PID for the daemon socket and then scan /proc to parse guix-daemon's command-line options. <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 <kwjc>how is the hurd kernel these days? <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. <nckx>We'd also need your channels.scm. <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 <zamfofex>I’ve heard it works well in VMs, though. I suspect it’s a problem with my hardware not being supported. I’d encourage you to try it out with my patch and see if it works well. <rekado_>civodul: I'm looking at the management interface of the storage array. Nothing obviously wrong there. <cybersyn>attila_lendavi: by standard libraries you mean trans-scheme/rnrs? or the ice-9s? as they both ship with guile, its hard to know <civodul>still 34K entries in /gnu/store/trash <rekado_>in 536 days the two RAID controllers encountered 13 disk errors. All disks are operational and "Status: Optimal". <rekado_>we only use one of the two host adapters (because without multipath the two adapters would appear as two separate disks in Linux), but the one that's up is running at full 12Gbps. <civodul>i'm running: time unshare -m sh -c 'mount --bind -o remount,rw /gnu/store; rm -rf --one-file-system /gnu/store/trash/a*' <civodul>it seems to do more syscalls per file to delete than guix-daemon, surprisingly <rekado_>"rsync --delete /empty-dir /gnu/store/trash" is supposedly faster <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." <rekado_>average MBs/sec were at around 11.5 for the past few hours; jumped up to just above 17. <civodul>i think Linux should have an rm_rf syscall <cybersyn>I understand that rnrs is suppose to be for cross-scheme compatibility and isn't r6rs, but their placement in this area of the docs makes me think I should stick to not-rxrs modules <civodul>after all it already has sendfile, so why not <attila_lendvai>cybersyn, guix being portable between different schemes is a far cry at this point, so... my argument is more of a general rule than anything relevant for guix. <attila_lendvai>cybersyn, but if you ask me, it's certainly have quite some geek value to have the ability to chose between e.g. guile and chez scheme as the driver under guix. <cybersyn>oh yeah i don't expect guix to be portable. I'm just trying to understand if I should use ice-9 or rnrs... its unclear which you are referring to as stdlibs <attila_lendvai>cybersyn, rnrs. ice-9 is not standard, it's guile's own stuff. maybe i should have used 'portable' instead of 'standard' <cybersyn>cool, got it, thanks! and I agree about the geek value :) <civodul>rekado_: that means that current throughput is currently a tenth of peak throughput (~20M/s vs. ~200M/s), right? <nckx>Aren't you deleting files? <cehteh>thats normal for such big delete jobs, its mostly juggling metadata which means the heads are 90+% busy with seeking, the actual data updated is minimal <nckx>Thanks cehteh, I would have had to type all that & knowing me probably more. <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 <roptat>hey ludo, we should start preparing the guix days, no? *civodul feels overwhelmed these days <roptat>I'm in, I think Simon is also motivated <civodul>alright, let's recruit a few more people <roptat>probably a few more at guix-europe said they were interested, but I don't remember who <civodul>sneek later tell rekado_ another data point: "guix publish" is currently baking two different repeat-masker nars, and that's certainly i/o-intensive <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>at least, we'll need a retrospective on what happened since last year, and discussions about the future of guix (as usual), lead by one of the guix co-maintainers <civodul>and yes, we/i can resurrect the guix-days alias, you just need to tell who it should point to <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 <jpoiret>guix-devel will surely have something about the merge when it is done <apteryx>constfun: no, but you can help by running it already with `guix pull --branch=core-updates-frozen` and reporting any issue <vivien>Before merging, please review 52412 <Karthik[m]>Is there any sort of rule that guix infrastructure (website, CI system etc) should be built using guile scheme? <Karthik[m]>Or can they be done using other languages as well? <roptat>Karthik[m], it's more or less implicit that guix people are more familiar with guile ;) <roptat>so they tend to do things in guile rather than another language <jackhill>vivien: 52412 looks good to me. Hopefully someone can push it. ***stikonas_ is now known as stikonas
<unmatched-paren>weird, i tried to guix update but then icecat tried to build itself and failed :/ <unmatched-paren>i would just use epiphany, but it doesn't have any noscript functionality <zamfofex>unmatched-paren: What was the error message? ***iyzsong- is now known as iyzsong
<unmatched-paren> 0:07.68 ERROR: Command `rustup which cargo` failed with exit status 127. <rekado_>cehteh: would you like to prepare a patch for the daemon? <sneek>Welcome back rekado_, you have 1 message! <sneek>rekado_, civodul says: another data point: "guix publish" is currently baking two different repeat-masker nars, and that's certainly i/o-intensive <cehteh>rekado_: i am scheme-legasthenic :D <cehteh>rekado_: i would like to help with some prototype/review/tips .. i think i can do something that performs better than now in bash already :D or in C, or Rust <cehteh>well its more about some optimized algorithm/concept <cehteh>this is not the first/only time this makes problems, so putting some efforts into it would be generally good or? *cehteh being away now, looking later or tomorrow into details <rekado_>it's the first time mere deletion makes problems. <gnoo>unmatched-paren: guix-patches@gnu.org <gnoo>it's very likely <id>@debbugs.gnu.org <gnoo>although you can search in the patches archive for your patch and see the exact one <gnoo>oh well, the issues.guix.gnu.org website is broken <gnoo>if you use a browser such as eww, the links are search links instead of links to the thread <gnoo>ohh, it's the first word <unmatched-paren>i suppose i could just use epiphany and ditch icecat altogether, then just avoid websites with nonfree JS <gnoo>i use eww for the most part. it dosen't support both javascript and css. depending on what you need to use, it does a good job <gnoo>yeah! it's built in actually <gnoo>never too late to join the church of emacs :P <gnoo>but, i haven't found any other text based browsers as good as eww <unmatched-paren>neither vim nor emacs get it completely right imo; i like the idea of lisp configuration but the keybindings and general defaults are gross <unmatched-paren>honestly i'd like to write my own keyboard-editor since both feel not quite right <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>Zambyte, no we don't allow setuid bits in the store for security reasons <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 <roptat>the setuid programs are copied on activation of a new system <Zambyte>So it's simply not possible on a foreign distro? <vivien>Zambyte, you will have to do the copying and the setuiding on the foreign distro, if I understand correctly <cehteh>rekado_: was the gc/deletion problem discussed on some ML? <roptat>yeah, I think you'll have to do it manually, but then it's not guaranteed the thing will stay in your store, and it won't get updated automatically <unmatched-paren>ld: warning: libldap-2.4.so.2, needed by /gnu/store/078d2r11h0ml9y1jczqb8597jmf4wfwx-samba-4.13.14/lib/libsmbconf.so.0, not found (try using -rpath or -rpath-link) <tex_milan>Hi, any idea why installation of steam with nix install works, but when I put it to home manager (same user) then it wants to rebuild nns-certs? <unmatched-paren>(and discussion of nonfree software isn't allowed here, so no steam...) <tex_milan>:) I ask differently, does inputs compute differently if package is installed with guix instal then with guix home? <unmatched-paren>weird, `guix import hackage haskell-language-server` fails with In procedure append: Wrong type argument in pos <silicius[m]>sddm-configuration is mentioned twice in the guix manual, each time with different fields <roptat>tex_milan, no it should be the same, although from the CLI, a package might be different from its variable name <roptat>like, you could define foo (version 1.0) and foo2 (version 2.0), then guix install foo installs foo version 2, but refering to the variable foo installs version 1.0 <roptat>but other than that, I don't see any case where it would be different <roptat>you might get confused because of grafts, or because you're actually not running the same guix between the two commands? <roptat>also, nix is not guix, so you'll get a different derivation between the two <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? <tex_milan>roptat: doesnt guix pull update installed packages? <roptat>no, only the list of available packages <unmatched-paren>no, guix upgrade does, guix pull only updates your version of guix (which includes the package recipes) <unmatched-paren>when you guix upgrade, it looks at the new recipes from guix pull and upgrades the ones it needs to <unmatched-paren>sudo guix system reconfigure does the same for system packages i think <nckx>unmatched-paren: <sudo guix> Yep. <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>the kernel fails to load it on boot. I noticed that david wilson of system crafters had to load that in but he also was using non-guix which is not something I'm willing to do <GNUtoo>opalvaults: what is 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>It's apt-get update. Confusing UI. <GNUtoo>It depends a lot on the software, some software is trivial to package, some is less trivial <GNUtoo>Here you'll also have to check if it's fully free and can work without nonfree firmwares <unmatched-paren>nckx: for some reason loads of software uses that update/upgrade paradigm <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>(I actually avoid ‘git pull’ because I find it does too much at once, I run ‘git fetch --all’ manually, so maybe it's just me.) <opalvaults>So it should be fully compatible with the linux libre kernel, and therefore guix *nckx feels like they ought to be congratulated for typing git a good few times without mistyping it as ‘guix’ once. <roptat>opalvaults, sounds like a kernel update is all it needs, no? <opalvaults>roptat, i'm using the latest image. what kernel is guix using?! <opalvaults>unmatched-paren, sorry i'm not by my computer thank you for looking that up for me <roptat>trying to update our log4j package, it's ancient... <opalvaults>I have guix pull --branch=core-updates-frozen --allow-downgrade <nckx>You shouldn't need the latest kernel during installation, unless you want to listen to some tunes. <opalvaults>and i have attempted to reconfigure but ran into a crash <opalvaults>Wait but the 5.2 kernel is the one that let sof-firmware in <opalvaults>so if guix latest image is only using 5.15 then that's a problem right? <unmatched-paren>the latest master uses linux-libre 5.15 at least, not sure about the image <nckx>unmatched-paren: The ‘latest’ (not release) images aren't old. <opalvaults>I just did a guix install linux-libre so maybe it will pull a newer kernel <roptat>guix install linux-libre won't do anything for you <nckx>I think I'll use ‘snapshot’ from now on, even though the URL says /latest. ‘Latest’ could still refer to a release. <roptat>it just installs linux files in your profile, it doesn't magically change your system's kernel <opalvaults>right but upon restart I figured it would load the new kernel :) <opalvaults>Wait so that's how every other distro does it. brb reading manual <unmatched-paren>you'd need to install/update the kernel in the /etc/config.scm, which needs a reconfigure <nckx>‘guix install linux-libre’ will just put a bunch of inert files in your user's $HOME/.guix-profile. Nothing will actually use them. <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. <nckx>Your RHCSA is almost powerless here. <nckx>[to continue] but not including any packages installed with ‘guix install’. That is a completely different, per-user, profile. <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) <unmatched-paren>qubes seems excessive to me, unless you really, *really* need that much security <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>Take care, thank you for your answers once again nckx <opalvaults>and unmatched-paren, whom I seem to recall helping me as well before <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. <opalvaults>I feel as though GUIX could definitely achieve something similar because it's already in the good habit of user-level isolation. Could be really interesting in the future <unmatched-paren>that sounds extremely useful even if you disregard the security benefits <opalvaults>It would work very well with current FIDO authentication methods too <opalvaults>Especially with open source alternatives to the Yubikey <opalvaults>(The link is a FOSDEM talk featuring leanart poettering speaking about his ideas about systemd-homed.) <opalvaults>It also has the added benefit of clearing up a lot of NFS/shared storage solution UID/GID messes that typically occur with large organizations <unmatched-paren>naturally, there are loads of `systemd bad!!!11!!!!11` people in the comments :P <florhizome[m]>cool, and would be good to have a solution not dependent on systemd anyways maybe <opalvaults>I would agree florhizome[m], but I have no bad things to say about systemd personally. <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? <unmatched-paren>but "Thank you Lennart Poettering (and Red Hat) for destroying GNU/Linux. Your trojan horse called systemd was the big nail into Linux's coffin." is a little bit dramatic :P <roptat>you need root priviledges, you're updating the system <roptat>whereas "guix install" only updates your user profile, so you don't need priviledges <opalvaults>I see the warning: cannot determine provenance for current system. From the meaning of the word, does it just mean it cannot determine previous versions of the system profile? <unmatched-paren>you can do `guix package --roll-back` to go back to a previous version :D <opalvaults>okay ya'll im off to open up the reference manual <unmatched-paren>there's also an option in grub to do it in case you mess something up <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? <lilyp>the magic solution is rolling back and garbage collecting the dirty generation <lilyp>sounds counterintuitive at first, but trust me, you'll be thankful that this exist if ever something happens <unmatched-paren>i always really wanted to use a bleeding edge distro to get the latest versions of everything, but the risk of arch felt too high <opalvaults>ahh, unfortunately the upgrade did not get sof-firmware working <opalvaults>best mailing list to try and get this sof-firmware implemented? <opalvaults>unmatched-paren i imagine so, it's what I've used bc for in the past. POSIX shell/bash is actually really terrible at doing any kind of numerical evaluation past simple expressions <opalvaults>bc can handle just about anything you throw at it *unmatched-paren uses fish instead :P <GNUtoo>Apparently it comes from e7b385008ca0f0817c3514357cf53151cea0f511 (gnu: linux-libre: Upgrade to 3.11.) <GNUtoo>The best way to find out is probably to build it without bc <GNUtoo>(given that the information is not in that commit) <GNUtoo>ahh I missed it because I looked at Makefile* only <GNUtoo>It's the input of the make statement <GNUtoo>The GNU Make manual has a list of all these "shortcuts" <GNUtoo>*information on all these "shortcuts" <GNUtoo>btw, the Guix manual has '(user-group (name "students")' <GNUtoo>Though it doesn't tell how to use it in a system definition <GNUtoo>Is there somethig for groups somehow like users is for users accounts definitions? <roptat>yes, I think this is what the example is using; I think it's defining a new group called "students" <GNUtoo>Yes but it doesn't tell where to add it in the operating-system definition <roptat>which page of the manual is this? <GNUtoo>That's part of "10 System Configuration" <GNUtoo>I've tried to add it to the users but that failed <roptat>would you like to send a patch for the manual? <GNUtoo>I'll try but that doesn't work either for me <GNUtoo>I've tried (groups (user-group (name "students"))) and (groups (cons* (user-group (name "students")))) <roptat>you'll need something like (groups (cons* (user-group (name "students")) %base-groups)) <GNUtoo>Now I need to find where to add that info in the manual and how <roptat>yeah, that's the most difficult part ^^' <roptat>probably in User Accounts, just after the first sentence "User accounts and groups are entirely managed through the operating-system declaration." <roptat>I think we need to explain in which way they are managed through the operating-system <GNUtoo>I think I'll modify the tmpl as (users is not explained either apart from the examples <GNUtoo>Though there is already users (default: %base-user-accounts) and groups (default: %base-groups) that I missed <GNUtoo>An example is probably best anyway ***mark_ is now known as mjw
<KE0VVT>Whoa, just discovered Guix Home. <sneek>Welcome back KE0VVT, you have 1 message! <KE0VVT>ArneBab: My issue with the so-called Noweb in Org Mode is that macros are just expanded in the printed document. You don't get to see them like in a traditional literate program weave. ***ChanServ sets mode: +o litharge
***litharge sets mode: -bo *!*M6piz7wk*@* litharge
<tex_milan1>Hi Guix, I made it, I MADE IT!!!. Blueman no longer complains about missing Mechanism service when it starts!!! <tex_milan1>Put "bluez-alsa", "bluez", "blueman" into system config. Add this to system config <tex_milan1>BTW, how to read services field of dbus-configuration? I'd like to append the blueman, instead of overwriting whatever was there with the blueman <civodul>tex_milan1: well done! could you email that to bug-guix@gnu.org so we don't lose track of it? <civodul>perhaps the solution would be to add blueman there by default? <tex_milan2>can you help me with the appending blueman into dbus services instead of just setting it as the only service? I don't know how to access item from inherited record in modify-services... ***tex_milan2 is now known as tex_milan1
<civodul>tex_milan1: to add blueman to the set of dbus services, you need to "extend" dbus-root-service-type <raghavgururajan>tex_milan1 and civodul: Perhaps, we could add `blueman?` option to bluetooth-service-type and if `#t` make it extend dbus-root-service-type to include blueman? <civodul>tex_milan1: the definition of bluetooth-service-type already reads: (service-extension dbus-root-service-type (compose list bluetooth-configuration-bluez)) <civodul>this is what needs to be changed to it includes not just bluez but also blueman <civodul>in the meantime you can work around it in your OS config by adding: (simple-service 'blueman dbus-root-service-type (list blueman)) <civodul>raghavgururajan: oh yes you're right <tex_milan1>for learning purposes, do you know how to get item from record? <tex_milan1>btw: i like guix and guille. i used nixos but i was unable to learn their DSL... *raghavgururajan also need to polish his scheme skills <jgart>Does anyone know of any guix python packages that *don't* use setup.py or pep517? <jgart>Should I first try asking upstream to include a setup.py? <civodul>jgart: maybe Python packages written in C/C++? <civodul>do numpy/scipy have setup.py for instance? <civodul>pytorch has setup.py but that just delegates to CMake <lilyp>I think most Python packages still have a setup.py delegating to the C/C++ toolchain even then <lilyp>perhaps swig-generated packages don't <jgart>this is a simple python file <jgart>but I can check those too if they apply to this case also. thnx! <nckx>tex_milan1: I'm not quite sure what you mean, but do (<record>-<field> RECORD) accessors fit your bill? E.g. (package-name hello) → "hello". <tex_milan1>And wanted to know how to add inherited config services into (append) the new one <tex_milan1>so (services (append (list blueman) (config-services))) ? <nckx>Maybe [untested] something like (services (cons blueman (dbus-configuration-services config))) <nckx>(append (list blueman) …) is equivalent to (cons blueman …) here and Some People prefer it 😉 <lilyp>Okay, can someone ELI5 the transformation of `guix shell' to guix-environment* arguments? <lilyp>guix shell emacs -D emacs produces the correct result and I have no idea how it does <civodul>lilyp: there's nothing fancy; a good way to see how it works is to print the option alist <lilyp>Hmm, so the ad-hoc vs. non-ad-hoc variants are already resolved during argument handling <nickdaly>Do I understand correctly that Guix can be overlaid on an existing Debian system? Could I install an updated Firefox/Iceweasel alongside Debian Stable's FF-78? <singpolyma>nickdaly: if you want a newer version of your browser specifically you might try running the version from debian experimental. I doubt you'll find icecat usefully newer ;) <lilyp>In Firefox terms, that's uselessly newer; it breaks all your existing configuration. <nickdaly>singpolyma, unmatched-paren: FF 91.4 is still the current FF-ESR, so that's certainly new enough for me :) <nickdaly>Upgrading from Experimental will probably force upgrade mesa, which would basically convert the entire box to an experimental box, which is somewhat less stable than I'm looking for. <KarlJoad>For guix-mode in Emacs, must I install guix-mode using Guix? I keep encountering issues with Emacs when I do it with straight.el 