<rekado>ever since I started using emacs-bash-completion I get *no* completion at all in M-x shell whenever I’m inside a “guix shell”. <rekado>I also occasionally see a list of all executables printed to the shell right after executing a command (such as “guix build”) <rekado>all I do is (require 'bash-completion) and (bash-completion-setup) in my init.el <rekado>does anyone else see behavior like this? <attila_lendvai>some gnome extension is crashing my session after a reconfigure. unfortunately i can't easily debug which one, because there's no option to turn them on one by one. maybe gpaste? *attila_lendvai goes to sleep ***Xenguy_ is now known as Xenguy
<one>Are guix installations in Debian supposed to have the daemonize included in the list of dependencies? <one>**daemonize paclage ** <oriansj>if that is what you are aking (you wouldn't if you had a difffernt init) <one>@orlansj, I am talking about the ##sudo apt install guix## approach. That command on ubuntu22 fulfills the foreign distro installation, and the comparable(read same here) in Debian 11, leaves you with missing guix-daemon socket. <one>I was able to rectify by using aptitude to pull the daemonize package and install and update and haven't had any issues yet... <one>Sorry, I put Debian 11, but meant Devuan 4 Chimaera <one>the sysvinit in Devuan, I believe can interact using systemd commands..? Somehow... (not sure on this, but based on interpretations from people in the Devuan chat <one>I've just been trying to template guix on as many variants as possible.... just kind of exploring <lechner>Hi, I get a lot of "source file XXX newer than compiled XXX" when running ./pre-inst-env guix ... is something touching the files? <one>@lechner, are you pulling and updating before installing packages to ensure most recent packages> <lechner>Also, is there a value in modifying a source declaration to pull from git instead of a tarball? it requires additional prerequisites but is arguably more robust and provides an updater <one>## sudo guix pull && guix package -u before installs, and adhering to the suggestions about the paths.... in the terminal should address that <one>search paths command lists the different locations of guix <one>guix pull && guix package -uguix refresh && guix upgrade <oriansj>one: oh then the only difference in my procedure would be: guix-daemon in either ${GUIX}/etc/init.d/guix-daemon or {$GUIX}/etc/openrc/guix-daemon <one>lechner: oops above, my IRC: ## guix pull && guix package -u ; guix refresh && guix upgrade; guix describe, guix graph, these <one>oriansj: gotcha. I've been DIY computer nerd for only 3 yrs. So, I am always learning, and learning more about what I miss or didn't grasp at first <one>lechner: sorry, didn't complete that sentence.... was just saying that I thought those commands in that order would resolve your issue. Also ,in the context of guix manager, not system.. (not sure if that matters based on your issue) <oriansj>one: to assist, I have added those details to the steps in the procedure (and uploaded them), please let me know if I made an error or could otherwise improve the existing procedure. <one>oriansj: SWEET!, where did you post the changes you made? I'm still figuring out where all/best resources are.. do you mean on the project page? or other resources? <oriansj>with notes for for setting up systems <one>oriansj: wow, it's amazing how much a difference that makes, at least for me. Service file permissions alone would have saved me a good half hour. <oriansj>one: wait until you realize the debian procedure enables something that most people would find impossible to do. Encrypted /boot on Debian <apteryx>jpoiret: re QT_PLUGIN_PATH yeah it doesn't honor that anymore because Qt hasn't thought of a way to make it work for both Qt5 and Qt6 at the same time. So now things have to be wrapped, until (if/when) we figure out a better way. <apteryx>they're wrapped automatically if you use the qt-build-system and have them listed in inputs <one>It seems simple now, but really eliminated ambiguity that made me have to check rather than just mashing pad... Oriansj: there is nothing better for the growth of any project like low barriers and warm receptions! good stuff! <oriansj>one: well I also am a member of #bootstrappable and we teach anyone who wants to learn about how software works and why. As we literally build everything from hex0 all the way to a modern software stack and belive that all of it should be understood. So anything you don't understand would make for good question for us to add and provide (with your help of course) an answer that would help make it clear to new people. <one>oriansj: lol DOPE. I actually was just going to ask about whether this is the place to ask about foreign distros that don't have guix, but I'd love to see? Maybe that's a bootstrapable question? over here? <one>Over asking it here*** <apteryx>sneek: later tell civodul I see the FD_CLOEXEC mastery has paid off in fixing the "error in finalization thread: Success" error message :-) <podiki[m]>apteryx: now we can make those shirts in memorium *apteryx proudly wears some Guix gear, it's fun to advertise something a bit more meaningful than a fashion brand ;-) <podiki[m]>yeah those are some nice ones, this would make a fun inside joke/conversation starter ***iyzsong-alt is now known as iyzsong
<nckx>nashdidan[m]: Did you update your entire profile at once, and update both your system and users profiles if you use Guix System? <nckx>Some kind of version mismatch is all I can think of for the moment. <nckx>It's trying to parse a tracker3 error/help message as data :-/ <nckx>I'm very unfamiliar with GNOME, but the story it seems to be telling is: I found a tracker2 database, let me invoke tracker3 to convert it, I know the options it needs to do so—oh dear those options were bogus. (???) <nckx>A segfault is a rather extreme emo-kid way of dealing with that but that's an upstream problem. <nashdidan[m]><nckx> "nashdidan: Did you update your..." <- Thanks, yes. Running Guix System. Updated both system and user profiles... would be simple then to simply remove the tracker 2 db and let it rebuild I assume... if I can find it...I'm only seeing ~/.cache/tracker3 <nckx>Yes, that's a good idea. <nckx>The only thing that worries me is if this affects all users upgrading GNOME it would be nice to fix it properly, but if you discover a manual work-around that's valuable too. <nckx>AFK a bit, TTYL & good luck! <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, apteryx says: I see the FD_CLOEXEC mastery has paid off in fixing the "error in finalization thread: Success" error message :-) <nckx>nashdidan[m]: …have any? <nckx>o/ civodul. And well done. ***wielaard is now known as mjw
<nckx>one: #bootstrappable is awesome, but it's a much lower-level (and important) level of bootstrapping than packaging Guix for distributions that still lack it. This would be the better place to discuss that. <nckx>one: …but in practice, distro packaging happens because someone already using (and familiar with) that distro falls in love with Guix, not because the Guix project decides to submit one. It would swiftly bit-rot. *nckx adds a missing ‘[GNU/]Linux’ assumption to ‘distributions’, as those don't involve or even allow proper bootstrapping. Adding to a brave new world like a BSD… could, although it would be a lot more work. <attila_lendvai>bash in my user profile's path is bash-minimal (it has no progcomp, leading to an error). why is that? i'm using home-services <attila_lendvai>and i don't think i'm doing any wizardry. a pretty simple home config with some packages (not mentioning bash) <attila_lendvai>wild guess: resolve-collision has changed and resolves `bin/bash` to the one from bash-minimal instead of the full bash binary? but that would probably break a whole lot of other things... <nckx>I can't help much with home, but does the bash-minimal bash come from a profile also containing bash-sane? That should (almost definitively) answer that hypothesis. <nckx>Profile here being ‘PATH element symlink’. <attila_lendvai>nckx, not sure i follow, but ll /gnu/store/[hash]-profile/bin/bash* only lists bash and bashbug from bash-minimal <attila_lendvai>err... i think i know what happened (not the reason, though): i did a home reconfigure, and the already open terminal had this issue. i started a new terminal, and there it properly points to the full bash binary (and starting a nested bash works, i.e. symptom is gone). <nckx>Hah, no, that's not what I mean (what you're listing is already the *result* of randomly choosing a bash), but yes it is confusing… I think ‘guix gc --references $(realpath $(dirname $(dirname $(command -v bash)))) | grep bash’ is what I want. <nckx>Also let us never speak of that command again. <nckx>Same: no idea capital-W why that would happen. *attila_lendvai makes a note of that command nevertheless... :) <nckx>Uh, there's probably a better way to write it, I just wrote in on the fly in this textbox… *attila_lendvai gets back to debugging gpaste <attila_lendvai>oh well... it starts threads, and gdb "Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.". not that i have any experience with that... i just wanted a backtrace. <attila_lendvai>for any interested parties: gpaste-client --version dies with a sigsegv *attila_lendvai gives up and reports to bug-guix <nckx>(That's not giving up, it's gathering reinforcements :) <nckx>Don't know what it is about the letter G but I seldom manage to debug anything that starts with it, sorry. <nckx>'s Why I went wild about this ‘Guix’ thing. <attila_lendvai>nckx, yeah, i think it's some glib/gnome magic. it seems like an entire forest that i don't want to get familiar with... :) (and that's a good point on reinforcement!) <nckx>PSA (best to be up-front about this I guess): I've done some more omg censorship on the logs, but—as always—it was only removing implausible claims of being thanked later. All 4 of them were got good by litharge, which is nice to see: e.g., https://logs.guix.gnu.org/guix/2022-09-29.log#184210 <nckx>If anyone wants to work on our own bot, it could do this automatically, and I would actually thank them later. <nckx>I notice we don't set rel=nofollow on our log links, which might be a (secondary) goal of these bots. Is that still worth adding in 2022 or is my SEO knowledge hopelessly outdated? <civodul>nckx: the thing that formats logs as HTML is in maintenance.git, so we could easily add rel=nofollow <nckx>Oh, I know, but if it's 2004-era noise I'd rather not. <nckx>Also starting to second-guess my above guess. I can't actually imagine anyone typing ‘make $20 in 12 hours!’ into $search_engine and clicking the top link… Not really the point of t.me links AIUI. So maybe not a real issue. Dunno. <nckx>Hm. That example was meant to be amusing but it's reality for many people, so consider it unsaid. I'll remove it from the logs. /s <nckx>So at least Google has demoted nofollow from an instruction to a ‘suggestion’, but it still influences rankings, so I'll add it. Thanks civodul. <nckx>civodul: I thought it was called goggles? <nckx>Oh, goggles-bot. Ne'er mind. <nckx>Overly restrictive find -name… <civodul>but actually i think berlin is still is a "frozen" state: it can't be reconfigured just yet <nckx>(1) Actually, that's the bot, not the viewer, I'm still wrong (2) isn't logs. on bayfront? <tom-1>Hello . Can you please tell me how the search for programs works on the site? I don't see the search bar! => https://guix.gnu.org/en/packages/ I wanted to find a matrix client that supports end-to-end encryption and proxies by default. <civodul>tom-1: hi! unfortunately there's no search bar on that page <civodul>but you can run "guix search matrix" (or similar) <tom-1>thanks for the answer, I'm interested in searching the site.civodul: ***Dynom_ is now known as Guest5025
<tom-1>civodul: Please wait for the package data to load... 5 min .... <tom-1>Is there another way to find the program I need on the site or only through the terminal? <nckx>Terminal is the recommended way. But both Web sites should work! You found either a bug, or a network issue on your end. <nckx>Is the ‘please wait’ repeatable if you refresh the page? <civodul>tom-1: this is weird; you should try refreshing indeed ***PrinceMyshkin03 is now known as PrinceMyshkin0
<tom-1>civodul: sorry it's my mistake i didn't enable the script in the browser so nothing was displayed <jpoiret>attila_lendvai: ah yes, the good old gnome programs segfaulting ea <nckx>It is unfortunate that it requires client-side scripting, but it's a trade-off to not require that server-side. The site is static. <jpoiret>Each time the whether is slightly too humid for them <jpoiret>I think there was a bug open about that gdb issue though <jpoiret>You can also use a core dump to investigate <nckx>Plus, aside from the kneejerk JS-dislike most of use have (including me), it's a pretty user-centric approach: here's the full dataset, here's how you'd search it, have fun. <nckx>jpoiret: They couldn't get gdb to work OOTB unfortunately. <nckx>Quote: "Unable to find libthread_db matching inferior's thread library, thread debugging will not be available." <civodul>that's when the inferior is running in separate namespaces, no? <civodul>in "normal" cases i don't recall having problems <nckx>Ah, so using a coredump would be a different case? Good to know. *nckx will try to remember that. *attila_lendvai notices that the @gschemasCompiled@ marker has never been substituted in the gpaste package <civodul>itd_: hi! it's possible to have both /a/b and /a in %load-path, nothing prevents that <civodul>but i'm not sure i understand what the patch is doing <Guest11>how can i make use of "tcpdump" in a guix shell? tcpdump requires root privileges, but `sudo tcpdump` gives "command not found". `sudo -E` didn't resolve the issue either <itd_>civodul: I'd like to use 'guix import json' with 'GUIX_PACKAGE_PATH'. Currently, I can't figure how to do this. My problem is that for non-guix dependencies the importer seems to expect the path given in 'GUIX_...' plus the actual module name as module name (and fails since that module does not exist). I'll try to come up with a brief example. <nckx>Guest11: I cannot reproduce that sudo failure. <nckx>Are you adding sudo to the guix shell invocation? If so, don't. <nckx>By ‘guix shell invocation’ I mean the part before any optional ‘--’. <nckx>I'm the one who suggested that generating ‘(. my module)’ is always wrong, so direct any criticism of that premise my way. <civodul>in (guix modules) there's file-name->module-name <civodul>perhaps (guix import print) should use that <civodul>and then we can fix that one if needed <civodul>currently it doesn't have special treatment of "." <MaNI>my builds keep failing due to "guix substitute: warning: ci.guix.gnu.org: connection failed: Connection timed out" other than modifying the build system to use "--no-substitutes" (which I'm not even 100% su re where to do) is there anything else i can do to stop this? <nckx><which I'm not even 100% su re where to do> Just to your ‘guix whatever’ invocation, although you can also add it to the guix-daemon service to disable them entirely. <nckx>I thought there was an open bug specifically about ‘Guix should not die on network hiccoughs’ but I'm failing to find it. <nckx>There are many open bugs that are about this core problem though. <nckx>Which means I can't tell you if anyone's working on it. <itd_>civodul: Nice, thanks. However, looking at the two lines below 'srfi/srfi-1.scm', I'd argue that things likely remain interesting when using this function: gettext's path is relative to the guix checkout; myhello's path starts with GUIX_PACKAGE_PATH. ('.' is not a special case, IMHO. Same thing happens with other/absolut paths.) <nckx>If it's specifically ci.guix that times out, you could try manually specificying the ‘other’ substitute server(s) with --substitute-urls="https://bordeaux.guix.gnu.org [any others you may use]". <efraim>looks like I can't install both qtwayland and qtwayland@5 in the same profile <MaNI>nckx, okay thanks, is it likely to be a slow server though? Or should I be looking to my ISP for connectivity issues (general speed tests are fine, but perhaps theres some routing issue to the server doing this). Is there a process to determine why its happening before I try the "--no-substitutes" route? <nckx>I can't say. The server box itself should not be slow (not trying to be pedantic, read on), and everyone close to it (Germany) apparently gets insanely great speeds, but something is wrong/suboptimal with routing/peering somewhere, yes, and others see abysmal speeds. This makes it very hard to debug. Network gurus welcome. Apart from making Guix more robust, I'm not aware of any ways to debug this I'm afraid. <nckx>I'm in the lucky segment of users. <antipode>nckx,MaNI,others: I'm getting about 6.4 MiB/s (Belgium, ISP, not 'mobile' Internet) for ci.guix.gnu.org <nckx>Same ISP, same speeds (if not higher). And all my VPSes are in Germany, so… <nckx>Actually, I have one that isn't and… it's IPv6-only. <MaNI>anticomputer, what command are you testing with? I'll run the same just to see <antipode>Can't connect to logs.guix.gnu.org now I have disabled IPv6 ... <MaNI>my traceroute for ci.guix.gnu.org seems bad, going to chat to my ISP <Guest11>of the shell manifest, but i'm on a foreign distro (Debian) <nckx>Could you paste(.debian.net) the exact command and output? I don't have a Debian system but maybe something will jump out. <antipode>* have disabled IPv6 -> ave disabled IPv4 <nckx>antipode: All of berlin is IPv4-only. <Guest11>nckx: is termbin.com ok for you as well? <nckx>I guess. As long as it curls, it's good for me. <nckx>antipode: logs. being IPv4-only looks like a bug, not a hard limitation. Somebody just forgot to add an AAAA record. <nckx>bayfront. itself has one. <Guest11>the error i get simply states: "sudo: tcpdump: command not found" <nckx>I'll add an AAAA record later when my stack is less high. <nckx>I can confirm that the problem is not the manifest (as you already knew). I can only suspect that Debian's sudo resets PATH and/or has a hard-coded whitelist of ‘safe’ elements that still happens even with -E. You could test that. <nckx>Failing that, you could invoke Debian's sudo with the absolute file name of Guix's tcpdump (a profile symlink would work too). <Guest11>weird. all combinations of guix shell (with or without the --pure, or --container option) with and without sudo (with and without -E) return the same path -- which is the same as the one i get when i `echo $PATH` in my home shell. or is my invocation `guix shell -m guix.scm -- [sudo [-E]] echo $PATH` wrong? <nckx>That will dereference $PATH before executing the command. <nckx>Try (the single quotes matter): guix shell … -- sudo sh -c 'echo $PATH' <nckx>You can also just drop the ‘-- …’ entirely and get an interactive shell! <jpoiret>sudo's default configuration on Debian is in fact too safe <Guest11>echo $PATH dereferences before the guix shell is initialized in use with --? <nckx>Guest11: Before Guix is even started, by your current shell. <Guest11>np i'm not using backticks in my commands -- i just did that here for monospaced-formatting in the web-chat client <nckx>First, your shell expands variables & globs (like ~ and *), only then does it invoke ‘guix shell …’. Guix only ever sees the expanded string, let alone sudo & the echo happening much later. <nckx>Sure, your commands wouldn't have made sense with them :) <jpoiret>you should check if secure_path appears in your sudoers configuration <nckx>Note that they have absolutely no effect on the vast majority (if not literally: all) of IRC clients. We just see `s. <jpoiret>this is what causes sudo to reset the PATH when invoked <jpoiret>Debian has its reasons for enabling it by default, so you should consider whether you want to keep that behavior or not <Guest11>jpoiret, nckx: thanks for helping me debug this issue! commenting out secure_path made everything work as expected! <nckx>Guest11: Always welcome. What jpoiret said is also true. Some would say that you're not decreasing security significantly because this is sudo we're talking about, but it's still true, and you should read about the option & draw your own conclusions, because everyone has different trade-offs. <nckx>A totally secure system does not accept pesky & dangerous things like user input, or produce any output. That could be used to divine its internal state. ***maximed is now known as antipode
<nckx>apteryx: All berlin home directories are gone… <nckx>SAN is mounted there but it's empty (apart from static-web-site). <rekado>just the home dirs? Isn’t the store and/or the cache also on the SAN? <nckx>Yes to both IIRC. (Not sure I understand the link, if one's implied.) <nckx>I logged out, so now I must play the waiting game. <nckx>Hm, it's not the SAN, it's the ‘btrfs storage array’ (16ff18e1-eb41-4224-8df6-80d3b53c411a) whatever the difference is. <rekado> /dev/sdk2 on /mnt/btrfs-pool-san <nckx>That makes two of us who shockingly don't know UUIDs by heart. What admins we are. <nckx>Should be sda3. By ‘should’ I mean ‘was’. No idea what ‘should’ be there. <rekado> /dev/sda3 on /home type btrfs (ro,relatime,degraded,compress-force=zstd:3,ssd,space_cache=v2,subvolid=257,subvol=/@home) <nckx>sda3 mounted at /home and /var/cache is 99% used, that can't help, but might be an unrelated uh-oh. <rekado>so… we’ve got the SAN mounted at /home after having mounted /dev/sda3 there <nckx>What devilry/left-over is this. <nckx>Are you messing with mounts? Because more stuff just vanished from / that was definitely there when I first noticed this. <nckx>Was this FS rebalanced? I see a lot of There's a lot of ‘BTRFS info (device sda3): relocating block group NNN flags data|raid1’ preceding that <rekado>I haven’t touched ci.guix.gnu.org in a long time <nckx>Bit early for that phase 🤭 <rekado>I’m asking my colleague who administers the SAN <rekado>just in case there are any know problems <nckx>No, I think this is the array, although I could be mistaken. <rekado>one thing that we should address at some point is our primitive connection to the SAN. Multipath would insulate us from connection problems. <nckx>sneek: later tell lfam: Hi, I saw you last checked the btrfs balance status for the SSD pool on berlin. Were you just curious, or had you noticed something odd? <rekado>we have the hardware for a redundant connection, we just lack a suitable multipath config on berlin. <nckx>rekado: I'm not seeing evidence for a hardware failure, but I didn't search exhaustively. <nckx>It goes straight from software doing software stuff to software detecting file system errors. <rekado>colleague says no known problems with the SAN <nckx>apteryx was working on migration, so I'm going to wait for them to join. <nckx>I missed this on the first look: <nckx>Can't hurt to ask, just don't <nckx>[691708.437614] BTRFS: error (device sda3: state A) in btrfs_run_delayed_refs:2151: errno=-28 No space left <nckx>[691708.437620] BTRFS info (device sda3: state EA): forced readonly <nckx>So no mystery what happened, only how. <rekado>IIRC apteryx wanted to kick out one or two SSDs from the array to use them as independent root devices for an oversized local /boot <apteryx>nckx: that's with btrfs-pool-ssd, which is not in actual use <apteryx>I converted the array from RAID10 to RAID1 to have some spares I could take offline <civodul>cbaines: hi! the load on bayfront is really high, to the point that some HTTP GET requests on hpc.guix.info & co. take several seconds <civodul>i'm not sure what can be done though <civodul>it might be the web site mcron job that are too intensive <apteryx>mothacehe, rekado, civodul would you mind logging out of berlin temporarily while I try to cleanly umount /dev/sda3 <apteryx>that's the old ssd pool that got used erroneously by that old generation that is currently running <nckx>Maybe not intentional, but it seems to be de facto in use. <apteryx>or perhaps cd'ing out of your $HOME is enough <nckx>(Sent before your last line.) <mothacehe> apteryx: i removed my screen instance, hope it will help! <nckx>I logged in without a home directory, and am not cool enough for a permanent screen, but logged out just in case. <apteryx>only rekado remains, per "lsof | grep '/home'" :-) <rekado>wait, I still have a screen session there <apteryx>hmm, mount --uuid=d5d1a040-7f2a-4c38-9a89-82f08866f6ec -o subvol=/@home,compress-force=zstd,space_cache=v2 /home -> mount: /home: mount(2) system call failed: File exists. <nckx>They were both mounted, just one above the other. <nckx>(So sda3 above sdkwhatever, IIRC.) <apteryx>that UUID corresponds to the yeah I had bind mounted sdk2 on top of sda3 <apteryx>both umount now, as far as I can tell, at least for the /home mount point <nckx>(Or the other way 'round, totally what I meant to say.) <apteryx>My removal of the first 2 drives from /dev/sda3 failed with ENOSPC, for some reasons, and it's now mounted degraded as read-only. Still stuck without free bootable drives. I guess I'll have to fix the machine from a chroot (using a pxe-booted image) <apteryx>I'll need to put berlin down for some time, perhaps an hour or more <nckx>Is it worth putting up a ‘planned(heh) maintenance’ page on bayfront? <nckx>…hm, judging by bayfront's current performance: no. <nckx>Plus the TTL is 1h anyway. <elaexuotee>How the heck does the gnu.load kernel parameter work? The kernel doesn't really know about this parameter, and Guix doesn't set the init parameter, so there's gotta be a /sbin/init or /bin/init somewhere that's running the gnu.load scheme blob, right? <elaexuotee>However, my initrd contains nothing but 2 blobs of microcode. <nckx>You probably have 2 initrds. <nckx>I think lsinitrd deals with this, but it's not packaged yet (it's part of dracut). <nckx>Search the Web on instructions on how to extract the second initrd. <nckx>OK, reconfiguring bayfront seems to be right out at the moment. ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | 🚨 ‘planned’ maintenance for most of guix.gnu.org 🚨 | https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<nckx>Hi the tubular. If this is about bcachefs, I was actually going to get back to you, just haven't yet. If it's for any other reason, that is very kind, and I am well. <nckx>I am well in the first case as well. <nckx>OK, so: it's not ‘supported’ here, because there are 2.5 things missing AFAIK: (0.5) kernel support, but that's true of any distro (1) Guix System support for separate /boot, which has always been TODO and everyone just hacks around it (including guix.gnu.org) and (2) multi-device support in the initrd, which I didn't really care about until recently, because I bought an overpriced 2-TB SSD to use as my second device, but can't yet. <nckx>Potentially having 4 TB of storage in my laptop should be a good motivator, or so I hope. <nckx>Apart from that, it works! <nckx>My / has been bcachefs for years now. <apteryx>multi-device is "supported" by our initrd if you use Btrfs RAID <nckx>The 2nd SSD is connected over a slower link than the 1st, so this would be a perfect test case for tiering (or… it's been renamed now… I forget to what). <elaexuotee>nckx: Oh! So initrd isn't just cpio archive! There's separate ones embeded. Thank you. <nckx>apteryx: Sorry, I am specifically talking about bcachefs. Yes, it's supported for btrfs but there's nothing universal about it. <nckx>elaexuotee: It is, but more than 1 can be concatenated (literally, as in cat) and Linux will extract them on top of each other. <nckx>Not_Leader: bcachefs has bcache concepts built in. <nckx>You probably could (pending debugging) run bcachefs on bcache, but you'd gain no new features. <Not_Leader>i didn't know bcachefs could be use for disk caching at all lol <the_tubular>I don't understand how can your root partition be bacachefs with all the problem above <nckx>As the story goes, Kent took a good look at bcache, thought ‘I basically wrote a file system exposed as a block device’ and wrote bcachefs. I'm sure that's oversimplified (and he perhaps regrets it now!) but there's a kernel of truth there. <nckx>I run my own extremely trashy kernel fork, which includes amongst the detritus, bcachefs. <nckx>For the others: (1) I manually copy stuff to an ext2 /boot (2) I still use only 1 device for now. <nckx>You could rebase the bcachefs kernel onto a receptive linux-libre version, sure. <nckx>It's just work, and work I have no intention of doing, since I've never used linux-libre. <nckx>But it shouldn't be that hard, and I actually started on a linux-libre-bcachefs kernel when the last person asked. <nckx>So that ‘intention’ is worth little and I am easily swayed :) <the_tubular>lol, I'll go catch up on the news, feels like I missed a bit of them <elaexuotee>nckx: Cool. I see now. cpio format knows its own length, so extractors can just ignore junk at the end. Makes sense, given that cpio was originally for tape archives. I guess that means we can just search for the header magic bye, lop off the beginning and feed that to cpio. <nckx>I never miss a chance to ramble about kernel stuff! <nckx>the_tubular: If you mean Guix news, I doubt you'll find anything, I don't think anyone but me has worked on it. If you mean bcachefs news, check out Kent's Patreon page for high-level stuff beyond the git log. *apteryx takes berlin down <apteryx>nckx: I'm struggling to pxe boot, it always finds that GRUB entry <nckx>Yes. See topic (don't mind: many people miss it, hence the obnoxious mojees). <apteryx>tries to reach there from the system setup (f2) *mjw hides in shame for not reading topic. sorry <Guest80>Is it just me or are the guix servers down? <nckx>Yes. We announced it in the topic, but it would be nice to eventually have a proper status page. <nckx>apteryx: Was that a /me or do you mean the system tries & fails? <Guest80>Oh, I completely missed in in the topic <nckx>It is subtle (☺). No problem whatsoever. It's not ideal. <Guest80>I was watching some 10 years of guix videos and they just cut out. I've been having a lot of ISP issues lately, so I just wanted to double check <apteryx>nckx: just wished reaching PXE boot was not as much of a mystery/luck thing :-). I'm retrying after leaving PXE boot as the sole boot options (F2 - <nckx>I'm at the idrac prompt but won't open the console (because it doesn't always multiplex well). Holla if I can be of service, but I don't think I know secrets you don't… <nckx>Guest80: Oof. Bad timing. We'll check the logs for mid-video visitors next time 😉 <nckx>(IME nginx logs connections only when they terminate, so jokes aside, I don't think we can.) <nckx>apteryx: I've always had to try a few times. One of the things that makes me weary to execute even planned reboots. It eventually succeeds, but always feels like it might not this time. <apteryx>I could reach an SSH shell of the pxe booted image like last time <nckx>Sounds like your in a position to do the needful then? <nckx>I did nothing, but then I can go have a quick bite in peace :) Good luck, and please let me know (pings are on) if I can be of service. <rekado>this serial console weirdness is something I’d love to see fixed <rekado>it’s like we’re talking to two consoles simultaneously <rekado>and input is distributed randomly among the two consoles <rekado>even if you manage to log in this way you’re still only logged in on one of them <rekado>and any commands you input will still be partially sent to the login prompt of the second console <rekado>something about our kernel arguments is wrong <apteryx>rekado: to mount from the SAN, can I use e.g. /dev/mapper/mpatha-part2? <rekado>our SAN slice is 100TB, so I would guess that this is in fact the SAN <rekado>but I don’t how the device presents itself to the kernel and whether that location is stable <apteryx>I tried mounting this from the live system, and it hung, eh <apteryx>like, mount /dev/mapper/mpatha-part2 -o compress-force=zstd,space_cache=v2 /mnt/btrfs-pool-san <apteryx>can't seem to kill that 'mount' process either which is stuck. odd <rekado>(could it be that it’s slow because 100T is big?) *rekado doesn’t know anything about how mounting works <apteryx>should I preserve /home? I can migrate it, if it's valuable, but it'll use some more time <nckx>Part of btrfs mount time is proportional to FS size, yes. (This seems to be the case, but much less severely, for bcachefs — maybe some CoW design tradeoff.) <nckx>I'd disagree, even for other's home: I must admit to snarfing .bash_history entries (but nothing else!) from there… <nckx>mothacehe: I think I have yours to thank for having ever been able to figure out the Cuirass database, for example. <nckx>Again, 's all I ever looked at :) <rekado>the most valuable in my home is indeed .bash_history <apteryx>there's also 199G in your home for some reason :-) <apteryx>199G /mnt/btrfs-pool-ssd/@home/rekado <rekado>that should all be in /var somewhere <rekado>199G is much bigger than I’d expect, too <rekado>could you perhaps send me a listing of the big stuff? <rekado>the debian hurd images can be deleted <rekado>whatever is in mumi can also be trashed <nckx>apteryx: Missing dotfiles. <nckx>You can also pipe through ‘sort -h’, life hack. <rekado>oh yeah, my emacs config is probably responsible for the missing GBs <rekado>debian-hurd-20171101.img and debian-hurd-20190220.img are already 160GB <rekado>these are likely from before we had the childhurds <nckx>Well, I was thinking of .cache more than .emacs, but you do you. <rekado>in any case I won’t miss anything if you trash my home dir <lechner>Hi, is there a need to copy guix-patches when responding to a bug report, please? <apteryx>rekado: alright, I'll clear yours and mathieu's since I have your agreement and they are the largest <jpoiret>lechner: guix-patches and bug-guix should only be used to open bug reports <mothacehe>static-web-site is built as a derivation then hosted in /srv so probably useless <apteryx>rekado: 983, which corresponds to its own user, static-web-site <nckx>lechner: Debbugs *often* does the right thing and won't open a new one, but it's not fool-proof so certainly don't go out of your way to add it. <lechner>Hi, is there a special debbugs tag for core-updates? <abrenon>how does one delete old generations of guix itself ? (not my user's profiles) <abrenon>in /var/guix/profiles… for my user I have many current-guix-<n>-link which apparently still point to valid places within the store <nckx>abrenon: ‘guix pull’ is the ‘guix itself’ subcommand, as unintuitive as it might be (although, not too bad, I can see the logic). <nckx>So it also accepts --delete-generations. <abrenon>ohhhhh I tried guix --help which of course referred me to the various subcommands instead of the expected --delete-generations but I didn't see that one coming <abrenon>(now, I remark that the links start at n=32, so I guess I must've been able to run something equivalent before without knowing it, I wonder what that could've been) <abrenon>also, I have a guix-profile-0-link in there, which doesn't come out in guix package --list-generations but is apparently still among my gcroots <nckx>‘guix gc -d’ says ‘when run as root, this applies to all the profiles _of all the users_.’ Doesn't mention Guix-itself profiles but looks like a safe bet. <nckx>It also mentions generation 0 explicitly elsewhere. <abrenon>ahhh, maybe I used to sudo guix gc before knowing I didn't need root rights <nckx>Bah, I saw the ‘generation 0’ thing just now whilst searching for the other, now I can't find it. Pretty sure I didn't make it up? <abrenon>here it's visible with: ll /var/guix/profiles/per-user/alice/ <nckx>I meant the note about it not being deleted. <abrenon>the linked profile doesn't seem to contain anything but etc/ and a manifest <nckx>My guess is it's a safeguard of some sort, so you never accidentally GC Guix, but I don't see how protecting the current generation doesn't achieve that. <nckx>Probably a second safeguard against *that* failing. <abrenon>it'd make sense; I can understand why you don't want an empty list there yeah <nckx>(But then, won't it eventually keep an ancient closure in store? Anyway, I skimmed over it and can't find it now, who knows what it said exactly.) <nckx>I don't think those videos will work, abrenon the_tubular. <nckx>They are hosted on the berlin server, even if that page itself isn't. <xd1le>the_tubular, berlin is down atm <nckx>Ah, I'll add it to the channel entrymsg too. <nckx>New joiners will now get a nice spammy message to complement the nice spammy topic. <apteryx>ah, silly me, going from RAID10 to RAID1 didn't increase the capacity of the array, so I can't take a disk out <nckx>abrenon: …and exactly the wrong kind of redundancy :) <abrenon>yeah, I assumed everything was stored on the same machine, that was a bit optimistic ^^' <abrenon>ok, while I'm diving into old profiles, I see that my auto/ directory in the gcroots is still… pretty hairy I guess <abrenon>it's got a link to my first guix generation (but not the other), as well as many other profiles <abrenon>I suppose the relatively recent ones are created by guix shell <nckx>Links in auto/ (like anywhere, but more common there) can be dead. <nckx>And will not influence GC. <abrenon>hmmm I was mistaken, the current-guix-1-link isn't mine, it's root's <nckx>But if they are live and shouldn't be, something's up. <abrenon>(that's the "removing stale …" lines that flash by at the begining of guix gc ?) <apteryx>so hm, I'm rebalancing /mnt/btrfs-pool-ssd to with -dconvert=raid0 to extend its capacity, but that's going to take days... not a practical option. I guess I'll have to wipe the array. <abrenon>so all that's left for te figure is how I managed to get this link to root's profile… <nckx>These are often symlinks to symlinks, so breaking any one should invalidate the rest & Guix will clean it up. Unless you break the chain in a way that Guix can't find the head, but that implies manual muckings about. <abrenon>must've run sudo guix pull or something, <nckx>Hmm… possible. I think (hope!) we now disallow that, at least. <nckx>I don't remember the side-effects. <nckx>World's biggest /boot in 3…2… *apteryx suddenly has 6 drives to play with <abrenon>would it be a bad idea to try "sudo guix pull --list-generation" to see if that link's still mentioned there and if I can perhaps delete it from the auto/ roots ? somehow it seems wild to have to retain a very old version of guix for a user I'm not using it with <nckx>I'd say bcache, but the SAN isn't slower is it (and also, the suggestion would not be serious). <nckx>abrenon: It should not write anything. <nckx>I can't guarantee ‘safety’ but if it writes that would itself be another bug. <nckx>(A very unlikely bug, to be clear :) ***jonsger1 is now known as jonsger
<nckx>If you don't see what you expect, also try ‘sudo -i’ just in case <abrenon>I see what I expect, the time is right etc. <apteryx>how large shoudl the efi partition of berlin be? <nckx>lechner: Oops, hint taken. linux-pam patch marked for imminent processing. Beep boop. <abrenon>(again, it won't delete the last generation for user root) <nckx>A few 100 MiB should last forever, apteryx. <nckx>Which makes sense if you're allowing for other OSes (or if we eventually copy kernels &c. to /efi, which seems unlikely). <nckx>Hmm, considering our chonky initrds, 550 MiB sounds worryingly small then. <nckx>So probably not worth trying to predict that now. <nckx>Actually, that might just be me, with my not-quite-static bcachefs-tools & whatnot pulling in stuff. <apteryx>I'll have /boot from 1GiB to 10GiB, does that seem large enough to hold all the kernels copied we'll be keeping there (berlin) ? <nckx>How big is a vanilla-Guix initrd, anyone? <nckx>apteryx: :) (Yes if serious.) <apteryx>I think each generation eats up about 30 MiB <nckx>Of just kernel + initrd? <nckx>30 MiB *is* chonky, but maybe the norm now, who knows. 14 MiB sounds more like what I'd expect. Thanks. <apteryx>so yeah, about 30 MiB to round it up <nckx>I am out of touch. My biggest bzImage is 5.9M. <nckx>Reminder that bzImage (‘big zImage’) was introduced because some nutter managed to build a kernel that was larger than 512 KiB. *nckx nods. I wouldn't joke about that. <abrenon>(and why was it called zImage ? and not kImage ?) <nckx>It was already compressed. <abrenon>but then a zip image can be larger than 512 KiB so what was the need for a new format ? <abrenon>is bzImage still a gzip format, and is the name only a cultural thing ? <nckx>bzImage = small decompressor code prefix + compressed vmlinux. bzImage gets copied to RAM by bootloader, execution jumps to decompressor, which (predictably) decompresses the data and jumps to the real kernel. <nckx>abrenon: You can choose the algorithm, including none. <nckx>abrenon: It was not a gzip limitation, but a Linux one. Remember: 640K low (boot) memory on i686 — who would ever need more? :) <nckx>abrenon: Mine uses zstd, because everything should use zstd and the rest go away (apart from niche stuff like lz4). <nckx>So you can retcon the z to that if you like. <apteryx>alright, the uefi and boot partitions are ready <abrenon>does this 640K thing mean that the first program copied in RAM by the bootloader had to be smaller than this size ? <nckx>Kind of, if you naively stuck the whole thing in that memory area. Which old Linux did, hence the need for a ‘new’ boot process (doesn't mean earth-shattering, but still incompatible) that would put some data beyond the reach of that. Of course, the restriction is ancient and obsolete, and now GRUB itself has been using that extra forbidden memory for decades — for the bootloader :) <abrenon>thanks for the historical comments track ! : ) <nckx>Thanks for indulging me. *jonsger follows nckx in his praise on zstd blindly :) <flypaper-ultimat>rhetorical question: if savannah where to go down, and i want to guix pull/time-machine to a commit of the guix-channel that has been stored by the software-heritage project, would guix know how to handle that? <nckx>Rhetorical answer: absolutely not, unless you manually point it to a mirror. <nckx>Or, at least, it never has fallen back to SWH for me, and it didn't look like it was tryin'. <nckx>I didn't check the code to see if it *should*. <jonsger>I'm on Guix 1.3.0 on foreign distro (openSUSE). This error comes when do someting like `guix install/build icedove` <jonsger>guix install: error: while setting up the build environment: getting attributes of path `/etc/services': No such file or directory <f3n1x`>cannot see ufw package at hand... how do you manage firewalling ? thanks, thanks , thanks ! <f3n1x`>does a guix fresh installation come with some iptables default setup or do you have to setup it afterwards ? *f3n1x` ouch... installing iptables now. <jonsger>and manual should have further details :) <jonsger>there where patches around for an easier service, but i don't think they are merged yet :( <apteryx>nckx: I'm working from this ubuntu SSH installer thing; I've tried 'passwd root' to set a password, but it didn't seem to work. Any tip? <apteryx>I'm trying to shuffle my berlin.scm config across <apteryx>perhaps I'll simply paste in the text editor <nckx>I can log in if you secure me the password. Or has it been lost now? <nckx>But yeah, whatever's quickest. I've used SCP-over-clipboard enough. <nckx>I'm also AFK for a flick, but not long. ***mark_ is now known as mjw
<attila_lendvai>nautilus (gnome file manager) crashes for me immediately after starting it <sneek>Zelphir, you have 6 messages! <sneek>Zelphir, daviid says: actually, the ice-9 modules would be in $prefix/share/guile/3.0/ice-9/, and that dir, nor $prefix/share/guile/3.0 is not returned by any guile proc, you need to build the result 'manually' using what ever guix gives you for$prefix, then (string-append <guix-prefix> "guile/" (effective-version) "ice-9") - copy/update boot-9.scm, compile and install the go file in <sneek>Zelphir, daviid says: in $prefix/lib/guile/3.0/ccache/ice-9, so whatever guix gibes you for $prefix and 3.0 being (effective-version) ... the important thing is that (%site-ccache-dir) won't retrun what yu needm this is for user installed libs go file, guile's ccache is $prefix/lib/guile/3.0/ccache <sneek>Zelphir, daviid says: those steps, to identify where guile's modules are, are very well described in the links i posted, Configuring Guile for Guile-CV, Configuring Guile’s repl-print procedure and Configuring Guile’s raised exception system - given autotool chain vars, just need to ask guix super heroes how to translate those for guix .. <sneek>Zelphir, daviid says: hum, pkg-config vars rather <sneek>Zelphir, daviid says: i found what you need for thelocation of ice-9 file, here - (%library-dir) -> Return the name of the directory where the Guile Scheme files that belong to the core Guile installation (as opposed to files from a 3rd party package) are installed. <sneek>Zelphir, daviid says: all this 'prose' because the guix super heroes were asleep or drinking and dancing at the guix's 10y anniversary :) <f3n1x`>Newbie here! I'm learning Guile Scheme and 'guix shell' altogether. After cloning the repository, when i ' ~/Guix/website-guix-10years $ guix shell -C -m manifest.scm -E GUIX_LOCPATH -E LANG --share=$HOME/.guix-profile/lib/locale -- haunt build ' <f3n1x`>i'm getting this error message : 'guix shell: error: statfs: /home/fenix/.guix-profile/lib/locale: No such file or directory' what am i missing ?! <ae_chep>What is it a sign of when a "guix install ..." freezes at "{X} MB will be downloaded"? <nckx>Zelphir: It's known and due to unrelated maintenance that was planned but moved forward, but thanks for the report! <nckx>ae_chep: Maybe the same thing. <nckx>You got unlucky with your chosen install time. The main substitute server is down and Guix (still) doesn't handle that well. <nckx>Are you installing manually from the CLI or using the ‘GUI’? <Zelphir>Not sure exactly, but I think I had that issue before and what solved it might have been installing the locales in the root guix. For example: `sudo -i` (very important to have the -i!) and then something like `guix install glibc-utf8-locales`. Then leaving the privileged shell again and try to do normal guix things like `guix installe <stuff>`. <foca>thanks nckx, I was having the same problem when trying to install some packages <ae_chep>CLI. I didn't even know there was a GUI <nckx>But first: does ‘grep 7D602902D3A2 /etc/guix/acl’ (in the installer) return a thing? <Zelphir>^^ Today I had a mini presentation of using GNU Guix package manager. Good, that it wasn't down when I scrambled to prepare that :D <ae_chep>well well, I use guix in a foreign distro (archlinux) and archlinux's firefox somehow linked against the guix glibc. So I thought I'd switch to sth from the guix to browse the web <nckx>Sorry, for some reason I assumed that you were installing Guix System. No, there is no Guix GUI, sorry for the confusion. <ae_chep>it's good .I should have asked my question more clearly <nckx>No, you even said ‘guix install’, it was all me. <nckx>Just to be clear, my question still applies. <nckx>If the grep returns a line, you're good to go with the fallback server; otherwise we'll have to authorise it first. <mekeor[m]>hello. "guix pull" leads to "error: failed to load '/home/user/.config/guix/channels.scm': No route to host" for me. any ideas, why? <nckx>No errors before that one, though? That's not clear. Could be improved. A bug report for a better error message (at least listing *which* host(s)) would be welcome if you have the time. <ae_chep>nckx: we'll have to authorise it then. You can just point me out towards a page where I can read the stuff <ae_chep>actually no, I'd rather I'm given detailed instructions as I don't have a functioning browser now :) <nckx>When this is all done, and since I'm basically ‘back’ now whether I like it or not, I'm going to take a look at hosting a very simple status page/endpoint on bayfront that we can point berlin's DNS to next time we need to do the downtimes. <nckx>Finding bugs is great but not at users' expense. <nckx>But you have networking, right? <nckx>(Some people chat from their phone, but again, forgot you were a foreigner.) <ae_chep>hehe, yes indeed. a foreigner and a leecher <ae_chep>I will make the jump eventually but it's gotta be this way for now <nckx>Depending on your leeching softwares of choice. <nckx>Now to hope I didn't typo that. <nckx>That will add said key to /etc/guix/acl, meaning grep should list it now, and Guix will trust the secondary server. <nckx>It has been the default for a while but not long enough to make it to all installations, unfortunately. <ae_chep>or, is this a migration or an upgrade? <nckx>Not a server migration, but the last (hopefully) leg of a storage migration. <mekeor[m]>foca: thanks. i wasn't able to read the chat history ;) <nckx>Puny SSD storage array → 100-TB SAN-chad. <nckx>(With some asterisks, but still.) <nckx>Sorry, I missed that or would have said something: it won't. <nckx>Same root cause but different reason. <nckx>Actually, now I'm not even sure why you're getting that error. <nckx>Could you share that channels.scm? <ae_chep>so, my issue with the install seems to have been fixed. I'll be on my way to fix my browser now. Thank you nckx <nckx>YW, and sorry for the inconvenience. <ae_chep>it caused me literally zero amount of inconvenience <mekeor[m]>nckx: oh, i just read the topic, okay, thanks <nckx>ae_chep: Bless your lying heart (no, that's great). <nckx>I don't know what more I can do to it. I guess some clients just hide it by default? <nckx>I don't think there is <blink> support. <mekeor[m]>anyway, i will be able to continue my thing with --no-substitutes, i'm good :) <nckx>mekeor[m]: No, it wasn't, and we should really work on that. <nckx>In our defence, it was forced by file system errors, but this is still a very poor failure mode and it has been known forever. <mekeor[m]>nckx: am i preventing you from working on this maintenance by chatting with you? <nckx>Hah, very considerate, but no :) <nckx>I am merely consulting; apteryx is doing the hard typing work. <nckx>I ignore the channel then, hence the periods of silence, don't worry. <mekeor[m]>would love to look over apteryx' shoulders now <nckx>Hah. We could almost do that as-is, if the virtual console was more reliable. <nckx>…although it's currently over SSH, so no. <nckx>You'd be looking mostly at Guix running and people staring at mountpoints, lsblks, and grubs.cfg. <jab>nckx: you might just be the funniest man alive. Just saying <nckx>I love how you always say that in a way that can be interpreted as 100% sarcastic. Adds to it. Really. <jab>Definitely not sarcastic in this instance. I'm referring to your fluffball comment. I laughed so hard I almost peed. :) <jab>it was sent in guix-devel. <nckx>Adorable floofy kittens of fascist death. <nckx>Think tiny jetpacks. Also, lazers. <nckx>(I am a fascist. That's important context.) <nckx>Anyway, even if fun, I'd rather keep the drama confined to one place :) <lilyp>Are the substitute servers down currently? I assume the 🚨️ means 💩️'s on 🔥️ <itd_>lilyp: berlin is down, yes <lilyp>nckx: I thought you were a commie? When was your change of heart? <mekeor[m]>i'd appreciate if we stopped joking about being fascists. i only know this kind of jokes from fascists, personally <nckx>lilyp: Horseshoe theory or whatever. <nckx>mekeor[m]: I appreciate that. But if someone calls me one, I'm going to joke about it. But not here. <nckx>lilyp: Not really, it was planned stuff that just got moved forward by a very angry-looking dmesg. Scary, but in the end nothing was actually in danger, and now the job is done, which is nice. <iudrix[m]>"I am a fascist" - translates to I never left my mothers basement <itd_>nckx: thanks for your input on the dot module name thingy. now the import works for me and stuff that used to take hours takes minutes instead. :) <nckx>sneek: later tell lfam: …never mind. I think. <nckx>itd_: Very happy to hear that! <nckx>Fun fact! Kids, did you know mounting a ‘butter effes’ can take up to 15 minutes? ‘crazy’ — noted butter effes expert, apteryx. ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
***maximed is now known as antipode
<lilyp>does this change anything for the weather or do we still need to build stuff "by hand"? *nckx quietly takes the ‘woot’ they had been saving off the table and puts it back in the drawer. Things might not be… good. <lechner>Hi, is there an easy way to get a container with Debian running under Guix? <antipode>Are you looking for an actual container, or a VM? <antipode>If the latter, IIUC the Ganeti service can do such things. <lispmacs[work]>is it just my imagination, or do the Gnome fonts and icons change every time I do an upgrade? (About once per month) <lilyp>lispmacs[work]: there has been a recent breakage (refreshing your cache helps), plus the 42 upgrade <lechner>antipode podiki[m]: i need to sign a Debian package with my key material, but the Debian tools are not available in Guix, i do not think. i am just not good with docker or podman <antipode>lechner: ganeti is not docker or podman. <antipode>Also, it should be possible to package the tools. <lechner>antipode: wow, ganeti is new. i will look into it, although docker seems more lightweight <zpiro> https://github.com/bldur/aguix/blob/main/readme.txt I proposed this at CERN, and probably still work. Where I was the first user of CEPH at CERN back to 2010, but still nor support. Where I could, in a better position have had between 2 and 10 technical students with all imagineable backgrounds working on it until present day. <antipode>lechner: Keep in mind that only the 'Depends' are prerequisites, the 'Suggests' and 'Recommends' are optional. <lechner>zpiro: hi, any chance you can find a channel focused on particle accelerators? you are going to get kicked from here <zpiro>lechner: Perhaps you can find someone with a larger vested interest in GPL code than world of science. <unmatched-paren>hmm, isn't this the same guy who was ranting semi-incoherently earlier? <zpiro>may very well be that respect for some agendas should more easily lead to public service jobs in academia close to ascientifc research activity. <zpiro>For historical reference, the recipient of this proposal is well known to have introduced Linux use at CERN in 1996. <vagrantc>zpiro: it's not at all clear what your proposal proposes <vagrantc>zpiro: and seems to have confused the relationship between gnu and fsf ... <zpiro>vagrantc: build script and setups you need to know about and ask, to find the versions that work for succesfull build of software, are you joking? <vagrantc>zpiro: this is the second time i read that, and while it describes some of the benefits of guix, and maybe it is suggesting for CERN to use guix ... i don't know what you're talking about really. <vagrantc>zpiro: and also suggesting an email from 2016 sent to a very specific group ... i'm not sure what you're expecting to get from #guix about it <zpiro>vagrantc: I was in a meeting with a guy that had name dropping of inventor of c++ around him, for being a bit special for being more known as a fortran hall of famer. Where CERN used to be able to dicate CPU instructions as a major customer and world resources, with people so tied to GCC that CPU instruction news were discussed by following commits. *nckx *** The system is going down for reboot NOW. <nckx>(Should be the last time.) <zpiro>vagrantc: it is tied to a central work methodology at CERN, it is where often systematic errors and quality are done with physics methods. Studying a binary as a physics process for information in and out. <podiki[m]>isn't that why we all go to sleep at night too? :-P <vagrantc>zpiro: so, are you asking people to help you promote guix at CERN? are you letting people know this is a work in progress at CERN? or you want to take this to some other group? or what? <zpiro>Noisytoot: It was dismissed with the main argument that Nix was considered from before, and not in line with needs, tools and alignment with necessary frameworks and communities; roughly speaking. <nckx>zpiro: Welcome back. I noticed you've already been pointed to the CoC, and several users have found your chats distracting & asked you to stay on topic. Now, the link you shared is definitely about Guix, and hence awesome, but everything around it is extremely unclear, including what you're trying to do. If you could focus on clarity rather than volume, that would be great. *nckx tightens braces & goes to check on the TPS reports. <nckx>We've been mounting for 10 minutes, folks. 5 more to go. <mbakke>it's unfortunate that people are evaluating Nix, and extrapolating that Guix also won't work ... I had essentially the same argument with people behind EESSI, which is "Portage for science" (but kind of started as "Nix for science"): https://www.eessi-hpc.org/ <mbakke>#guix-hpc might be more appropriate for discussing Guix in scientific environments however ... <mbakke>also, funny to see you here zpiro :P <zpiro>nckx: I'm admit to ranting a bit, somewhat related to personal issues, and especially in this context. Where is should be able to offer work that others could say yay or nay to. Not having met the Ph.D student behind Guix after chatting with him as an early adopter of gentoo-amd64 and helping people with 32bit chroots for firebox before 64 bit was supported, the reference to work where news about arm64 given <zpiro>to my by reports form bosses about GCC commits. I in that work and interaction met the Ph.D student and founder of CEPH on several occasions in passing, after spending time about nagging for RDMA support. <zpiro>but there is a reverse complaint, that nobody reallt cares. and unless disturbing core activity, support and topic relevant chat. There are no IRC kickable offences for making a bit noise. <lechner>zpiro: unlike you, however, we have no illusions about Guix being an underdog. there is no way CERN would switch to Guix six years ago (!) from Debian or whatever they are using <zpiro>lechner: not really, it is stateless. When I worked there full time, I had diplomatic attache status attached to an LHC experiment. I used it once in a work phone meeting that was important going through airport security in geneva, showing my card. Stopping short airport security and getting their manager that without my help while talking just picked the water bottle out of my bag and gave it to me, where I <vagrantc>zpiro: flooding a channel with offtopic content is totally valid grounds for being kicked from the channel, especially when people ask for you to back off <zpiro>just finish it. No questions asked or answered. <zpiro>vagrantc: not offtopic, and not flooding. No other conversations are drowned out, and CERN relevance and my personal involvement addressed and defended. <vagrantc>zpiro: i'm sorry, this channel is about #guix, not your personal ranting space. <ae_chep>zpiro: it does feel like irrelevant stories with some matching keywords sprinkled in. <mbakke>zpiro: from personal experience, you usually have interesting insight on just about any technical topic, but personal anecdotes about your life experiences are generally not interesting to the wider guix community :P <zpiro>There are two organisations with observer status in UN, and that is CERN and Red Cross, where the former used to be the European backbone on the internet and received first transatlantic conncetions. <unmatched-paren>zpiro: you are typing a lot of text, much of it totally irrelevant to guix... <unmatched-paren>see, the only relevance that last one has to guix is that it involves CERN which you unsucessfully tried to convert to guix this one time in 2016 <ae_chep>I would totally read them in a blog. This may not be the best medium. But I'm merely a guest here so take this only as a personal opinion <lechner>zpiro: also, it's not about drowning out others. a conversation should involve two or more people. we all think you are a nice guy, but you are talking to yourself a little bit <vagrantc>a little bit of off-topic here and there in #guix is fine, but please, understand that this is a shared community space with loosely established norms <nckx>ae_chep: There is no hazing period (no, sorry, all those bugs were real, not a test). You have a as much of a voice as anyone else. <zpiro>offtopic would be to say that IRC is banned at CERN, and while borderline, saying that torrent traffic is thwarted with sophisticated network analysis definitely is off topic, as it is thought to disrupt science. <vagrantc>zpiro: seriously, if you can figure out what the norms of a community are, take a step back and watch <vagrantc>zpiro: i think you've been given some direct and indirect hints that you're out of line <zpiro>vagrantc: I just came back, and answered because it is yellow text here now. Otherwise, as long as barely tolerable. I'll randomly interject and rant about something else, and there could be 1-2 people that apreciate it more than parting, joining quitting and leaving messages. <nckx>All this made me forget to annouce the 15-minute mark. We're back on-line. Happy tooting. *mbakke checks the weather <jab>nckx: how are ya'll ensuring we don't lose data at the servers? raid, backups, off-site backups, underground hand copied backups? Just curious. <vagrantc>bit-for-bit reporoducibility! ... if only. :) <jab>we* that sounds wrong. I am too lazy to help guix in a significant way.... <jab>vagrantc: that would be awesome <vagrantc>it's *mostly* there for guix packages ... but not quite <nckx><as long as barely tolerable. I'll randomly interject and rant about something> I appreciate the honesty but this is not a good plan! I urge you to consider vagrantc's, which was excellent. <jab>I wish you the best of luck! I've lost data soo many times when I was distro hopping. I think I have had the least amount of issues on guix system though! <jab>also a 100TB SSD server sounds awesome! <nckx>No, there is redundancy built into the SAN, so we are normal levels of safe from drive failure. Beyond that, the system configuration is pulled from git (so the latest will always be available on Savannah), and as vagrantc rightly said, the substitutes can be remade, it only costs time. <nckx>They are weird in that their only value is in their enormous collective size, but each substitute on its own is basically worthless. <nckx>Backing them up might not be cost-effective. <jab>SAN -> storage area network...I learned a new word today <nckx>Draw a little cloud, now draw a little line connecting it to your server, bam, done, sysadmin ain't hard. <nckx>We only make it look like that. <jab>I really should take a look at the official guix servers <vagrantc>occasionally there are ones that really need to not be lost (something with a time-based test suite failure that was very core on the dependency graph ... openssl maybe?) <jab>I probably can learn a lot from those <nckx>vagrantc: They are annoying to reproduce, but still not precious. But good point. <nckx>jab: There's just as much duck tape & XXX TODO as anywhere else, but sure! You'll learn something. <vagrantc>not too bad ... guix ~82% reproducible ~today ... seen it as high as 86% ... guessing berlin being down on and off again accounts for some of the unkown % <jab>vagrantc: 86% !? That's awesome! <jab>though that's probably x86_64 bit. <mbakke>vagrantc: we've had time bombs in GnuTLS, OpenSSL, NSS, Node and Serf (a SVN dependency) ... off the top of my head. Perhaps we should have a build phase that warns about certificates with expiry dates ... <nckx>jab: I'm a bit of a preachy zealot, but: hourly back-ups. Automated hourly back-ups. Just do it. It really feels different. That low-level dread? Gone. I blew my / away last week and felt nothing. <jab>nckx: as far as I know the guix server's have not been hacked...so you must be doing something right! <nckx>PermitRootLogin no # security achieved, all done. <jab>nckx: how do you restore your room partition...? do you boot up a ubuntu live CD? mount / and do a "$ mysterious command to resore / backup?" That's how I would do it... <jab>nckx: I bet the OpenBSD guys would laugh at that. Full disclosure...I tend to admire OpenBSD (and not use it). <jab>nckx: probably becuase they do way more stuff in the name of security...so much that porting packages to OpenBSD can be difficult. <rekado>it would help a great deal if we could remove the logs from texlive packages <jab>really difficult. but I'm not an expert. just the way that I conceptually grasp OpenBSD security. <mbakke>rekado: is there a bug about it? <nckx>jab: Uhm… I boot a (in my case, home made, because bcachefs) rescue USB drive, although I now have a dedicated bootable rescue partition in my laptop, and then rsync my backups back to my laptop & reboot. It's boring, almost disappointingly so. Sometimes I mix things up and re-init my Guix System (only restoring stateful files & /home) for that fresh kleen feel. <nckx>jab: I thought you were talking about OpenBSD backups and was really confused. Oh, sure, they'd laugh at our security. I'm not sure that's meaningful, but they would. <zpiro>nckx: actually, OpenBSD is more in line with Open Box ideals. That first of, limited to where machine ware is open, and after that going to work on reliable secure and fast. The former limits the activity, and due to netowkring interest, focuses on adapters more so. <zpiro>nckx: guix here, with a minal set of assembly to bootstrap, can laugh in return. but there may be quirks involved about open default for being supportive of needs of frameworks and programs. <zpiro>nckx: that being said, for arm64 openbsd has sound technical boot loader strategy and what could be called technical guidance. <jab>nckx: I didn't know you use bcachefs? <zpiro>a tremdous amount of effort in trusting hardware, and nitpicking on what runs tied to their defaults. <zpiro>jab: referring to that? at the very least, coaxing binaries and opening up BL0 is a challenge, as just getting things into stable running involves bits and bytes, so BSD licenses is a slit wrist offering. <florhizome[m]><nckx> "jab: I'm a bit of a preachy..." <- What things do you back up? <jab>florhizome[m]: nckx said that he backs up / . <jab>nckx: a bootable rescue partition! That's genius! Why didn't I think of that! <zpiro>GPL is open wrist about support of tools and libraries, but there is admiration and respect for inside and outside of the box for invested skills difficult to avoid. <mbakke>tests are correctly skipped when i manually build -s i686-linux <jab>florhizome[m]: that's probably the best way to do it. :) <civodul>mbakke: looking at the builder of /gnu/store/sdgcjk8wiv4wk69nlxwp43adppmvijpz-imath-3.1.3.drv (from the ci.guix page above), it has #:tests? #t <mbakke>civodul: I filed #58203 about it <mbakke>issues.guix.gnu.org does not see it yet for some reason <rekado>sorry, I’ll start the sync again… <old>Is there a way for me to `guix upgrade` and skip the `check` phase of `rust`? I've been at it for 2 hours now .. <old>I don't really understand why it's building rust either, there should be a substitute for that no? <rekado>mbakke: it’s synced again, so issues.guix.gnu.org now shows 58203 <lilyp>we just recently restarted berlin, so it's slowly getting to 19°C <jab>old: I believe guix tries to encourage to build with tests...building with tests catches bugs. <old>unmatched-paren: awesome thx <old>unmatched-paren: TIL that transform options also applies to guix-build! <zpiro>checking the weather, scheme is great for homework, tied to early adopters with acqquanties of newphe of author of book of pf. <antipode>zpiro: mbakke: A 'detect certificates' phase sounds nice to me, though I think it needs to be an error, not a warning, otherwise it seems too easy to merely disappear in the logs to me. <zpiro>antipode: nope, the ideal is that there are no logic or instructions that give early warnning of such data. where it then comes down to compiler security for having it tight, and perhaps ideally with a certificate indistinct for random data. <antipode>zpiro, I don't understand what you are writing about, I didn't write anything about compilers or security <nckx>florhizome[m]: Yes, /, but the store (and /var/guix/db!) are exceptions to the hourly schedule. It could be done, but it's wasteful. It doesn't really matter that they're fresh. <nckx>jab: <bcachefs> 't was the subject of conversation earlier, so I won't retread, but yes. <zpiro>antipode: well, you can snoop for such data from the kernel, and not trusting anything and assuming the kernel is comprosised you dont want logic form user space invlving pre-processing. <nckx>jab: <rescue partition> Maybe because because you grew up when partitioning your disc was a Big Decision about that 1 extra GiB either way, then recently you realised, wait, 1 GiB is 0.05% of one drive… No? Well, it happened to me. <vagrantc>old: if you build without tests, you definitely will not get a substitute, as it is a different package *vagrantc always tries to leave 10+% of the "disk" unpartitioned to give more room for wear-leveling <antipode>zpiro: The kernel can snoop on everything; what does this have to do with the pregenerated certificates being time bombs? <antipode>Also, I don't think the guix daemon can do anything about the local kernel being compromised, as its run by the kernel. <zpiro>antipode: the vaerage user have one that is healthy, and there need not be identificable special treatment for those that are compromised. <antipode>zpiro: OK. But what does this have to do with time bombs? <zpiro>special things are more resonable for anything not crypto, security and safety. <antipode>To be clear, I'm talking about time bombs in the build process, not exploits on a timer. <zpiro>antipode: been a while since i slited to Rancis. bur special logic not straight forward for certificates at any stage is a time bomb, for instructions and timing facilities down to performance monitoring instructions in the micro kernel. <dabbede>dear all, first time guix user here... someone is aware of an already existing package for xenomai kernel? (deblobbed is probably ok) <nckx>I'm afraid that almost certainly doesn't exist (yet), dabbede. <antipode>zpiro, I have no idea what you mean with "Rancis" and "slited" <dabbede>nckx thanks. I am currently looking into linux-libre package definition to see how hard it is to customize it <antipode>zpiro: I also don't see how all this is an argument for going for a warning instead of an error. <nckx>(You might have found it already.) <zpiro>antipode: Rancid is a punk band that had a hit called Time Bomb. Anyways, dont't do it, for it involves crypto and timeable events for special treatment. <antipode>Could you clarify your reasoning for why Guix should not error out in case of detected pregenerated certificates? <nckx>And how doing so involves ‘crypto’ at all? <zpiro>some cetificates come with a prefix for type of data, and here be9ins the contest of what is boolean possible. <antipode>You seem to be against special casing and time bombs, so I really don't follow why you don't want Guix to fully detect+error out. <dabbede>there is also a good cookbook for customizing the kernel (nckx anticipated me in writing the message) but with xenomai the "difficult" part is that I have to download both the kernel and another tarball (provided by xenomai) "side by side" and then execute the xenomai's script. It seems similar to what happens with the deblobbing script, but it <dabbede>appears order of magnitude more cryptic than what I can read in scheme <nckx>Oh. That wasn't the reaction I was hoping for. <nckx>Well, the (@@ …) don't really help. That's for sure. <zpiro>antipode: I mean is, for being treated as banking for crypto, fast generation, use and execution without further ado. As they certainly get no special treatment and consideration for any reasonn by industry segments, at the unthinkable levere where service and speed is the most important for society.