IRC channel logs
2023-03-03.log
back to list of logs
<nckx>Scrolling up, I see btrfs has a subcommand(!) now, so it would take care of that if needed. <nckx>apoorv569[m]: Does ‘swapon’ also list 1G? If you ‘swapoff /swapfile’, ‘mkswap /swapfile’, and ‘swapon /swapfile’, does anything change? <apoorv569[m]>Doing sudo swapoff /swapfile then sudo mkswap /swapfile and sudo swapon /swapfile now it shows 10G. <apoorv569[m]>Not sure if this would persist after reboot. I am in the middle of copying some large files ATM. <nckx>(Nitpick: ‘mkswap’ is similar to ‘mkfs’ also in the fact that it defines the size of the swap area, which can be smaller than the underlying device. ‘swapon’ didn't claim to show the size of the file. But why ‘mkswap’ created such a small header, I don't know.) <nckx>I wish I could feign more amazement at the apparent fact that the official btrfs tool is worse at doing something than manually truncate+chattr+mkswap was… <bjc>i'm mostly just mad at sun for concentrating so much quality work behind the cddl <patched[m]>Could somebody here check if they have the same issue as I? If I do guix shell ant openjdk openjdk:jdk and then run ant, it complains about missing build.xml (expected), but if I add the --pure flag, it instead complains about missing java installation. <nckx>If you add coreutils, the distracting errors (which should also be fixed but don't seem related) will go away. <nckx>‘We have tried to execute java but failed.’ is probably a lie, since ‘java’ exists & runs fine… <cel7t><civodul> "shouldn't we add a couple more?" <- As someone who'd like to participate, I wanna work on (1) adding a NixOS-like command-not-found script <cel7t>(2) making parameterized packages (Guix equivalent of Gentoo USE flags) a thing <nckx>Ah, ant itself is another bash script, so it's going to be another we-say-we-tried-x-but-we-really-tried-y and swallowed the error… <nckx>Yep, it's a Pointless Use Of Which. <nckx>Add ‘which’ and be happy, but not at ant please, it does not deserve to see you smile. <nckx>patched[m]: Do you have the time to open a bug to suggest wrapping ant with coreutils & which? <bjc>yu can use ‘license:non-copyleft’ with a url, as seen in #60437 <bjc>oh, would you look at that? an open issue that i'm sure at least one person would like merged =) <nckx>ellysone[m], jlicht: I like the ‘licensecheck’ tool for this. You can run it on a file or on entire source trees. <mirai>jpoiret: not a config per-se but <mirai>simply add a file-system /tmp mount with tmpfs type <winter>hmm, so looking into that "configure script somehow affects built Guix in 'guix system image'" issue, it seems that that should not be possible at all... <mirai>and do __not__ set (needed-for-boot? #t) <mirai>jpoiret: you should still get a wayland session <ellysone[m]>nckx: that's pretty nice, is it integrated in guix somehow? or documented in the packaging guidelines? that'd be pretty nice to have something automated to double check. <mirai>for gdm (using loginctl to query it) <jpoiret>oh, right, with a wayland gdm that should be enough <jpoiret>i'll have a look with a quick `guix system vm` <jpoiret>i'm trying to review a couple of patches <nckx>ellysone[m]: Not integrated, it's just a package in Guix (I think it's in Haskell, even). We could recommend it… good idea. ‘licensecheck’ is just what I happen to know & use, I don't know if there are other similar tools? (I've tried ‘reuse’ once but it's not suitable for this—it assumes a very rigid SPDX format.) <mirai>see the test suite for how I query the type with loginctl <jpoiret>although it might be a good idea to ask for submitters to also send the configurations they use to test their changes <jpoiret>otherwise reviewers have to create new configurations themselves to test the patches, something which contributors have likely already done <nckx>ACTION was wrong about Haskell, this one's in Perl. <jpoiret>winter: what issue are you referring to? <nckx>ellysone[m]: Cool! I'm not going to package that one (Go…) but a face-off would be interesting :) <winter>jpoiret: if you './bootstrap && ./configure --localstatedir=/var && make && ./pre-inst-env guix system image ...', the resulting image will have broken substitutes, as the base service for ACL insertion hardcodes '/etc/guix' for sysconfdir. though I cannot find how the current Guix gets into the built image 🤔 <winter>build-self is only used in pull, and guix-service-type just uses (gnu packages package-management guix), which has all the proper flags set <jpoiret>winter: are you talking about specifically the installer image? <jpoiret>that one uses (current-guix) and not the standard guix package <jpoiret>tldr: the guix installed in the installer image is built from guix pull, not the guix package <winter>oh, that would do it, damnit. i was looking for something like that but guess i didn't grep hard enough <mirai>jpoiret: ideally they would be system tests :) <jpoiret>right! but even without tests, it's always nice to get the testing setup they have <mirai>though in this rare case it was unsuitable <jpoiret>my opinion is that we should still keep that test around, since it at least checks that the session boots <mirai>it just nukes the bogus test <mirai>but I agree with you, I'll try to include a mini-vm config in the future if possible <mirai>I usually test with small vm configs but for that one I directly system reconfigured since the change was "small" <jpoiret>ah, right! I don't use a manual tmpfs though. <jpoiret>it would be worthwhile to base it on a minimal operating-system definition, I don't know if we have such a suitable definition in guix atm <mirai>!! actually, I'm not sure if you can test this with a vm (reliably) <mirai>it will still work like before but VM is what made the test bogus <jpoiret>the problem is that `guix system vm` overrides some file system declarations <mirai>because vm overrides file-system mounts... and sets /tmp to tmpfs + needed-for-boot #t <jpoiret>that's one of the gripes i have with `guix system vm` and `image`, they don't let you test things with 100% certainty <mirai>so it will appear that "all is fine and dandy" but the patch may actually not fix the real issue =) <mirai>though in this case I did reconfigure and reboot locally <mirai>jpoiret: yeah, it's not "documented" as well <mirai>so you only find about it by reading the code <mirai>jpoiret: can you show me later the commands you're using for testing this using image, etc... ? I only used vms <winter>jpoiret: Won't current-guix still force a reconf, leading to the proper flags being set? <jpoiret>mirai: I can try, although it's really just a matter of building an image and starting qemu <winter>from what I can tell, that should be the case... <jpoiret>winter: but, isn't /etc/guix the proper dir for ACLs? <winter>jpoiret: it is, but it's notably *not the default* <winter>it's explicitly set when building Guix <winter>but just running ./configure won't get you there <winter>which is why I'm concerned that the result of the autoconf run from my checkout is somehow getting into the image <winter>when it should be reconfigured when current-guix is built <jpoiret>if you check inside the image, you can find the config.scm file that's generated by the build process <jpoiret>it should be in /run/current-system/profile/share/guile/.../guix/config.scm <jpoiret>both (current-guix) and the guix package should generate a new config.scm, since the former imports the current guix checkout using git-predicate, which only selects files that belong in the git index, and config.scm is excluded (only config.scm.in is checked out) <guixfren>can I add my own scheme module paths to %load-path? <sneek>guixfren, you have 2 messages! <winter>thanks for the hint jpoiret, will take a look <winter>definitely seemed like it was using the wrong path, but at least i can confirm easier now and go from there <apoorv569[m]>@nckx Just rebooted. Looks like it remembers that the swapfile is 10G now. That is strange. Perhaps there is a bug or something is missing with btrfs filesystem mkswapfile command.. <apoorv569[m]>The command btrfs filesystem mkswapfile works in Arch I was using this before as well. <civodul>it's about building a YUNoHost-like web interface to configure Guix System <civodul>ACTION looks at cwebber, wonders where dthompson is <mirai>civodul: regarding your reply at #61803, what's the problem with using 'system' within shepherd? <civodul>mirai: 'system' is "bad" in general: it goes through the shell, which gives less control over what actually happens <mirai>oh wait, that only applies to system right <mirai>forgot for a moment that there were two variants there <lechner>ACTION actually sometimes uses open-pipe <Guest74>I installed Guix System with EXWM and eshell says ssh command not found. Basically every shell says bash: ssh command not found. How can I fix that <ulfvonbe`>> Out of curiosity, do you have a need for ‘system’? I’m inclined to recommend against its use, in which case this patch is unnecessary. <ulfvonbe`>I don't, and I tend to agree about not using it, but make-system-constructor and make-system-destructor both use it and are documented in the manual, so we should either make them work properly or remove them. <gabber>Guest74: you need to install the package `openssh` to each profile where you need to use the `ssh` command <gabber>you can of course choose any other SSH package -- find them with `guix search ssh` <Guest74>gabber: Ah. I always thought that command is a build in from bash <lechner>you still manage to send in the most amazing patches <tricon>civodul: Ooh, I am just beginning to plan a distributed system myself. I really like this idea. Imagine if I could pull subs from servers on my LAN... <mirai>is bittorrent unsuitable for the purpose? <mirai>I see multiple protocols listed but not BT <tricon>mirai: BT would be an interesting and useful delivery mechanism. <mirai>especially with BTv2 and the new bells and whistles <tricon>AFAIU, civodul is proposing, in part, developing the substitute system so that it could potentially be protocol agnostic as far as the delivery channel/mechanism is concerned. <lechner>tricon / i think i do locally, via cross-publishing my stores <tricon>lechner: that's an interesting idea i had not considered. <lechner>i even use port 4849, which spells G-U-I-X <mirai>lechner: can you show how you're doin this <lechner>coming. my browser is a bit slow. i will send my config. <lechner>you also need avahi-service-type (if you have a minimalist setup like mine that is not based on %desktop-services) <mirai>I haven't explored guix publish yet but I was going to suggest mDNS <mirai>looks like it was already handled <mirai>(if you want to be pedantic, an implementation of) <tricon>lechner: thanks for sharing this. i had yet to explore private substitute servers, and this is exactly what i want. <lechner>tricon / mirai / i believe you also have to restart the daemon for this to work. please write if it gives you any trouble <tricon>Yes, now that auth part I have done as I have "cross-built" systems for deployment to other Guix systems - one of my favorite Guix features. <lechner>if you are talking about 4849, i think i am the only one using that port. the manual uses another, and it should perhaps be a privileged port (<1000). i just wanted to have some fun <mirai>lechner: I've been itching to give some touch-ups to avahi <opty>gabber: hello, i modified two elogind libraries (sed 's/name=elogind/name=systemd') and so far so good \o/ <lechner>can you have it pulled in by guix-publish-service-type, if it's not present already? <lechner>in my case, it's in the same file that declared the public key above <mirai>that's impossible, services have to be explicitly included <mirai>what's possible is to place ordering between them (i.e. dependencies) <Kabouik>Forgive the noob question, but if I want to occasionally use a pip package, I would `guix shell python3 && guix shell python-pip && pip install somepackage`, or should I use guix environment? Also, the package needs an internet connection, and I am not sure this is possible with guix containerization, is it? <lechner>Kabouik / i know nothing about Python, but i would do guix shell python3 python-pip -- pip install ... <lechner>that's one command instead of three. when guix shell exits, that's it. the profile is gone again <gabber>i have tried `guix shell [--pure] python python-pip` but i've had some troubles with it (not sure what they were exactly but i remember that i wanted to do some more research with it) <Kabouik>`guix shell python-pip -- pip install somepackage` seems to be the way, thanks. <mirai>if the appointment is at 8:00 but I only boot up the system at 9:00 it will run <mirai>but what if I reboot the system at 10:00 ? <mirai>will the job run twice in the same day? <mirai>how does mcron keep track of what's been executed <jpoiret>mirai: from a cursory reading of the `guix system image` source code, filesystems other than root and esp are kept so i'll be testing using that (of course `guix system vm` didn't work) <gabber>i ran `guix home reconfigure` logged out and back in and now the connection to herd (as unprivileged user) is refused? <gabber>ACTION confused and not sure how to debug the issue <gabber>is there a log for the `guix home` shepherd? <lispmacs[work]>Kabouik: fruit-loops: thanks. Sounds like I would need to rebuild my kernel as well? <lechner>fruit-loops is a bot, but says thanks! <Kabouik>I haven't tried to apply the patch myself to be honest lispmacs[work]. It seems to be a pretty involved patch, and it remaining unfinished does not align well with my noobism with Guix. <graywolf>Does anyone here use ibus-anthy? Couple of questions: 1. When you open the setting and click on the Japanese - Anthy method, is the "properties" button on the right clickable or not? 2. Does the icon for the input method properly load up? <Kabouik>Hum, so I installed my pip package earlier in guix shell using `guix shell python-pip -- pip install somepippackage`, then I closed my terminal window and all, and yet the guix shell still exists (I can see that because the package is already installed if I redo the same). I thought guix shells were cleaned upon exiting/closing. Does that need a guix gc after all? <nckx>Doesn't pip install into ~? <Kabouik>I thought one of the goals of guix shell was to make one-off environments instead of cluttering the filesystem with things not installed by guix? <graywolf>For that you might want to try guix shell --container <Kabouik>Oh, but then I don't quite get the usage of guix shell, I'll need to read the manual again. <graywolf>(I'm novice here as well so I might be wrong): I think guix shell is for using packages (from guix) without making mess in your profile. But (by default) it does not isolate the filesystem in any way, so if something tries to install into ~/ (which pip probably does), it *can*. <graywolf>The --container option should bring in that isolation (with option to whitelist specific paths) if I recall correctly what I've read <graywolf>Nevertheless you can likely combine guix shell with python -m venv to make pip install whenever you want even without the isolation. There still want the be automatic cleanup though. <Kabouik>I totally got it wrong that it was useful to use packages from other package distributions systems, without the --container option (which I hadn't used so far anyway). So `guix shell python-pip -- pip install somepackage` would only be useful to me if (1) I want to install somepackage with pip instead of waiting for its guix port or writing it myself, and (2) if I don't want to keep the pip installer on my system? <Kabouik>I don't know what python -m venv brings <graywolf>virtual environment, basically make the pip install into any directory you pick instead of the default location in ~ <Kabouik>And then it stays there, except if I used python -m venv /tmp/? <graywolf>nah, the typical usage would be `python -m venv SOMEDIR' then `. SOMEDIR/bin/activate' and then you can just do pip install (and it will be installed into SOMEDIR instead of into ~). Then you can just rm -rf SOMEDIR. <graywolf>venv is imho pretty useful, I recommend to read up on it <Kabouik>I was under the impression that using anything else than guix was baaaad. Which I think it is, because it kind of breaks the workflow of a system being all managed by a powerful package manager like guix. <graywolf>Depends. If you can avoid it, then yes, guix-only will likely be better. But sometimes you have to, since 1. not everything might be packaged (yet) 2. some projects might have strict version requirements that are not in guix (yet) <graywolf>You can have reasonable middle ground when you use guix to manage non-python dependencies (gcc, various C libraries, ...), and pip install -r to manage the python ones. At least that is how I plan to do it at $dayjob once I get guix up and running on my laptop. <Kabouik>Yeah, I was already breaking the ideal workflow since quite some time, but was not sure how to do it as properly as possible. I guess using pip is not as bad as I thought then (plus pip does allow easy upgrades and uninstall, so that's not too bad), especially if I use it inside a guix shell --container, or with venv (not sure which option to favour, but guix shell --container will be easier to remember). <mirai>jpoiret: thanks for the info <Kabouik>I have come some more serious conflicts when mixing R packages installed from R, guix packages for R, and rekado's guix.install() R command which allows importing those that are not yet available for Guix. Same with emacs packages already available in Guix, and those only in some channel doing the importation of others packages automatically. And I still haven't come up with a sane workflow for both of these situation, I keep postponing. <mirai>can archived mails in a GNU ML be deleted? <civodul>mirai: possibly but it's a manual process and Guix folks don't have direct access to the mail servers <mirai>the ML archives of mcron are an absolute mess <mirai>it's horrible to search for any info regarding mcron <civodul>mirai: i think nckx would know who to contact (might be Bruce Korb?) <mirai>the question about mcron was whether it keeps state across reboots which you can see the searches returned garbage <jpoiret>forgetting `-enable-kvm` when using qemu is quite costly 🙃 <mirai>civodul: thanks, I'll ask nckx when he's around <graywolf>Why is there both en_US.utf8 and en_US.UTF-8 in /run/current-system/locale/2.33? 1. I assumed that UTF-8 would be normalized to utf8 2. It is the *only* locale in there that has both variants. <mitchell>civodul: Yesterday you shared a link to a talk you gave in 2021 where you show cased a browser based application to view guix systems in. Where can I find that program? <mirai>if the TODO file in mcron.git is to be trusted, then mcron does not have 'anacron capabilities' <Kabouik>Interesting, I don't know what would be the pros and cons compared to r-guix-install. This is fairly similar to what I've been using for Emacs plugins though, and I still ended up with conflicts <Guest74>Upon installing a package like mpv Guix updates its substitutes even from different channels. Can this be improved? Kinda annoying since it takes some time for updating one substitute server that it not even used anyways <jpoiret>mirai: I'm reviewing your patch, everything looks good, but just FWIW (compose list (const x)) is just (const (list x)) 😄 <mirai>I usually use it for foo-shepherd-service, where I have it return a shepherd-service rather than a list <mirai>and then compose it with list <jpoiret>aha yes, i just thought it was funny <jpoiret>that's what we get for being used to over-engineered services <mirai>it turned out to be commutative there <mirai>not something you usually see <jpoiret>civodul: since you're around, wdyt of adding a recommendation for contributors to the system services to 1) add tests if possible 2) at least provide a simple configuration to test the changes with? that would probably avoid some duplicated effort on the reviewers part <jpoiret>1 might be quite hard depending on the system, but 2 should be a minimum <mirai>jpoiret: regarding 1) that will need to be documented first <jpoiret>yes, I'm thinking of adding it to the new team specific pages <mirai>it's non-obvious that check-system is a thing <jpoiret>2 as well: you can't expect things from people if they're not documented <jpoiret>i also feel bad asking submitters to convert their packages to g-exps if there's no explicit style requirement <mirai>and depending on the service, writing the test can be harder than writing the actual service out <mirai>but overall it is nice to have <lechner>mirai / Hi, would it be possible to make guix-publish-service-type depend on 'mdns, which is in turn provided by avahi-service-type? Maybe then the configuration would at least fail without the latter <mirai>avahi should provide a mdns symbol and have avahi as its canonical name <jlicht>might be an older version of npm than what you are used to on current master though :) <mirai>should alternative mdns implementations be used <lechner>i am not good for more than the idea, though <mirai>lechner: I'd wait for the opinion on #61587 first, which has the canonical name proposal buried in it <mirai>it's also not an entirely obvious feature of shepherd <gnucode>so I have good news! My friend let me borrow his Talos II for two weeks while he is on vacation...this is going to be fun! <apoorv569[m]>I want npm mostly for installing lsp plugins for Emacs. I am learning web development though but not very familiar with node versions. I hope it wouldn't be much problem. <PurpleSym>Kabouik: There should not be any conflicts. guix-cran does not contain packages in Guix proper. <mirai>the documentation makes some passing references on it but is ambiguous (which can be improved later on) <jlicht>mirai: Julien once wrote an interesting proposal of having 'extension-points' as part of the guix-home-manager experiment. <civodul>jpoiret: i'm all for it! in practice this is what we've been asking for most (if not all) service contributions <civodul>but yeah, writing it down would be great <civodul>i think we need to split the "Submitting Patches" check list in different parts: packages, services, doc, core, etc. <jackhill>mirai_: lechner: what about if I don't want to advertise my guix-publish server via avahi? Will it be conditional? mdns isn't allowed on the network where my publish server runs. I mean, I could just block connections, but running something that nothing will connect to seems suboptimal to me. <mirai>jackhill: that should be a guix-publish config option <lechner>jackhill / mDNS advertisements are used by many devices like printers (and CUPS) for service discovery. i am not even sure people can turn all of them off, but if they are not allowed there is possibly a way to hardcode it <lechner>civodul / i think their concern is, however, that they would still like to publish using fixed ips <mirai>that's more complicated dances with avahi <mirai>it can do more tricks if you look up the docs <lechner>i think they want complicated dances without avahi <jackhill>yesh, I think the way it is now, it configurable in the service, but if I understand what you're trying to do is that currently if one turns it on, they have to separately configure an avahi service, but now the publish service will always pull it in. <jackhill>yeah, I guess I don't see a way to win here, but I want complicated dances without avahi, but if I'm in the minority, don't let me stop progress for the masses <mirai>symbols can be appended as needed to shepherd requirements <jackhill>oh, conditially depends doens't pose a problem. Cool, I didn't think hard enough about it; sorry for the noise! <lechner>jackhill / hardcoding is usually easy and just hard to maintain, so i would look around. you can also run guix-publish manually if needed, i thinkn <Kabouik>I'll try it PurpleSym instead of r-guix-install, at least for some time to see how it goes! <mirai>is the updatedb-job example right? <mirai>won't it run the lambda procedure and then run "updatedb" again? <apoorv569[m]>Looks like pipewire package in Guix doesn't provide pactl command even though there is pipewire-pulse.. <apoorv569[m]>I use pactl to set and get volume using keybinds in dwm.. <apoorv569[m]>If I install pulseaudio using guix home and manifest files would it conflict with pipewire? <jackhill>apoorv569[m]: does pactl from pulseadio not work again the pipewire-pulse server? My expectation is that it would <nckx>Why would pipewire (or pipewire-pulse) provide its own pactl fork? I can't find it in other distroes. <nckx>(Arch, Debian, …that's all of 'em, right?) <Guest74>I had Gentoo with dwm and pipewire. Using pactl to control vol was no problem <apoorv569[m]>Not fork.. but on other distribution installing pipewire also installs the tool pactl but there is pulseaudio thing only pipewire-pulse <nckx>That doesn't sound like something we want to emulate. <apoorv569[m]>I am saying that installing pipewire and wireplumber package on Guix I don't have pactl command <jpoiret>installing the pulseaudio package should be enough <nckx>apoorv569[m]: You wouldn't if you haven't installed pulseaudio. <apoorv569[m]>Yes, my original question was will installing pulseaudio conflict with pipewire in any way? <nckx>I don't understand why it would, no. <jackhill>if I understand `guix size` correctly it doesn't even increase the closure size <jpoiret>one tip though: if you're using guix system, you should configure the pulseaudio-service-type to disable autostart <Guest74>pipewire replaces pulseaudio you cant have both on a normal system, he means that <apoorv569[m]>I was asking because other distributions have conflict with each other pipiewire-pulse or pulseaudio only . <jpoiret>otherwise applications using the pulseaudio library could autostart the pulseaudio daemon if pipewire-pulse isn't up yet, which could theoretically happen <nckx>mirai: …ouch. I think the person to ask about removing outright spam is Ian Kelling. But the list manager needs to change something about their moderation settings, or moderate by hand (like Guix does :-/ ) or it will just keep coming. <jpoiret>Guest74: you totally can have both on your system, other distributions usually make pipewire-pulse and pulseaudio conflicts <nckx>Guest74: I don't think that's true. <nckx>ACTION has the lag again today. <apoorv569[m]>There is no documentation for disabling pulseaudio service. <nckx>Isn't it part of %desktop-services? <apoorv569[m]>I have my own pipewire-service-type defined which starts a user shepherd service that runs pipewire, pipewire-pulse and wireplumber defined in my home-environment <apoorv569[m]>So I think I should be fine as in not worry about pulseaudio starting by some xyz application.. <nckx>pulseaudio-service-type is what sets up the auto-start (it does not ‘start Pulse’ like some people think), so if your system doesn't have it I think you're good. I've not switched to Pipes yet though. <jpoiret>and you shouldn't remove it, but rather disable the auto-start <Guest74>hmm, i cloned my org files and upon saving it in emacs (i use exwm btw) it takes ages to save and I cant do other stuff upon saving since the nature of emacs <nckx>Now that I don't know how to do. <jpoiret>i think if you don't have any config, pulseaudio considers it to be a free pass <apoorv569[m]>Yes I meant there is no auto-start option in the service-type <jpoiret>hence why I recommend keeping it around and disabling auto-start instead <nckx>So applications will… launch PulseAudio even if there's already Pipewire Pulse emulation available(!)? <mirai>pulseaudio-service-type just setups the systemwide config (do not confuse this with systemwide instance!) <jpoiret>nckx: no, if there is a pipewire pulse server running it will be fine <jpoiret>but if it's not running yet, it will start a usual pulseaudio server <jpoiret>checked my own config and realized I'm preaching things I don't even do myself <jpoiret>but still, I think the advice still stands :) <apoorv569[m]>Could you tell me or point me to how to set auto-start off anyway? <jpoiret>apoorv569[m]: i think it's in the general purpose daemon-conf <jpoiret>no, rather it's in client-conf. The pulse-client.conf manpage tells me that "autospawn= Autospawn a PulseAudio daemon when needed. Takes a boolean value, defaults to yes." <jpoiret>clients read this file by default when using libpulse, and they will spawn the server themselves <jpoiret>we already hate dbus for spawning services without asking anyone (and apps relying on that), but here it's even worse! it's not tracked by anything at all <nckx>zimoun: What do you mean by ‘Guix uses extrinsic identifiers for almost all origins, if not all’ outside of git tags? <jpoiret>which should be '((autospawn . no)) in the config iiuc <jpoiret>'((pair1-car . pair1-cdr) (pair2-car . pair2-cdr) ...) <nckx>See also the examples in the manual. <jpoiret>apoorv569[m]: do you already have %desktop-services in there? if so you'll need to modify the service rather than add a new one <apoorv569[m]>I am modifying some services maybe I can this to that list. <jpoiret>yes, then it definitely belongs there <jpoiret>let me also add the bit to my configuration :p <nckx>jpoiret: Are you also using Pipe? <jpoiret>yes! been using it for a long time now <jpoiret>mostly for the better bluetooth handling <jpoiret>you're missing a - in pulseaudio-service-type <mirai>lechner: why not? it's the negation of intrinsic <mirai>is the correct word actually <mirai>you have the word pair 'interior'/'exterior' :) <apoorv569[m]>I still also have to install pulseaudio package BTW right? <jpoiret>if you want pactl, yes, otherwise no <jpoiret>you only need pipewire, pipewire-pulse and wireplumber <apoorv569[m]>I'll reconfigure the system and let you know if it worked for me. <nckx>The love that ought not speak its name. jpoiret: Hmm, I've been itching to try it. Any drawbacks you think I should know? <lechner>mirai / if you haven't noticed, i am on a mission to make the world just a bit less logical <jpoiret>as long as you have all the required packages and they start properly, none! it's completely backwards compatible with pulseaudio <jpoiret>i know that one sway i need xdg-desktop-portal and xdg-desktop-portal-wlr for video to work in pipewire, but for audio i don't even think it's needed <jpoiret>yeah, well, that's where wayland was heading from the start, right? <nckx>Oh, sure, I just mean it's adding yet another thing to my system I myself don't understand :) <jpoiret>if you don't need video through pipewire it should be fine <jpoiret>ie. sharing your desktop with webrtc <nckx>Through meaning —OK. Got it. <nckx>lechner: I took that wording to be mostly tongue-in-cheek pseudo-academic fun… but then any ‘towards’ in the title will do that. <nckx>I do think that having an entire introductory chapter in an *e-mail* is a bad sign. <lechner>they said the same thing about books when people stopped using scrolls <apoorv569[m]>I think it worked.. I now have /etc/pulse/client.conf file which has autospawn = no field. <nckx>lechner: Sorry, I only read comics. <nckx>It's why I'm always so confused. <bjc>given the number of spelling errors, i think it's just a case of zimon having a less-than-perfect grasp of english <bjc>possibly mostly obtained in academic settings <nckx>lechner: Yeah, but then after a few years you figure out to read it backwards and it gets better. <bjc>fwiw, "extrinsic" is a perfectly cromulent word in my house. but then again, my partner is a university professor =) <nckx>As usual, I see no evidence of you being mean. <nckx>bjc: Mine isn't, and the word is (occasionally) used. <lechner>my point about logic is actually somewhat well-founded (at least in my view). it leads to an over-emphasis of justice, which is the counterpoint of compassion. this can be seen in societies that cut people's hands off for committing a crime. i like compassion, and should have had more zimoun. sorry, zimoun <bjc>i see no distinction between a proper justice and compassion <bjc>i think that depends on how one views justice <Guest74>gdm-configuration can take a xorg-configuration. where is the documentation about xorg-configuration to know which params i can set <mirai>I suspect there's two definitions of 'logic' at play here <mirai>not dissimilar to the commonly heard "its just a ``theory''" retort <nckx>Guest74: It's in the manual. <mitchell>where does guix implement progress bars? <mitchell>Ah, `guix/progress.scm` should have guessed <juli>on running a system reconfigure, i'm getting the following error: "guix system: error: gnu/services/desktop.scm:1880:9: no value specified for service of type 'geoclue'". does anyone know what's going on here? should i open a bug report about this? i'm running gnome if that's relevant <nckx>juli: Can you share your system.scm? <nckx>ACTION should pull first, actually. <nckx>ACTION playfully suspects mirai. <mitchell>Reporing download progress is a fairly complex thing... <nckx>Well, when you make it a generic record type… <nckx>Oh, I'm not sure, it's just an old-style service, and I know you've been unable to stop touching those. <nckx>It seemed like a safe bet to scapegoat you. <nckx>Ah, yes, it has literally unbecome old-style since I pulled. <juli>I believe I ran a successful system reconfigure yesterday, and the patches to deprecate old-style services was merged before then, so I don't think that's it. Not directly, at least <nckx>ae0975332c60818793c6c63a3646c982d686bf49? Are you sure? <juli>wait i'm silly; it was opened before then, not closed... <nckx>No, that was pushed today. <mirai>I didn't set default-value to (geoclue-configuration) for geoclue-service-type <mirai>nckx: do you want me to send a patch? <mirai>for insurance, I'm going to do a system reconfigure to see if I missed anything else <mirai>turns out using gdm as a test for services/desktop.scm was insufficient <mirai>maybe a system build does the same? <cel7t>Is there a Guix analog for Nix's overlays that I can use to make it build dwm with my git/local source <nckx>I'd run at the very least ’system build’, but ideally ‘system vm’. <nckx>‘build’ should suffice though, I'm just being overly cautious. <mitchell>where specifically do you want to overlay? the command line or the config? On the command line you can pass `--with-source=dwm=/local/repo` or from the config.scm you can use (package/inherit dwm (name "my-dwm") (source (origin ...))) <nckx>ACTION thinks ‘guix system build’ is underappreciated. <cel7t>This won't require me to write a dwm.scm, right? <mitchell>Another option if you don't want to fork the entire project but only introduce a few additional files would be to add a phase after 'unpack where you can copy additional sources (which you sould specify in the native-inputs section) <mitchell>no you can do it in the config.scm if you want <nckx>If you CC me I'll get it faster. <nckx>Not sure what that meant :) <nckx>The second I pushed I realised I'd forgot to add a ‘Reported by juli in #guix’. Sorry. <juli>all good, I just want to stuff to work XD <juli>I'm glad I mentioned it so it could get resolved so quickly :3 <helaoban>it might be nice to have some kind of rolling pointer to the latest 'package add' commit, and this pointer only advances past service / core changes once they've been vetted :) <nckx>This would not have caught this, since it was vetted. <helaoban>running a guix pull can feel like russian roulette sometimes :) <juli>that's what generations are for ;) <mirai>I've just noticed that git send-email doesn't preserve the true commit date <nckx>helaoban: Sadly, that's one of those perma-suggestions that can't seem to get enough people to agree on how *exactly* it would work and implement it. We all agree on the general shape, but everyone seems to project their own face on it. <lechner>Hi, is there a place on IRC where i can get some help with a bricked Android device, and find out whether there is a remedy? <nckx>None I would personally recommend :-/ <nckx>There is #android, there are places like #lineageos (or whatever your distro is might have theirs), but I found them all to be a very poor culture fit for me. <nckx>Although if it's #replicant, I haven't visited them. <cel7t>I wonder how my matrix "replies" show up on IRC clients <mirai>oh, maybe git send-email does preserve the original commit dates <nckx>responder: <op> hello everybody what's up here's my long-ass question you just read 5 minutes ago <-- and here's my cool response which you actually care about <nckx>mirai: So please, feel free not to reply ‘properly’ here, just type ‘foo: hello’, we really won't mind 😉 <helaoban>nckx: yea, at first thought it seems you could just segregate package updates in a separate branch, but then again a bad package update can just as easily brick somebody's setup. <cel7t>nckx: I'll avoid using replies in that case haha <cel7t>I used to use ERC before but I don't have a bouncer set-up, and I don't wanna miss any messages <juli>wait is there a matrix bridge of this room? <nckx>cel7t: If you accidentally do, that's no big deal. What's really horrid is editing your message. Please don't. The bridge has regressed and now sends the entire message again. And again. And—for each edit. <PotentialBear-75>Hi, so Im getting started with guix this week on my old macbook. Some ups and downs but so far have the wifi and such working so its technically working. My issue now is that I need to install certain applications not available thru the main channels. In particular Brave (the browser I like), Slack (talk to work team), and Sagemath (work). I was <nckx>cel7t: It used to auto-generate s/x/y/ expressions but they ripped that back out, for unclear reasons. <nckx>juli: #guix:libera.chat, which works for all channels. We didn't specifically set up a Guix bridge. <mitchell>PotentialBear-75: I am trying to get guix working on my 2015 macbook air but while the wifi driver probes correctly it won't connect to any networks. The macbook bootloader can connect so I know it is not a wifi bug. How did you get the wifi working on yours? Does it use a broadcom chip? <PotentialBear-75>mitchell Yeah My is 2014 pro with broadcom. I used 5.15 lts kernel of unclean origins <PotentialBear-75>If you know where to get that kernel, the code on that page is what I used <juli>thanks so much nckx and mirai <nckx>I was happy to push mirai's work. :) <nckx>mirai: I mis-addressed you above. What I actually meant to ask: what was wrong (if anything) with the date? <mitchell>PotentialBear-75: To answer your question I would make your own channel and copy the structure of that other place. You can add whatever package definitions you need there and guix pull like normal <PotentialBear-75>@michaelll I rememebr now. I had to also modprobe blacklist usbmouse for some reason. I forget how I cam upon that solution <nckx>mirai: Please don't compare your commit to mine, I lie. <PotentialBear-75>Ah so like, I can make a custom channel for like .deb's or flatpaks or something? <mirai>nckx: git send-email mangles the authoring date <mirai>it sets it to the date the email is sent <mirai>looking at the history, there's no way that stream of service changes could have been done that quick <Guest74>i want to configure xorg-configuration with a different server but it says xorg-server: unbound variable (need to transform the default one). what do i need to include to get the var? <mitchell>Guix packages flatpak so if you can get these things that way then so be it. If you know how to build them from source but they can't be included in guix because of licensing or whatever then you can stuff them in your private channel. The other place defines a binary build system which may be useful to you <mitchell>It's not pretty but if you have no other choices... <Guest74>nvm found it, its in use package modules xorg <PotentialBear-75>Yeah doesnt sound fun... Im wondering if just like shelling into a container with some other manager and the package I want could be viable? Does anyone use this kind of workaround? <nckx>mirai: I cannot reproduce this at all, to the point that I had to go hunting for the patch I just sent-email to myself under piles of ‘newer’ mail (the Date: was Sunday). <nckx>OK. Otherwise, could you send-email (only to) me a patch and tell me the expected Date:? <mirai>pretty much what the guix manual says <nckx>(I use both; just never like this.) <nckx>Eh, who reads that thing. BRB. <mitchell>nckx: It makes for good magazines to keep in the bathroom <nckx>…OK, I never use this workflow… <nckx>Well, you're right. Date: in each *.patch is a unique snowflake. Date: on each mail is when git thinks it was sent. Fine, but *why do this only when sending .patches*? If anything, the other way 'round would be more logical, if equally frustrating… <nckx>[‘when git thinks it was sent’ because I run git under faketime.] <nckx>This almost feels unintentional, TBH. <apoorv569[m]>How to mount a NFS share? The manual only shows example for exporting <nckx>My answer is I prefer not to leak more info than I already do. <mirai>you're free to keep it, forge it or discard it <mirai>otherwise that field may as well not exist <nckx>Agreed. Whatever importance one ascribes to it (or none), it's odd that git just clobbers it in one specific workflow and not another. <nckx>git send-email -N doesn't do this. <nckx>I think? It seems inconsistent, from the replies to that SO question. <nckx>It's possible that faketime was interfering here, let me disable it. <nckx>Still, sounds like a misfeature, absolutely. <juli>i intended to setup virt-manager so i could do schoolwork, but it's not working and instead i'm bootstrapping a riscv64 environment... neat <juli>(i suspect i need to do more configuration of libvirt but i kinda wanna mess around with riscv stuff now so...) <nckx>mirai: I shot myself in the foot with that. git send-email does also replace the date, my two fakes just happened to match. I'm not going to file bugs against git, but it sure feels like a regression. <guixfren>when I add a channel to my unattended-upgrade service it causes system reconfigure to break <guixfren>I copied the (channel) from channels.scm <mirai>nckx: who reported the -v prefix bug last time? <nckx>guixfren: Did you import (guix channels)? <nckx>Hm. Channels are normal records, you should be able to safely pass them around or assign them. <nckx>But *how* does it fail? What do you run and what does it print? <nckx>Bonus points if you can share your system.scm. <nckx>It's (cons thing list), not (cons list thing). <nckx>You're not an idiot. ‘cons’ is hardly a common English word :) <nckx>For future reference, the ‘View build log at’ at the bottom has the real error(s). <guixfren>ye the build log had the 'scm-builder:1:119: Unknown # object: "#<"' I posted earlier <nckx>I don't see that in my scrollback, I must have missed it or been away. You're welcome. <mirai>lets pray that this service I'm writing doesn't melt my SSD <nckx>ellysone[m]: Nope, but replacing the entire line (including \n, which .*$ matches) with a comment character can often get you just far enough to fake it. <mirai>well, mcron -s is bugged out to start with <mirai>so I'll have to divine if the thing is even running <nckx>If you explicitly pass N? <nckx>There's also ‘herd schedule mcron’, although I don't know if it's relevant to whatever you're doing. <mirai>but I'm suspecting that mcron extensions dont show up there <mirai>it does show something but of ???? value <mirai>ah wait, it needs to be manually restarted <nckx>I wonder how many fingers roptat has left. <nckx>(They'd also be most likely to know the answer to your question :) <mirai>ok, I give it less than 3 hours to see if fstrim will: nuke the drive; do nothing; work normally <nckx>mirai: It should not nuke the drive unless it's exceptionally ancient and buggy. <nckx>And would have been very unlikely to survive this long anyway. <nckx>mitchell: Hey, I said should, it's what the lawyers told me to use. <mirai>ACTION plays 🔫 trim roulette <nckx>ACTION waves at cwebber. <cwebber>I don't yet know if we'll have time to do it, but was considering whether or not "shepherd / guix daemon on goblins" is something there might be support for in guix-land <cwebber>sneek: later tell civodul funny thing, I was supposed to ping you to ask whether or not "shepherd / guix daemon on goblins" was of interest (not a promise to commitment that we'll have resources to do it but checking if there's interest before we talk more about allocating time internally) <nckx>lechner: Yeah. I still don't understand how clients are supposed to parse that if there's Unicode before that point, but it's a bit of a moot/philosophical point: all clients alive today will be using UTF-8 anyway. I suggest you do too. <lechner>nckx / it's not my choice. the guile implementation of SXML does not (or maybe it's the built-in web client) <nckx>It is very likely to choke on The Modurn Web. <nckx>Have you reported this bug/difference of opinion in #guile? <lechner>no, i have been writing to webmasters <nckx>I think you'll get the response I hinted at above. <lechner>actually, mailman@g.o hasn't responded at all <nckx>‘Use a modern framework that assumes UTF-8, go away, it's a living standard or whatever, be liberal in what you accept’ meaning accept the status quo. <dthompson>sneek: later tell civodul re: GSoC mentoring, I could probably co-mentor the guix system web interface as a personal-time thing. if any spritely+guix projects end up happening I could be part of that, too, but I'll leave that stuff to cwebber. <lechner>mirai / Hi, are you connecting via hand-held antenna. i can send screws, if needed <nckx>I feel kind of bad that my ‘this practice makes little logical sense if you think about it’ grumbling led you to ask webmasters, the most cranky of humans on this earth, to change their practices. That was not my intention. <nckx>You never stood a chance. <lechner>what do i have to to get guile, and then guix, running on my tablet? <lechner>ACTION thought dthompson was one of those cranky webmasters <nckx>I'm a webmaster in other context and fully include myself in the cranky 'noid demographic. <dthompson>I wasn't sure if we were talking about webmasters *in general* or if there was some gnu webmaster thing that happened <nckx>GNU webmasters are chosen at random each year and chained to the workstation before they can escape. <nckx>dthompson: No, nothing happened. <dthompson>because I tried to work with them *as an fsf employee* many years ago and it did not go well! <lechner>they still write html by hand i think, so changing the tags is easy! <nckx>You'll not convince them to, because this is a moot point. The whole world has settled on ‘assume text is UTF-8’. Guile is a straggler in that regard but you'll find no mercy out there. Stragglers will be shot. <nckx>Me explaining why your code broke on their input was not meant to send you on a quest to fight windmills. Had I known, I would have told you not to : <mirai>not just the connection is crap, I've been blessed with a crap switch as well <nckx>I assumed Tor was to blame. <mirai>enabling IGMP snooping on it mangles the NDP <mirai>so I can send IPv6 packets out... but the router can't send them back (!) <nckx>Your opinion is valid. Thank you. <mirai>lechner: if you could improve the state of sxml documentation... <mirai>I can't make heads or tails from the thing <mirai>other than cargo cult snippets that someone wrote <mirai>apoorv569[m]: NFS shares can't be automounted in guix <mirai>you'll have to trigger the mount manually (with herd restart) <mirai>nckx: is kyleam.com around on this channel <whereiseveryone>i'm going to get all the gexps tatooed on my arm. i hope the gexp API never changes... <nckx>We're going to add some new ones soon (Premium Gexps) but they'll use Unicode. <nckx>mirai: I don't know their nick. <mirai>switching to open-core model eh? <sneek>Welcome back lfam, you have 1 message! <sneek>lfam, jackhill says: thanks for reviewing the certbot update! <lfam>Looking at #61583 (Git security update), why can't we push it to master? <lfam>It worked for me before the update, too <nckx>zimoun reported failures but not what they were. <lfam>Yeah, I saw that, but I'm more concerned about the suggestion that it would cause way too many rebuilds. If some packages break... fine <lfam>AFAICT, it only causes hundreds of rebuilds <mirai>whereiseveryone: certbot works for me ™ <lfam>Certbot has historically been a very complicated dependency graph, although it seems to get simpler over time. I'm not surprised if it's brittle <lfam>And it has so many features. My use case might work, yours might not <whereiseveryone>what do people think of having an opinionated `guix deploy mumble jgart@192.158.1.38` command? <nckx>lfam: Yes, it's technically staging material, but I'm certainly OK with pushing CVE fixes to master. <whereiseveryone>basically a way for newbs to guix deploy subcommand a mumble server without having to prepare write scheme code for a mumble service <mirai>whereiseveryone: how does it get configured? <lfam>We haven't formalized it yet, nckx, but on the second day of the Guix Days we reached a rough consensus among the people present to abandon the strictly numerical criteria for which branch to push to, in light of improved build farm capacity. Of course it leaves some architectures in the dust, but... <nckx>lfam: That is (excellent) news to me. <lfam>It remains to be seen what it means, in practice, but I've personally been "cheating" on these things since then <lfam>But I'm worried that I'm missing something about Git that might cause, like, 10000 rebuilds <lfam>Some tricky inheritance, etc <nckx>TBQH, I expect zimoun to reply with something that turns out not to be an issue, but we should still wait. <lfam>Alright, I was hoping he might be around but of course it's late there <whereiseveryone>guix deploy mumble --welcome-text="hello guixers welcome let us talk" ... <mirai>whereiseveryone: I don't see how exactly this would work, it's likely to result in something much more complicated than some parentheses <rekado>whereiseveryone: why a subcommand for mumble? Is the idea that there would be an ever growing list of subcommands for different services…? Why not use files with services then? <nckx>I've certainly triggered mass rebuilds in the past by touching git, but I thought that should be taken care of by git-minimal/pinned now. <whereiseveryone>we can have opinionated defaults and then you can override those with long options if you need more <lfam>Yes, I noticed that package and was comforted by it nckx <mirai>whereiseveryone: we already do for many services <whereiseveryone>> Is the idea that there would be an ever growing list of subcommands for different services…? <mirai>its the default values of their record-types <nckx>lfam: By the way: <…but we should still wait> I meant, out of courtesy. If you think this is too urgent, say so. <mirai>whereiseveryone: deploying by command line defeats the point of declarative configuration <nckx>I don't really think this bump breaks anything, or it's very poor practice on Git's part. <mirai>you're looking for something like ansible <lechner>Hi, can I cross-build for linux-armhf in GUix? <nckx>lechner: If the package supports it. --target=armhf-linux. <lfam>It's been a while now, but my opinionated TLDR is that we restrict the core-updates branch to the actual core packages (defined in %core-packages), and then use feature branches to deploy changes with a relatively high compute cost. For example, a "mesa-updates" branch, a "python-update" branch. This is actually something we used to do in the early days of Guix, and then we stopped because of compute limitations that no longer exist <nckx>That's basically my opinion, so if you represented it at the Guix Days I'm happy :) <lfam>There was also an abortive discussion of the question "do we need releases?" but, as Andreas said, it was met with a near-total lack of understanding. So, that question is still open IMO <lechner>nckx / what's the full command for guile, please? is that a static executable? <nckx>lfam: That sounds like an opinionated interpretation of the room. What's there not to understand? <lfam>The question was raised and then not really discussed at all, and we quickly changed the subject to branches. <lechner>also, anyone know of a hypervisor for linux 3.10.108, so i can get a modern kernel going? <graywolf>Anyone has an example how to run firefox in a container? I'm not sure what all to expose. <lfam>IMO, the question implies "What are Guix releases for?", which is the real question to answer <nckx>lechner: guix build --target=arm-linux-gnueabihf guile # should work. I made a beginner's brainfart, though. --target=TRIPLET, --system=NIX_SYSTEM. <lfam>And once we answer that question, we can ask "Are releases the best way to serve those use cases?" <lechner>lfam / i think we only need working installation images <lfam>Probably not an easy thing to iron out but, on the other hand, we don't exactly have a strong culture of creating releases <lfam>It's always like pulling teeth and really just very hard to do adequately <lfam>We always barely get them out, and then there is usually some bug that makes it hard to install Guix System anyways <lfam>Hard to see what the alternative is, of course <nckx>Something about the 1.0 release never sat right with me and since then I find it hard to be enthused by them. <lfam>Branching, on the other hand, is much easier to thing of improvements for <lfam>Hm, I don't remember the specific issues with 1.0. It's always a bit unsatisfying though, and never feels "Guix-y" <nckx>No issues, just the number. <lfam>Well, I like how systemd does it. Monotonic integers with a semantic meaning <lfam>Of course it's the ultimate shed to paint <lfam>And 1.0 looks good on a t-shirt <nckx>I think year-based numbers communicate that even better, but yes, entering shedzone. <nckx>I didn't even notice until last week that even X has gone that route. <lfam>Ah, years are useful *and* have no meaning in terms of the software. That's great <nckx>IME the most common argument favour of releases is the ‘publicity’ they bring. ‘Testing’ is a close second. What else? <nckx>I think the first two vary depending on who you ask. <nckx>Let's put them at #1 together. <nckx>I'm struggling to come up with silver & bronze. <lfam>Well, like I said, that particular topic didn't really take flight <lfam>So it's still open for discussion next time there's a big Guix forum <nckx>At least you made me laugh out loud. <nckx>Well, I'm kind of disappointed if it went like you said. The point of bringing things up IRL is usually so the whole room can't suddenly go quiet unpunished. <nckx>We already have mail for that. <lfam>It didn't go quiet, it just changed directions <nckx>We also have mail for that. <lfam>Mea culpa, I say. I was eager to talk about the branching workflow <nckx>As long as we have volunteers for releases I guess they'll happen. <nckx>And removing the core-updates-crunch mentality might lead to that changing, too. <nckx>Thanks for bringing it up. <lfam>The big point I made is that, since we have soooo many packages now, there are a large number of non-core packages that cause thousands of rebuilds. But, we shouldn't hold those updates until we also update GCC+glibc+etc <lfam>Even if it uses more electricity and bandwidth to rebuild lots of packages more often <lfam>The open question is unpopular platforms such as armhf. They will be even worse off <nckx>Not really a question, though, is it. <vagrantc>i daresay the thing i like about releases, having just run the guix installer a few times ... is basically checkpointing how many commits you need to verify to get a fresh install, and it seems like the substitute availability was very high for a release (i think measures are put in place to avoid GCing packages at time of release?) <nckx>Building armhf on aarch64 was fundamentally unreliable, right? <nckx>That's how I remember it going, after too many attempts. <nckx>vagrantc: I don't get the checkpointing bit. <vagrantc>nckx: guix 1.4.0 has fewer commits to verify than 1.3.x when you guix pull <nckx>Yes, and latest has far fewer than 1.4.0. <lfam>nckx: I guess the "question" is "who will decide to drop armhf from the distro? or who will provide the large amount of hardware needed to support it?" <nckx>Nobody's suggesting that stopping these kinds of releases will make 1.4 the last installer :) <vagrantc>but latest likeyl has poorer substitute availability? <lfam>It seems like a legacy platform now that aarch64 is so cheap <bjc>honest question: /is/ there hardware that would work as an arm build farm? all the stuff i'm familiar with is pretty low power or made by apple <lfam>And I think we all expect it to be a big flamewar <nckx>vagrantc: Sure, I was saving that for now. It might be too optimistic, but we'd certainly like not to GC anything, or nothing close to what we have in the past. <vagrantc>i have had pretty good luck with using libvirt to run a virtualized armhf build environment, but i needed to hack around it for now <nckx>We don't have a way to express this yet, but it would be nice to save all ‘master’ builds forever, for example. <lfam>bjc: There is 64-bit ARM (armv8) hardware. The problem is 32-bit ARM (armhf / armv7). There was *never* anything powerful enough for a build farm <nckx>And discard only side-branch substitutes after a time. <bjc>you can convince arm64 to work in 32 bit mode can't you? <nckx>AFAIR that caused endless bugs. <lfam>So far, we've failed at it <bjc>in theory, there's no difference between theory and practice. in practice… <vagrantc>well, i'm running thousands of builds per day for reproducible builds on debian ... many of the machines are virtualized 32-bit systems on 64-bit hardware <nckx>By endless I don't mean countless, just a demoralising trickle. <vagrantc>there are a handful of natively 32-bit machines ... <lfam>That's awesome vagrantc. But the crucial problem for Guix is that you're doing it for Debian ;) <nckx>We still haven't fixed that bug. <vagrantc>well, i don't think there is anything fundamentally different with guix vs. debian in that regard <lfam>I mean, sure, except that we fail <nckx>Is it money? Fame? We have stickers. <lfam>So, fundamentally there is a difference <vagrantc>try and fail, or nobody has the resources to try? <lfam>Let me put it this way. Every piece of successful Guix infrastructure has a tireless person who makes it work. The reason we can build so well for Intel platforms is that somebody convinced their employer to give us >2000 cores in a datacenter <vagrantc>i can help with the technical issues around how to do it, but definitely a bit sparse for extra time <nckx>That ‘virtualized 32-bit systems on 64-bit hardware’ is rather pointedly leaving out any comparison between architectures. Does it really not matter. <nckx>IMLE i686 on x86_64 is a lot less painful. <lfam>The Bordeaux build farm also has a small team of volunteers who do a lot of work behind the scenes to make it useful <nckx>Than armhf on aarch64 was. <lfam>Buying hardware is easy, but hosting it and making it useful is probably more expensive in terms of uncompensated labor <nckx>Keeping it working has been a lot more work than naively budgeted. <vagrantc>yeah, seems like a human time availability problem for a ... dubiously useful architecture <lfam>I'd say we should "budget" (even in free labor) at least 3x the hardware cost for annual operations <vagrantc>(and another difference with debian is the lack of world-rebuilding events) <nckx>Turns out these things need constant babysitting if you load them 24/7. <lfam>Hardware is really just very cheap in 2023 <lfam>Human labor is expensive in Europe <nckx>Unpaid labour is about the same. <lfam>And it's astronomical in the USA <lfam>All that to say, the first thing is to grow some platform champions. Then, buying the hardware is an easy choice <lfam>The champions may even get the hardware for free <nckx>vagrantc: Does Debian build all packages from source on project hardware now? (If you're wondering how out of touch I am with Debian… :) <lfam>And get the hosting at a discount <vagrantc>nckx: kind of sort of mostly pretty much yes <vagrantc>nckx: there are weird corner-cases that can basically be ignored for any reasonable conversation <nckx>The corner cases that made it untenable for Guix? :) <nckx>Untenable in quotes, but still. <vagrantc>due to an entirely different legacy workflow <vagrantc>i don't think anything fundamentally different there <vagrantc>the biggest difference is guix is more prone to world-rebuilding or large rebuilding events that for the most part debian doesn't do ... so it needs even more compute (and thus indirectly, human) resources <graywolf>Is there a command to find a package providing specific executable? <vagrantc>at any rate, if anyone wants the magic runes to run virtualized 32-bit armhf systems with kvm support on top of a 64-bit aarch64/arm64 system, i can probably dig that up <vagrantc>if i had more time, i would probably try to keep some core subset of guix working on armhf, but ... i do not. <nckx>graywolf: Not yet. Our friend lechner runs juix.org which… sort of does that, most of the time, sometimes. <nckx>☝ you'll be surprised how well asking in #guix works, yes. <vagrantc>for any 32-bit architecture, i wonder how guix will handle year 2038 issues ... there is a big switch to time_64 that there was a lot of discussion for armhf in debian <graywolf>Ah, juix is awesome, will bookmark. password-store is the package I'm looking for :) <bjc>vagrantc: do you have the machine specs for one of the build hosts? i want to see how hard my wallet will cry if i try to set something like that up for guix <nckx>lfam: No, it's crowd-sourced in a rather high-overhead way, so far. <nckx>So graywolf, it's very incomplete, but it's better than nothing. Asking here is still a good fallback. <lfam>vagrantc: Advice on 2038 is welcome <vagrantc>bjc: guix already uses the ones i would most recommend ... honeycomb lx2 with 64GB of ram, 4 sata ports, nvme ... <lfam>But, tbh, anyone using Guix on armhf in 2038... shudder <lfam>It's the wrong attitude though ;) <bjc>vagrantc: my wallet is sobbing. thanks <lfam>bjc: If you like that, take a look at Ampere Altra <lfam>Now there's a platform to break the bank <bjc>otoh the lx2 at $1k isn't tooooo bad <nckx>I'd hope that by then widdle armhf boards will seem as energy-irresponsible as big beige towers do today. <vagrantc>bjc: i also have some apm mustang systems that were historically unobtanium ... that were cast-offs when someone retired a bunch ... i have a few spare boards i would happily be able to donate to guix formally <bjc>i'm not formally guix, this is just a project that tickles my fancy. i wouldn't necessarily be able to commit to it <nckx>bjc: Heh. I thought that too, once. <lfam>Covid seems to killed the momentum in this area <vagrantc>but the apm mustangs had 8 cores, 16GB of ram (32gb possible, if you can find compatible ram) ... that is what i am actually using for the most part <nckx>ACTION needs to go set up servers, nice talkin' to y'all. <vagrantc>they do occasionally require some kicking <lfam>The main thing is "can they sustain a full load", which a lot of SBCs can't <lfam>Slow and steady wins the race <ellysone[m]>-to=guix-patches@debbugs.gnu.org should be guix-patches@gnu.org right? <vagrantc>lfam: they are definitely slow ... moderately steady ... sometimes need to be power-cycled ... weekly? monthly? <lfam>Weekly is a bit rough, monthly isn't too bad <vagrantc>it is variable ... sometimes multiple times a week, sometimes goes a month without issues <lfam>Not a lot of options on the market ATM, as far as I know <lfam>I notice that juix.org says that FSF owns the Guix trademark. Is that really true? <vagrantc>lx2 aren't generally available? i picked up one last year ... took a while ... but eventually arrived <lfam>I mean, I think it's the only one <lfam>Not sure the Altra is available at retail