<dustfinger>tricon: I will let you know. I have not had any time to play with it. I assembled it at the end of the day yesterday and my weeks are generally quite busy. I will post back here though after I have had time to get to know the system more. <dustfinger>I really hope I get get guix working on it with decent performance. It sounds like it will be a challenge, which I don't mind, but that also means it won't happen immediately. <dustfinger>tricon: I was actually going to buy the pinebook pro before I discovered the mnt-reform. ***zub2 is now known as zubbie
<zubbie>anyone know how to see the config.scms the installer uses? trying to learn and seeing those examples would help! <zubbie>nice, thanks.. that's useful for sure <sneek>Welcome back whereiseveryone, you have 1 message! <whereiseveryone>how can I learn more about the status of the python-build-system big update? <podiki[m]>guix-devel or discussion on the patches? not sure <sia[m]>what are the minimum hardware requirements (memory, storage, cpu) for gnu guix system? <lechner>sia[m]: i run it on a 1G nano linode, but updates can take a while <lechner>sia[m]: also, i think you'd do well with 80 G to 200 G in disk space for anything holding graphical user programs. the garbage collector can be a bit aggressive, so i do not run it often right now <sia[m]>lechner: i'm planing to install on a 1g ram as well. i don't have that much storage, but i'll see if i can do it anyway and upgrade otherwise. thanks for the help!! <lechner>sia[m]: please focus on booting first (perhaps via mapped-drives). you may end up installing twice, and everything else may end up being a waste of your time the first time around ***rekado_ is now known as rekado
<lechner>Hi, how can I provide myself a patched version of /share/X11/xkb/symbols together with xkeyboard-config 2.34, please? <lechner>Hi, would someone please offer some packaging advice? I'm taking baby steps! The vendored Golang prerequisites probably have to be packaged separately, but why are the input declarations causing errors, please? http://paste.debian.net/1239753/ <lechner>Also, how can I bump the open file limit in Guix, please? <mroh>lechner: I'm not a go-build-system expert, but I think you commented out one ) to much on the propagated-input comment. <lechner>bu ti still get error: libfido2: unbound variable <mroh>try adding '#:use-module (guix packages security-token)'. I think you don't need to declare "version" twice. <luke-jr>I'm trying to install guix using --no-substitutes, but it seems to be using only 1 CPU core - any way to parallelize it? <mroh>luke-jr: a lot of tests use only one cpu. Maybe, the build is in test phase? <luke-jr>it should almost always be possible to do builds in parallel tho? <luke-jr>hmm, looking at the package list, maybe not for these early ones <luke-jr>but *should* it parallelize by default? or might I need to do something? <mroh>luke-jr: The default --cores param for the guix-daemon is 0, which means all cpu's. <luke-jr>well, I realise Guix doesn't allow a fully trustless bootstrap, but I want to do as close to it as possible <drakonis>i'm not sure how did you come to this conclusion <luke-jr>unless something has changed in the past year or so <drakonis>last i checked, guix already engaged in bootstrapping builds ***unwired2 is now known as unwired
<luke-jr>in any case, using ubstitutes would be LOTS of trusted third party binaries, not even just the minimal <drakonis>there's only two things left, mes and guile at this point <drakonis>and both are controlled by guix's developers? <luke-jr>(and yes, 100% of software on my desktop PC - including my CPU's firmware - is currently built by myself with zero third/other parties' binaries involved) <bjc>it's always going to be more than 0 <drakonis>seems extremely wasteful to recompile everything in the bootstrap chain <bjc>even if you start with assembler, you need to turn that into the appropriate configuration of bits for your computer to run <luke-jr>bjc: as I already pointed out, it's 0 for my current system <bjc>and if you start with the appropriate bit configuration, you're back to blobs <bjc>if you compiled your compiler, you started with a binary compiler <luke-jr>bjc: I cross-compiled my boot USB stick from my previous desktop, which has been self-compiled for over a decade <bjc>no, it's not: you started with a pre-compiled compiler to cross compile your current compiler <luke-jr>the pre-compiled compiler, didn't even support my current architecture, and was over a decade ago on another system <bjc>so? you still had to start with a blob to get going <bjc>the point of the bootstrapping is to reduce that blob to as close to nothing as possible, but it will never be nothing <bjc>the point is that you're not at 0, your bootstrap was just far in the past <luke-jr>anyway, there's no reason Guix can't be fully bootstrappable, and AIUI #bootstrappable is working on that <bjc>it's not limited to guix by any stretch <luke-jr>Guix has a unique circular dependency on its own bootstrap binaries <luke-jr>I could compile Ubuntu from scratch with my current compiler, for example <bjc>you're not bootstrapping from nothing if you use an existing compiler <bjc>the bootstrapping project is an answer to “reflections on trusting trust” <luke-jr>that was already solved in other ways, but certainly is not an issue for my current compiler <luke-jr>anyway, I didn't really want to get into another long discussion on this. it is what it is. <luke-jr>I'm okay with Guix doing its thing isolated in a VM; but at the very least I'm going to build what it lets me :P <drakonis>that seems like a really wasteful thing to do <luke-jr>on that note, the manual says how to enable them, but not how to disable them when they're enabled by default? <littlebobeep>drakonis: you call bootstrapping wasteful?? That's the only way I ever installed Guix!!! <littlebobeep>luke-jr: Sorry how did you compile CPU firmware? You have source for this? What CPU is this? <littlebobeep>I did not know POWER9 had CPU loadable CPU microcode like x86..... it translates machine code instructions also? <luke-jr>no, unfortunately, I don't think it does that <drakonis>i have things to do instead of bootstrapping nearly a decade's worth og gcc <luke-jr>dragestil: I am glad my CPU being busy doesn't mean I can't do other things <littlebobeep>luke-jr: Why is that unfortunate? I think hardcoding the ISA is nice <luke-jr>littlebobeep: well, it would have been cool to implement RISC-V or some other architecture in microcode :P <littlebobeep>drakonis: well we can hope you would benefit from OTHERS bootstrapping with diverse double compilation even if you are too lazy to do it yourself... <drakonis>it is very nice and useful to have it from a trust viewpoint <drakonis>i just think it is incredibly wasteful to do it per machine <littlebobeep>luke-jr: I don't think stage0-posix is ported to POWER9 though, and honestly I do not even see POWER9 mentioned in Guix's commencement.scm so i dunno how you do this? <luke-jr>drakonis: it might be nice if there is a way I could flag binary hashes after I build them and tell Guix on another system later to trust those exact binaries <luke-jr>littlebobeep: well, that's part of why I am not installing Guix on my main workstation ;) <luke-jr>littlebobeep: AFAIK some others have in fact done it tho <luke-jr>is there a way to ask Guix for a status report and/or time estimate? <littlebobeep>luke-jr: Ahhh well nothing in commencement.scm but I see powerpc64le bootstrap binaries referenced in bootstrap.scm and according to bjc's link yes it is supported platform, but from your words you don't even want to use these bootstrap binaries? Without stage0-posix support you will need to cross-compile I guess... <bjc>hopefully the cross compiled binaries that are built will match the existing ones. although i think i saw in the ml today that guile is one of the ones that fails a challenge <luke-jr>littlebobeep: my goal for a Guix install I fully trust, would be to create the bootstrap binaries with my existing system <littlebobeep>Also why are they using GCC 5.5.0 for %gcc-static that is partially written in C++ you need a C++ compiler to bootstrap that, shouldn't it be GCC 4.7.x or less? <luke-jr>cross-compiling from Guix isn't a solution for me tho <luke-jr>littlebobeep: I would guess GCC 4.7 doesn't support PPC64LE <littlebobeep>luke-jr: Well I did not read all responses in bug #41669 yet but if the bootstrap binaries are not reproducably built during cross-compilation that kind of fucks up the entire trust chain <littlebobeep>luke-jr: Why can't you cross-compile from Guix? Don't you have x86_64 hardware? How else will you bootstrap? <luke-jr>littlebobeep: I don't trust Guix yet - the point of this exercise would be to build a Guix I do trust <luke-jr>littlebobeep: so what I'd want to do, is figure out the right version of GCC etc to build with my current system, to build matching bootstrap seeds <littlebobeep>luke-jr: Ahhhh okay fair enough but do you trust Guix starting from stage0-posix going to M2-Planet then Mes and TCC? <littlebobeep>luke-jr: I am not sure what OS you could reasonably trust if not this ^ to cross-compile your POWER9 bootstrap binaries <luke-jr>at this point, I have a PPC64LE system I fully trust, which I compiled everything on from scratch <luke-jr>so no more cross- required, just need to find a way to produce the seeds Guix wants ;) <littlebobeep>luke-jr: How did you start from scratch I don't know how to do this on PPC64LE <luke-jr>littlebobeep: my old workstation was x86_64 Gentoo, bootstrapped from a stage1 over a decade ago <luke-jr>I cross-compiled a PPC64LE USB boot on that <littlebobeep>But didn't stage1 just use an old version of GCC to compile a new version of GCC + even larger binary seed than Guix currently bootstraps from? I never started from stage1 Gentoo but as I understand it they never implemented diverse double compilation <luke-jr>stage0-posix or such might be better if I were to need to start over today, but I'm not comparing stage1 today to it <littlebobeep>Hmmm well I don't see how that is more trustworthy than Guix <luke-jr>over a decade ago, I wasn't a target ;) <luke-jr>and it's had a decade of opportunity that nobody has exploited anything <littlebobeep>Anyway I am pretty sure stage0-posix needs a kernel binary to work so you have to build that somewhere <luke-jr>also, if I can use it to recreate the Guix seeds, then I *also* benefit from Guix's efforts to prove them <luke-jr>(and if people trust me, my doing so provides an independent "line of trust" for those seeds) <littlebobeep>luke-jr: That might be difficult depending on the progress on #41669 <djeis>Can't you toggle the monitor at the base of stage0 in by hand? <djeis>At least, if you had the right hardware for it? <djeis>My understanding was that at least the first couple levels of stage0 could be done on a much more stripped down system without even a kernel. <luke-jr>djeis: the difficulty is that Guix bases its hashes on the inputs, rather than the outputs <littlebobeep>djeis: Yeah apparently stage0, not stage0-posix, works without a kernel, but I have no idea how to practically boot and execute that, does that work from GRUB or what? <luke-jr>oh, maybe you meant something else than what I thought <bjc>a given output should be soley determined by its inputs in guix <djeis>luke-jr: Yea I was just responding to the comment about needing a kernel binary for stage0 <luke-jr>bjc: right, but I can't just take any random output that matches the expected binaries, and plug that into Guix <djeis>Well, you could if it were a fixed-output derivation. <djeis>That's kinda the point of fixed-output derivations. <luke-jr>or maybe my issue was that I wanted Guix to use input binaries without making their hashes match <bjc>you'd have to build your own bootstrap tarball with your own tools <oriansj>djeis: stage0 doesn't need a kernel but stage0-posix does need a posix kernel <luke-jr>ooh, Guix finally started using all my cores *luke-jr hears "jet engines" fire up <bjc>thankfully, guix does have that information. you can see what versions of the bootstrap tools it uses, then cross compile those yourself. then you should be able to put it into the expected paths in the tarball and go <bjc>you will need to adjust the sha of the tarball, though, since it's not actually reproducible according to 41669 <luke-jr>bjc: it would be nice if you could inject tools that don't match, then produce matching outputs that adopt the same hash as the normal ones <oriansj>oh and if anyone has PowerPC hardware and wants it properly bootstrapped contributing to M1 macro assembly developmenet in mescc-tools is an important step <luke-jr>eg, if the input data hashed included only the actual inputs, not the recursive hash of the input's inputs <bjc>luke-jr: that's a pretty big violation of guix's expectations <djeis>You can layer content-addressability on top of guix's model, nix has done that. <bjc>you might be able to use grafts to do it <djeis>But the package definitions, for example, refer to other packages- not on the built hashes of those packages. <bjc>the hashes, in theory, are redundant <djeis>Yea, nix essentially uses grafts to implement content-addressing in order to help with unnecessary rebuilds, but they have to have a trusted mapping of input hash to content hash to do it. <djeis>And it only helps with rebuilds, not the original builds. <djeis>Because the package definitions don't have hashes of their inputs, they just refer to the definitions of their inputs. <djeis>So there isn't a stable hash to inject- the only hash you have when translating each package def to the corresponding derivation is the depencency's input hash. <djeis>Unless you want to wait for all depencencies to build before you can even talk about a derivation. <luke-jr>but if the input hash committed ONLY to the input, it would work <djeis>Right but, until you've built that input you don't know the contents. <djeis>Do you don't know the hash to put there. <djeis>You couldn't even define a package until you'd already built all of the inputs to that package, and different ways of building a dependency would result in totally different package definitions. <djeis>It'd make maintaining the package definitions significantly more complex, and then you also have questions about who's deciding which of those content hashes to put in to the package def. <djeis>Auditing that becomes a headache in and of itself. <bjc>i'm not clear. is the suggestion to add the input hash to the input declaration? <djeis>Input's content hash, was my understanding, yes. <djeis>That being said, I'm pretty sure the bootstrap tarball is a fixed-output derivation: its content hash is part of the package definition. <bjc>that'd break any time the hash isn't stable, which shouldn't happen, but definitely does happen <djeis>If you want to supply your own bootstrap tarball you can just edit that content hash. <bjc>i assume the bootstrap tarball just has a sha assigned to it like other tarballs <luke-jr>djeis: then everything else won't match :P <djeis>But that only matters if you want to use the official substitutes. <djeis>Nix's content addressing would also help there, actually. <luke-jr>is that what grafting would do? lie about the hash of inputs? <bjc>the hashes may end up converging after a couple rebuilds anyway <luke-jr>bjc: I don't think they would? unless you go back to bootstrapping again <djeis>Grafting is taking a built package and changing one of its dependencies by replacing paths in the content of the package. <djeis>It produces a new package where the dependency has been replaced. <bjc>if things are working well, they'll converge, since the bootstrap will build the next phase, which should now be at least the same version of things built the way guix expects it, and then the build from then on should be, ideally, the same as what the substitutes servers produce <djeis>It lets you change a dep without doing a full rebuild. <djeis>Nix does something similar to grafting to implement content addressing. <luke-jr>bjc: but the input hashes won't match still <bjc>you will likely have to change a fair few hashes on the first post-bootstrap rebuild, yeah <djeis>He's suggesting you build the bootstrap tarball using the bootstrapped guix. <bjc>and maybe some after that, but it should be fewer <djeis>Then you take that new bootstrap tarball and bootstrap a new guix out of it. <djeis>In the hope that eventually you produce a bootstrap tarball with the same hash as the one we already use. <djeis>B/c the guix you bootstrap off of that will have the same hashes as ours. <luke-jr>I think I might have actually tried that once, and didn't get far <luke-jr>probably because I didn't/don't know what I'm doing XD <djeis>Since the bootstrap tarball is a fixed-output derivation (a content-addressed/content-hashed dependency) it doesn't mater what you used to build it. <djeis>But if you use an already bootstrapped guix to build it you have a better chance of producing the same bootstrap tarball we're already using. <djeis>At which point the rest of your dep tree will match. <bjc>i don't know if you have to have the tarball match exactly, since presumably the things that differ are going to be minor (rather than a sign of broken code or malfeasance), in which case, even if the hash for, say, gcc is different, the binary produced by that gcc will still be bit identical with the one produced by the existing bootstrap tarball <bjc>rebuilding the bootstrap tarball is probably the most straightforward way to get to that point, but i wouldn't go past doing that 2 or 3 times <djeis>Well, for the bootstrap tarball that's actually at the root of the derivation tree it would need to match exactly. <luke-jr>djeis: the hard part was getting Guix to accept the divergent bootstrap tarball <djeis>I would expect that'd just be a matter of editing a sha at the right spot in the code. <bjc>does guix actually verify the hash of the tarball after its been downloaded? <djeis>It's treated just like any other fixed-output derivation. <luke-jr>djeis: IIRC Guix wanted a different hash than the one it injected it with <djeis>Well, the definition probably cites a particular place it tries to download the tarball from so you might've needed to change that too? I've not actually looked at the in-tree definition of the bootstrap tarball... Lemme see if I can find it. <bjc>oh, is the bootstrap tarball the root of all packages? <bjc>i suppose it must be <luke-jr>IIRC, there was some way I injected the bootstrap, then it gave me a hash, and I put that in the relevant file, and Guix refused it <euandreh>Does Guix have the server/daemon component of libnotify? I couldn't find anything related to that in gnu/services/desktop.scm <luke-jr>but it's been over a year since then, so I can't really elaborate or be sure <bjc>‘guix download’ will get the hash you need, which you can then put into the package definition <luke-jr>weird, my infinite bash history lacks any mention of whatever it was <djeis>Ah, there are a couple bootstrappnig tars. <djeis>They're all defined in gnu/packages/bootstrapping.scm, as might be expected, and there's a lot noise because the single file needs to handle a bunch of architectures all at once... <djeis>So you'd probably need to replace quite a few of those hashes to do the whole build yourself. <podiki[m]>euandreh: I'm not sure what you mean, doesn't libnotify run in the background on demand anyway? (via dbus? I don't know but didn't need any setup for me) <euandreh>podiki[m]: That's what I thought, but it's not working. IIUC so far, libnotify needs a daemon to talk to dbus, and notify-send is only a client to it <djeis>What desktop environment are you using? <podiki[m]>for me, I'm using dunst and can send notifications that way, which I think is all just libnotify in the backend <djeis>Usually that, or some standalone notifier like dunst, provides the server side of that. <djeis>Yeah, libnotify talks to your notifier daemon over dbus. Dunst is one such notifier, DEs usually provide one but you'll need to pick/run one yourself if you're just using a wm. <podiki[m]>euandreh: what is your set up that is not working? <luke-jr>is there a way to see --dry-run with a dependency tree? <djeis>Do you have a notification daemon running? <podiki[m]>in case it helps, I only have dunst installed explicitly, so no notify-send available; if I do guix shell libnotify then I can use notify-send and it works as is <euandreh>I'll try adding dunst to my home environment <euandreh>nice, just running dunst works fine, ty :) <euandreh>do you manually start dunst from i3/xmonad, or did you write a system service for it? <euandreh>I've added an exec line on i3 for now, seems to work fine <euandreh>podiki[m], djeis: thanks for the help :) <podiki[m]>I don't think I start dunst anywhere, I believe it is all done on demand (dbus I assum) <attila_lendvai>was there discussion about setting up a logger library for the guix codebase? i badly miss it in some parts of the codebase, like the importers... <sneek>Welcome back attila_lendvai, you have 1 message! <bovid-19>Hi! I've installed an Emacs based on emacs-with-native-comp (from github.com/flatwhatson/guix-channel), but transformed to use the master branch (http://paste.debian.net/1239789). Now I'd like to pin it so it doesn't recompile as soon as I use it as an input of another package. Is there any way to find out which commit a package was built from? I had a look at the symlink I got from `which emacs-29.0.50', hoping I could use the <bovid-19>shortened hash in the directory name, but it's located inside `/gnu/store/nx6f4xjrvzdqjb0s32q1qyhxm29xp2r0-emacs-native-comp-28.1.50-199.5e47d62'. <nckx>And that's not the hash? <nckx>apteryx: I don't think I can cennect. <nckx>I'm using the Androidical Jami if that matters. <apteryx>perhaps my rendezvous point is messed up, I'll restart the service <nckx>There's a green dot next to it... <mothacehe>apteryx: hey! i'm connected but cannot see anyone is it normal? <apteryx>there seem to be a problem with it (nckx couldn't join), so I'll restart it <nckx>I'm ah mothacehe's experience now. <mothacehe>it's rdv-guix-jami as you wrote in the email or rdv-guix-maintainers as it used to be? <nckx>I'm using r-g-m without luck. <nckx>Brief flash of apteryxface. Progress! <apteryx>nckx: perhaps you can try joining audio only? <nckx>You'll miss beautiful shots of the absolute middle of nowhere but tant pis. <nckx>apteryx, mothacehe: I give up. Feel free to continue in French :( I'll send an e-mail later. <nckx>Thanks for answering my questions! <tricon>yewscion: apparently sneek doesn't want your botsnack. <yewscion>tricon: apparently. Maybe sneek is full? <tricon>Poor bot has no garbage collection. <attila_lendvai>every once in a while i reach this: substitute: In procedure write_wait_fd: unimplemented <unmatched-paren>what does "the source file name should contain the package name" mean? it's from the linter <apteryx>the file name of the origin used as the source <apteryx>it takes a (file-name ...) argument; commonly provided with the git-file-name proc for git checkouts <apteryx>clarity; if you 'guix build --source foo' and you can '/gnu/store/xxxx-checkout', that's not as nice as '/gnu/store/xxx-foo-version-checkout' ***ChanServ changes topic to '!! Website, CI, MUMI down for maintenance !! 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'
<attila_lendvai>i started to use home services, and it did something with my fonts... random anomalies, like gnome password entry font is a bit smaller, emacs displays some unicode chars with an enormous line spacing, etc. what am i missing? <unmatched-paren>attila_lendvai: it does some stuff with fontconfig afaik, but i'm not sure how that would mess it up <attila_lendvai>nothing special, points to <dir>~/.guix-home/profile/share/fonts</dir> <attila_lendvai>wild guess: maybe i simply have a different set of fonts installed in the user profile now, that overrides/shadows the system fonts that previously were available for my user... <luke-jr>I assume someone knows the website is down, right? <luke-jr>would that have caused my no-substitutes install to fail too? <lechner>Hi, do Guix profiles work with networked home directories? <apteryx>sneek: tell rekado was there a 2nd public IP to reach ci.guix.gnu.org? via which I could hop onto Berlin's iDRAC <sneek>rekado, apteryx says: was there a 2nd public IP to reach ci.guix.gnu.org? via which I could hop onto Berlin's iDRAC <apteryx>sneek: later tell rekado was there a 2nd public IP to reach ci.guix.gnu.org? via which I could hop onto Berlin's iDRAC <jfred>Hmm... so I've been using 'guix home' to manage some of my dotfiles and my user's packages, and lately it's been getting stuck on 'Finished updating symlinks.' near the end of a reconfigure. Has anyone else experienced this? <bjc>are you managing shepherd with guix home? <bjc>and have you done a pull recently? <jfred>oh, yes, I am - and I may be slightly out of date there <jfred>(was there a recent fix for something like this?) <bjc>it was an issue a month ago or so, but it should be fixed now <bjc>do a pull and try again <jfred>will pull once CI is back up I think haha <WesterWest[m]><jfred> "will pull once CI is back up I..." <- if i understand it correctly, you can just update with —substitute-urls=“bordeaux.guix.gnu.org” as that server is not down <WesterWest[m]>btw should the guix command really fail when substitute server is down? even if others are available? <lechner>Hi, is anyone serving Wordpress from Guix System? <lechner>Also, is there a way to get exim4 running? <tricon>lechner: I run a Guix server with WordPress. <lechner>tricon: Hi, that's great! do you use Apach or Nginx? <dirtcastle>new to guix. can I give options for ./configure alongside guix command. <vivien>lechner, exim4 doesn’t work well with guix (I tried to improve the package some time ago but it’s difficult), I use opensmtpd instead <unmatched-paren>dirtcastle: in a (package) that uses gnu-build-system, you can use (arguments `(#:configure-flags (list ...))) to add extra configure flags to a package <unmatched-paren>(define-public foo-modified (package/inherit foo (arguments `(#:configure-flags (list ...))))) <unmatched-paren>put that in a scheme file with `(use-modules (guix packages))` at the top and `foo-modified` at the bottom (so that evaluating the script returns foo-modified's package object) <unmatched-paren>and then run `guix package -f FILE.scm` to install it, or `guix shell -f FILE.scm` to try out your changes <dirtcastle>I'm thinking of Bringing gentoo level of compile time optimisation and use flags profiles into guix <unmatched-paren>or, if you're using `guix home`, you can put the definition of foo-modified in your home configuration, and add the resulting variable name to your home's packages list <unmatched-paren>dirtcastle: guix is nothing like gentoo, from what i can gather about gentoo <dirtcastle>yess. basically options u give into ./configure. <lechner>vivien: Great! The Guix docs are down. Can you share any part of your config or setup, please? <lilyp>for instance USE xorg would specify for every graphics toolkit to build the xorg backend, whereas USE wayland would build wayland <unmatched-paren>dirtcastle: to get that kind of customization, guix provides package inheritance <dirtcastle>sometimes u can add remove software features for certain software. <lilyp>however, use flags can imply or conflict with each other, making USE NP hard <lilyp>what's worse is that you can set them per-package on top, so every gentoo setup is its own special snowflake <lilyp>you can trivially encode 3SAT in use flags <lilyp>it was one of my distros before switching to Guix system <lilyp>boolean satisfiability with three variables per clause *unmatched-paren was about to visit the guix blog to remind myself about package tuning, and then realized :( <dirtcastle>hmmmm.... definitely that was like a language that I don't know <unmatched-paren>dirtcastle: don't worry, scheme isn't that complicated :) just its users generally seem to be people who know a lot about CS theoretics <unmatched-paren>continuations are the most mind-bending bit imo, but it's not absolutely essential to understand call/cc to use guix <dirtcastle>unmatched-paren: nice. u said the right thing at right time. I anyway have to learn common lisp. I heard scheme is different but simpler than CL <dirtcastle>how nixos has lots of packages when the community seems so small. the subreddits have only 2000 ppl. irc also has less ppl. but arch Linux has now than 1 million and irc also has around 2500 etc iirc. who is making these packages/build scripts. <unmatched-paren>(define (frob foo bar) ...) is equivalent to (define frob (lambda (foo bar) ...)) <unmatched-paren>dirtcastle: generally it seems to be easier to create a nix or guix package? idk <dirtcastle>i thought they figured out a way to automatically generate buildscripts somehow <unmatched-paren>you can define a scheme procedure or nix function to make a repetitive task easier <unmatched-paren>as a (poor) example: before python2 was deprecated, we used some procedure to convert a python3 package to python2 <dirtcastle>unmatched-paren: they are almost equal in number of packags when having such a big difference in userbase <unmatched-paren>dirtcastle: the AUR is almost equal to nix's package repo??? really??? <littlebobeep>Hmmmm Is there some error on my end, or is guix.gnu.org down? <dirtcastle>unmatched-paren: exactly what I want in a package manager <djeis>Since I can't just look through the issue tracker, anyone know why guix ships a broken QtWebEngine? <djeis>Trying to play around with qutebrowser and faceplanted right in to that lol <dirtcastle>unmatched-paren:i just thought I'll end up writing lots of buildscripts why not have an option to make guix gentoo like. <nckx>djeis: It would help if you described how it's ‘broken’. <nckx>Not that I know the answer. <djeis>Some text doesn't render properly, the qutebrowser dev says its due to the QtWebEngine from guix not having some patch or such. <djeis>The quickstart page's keybindings are missing and the devtools don't have any text. <unmatched-paren>dirtcastle: i can assure you though that you will prefer guix's way of doing things once you get to know it :) <djeis>The chromium devtools, that is. <nckx>Some upstream patch? As in our QTWebEngine is out of date? <dirtcastle>unmatched-paren: hmm. but I was thinking at worst case just implement portage in scheme. <djeis>Quoting the message he just sent me: "not really guix-specific to be fair, but guix seems to be the only distribution still shipping such an old unpatched QtWebEngine while shipping a much newer glibc" <nckx>djeis: By the way, you can still send mail to bug-guix@ and it will still end up in mailboxes and on the ‘main’ (if ugly) debbugs archive page. <unmatched-paren>dirtcastle: and that applies to your whole suggestion to turn guix into gentoo: why not just use gentoo? <dirtcastle>unmatched-paren: I have this ambitious goal of creating a package Manager that can give extremely easy user interface and the the option to download packages in stable, rolling and source based way. all three in one. apt is good at stable release. arch is good at rolling release. gentoo at source based. and we need immutable , reproducible and roll back nature of guix/nix. mix all of them together. I think guix does 3 already upto some level? <dirtcastle>stable, rolling and being nix like. so only Bringing the features of gentoo is left. <unmatched-paren>dirtcastle: guix brings different features to gentoo, with the same or better results :) <unmatched-paren>what _exactly_ is it that you're missing? i think you'll probably find that there's a way to do it in guix <dirtcastle>theoritically u can do everything u can do on gentoo. but gentoo does it with less human intervention <unmatched-paren>(package/inherit ...) 1. allows guix to fulfill reproducibility goals, because you have to create a new package or modify an existing one to get different results and 2. gives you far greater control <unmatched-paren>i suppose i'd better show you how to use (package) so you know how to use (package/inherit) <dirtcastle>unmatched-paren: mainly this - there are profiles in gentoo. u can choose desktop ( which means Xorg) gnome and kde. when u select a profile, say gnome all the packages u compile will get gnome support but kde and xorg support will be removed automatically. <unmatched-paren>so, package is basically just a guile object (package ...) with s-expression fields (package (foo-field ...) (bar-field ...) ...) <unmatched-paren>metapackages are basically packages that do nothing except propagate other packages to the profile <nckx>I wouldn't compare them to Gentoo profiles though. That will only bring misexpectations & disappointment. <lilyp>you don't, it's a rare convention <apteryx>djeis: jami-qt uses qtwebengine. It works. <unmatched-paren>i'm not even aware of any packages that have specific gnome support or specific kde support that you might want to toggle? <lilyp>xfce is also a meta package fwiw <dirtcastle>I'll try to implement this in my free time. got elisp, common lisp , guile, scheme to learn. <djeis>apteryx: Some websites work just fine in qutebrowser too, but others have large stretches of missing text. <dirtcastle>unmatched-paren: really? i think a lot of gui apps will have that. i might be wrong. <djeis>I wonder if it would be helpful for guix to have a notion of package variants beyond just version number... <djeis>I suspect package with multiple outputs cover some of that. <unmatched-paren>djeis: couldn't you just inherit the package and make your changes though <mroh>perhaps, we could wrap these pkg's that use qtwebengine (and need text rendering) with --no-sandbox?! <djeis>I'm thinking about multiple supported variants that coexist in the official repo tho. <djeis>So they both have provided substitutes etc. <djeis>Sure, and you could just name them differently. <nckx>djeis: Guix doesn't ‘resolve dependencies’ like other package managers, so what's the use case? I.e. you can't say ‘barpkg requires foopkg with features A & B set, C unset, I don't care about D’. <dirtcastle>unmatched-paren: just really make one distro that can do everything that other distros do. a distro that has everything which will put and end to distrohopping. <nckx>djeis: So there's no need to specify variants beyond what we already do: foopkg-with-foo@1.0, foopkg-minimal@1.0, etc. <djeis>nckx: I'm essentially wondering if guix should have the option to work that way layered on top of the existing logic. <nckx>I wonder if it even can, or if it even makes sense. <djeis>You'd need more metadata attached to the different packages. <nckx>Hm. What would you do with that metadata? <djeis>Idk, I'd need to think about it... <dirtcastle>unmatched-paren: I've seen one that'll totally relate to this scenario. :D. <djeis>Probably wouldn't be worth the effort. <nckx>I don't want to pin you down to one concrete use case or kill your dreaming (far from it!), but I'd find it easier to discuss. <nckx>That said, bye for now o/ <blake2b>i'm able to guix pull locally fine, but with my linode server I'm getting: "guix pull: error: corrupt input while restoring archive from #<closed: file 7f2525443770>" <blake2b>sorry I'm a bit confused, you aren't having problems or you are? <unmatched-paren>there is maintainence going on, but seeing as you can pull locally, i'm confused :) <blake2b>haha, sorry, I can pull locally *but* my remote linode server fails with the above error on guix pull <blake2b>I'm wondering if thats due to perhaps the region where my linode server is, or maybe the linode ip was blocked for whatever reason <blake2b>I get a similar error trying `guix install`, I'm building packages locally atm <nckx>Berlin (‘CI’) being down shouldn't break guix pull. Perhaps your Linode guix still has cached ‘this substitute is good’ URLs that it tries to download anyway, and guix is still very bad at handling network failures. <nckx>I cannot sufficiently stress how extremely bad Guix is at handling network failures. <nckx>Maybe rm -rf /var/guix/substitute/cache/* — it certainly won't hurt, although I'm not sure if it will help. <f1refly>how do i suspend my guix system? with systemd it was systemctl suspend, but I don't know how it work here <nckx>f1refly: s/system/login/ <blake2b>cool, I'm trying --with-subs rn, I'll try that next if it fails <blake2b>using the subsitute url worked :), thanks <f1refly>i don't understand what you're trying to tell me with that nckx <nckx>blake2b: In theory (well, and in fact) substitutes are fully transparent, and your local guix has all the information it needs to calculate the pull locally, if slowly. It just refuses. Borderline bug. Definite annoyance. <nckx>f1refly: Sorry, it's sed. <nckx>‘Replace systemctl with loginctl’. <f1refly>i thought you meant 'guix system' -> 'guix login' <f1refly>i only notice systemctl indeed also has system in it of course <f1refly>my bad for not thinking hard enough ^^ <nckx>My bad for forgetting /g, and also just not thinking enough in general. <nckx>apteryx: You still around? <nckx>I think perhaps we should clarify the possibly longish duration of the ‘maintenance’? <nckx>And hell if I'm not going to abuse this chance to add mojos. ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix ⚠️ Website/CI/issues indefinitely down for maintenance ⚠️ | 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
<luke-jr>anyway, guix-system-install-1.3.0.x86_64-linux.iso fails to install :/ <luke-jr>idk why it wants texlive for a supposedly minimal config in the first place? <sneek>rekado, apteryx says: was there a 2nd public IP to reach ci.guix.gnu.org? via which I could hop onto Berlin's iDRAC <rekado>so, uhm, it doesn’t boot because of degraded btrfs things <rekado>nobody told me I should be around for any maintenance <atka>I don't know what happened but I feel for you rekado <rekado>I don’t know what the current setup is and what generation I should expect to work. <atka>side note, btrfs raid should be run on more than the minimum required number of disks to avoid degraded mounts and downtime <rekado>apteryx: I can powercycle ci.guix.gnu.org again <atka>ie raid1 minimum 2 disks but with 3 you can still survive a drive failure without mounting degraded *rekado powercycles the server <luke-jr>so even after I found the missing patch file and guix download'd it, guix is still refusing to use it? :/ <nckx>atka: Don't quote me but I think it's ‘raid’1 over 6 discs, or something ridiculously redundant like that. <nckx>Which, yeah, I know is flawed. <nckx>Ridiculously redundant without ridiculous redundancy (RRWRR). <atka>nckx: hello! haha yes, but with so many disks when would you ever have to deal with degraded mounts? <nckx>As soon as one fails, I'd guess? Due to how btrfs ‘raid’ raids rather poorly? I'm not a btrfs user tho'. <luke-jr>I used to be a btrfs user. finally got rid of it a few years ago <atka>well that's what I'm saying <atka>with more than the minimum (2 for raid1) degraded is not needed <atka>only if you fall below the minimum number of disks <rekado>the problem here is not degradation but enumeration. <rekado>the partitions are not ready when they should be, and nobody is there to tell the system to wait <nckx>atka: The fact that that such logic doesn't make sense (to me) and yet I believe it confirms my prejudices of btrfs. 2 drives failing in a 6-drive array will still kill data, so at 5 it *is* hella ‘degraded’. <atka>hmm maybe one of the extra copies would be better with raid1 and six disks <nckx>atka: In this case all 6 drives are up, but thanks for the general advice anyway. <atka>but what is the data worth :) <atka>I feel you, bcachefs can't come soon enough <nckx>Yeah, for various reasons it would be a nice fit for berlin. I almost mentioned it today in the maintainers meeting but got cut off before I could start preaching. <nckx>(berlin = the server currently feeling poorly.) <luke-jr>I guess this is a bad time to get normal guix help? :x <nckx>A fact, but also, define terms like ‘use it’ if you want to lure more people to your problem. <luke-jr>it continues to give me sha256 hash mismatch <luke-jr>presumably still trying to use the bad download <atka>nckx: I have to run but it was nice to cross paths again, could we possibly discuss fstrim on luks root partitions some time? I would like to work on a patch if you can offer some guidance <nckx>We'll need more info than that. <luke-jr>is there a wgetpaste-like tool on the install ISO? <nckx>Hm. I thought wgetpaste was on it. <nckx>Is there a similarly-named tool with which I'm confusing it? <luke-jr>normally I would ls /usr/bin/*paste*, but I don't know where to look on Guix :x <lechner>Hi, is anyone serving MTA-STS info with Nginx's special .well-known setup in Guix? <nckx>atka: Same! Yes, I've been completely absent lately. I'm backish, and would love to, ping me next time. o/ <atka>nckx: thanks! have a good one! <nckx>luke-jr: Oh dear what happened to your $PATH? <nckx>I'm not in a position to spin up an installer ISO/vm, I'm afraid. <luke-jr>looks liek there's no wgetpaste-like named *paste* at least :/