<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>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?
<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?
<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>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.
<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.
<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>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.
<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)
<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.
<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.
<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>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.
<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.
<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>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>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>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.
<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>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).
<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 :)
*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.
<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 ?!
<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
<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.
<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?
<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.
<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.
<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 ...
<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.
<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.
<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).
<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.
<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>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.
<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.