<nckx>apteryx: I've never used pip or even Python outside of Guix packaging, but it turned out to be a different issue anyway. Thanks! <drakonis>so, the pypi importer has a dependency on unzip <the_tubular>Will I run into problem if I unninstall sudo from a guix machine ? <nckx>I mean, you'll not be able to sudo, so if that's your only route to privilege escalation you'd better not do so. Is there a reason (beyond curiosity) you ask? <nckx>drakonis: It's the old ‘do we want a hard dependency on something that is relatively (very) rarely used at runtime’, with no hard right answer. In this case, since the error is quite clear (considering the audience of guix import), I'd say no, but feel free to disagree and open a bug ☺ I may well be outvoted. <lilyp>It's likely you'll still have sudo in your closure regardless, though not with setuid IIUC <nckx>Dead useless misleading sudo is probably worse than no sudo. <nckx>…although I don't expect making guix depend on unzip will be an easy sell either. <cehteh>on a server i have zero passwords, ssh key auth, no sudo <nckx>As long as you have a way to gain root (e.g., traditional root password log-in), I'm not aware of any important dependencies on sudo. <nckx>This is fully divorced from the question ‘is it a good idea’ ☺ <cehteh>having the necessary 'secret' to become root stored on the server even in /etc/shadow is more dangerous than having key auth <the_tubular>I mean, what's wrong with using su nckx, it's already on your system anyway ? <nckx>Note that I've only used sudoless systems in non-graphical modes, but then, if (e.g.) GNOME needs sudo, that's not really Guix's fault. <nckx>the_tubular: Nothing? Plus there are sudo alternatives like doas; sudo itself is certainly not a core requirement of any system, just very entrenched. <nckx>To the point that it's a meme. <the_tubular>Well I heard it was a hardcoded dependency in a handful of programs <nckx>doas make me a sandwich said no-one ever. <cehteh>the_tubular: it is reasonable safe yet, but for sudo you need to enter the plain password into the the machine, there are tons of layers between keyboard/terminal/vt that open attack vectors <nckx>Although it's hard to tell since they won't have ,sudo as an input (because they need to use the setuid one). <cehteh>having key auth reduces this to pretty much ssh security only which i trust more <lilyp>actually, I think the underlying mechanism is PAM <the_tubular>Ok, so that was my first "dumb" question; here's my second one <nckx>And my opinion is if x breaks because sudo isn't installed, that's a real upstream bug in x. <nckx>Calling the sudo binary is a *horrible* general-purpose privesc API. <the_tubular>This is a VM I had for testing before installing guix on baremetal, when I try to guix system reconfigure I get : <the_tubular>guix system: error: '/gnu/store/354vgnsb0lfbpn059ndlkn55irhagk4p-grub-efi-2.06/sbin/grub-install --boot-directory //boot --bootloader-id=Guix --efi-directory //boot/efi' exited with status 1; output follows: <the_tubular> Could not prepare Boot variable: No space left on device <the_tubular>I know the error is straight forward, but I didn't mess with any space allocated to /boot <cehteh>was there linux before on that machine? <nckx>No mention of /boot, nothing to do with /boot at all ♪ <cehteh>thats efi crap .. some things there may not be cleaned away when unused <nckx>the_tubular: I can't remember the commands off-hand (because highly unmemorable), but you'll be using efibootmgr to delete boot menu entries you don't need. <cehteh>that happens with bugs and resinstalling OS'es / kernels often <nckx>the_tubular: Are you still talking about the nvram? <nckx>This has nothing to do with disks. <cehteh>put in some random live cd and look into /boot/efi/ ... which is a filesystem mounted there <nckx>NVRAM = flash chip on your mother board, and a generally tiny one at that. <cehteh>efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime) <nckx>It modifies grub.cfg, totally unrelated. <cehteh>debian here, may look different for you <the_tubular>So how do I make it so my NVRAM isn't getting full every X weeks/months ? <nckx>The boot entry is just ‘Guix’ (IIRC), pointing to Guix's GRUB, it doesn't matter how many or which generations you have. <cehteh>and there is shitload of important stuff and you may brick your mainboard with fat fingers <nckx>I'm not really sure. I don't know why it happens to some people. <cehteh>but some old installeds leave cruft there which piles up <nckx>Yeah, I don't generally recommend messing with /sys/firmware/efi/efivars, even though it's a valid suggestion. <cehteh>its a bug in the previous attempts to install OS'es / kernels /bootloadsers <cehteh>i dont say mess with it but google for help <nckx>It's dangerous if your firmware is buggy, and a *lot* of firmware is buggy. <cehteh>would a bios reset fix this? i dunno <nckx>cehteh: By ‘mess with it’ I mean ‘mount it rw and delete anything’; I know you weren't suggesting deleting random crap. <cehteh>yes, sill some remants pile up there thats the bug <nckx>the_tubular: You're talking about disks again… <cehteh>the_tubular: this is a chip on the mainboard not a disk partition <nckx>It's the devil's plaything. <cehteh>you may try a bios reset that could help .. tip: make screenshots/photos from all bios pages first where you did customization ***stikonas_ is now known as stikonas
<cehteh>also: /dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) <cehteh>thats a real disc partition which may be clobbered and that could be recreated <nckx>I think the efibootmgr commands would be ‘efibootmgr’, then ‘efibootmgr -B 000n’ to delete entries you know for certain you don't use. <cehteh>problem is that 'for certain' :) <nckx>No. It's ‘triggered’ by Guix in that Guix invokes efibootmgr (via GRUB, actually) more often than most others, but it's not to blame. *raghavgururajan peeps-in <nckx>You can tell Guix not to reinstall GRUB on each reconfigure but that probably has its own gotchas, so I can't blindly recommend it. <lilyp>So just to get this straight, assuming that I'm always reconfiguring the same Guix over and over, will it fill /boot/efi unconditionally? <nckx>Uh, I guess your grub.cfg could grow to many many megabytes and fill up your /boot partition…? But no, not /boot/efi, unless GRUB 6.0 is just so bloated that it no longer fits. <nckx>Oh, we don't officially support separate /boot anyway, so that's safe too 😛 <lilyp>Well, too bad I'm using separate /boot on some efi-less machine :P <cehteh>i'D wish there would be some safe way to pass the hd encryption password from grub to the kernel <nckx>I've never heard of /boot/efi running out of space, although I'm sure it's happened to someone (probably not using Guix — we don't tend to ‘dual boot’ the traditionally misbehaving OS). <nckx>Patches (really) welcome. <lilyp>ahh, but what about dual booting the other misbehaving OS (Ubuntu) <cehteh>nckx: i that was some bug under certain conditions some time ago, even under debian <cehteh>but needs some special constellation of the stars <nckx>Which subject are you referring to? <cehteh>a friend had that, but its some years ago (maybe 2-3) <cehteh>was pita to diagnose because who would think about that <cehteh>he made a crontab job to clean it :) <lilyp>but to recap, stuff like that ought not to happen under normal Guix-only usage, right? <cehteh>actually this should never happen <nckx>We've discussed a few wildly different things, but I think the answer to all was ‘no’, yes. <nckx>‘Should never happen’ is always fun when it inevitably happens. <cehteh>not under guix, not under any other linux and not even under windows (omg i saied the w-word here :D) <lilyp>phew, no need to force that thing into legacy boot then <cehteh>when your bios isnt from stone age the legacy is just some emulation on top of efi <nckx>Sure, but at least GRUB won't try to update EFI variables in CSM mode and hence not trigger that bugpath. <cehteh>but no one knows if the firmware under the hood does that on the bootloaders behalf <lilyp>Yeah, I'll let MS have fun trying to figure out how to bug MBR. <nckx>Yes it's all extremely bad code, but if one terrible stack happens to work for you… <nckx>Yay for {Core,libre}boot. <the_tubular>So here's another dumb question : if it's NVRAM, why does it get emptied when you remove CMOS ? <cehteh>unfortunally the hardware choices are pretty limited <nckx>Sorry: ‘It doesn't’. Missed the ‘why’. <nckx>It's not battery-backed. <cehteh>the_tubular: i saied 'try' i am not sure but with a dim chance it may be a way to reset it into some initial state <cehteh>yes, but only for a try, i tihnk your chances may be minimal that it worked, but it would have the highest chance not to brick the mainboard <nckx>I hope you're not opening up your machine to yank out the CMOS battery to do so 😛 They mean choose the ‘reset settings’ option in the firmware menu. <nckx>This will write new/zero/empty/whatever values to the memory. <cehteh>unsolder the nvram chip put it on a breadboard and connect a isp programmer to it :) <nckx>You won't be zeroing the flash chip at a hardware level. <nckx>Yeah, or that, if you have a week and too little excitement in your life. <cehteh>real nerds would enter i2c with a morse switch :) <nckx>A million EEPROM chips launched unshielded into space for a year would return with at least one randomly containing a better BIOS implementation than before. *dstolfa read that as EPERM and realized he was writing too much systems code today <cehteh>nckx: chop them into half before launching will increase the yield <nckx>Chopping them in half would be therapeutic. *nckx makes a happy little torture chamber diorama for commercial BIOS chips. <nckx>The toilet-roll iron maiden is my proudest part. <drakonis>welp its time to write me some nice fancy libraries in scheme <drakonis>how much work does it take to write a library for handling compression formats in scheme? <drakonis>will definitely want to use it in guix to reduce dependencies for guix pack, import and archive <nckx>I want to answer something ridiculously low so you'll actually do it. <nckx>Presumably archive formats as well? <nckx>I mean, this was triggered by unzip, surely 😉 <drakonis>i need to have gzip, lzip, xz, zstd to compress <drakonis>but yes, needing unzip to run recursive python importing annoyed me a lot <nckx>Problem with zip is there was never an (authoritative) spec, but being compatible with libarchive will surely do. <drakonis>libarchive supports a lot of formats, so it should be a fun trip <drakonis>how would i proceed with making this work available for guix after i'm done with the first few formats? <drakonis>making it usable inside the source, not as a package, that is. <drakonis>also relevant, there's a guile library for stream processing that could potentially be useful? i haven't checked the specifics but it was announced late august <nckx>Why not make it a package? I get that you want to reduce dependencies, but… <cehteh>oh new pinephone ... could we make an emacsOS based on guix with exwm, native compilation and emacs pimped for touchscreen use? :) <drakonis>anyways, let's not get ahead of ourselves here <nckx>Almost feels like cheating. <nckx>Maybe it will get bundled into Guix in a hypocritical mood, but developing it as a package for now seems like a better approach 😉 <nckx>= still better than many C (and other?) library dependencies. <drakonis>libarchive is developed by a freebsd contributor, neat. <drakonis>but i should stop getting too hyped about doing a project before i can even get started <drakonis>oh goodie, it has dependencies on a bunch of headers for certain formats <the_tubular>nckx remember my sudo question? Is the same true for bash ? <apteryx>hmm, what is the error for this CI evaluation? it says failed, but the log doesn't seem to have a failing bit <GNUtoo>hi, did someone manage to test lightdm + lightdm-gtk-greeter in the past? if so was there a simple command to test it? <GNUtoo>basically currently lightdm-gtk-greeter fails to compile because it wants exo-csource <GNUtoo>Since there is a newer version and that exo-csource usage has been replaced by the use of xdt-csource instead, I didn't fix it and I packaged the newer version and xfce4-dev-tools, but I'm unsure how to test easily <GNUtoo>In Parabola if I do 'systemctl stop display-manager && lightdm -d' I've lightdm that appears again <GNUtoo>the same didn't work with the fixed-lightdm from guix <GNUtoo>[+0.04s] DEBUG: Seat seat0: Creating greeter session <GNUtoo>[+0.04s] DEBUG: Seat seat0: Failed to find session configuration default <GNUtoo>With Pabola the first line pasted here is the same, and the second one is '[+0.01s] DEBUG: Seat seat0: Creating display server of type x' instead <GNUtoo>Maybe it's not supposed to work when you do 'guix install' on top of a host distribution (Parabola)? Or maybe I need to install Xorg and so on from Guix too? <apteryx>GNUtoo: perhaps you could test it in a vm generated with 'guix system vm your-config.scm'? <apteryx>mix and matching guix + foreign os components is often tricky <GNUtoo>apteryx: thanks, since no one probably tried lightdm with a host distro, I'll try to do that <talos>Heylo all. Returning Guix user, right now running Guix in a VM. Anyways, I can't seem to reconfigure the system, it keeps complaining about needing to build cantarell fonts, then just stops. I did "git pull" then "guix system reconfigure /etc/config.scm" like the manual says, but cantarell fonts keeps getting in the way lol <talos>I treid with both the stable and latest installer images too :X <talos>Oh, and of course I used sudo for the reconfigure lol <apteryx>talos: hey, welcome back! Are you using one of the system templates (base examples) ? <talos>Well, during the installation of Guix System, I chose to use the MATE DE, if that's what you're referring to? <apteryx>I'll try to build the cantarell font here to see <talos>I can upload any and everything if need be <apteryx>nckx: sems the renaming of the font-abattis-cantarell package broken the URI <apteryx>talos: ^ that's your problem. if you 'guix pull --commit=a8cda7f57992e9ce9ae4a694eba54e3eab42c39b' all should be OK <talos>Everyone in the guix community is always so awesome, you guys deserve the best! <apteryx>nckx: also, shouldn't we deprecate the old font-cantarell variable, to ease the transition? <apteryx>actually, it's not the uri which is broken, just that the current GNOME mirror doesn't have v0.303 there... trying a build from git <talos>Ahhhh, well, thanks again for discovering the root of the problem <apteryx>yikes, it's a rabbit hole to build it from git <apteryx>nckx: perhaps reverting the update would be the best course of action <apteryx>nckx: oh, I see the name was already font-abattis-cantarell; nevermind about deprecating something <apteryx>talos: should be fixed on master, commit 405393ef7f <talos>Gotcha, coolness. Sorry, was away for a bit. I'll try it out here in a bit! <NicholasvonKlitz>Anyone know how to get rust-src on Guix? I'm trying to use rust-analyzer but it depends on rust-src. I can't seem to find any information about how to obtain rust-src. <dhruvin>wleslie: I have this in my shell profile export RUST_SRC_PATH=/path/to/rust <dhruvin>rust package definition fetches tarballs instead of git checkout <dhruvin>I have rust-1.52 installed, tarballs don't appear in my store <dhruvin>NicholasvonKlitz: (meanwhile you can try that workaround) <apteryx>sneek: later tell civodul I've now included the gdk-pixbuf loaders commits, if you'd like to take a peek <zacque>Wanna ask how do you develop a package definition? The "hello" and "libgit2" examples in the manual don't really help <zacque>What I'm looking for is something like spinning a docker, then I can come up with a definition file through trials and errors <zacque>I'm looking into the "guix environment --container ..." command, but I'm not sure, that's why I'm asking for opinions <wleslie>commands and packages are very different things <wleslie>defining a package is a matter of describing the dependencies, where to get the source, how to build it, and what the output of the package is <wleslie>guix packages are isolated by default anyway, you can build as many times as you want and you won't trip over previous output <wleslie>I find the --keep-failed flag to `guix build` to be especially useful when developing a package, so you can examine the environment and run commands within it <zacque>wleslie: Thanks, didn't know that I can build a package iteratively using `guix build` <zacque>wleslie: How do you "examine the environment and run commands within it" after every built? <wleslie>if it fails, it will give you a path, usually /tmp/guix-build-$(full-package-name)/ or so <wleslie>within that directory will be a file called `environment-variables`, if you source that it will wack your shell (best to do that in a fresh shell), but it will be exactly the build environment <wleslie>there will also be a directory containing the source and build output <zacque>wleslie: I see, thanks, will give it a try <bricewge>This morning I took some time to read the stern-kit channel from apapsch <bricewge>There are some gems in there, like <inventory> which make deploying multiple machine more streamlined <viivien>Hello guix! I have installed nss-certs, but I’d like to pin some self-signed certificates. How should I proceed so that they get included in the operating system definition? <nckx>apteryx: That's because that commit wasn't supposed to update to .303 at all (hence no mention of that in the commit message). <viivien>I thought about inheriting from the nss-certs package, but I don’t know how to proceed next. <nckx>I don't know what's wrong with me lately. <viivien>I also thought about using an extra-special-file to put my certificate in /etc/ssl, but it won’t be included in /etc/ssl/certs/ca-certificates.crt if I do so. <viivien>(also, I checked and I can’t put extra-special-files in /etc/ssl/certs) <bricewge>viivien: I just had a look. It seems you just need to put your certificates in packages under .../etc/ssl/certs <viivien>bricewge, oh so I can just create a trivial package containing only the cert and it will play nicely with nss-certs? <bricewge>There is no documentation about, it would be great to have some instead of having to look around in the code <viivien>Especially in the manual section about SSL certificates <viivien>So, the certificate MUST be in the .pem format, otherwise the bundle will be created but unusable… <viivien>(once converted with openssl, the files look identical to me, but cmp says they differ) <viivien>Well, I get this: error reading ca cert file /etc/ssl/certs/ca-certificates.crt (Error in the certificate.) <bricewge>I tried it in an environement with `nss-certs` and `le-certs` and the generated ca-certificates.crt was as expected <viivien>It gets included in ca-certificates.crt, but my certificate corrupts it <viivien>Although openssl can read the file and displays the first certificate (mine) without problems. <bricewge>`ca-certificate-bundle` just concatenate in .pem file s <viivien>I downloaded it with firefox, and then I used it as a guile string literal to use in the trivial-build-system builder <viivien>I added some # things in the header so that it looks like the others from nss-certs <viivien>This is a self-signed certificate generated by my libreCMC router <bricewge>Did you tried building your `ca-certificates.crt` manually by appending your certificate and then using `curl --cacert [...]`? <bricewge>That way you will know if it's only a guix issue <viivien>It’s obviously a problem with my string literal <viivien>I tried with \r’s at the end of the line but that doesn’t change anything. <viivien>OK so even with the raw certificate that I downloaded with icecat, I have the same problem. So, how do I download the .pem version of a website? <bricewge>With something like `openssl s_client -connect guix.gnu.org:443` <jonsger>hm, why can't I pull from savannah via SSH anymore. It asks for a password... <bricewge>jonsger: Are you using a GPG key as a SSH one? <bricewge>I had a similar issue when my GPG key expired <viivien>So, the server certificate seems to be broken, I’ll try to fix it. Thanks bricewge! <nckx>My guess is you're still using an RSA key pair? Because using Ed25519 keys apparently side-steps the problem too. <nckx>So switching to id_ed25519 instead of/in addition to id_rsa is another fix. <nckx>Thanks to whomever updated aws-sdk-cpp whilst I wasn't looking. <Guest82>i've installed guix recently and i need some help <Guest82>when i try to run "su" from my graphical environment i get this error: "su: Authentication service cannot retrieve authentication info" <Guest82>also when i try to run sudo from my graphical environment i get this error: "sudo: /run/current-system/profile/bin/sudo must be owned by uid 0 and have the setuid bit set" <Guest82>but both commands work fine from a tty <Guest82>can anyone tell me how to fix it please <jonsger>ah thx nckx, best support engineer out there :) Will try the ed25519 thing. I think thats what the cool kids out there are using now a days... <nckx>Thanks jonsger ☺ Feelin' quite the opposite, overworked and overstressed and downright stupid, so I'm glad to have been of use! <talos>apteryx: Heyo, upgraded this morning. Everything went smooth :) <talos>Thanks to that, gonna install guix on a real machine now :D <nckx>‘Aside from you, it seems thatnoone cares about minetest’ nonsense, they're just all to busy playing it. I'll fire up minetest with your patches… <NicholasvonKlitz><NicholasvonKlitz> "Anyone know how to get rust-..." <- Just wanted to follow up on this quickly and see if anyone else has any ideas. Might be very useful to document this <ngz>FWIW, I find it great minetest is getting some love in Guix. It's true that I don't have time for playing it, tho. <nckx>Same. It's a dangerous package to test. <nckx>Did Guest82 leave? There's nothing in my buffer; strange. <talos>I love Minetest, ran a server for it for a while on FreeBSD. Might start running another one since I plan to make another server. <viivien>I have a notification for Guest82 leaving at (current hour -1):04:56 <nckx>I'm seeing other quit messages (like Inline's above) & don't have any ‘Hide XXX’ options checked but it's no big deal. <nckx>viivien: Can I just ‘guix install minetest-moreores’? <nckx>Or minetest-basic-materials, I guess it should be. *nckx guix installs minetest-pipeworks instead to ensure that no work will be done in the next hour. <viivien>nckx, if you install minetest-basic-materials, you’ll be able to find a craft recipe for silver_wire, because minetest-moreores will be installed as a propagated input. <nckx>Yep, thanks for adding that as a comment (good practice IMO). <jonsger>hm, still no success with my upgraded ed_25519 ssh key :( <nckx>viivien: Why not use a git tag? <viivien>nckx, that’s what published on contentdb <viivien>Yeah, the commit ID is exactly the same as the git tag, so it’s clearer that way. <viivien>By the way, I love how we see the progress on core-updates by the length of the branch name ^^ <nckx>mod "moreores" has unsatisfied dependencies "default" <nckx>I assume I'm missing something? <viivien>Do you have minetest and minetest-game? <nckx>Should that be an input? <viivien>Minetest arranges sets of mods that work well together in "games" <viivien>But you also have minetest-mineclone2 <viivien>While you could in theory add any mod to any game, most mods will be used with the standard game that comes in minetest-data <nckx>So ‘default’ isn't a well-defined package; it's ‘give me a base game, any base game’? <nckx>Or ‘set’ if game is the wrong term? <nckx>I can only install minetest-mineclone (which I already had), but don't have minetest-{data,game} or anything that looks suitably generic. <viivien>No, default is a built-in mod in the base game *nckx just looking at ‘guix package -A minetest’ here. <nckx>Hm, then where has my base game gone…? ☺ <nckx>Oh, so it's incompatible with mineclone? <nckx>I can choose ‘Minetest Game’ in the menu (not ‘Data’, just FYI). <viivien>Yes, but it comes from the -data package ^^ <jonsger>hm, pros just use the correct user name :P <nckx>viivien: So I thought that mineclone would still inherit ‘default’ because it's called, well, default. I guess that was wrong. Thanks. <nckx>All my existing worlds are mineclone. <viivien>In mineclone, I can activate all mods <nckx>This installation's old. Maybe I have 🦇 state 🦇. <viivien>But the built-in mod is called "MineClone 2 mods" and has all mineclone mods activated <viivien>There, I have started mineclone with basic_materials enabled <viivien>But I guess writing a mod that works both on mineclone and the minetest game is substantial effort *nckx can make crappy tin things. Playtest passed. <nckx>So what, only the fact that it naturally occurs is added by the mod? <nckx>I also have copper rails which this mod claims to add. If that's also ‘default’ this mod is a scam 😛 <nckx>“This mod adds tin, silver and mithril in Minetest.” <nckx>This is not the kind of archaeology I signed up for. <nckx>OK, have to rewrite my description too, then. <nckx>I did see some comments to the effect of ‘only add tin if it's not already provided’ when reading the Lua source earlier, but I thought they meant other mods. <viivien>If it were supposed to work on mineclone, maybe there would not be tin. <viivien>But obviously that was not a goal of the authors ^^ <nckx>Mithril is also not in default. (There's a Lord of the Test game that seems to have its own implementation, just to further confuse me.) <nckx>Whatever. Description rewritten to be more vague so I don't have to care. <viivien>Sorry, I was disconnected after "Whatever. Description rewritten…" *viivien adds a person to the list of the double-spacers-after-dot <nckx>You missed nothing, and remember there's always logs.guix.gnu.org <nckx>I'm writing a reply to your patch mails. Beware: this reply will also be correctly double-spaced. <viivien>I just noticed because I copied the last message I saw, and it felt wrong when I typed it myself. <viivien>But I don’t have strong opinions on that. <nckx>I'm slightly less nervous about being on your list. <viivien>Anyway, thank you for the patch! If you feel like you should backup your new minetest world, you’ll find that deja-dup (the GNOME app for doing encrypted off-site backups) does not work. https://issues.guix.gnu.org/51127 <nckx>I was genuinely, well not scared, but unsettled the first time I got that message (I was, like, 10). <viivien>(maybe I should try to reformat the commit messages before showing you that though) <nckx>Yeah, fine, looks pushable. <nckx>I don't use dejadup myself so I'm taking your word for its working. <viivien>I’ve backed up my computer (except for the people list thing), so I can wage my hard drive that it works <nckx>I'll take a closer look in half an hour (have already applied the patches, but want to take a second look at the dbus one). <nckx>Well, ~half an hour, I'll see. <jpoiret>alright, for the record, never try to package proton-bridge (or any Go app for that matter). I've been at it on and off this week, tailoring the build system for the (outdated) go qt binding package which now modularly compiles subsets of the api (instead of the default everything, including qtmultimedia, qtgamepad and other shenanigans), only to <jpoiret>realize that there are just too many dependencies, most of them which are simply bullshit: <jpoiret>one good example, sentry-go depends on `negroni`, an "an idiomatic approach to web middleware in Go", which is supposed to be a minimal replacement to `martini`. The funny part is that sentry-go ALSO depends on `martini`, which is of course no longer maintained either. <jpoiret>(not commit in 5 years yet still used as a dependency) <jpoiret>go really encourages the worst ecosystem. In your dependencies, you can specify replacements, ie use your own fork of something instead of the original package, leading to even more bitrot. Test libraries pull in ginormous amounts of dependencies (why would i pull in AWS SDKs/etcd servers/netflix eureka apis for a desktop application???) <viivien>jpoiret, web middleware with NPM is not much more exciting ^^ <nckx>Go is… yeah. Let's completely ignore best practices and lessons learnt about building maintainable quality software. It just falls apart. <aramallo>Anyone know if there's an existing package that provides the jar command? "openjdk" doesn't seem to <shtumf[m]>Hi, does Guix have something like OBS from OpenSuse, lets can you make a package for other GNU Linux distros, like rpm deb ebuild and so on ? <nckx>aramallo: That's the jdk output of the openjdk package. <nckx>shtumf[m]: ‘guix pack’ has very rudimentary support for .deb generation but it's really not general-purpose at the moment. I don't think so. <nckx>Guix isn't primarily designed as a way to generate .deb/.rpm/… ‘artefacts’ that then live on elsewhere. It's intended to be present on the end user's system. <nckx>We don't tell the uninitiated. <lilyp>jpoiret: From the perspective of the Go ecosystem, why wouldn't you want to locally mirror AWS for your builds to speed up? :) <jbv1[m]>jpoiret: FWIW as a temporary workaround for protonbridge I use a package that just extracts the .deb and runs patchelf on it... not nice but it works if your desperate enough <robin>oh, patchelf adventures reminds me: there's some code from a certain popular unofficial channel that might be useful for guix for, afaict, creating an FHS-compliant container <robin>it uses it for running a nonfree program, but seems like it might be useful in general even for free packages (using an old binary may be easier than packaging for guix, etc.) <vivien>(well, maybe it’s not exactly the reason why the URLs are limited to ASCII, I typed too fast) <singpolyma>robin: ah, it's for faking FHS in a package not for packing into an FHS? <robin>singpolyma, yeah, faking an FHS container to run a program in <jab>what have ya'll been up to? <robin>vivien, wouldn't the presence of unescaped unicode characters make it an IRI rather than a URI? <robin>jab, avoiding work by work^H^H^H^Hplaying with guix ;) <singpolyma>Unescaped Unicode characters aren't allowed in URIs for sure <singpolyma>But I guess in some cases the transform is obvious and it's more convenient to write that way <vivien>robin, singpolyma, correct. That’s why I kept an option to parse strict URIs and reject IRIs <vivien>But most of the time, you will want to handle IRIs <Guest12>even though i included the "base" packages with use-package-modules <robin>i'd be wary about making it the default in guile, for non-guix applications (e.g. homograph attacks in browsers), though idk whether browsers treat IRIs specially <robin>and it seems confusing to make "uri-decode" actually mean "iri-decode" by default <robin>also i might rephrase the bit in the manual about "treating it as if it were an iri" to something more like "parse it as an iri" <robin>but it's certainly useful functionality <jpoiret>Guest12: what exactly are you trying to do? i don't think make itself is the name of a package <jpoiret>the exported symbol name is gnu-make <Guest12>but i should be making it a package using guix right? <Guest12>like thats the proper way of doing it in guix <Guest12>should i always come to this chat if i get stuck on something? are people active here? <jpoiret>yes, always check the documentation first though <jpoiret>if all you need is ./configure && make && make-install, it should be a breeze using gnu-build-system <Guest12>im probably better off writing a package but i havent learned how to yet <jpoiret>i mean, you won't have to write anything mostly, simply stating the dependencies and using the gnu-build-system in the package definition <jpoiret>most of the time you don't need to invoke make yourself in your package definition, since that build system takes care of all the usual package installation steps <Guest12>i should probably check the docs lol <Guest12> "1545vgizpypqi2rrriad0ybqv0qwbn9zr0ibxpk00gha9ihv7acx")))) <jpoiret>but yeah the docs will be enough for this use case <jpoiret>that's the sha256 of the source, guix has reproducibility at its core, so it needs to check that it does download the same sources every time <Guest12>i hope i wont have to change that string often lol <vivien>robin, would you prefer if there was a (web iri) module that had uri swapped for iri in all instances, and also adapt other web APIs (for instance, add request-iri along with request-uri)? <Guest12>alright imma write my first package brb <robin>guix will also tell you the expected hash in an error message if you feed it a garbage hash <jpoiret>you should read the Defining packages node of the info page of Guix <jpoiret>robin: yes but you can't add a `guix build -f` package in a profile right? <vivien>Or maybe an (install-unicode-uris!) function? <singpolyma>Guest12: you can put a package in a file and then use the -f switch to guix build or guix install <robin>jpoiret, yes, you can use `guix package -f` <jpoiret>oh, didn't know you could install from a file, great (although that's bad for provenance heh) <Guest12>but i dont wanna install manually i wanna put it in list of packages in config.scm <robin>(not saying a channel is a bad idea, but for someone's first guix package...) <jpoiret>if you put it in config.scm, it'll be available system-wide. for a program such as sxiv i think a user profile would be more appropriate (but it's entirely up to you) <Guest12>best thing about guix so far that i've seen is how i can build an iso and flash it to a usb and just get my system anywhere even if i was at college i'd just plug that usb and be right at home lol <Guest12>i mean sure you can do that with other distros but with guix its too easy <Guest12>how do i get the sha256 of a git repo <robin>vivien, hmm, not sure. i guess it depends on how far you're going with it, e.g. you could have an iri type that kept the original substrings (for round-trippability) and an iri->uri function <robin>(this is also a place where i might consider using goops, since srfi-9 structs are pretty limited and most of the procedures would be similar or identical, but people don't seem to use goops very much) <robin>vivien, for just encoding/decoding, an extra keyword option seems fine to me <robin>you could maybe refactor it into {iri,uri}-decode and {iri,uri}-encode procedures instead of using keyword args <vivien>robin, I’d love to see more GOOPS in guile (I’m aware that there are strong opinions in the other direction). The problem with uri-decode is that it’s mostly used in other functions, like split-and-decode-uri-path or string->uri. <robin>(supposedly someone's working on guile-cl; goops would probably be pretty important for that...) <vivien>The clever thing would be to have an iri class, and inherit as an uri that would simply not accept unicode characters, and then update the rest of the web API to use iris. Then, bug the guile web projects so that they switch to the IRI module (I’m using guile-rdf and it would require patches for instance). That would be quite a challenge! <robin>vivien, yeah, that would certainly be cleaner <robin>i guess using either a keyword arg or a separate proc would affect string->uri and friends <Guest12>i wrote a package but it wont build lol should i post it here for u to try or is that too much lol <robin>Guest12, try paste.debian.net <Guest12> (commit "e10d3683bf9b26f514763408c86004a6593a2b66"))) <Guest12> (file-name (git-file-name name version)) <Guest12> "161l59balzh3q8vlya1rs8g97s5s8mwc5lfspxcb2sv83d35410a")))) <vivien>Also I’d love to have the request and response API use GOOPS. These are too complex to use in pattern matching anyway, and using alists for headers and request meta-data feels just wrong, because multiplicity matters in headers <robin>Guest12, it won't build as in you're getting build errors, or is it not building at all? <vivien>Guest12, you should have a message saying that there is a build log <robin>could you paste the whole file (with use-modules etc.)? <Guest12>oh i put the package in my config.scm lol <singpolyma>Guest12: always best to test with guix build until you get things working <apteryx>nckx: nothing wrong with you, to err is human ;-) <robin>Guest12, fwiw synopsis is basically what you have as the description (a one-line description), description is a longer explanation of what the package is for (usually a paragraph or two). (info "(guix)Synopses and Descriptions") has more info <robin>(under contributing->packaging guidelines in the manual) <robin>sorry, i meant that you can *try* building it with guix build -f, not that it actually works (faster than extracting it from your config.scm) <robin>i'll ramble about what i'm doing in case it's helpful to you in the future <Guest12>wait how can i clone the guix code so i can grep it <Guest12>i need to know which module provides cc-for-target <robin>first of all the -K option to 'guix build' keeps the (broken) build directory under /tmp, and you can look around and potentially use 'guix environment' to manually try things out <robin>but...this is stopping in the configure phase, and the build log says: "./configure: No such file or directory" <robin>(normally guix would generate it if the package had a configure.ac) <robin>so i used guix build -Sf sxiv.scm to "build" the source... <robin>and the checkout appears to just have a makefile <robin>so we don't need the configure phase, but the makefile uses a PREFIX variable which will have to be set. so... <jpoiret>on another note, you should really use user profiles instead of installing everything in the system profile through config.scm, since `guix system reconfigure` is pretty slow and those packages don't really have to be available system-wide (most of them anyways) *nckx would really like to be a robot right now. <robin>after the build-system i added: (arguments `(#:phases (modify-phases %standard-phases (delete 'configure) (replace 'build (lambda* (#:key outputs #:allow-other-keys) (let ((out (assoc-ref outputs "out"))) (invoke "make" (string-append "PREFIX=")))))))) <robin>er, (string-append "PREFIX=" out) <Guest12>what do you mean user profiles jpoiret <robin>which also fails as it's trying to invoke "cc". adding "CC=gcc" as a make argument causes a more interesting error about an ft2build.h header <jpoiret>note that this doesn't talk about the system profile at all, since it is a `guix system`-specific feature <Guest12>can you tell me how i can get cc-for-target <Guest12>im trying to just copy the original sxiv package and modify it <Guest12>but i dunno where to import cc-for-target from lol <robin>so you also need freetype as an input <singpolyma>If there is an existing package you may want to try (inherit <nckx>I just know. But you could ‘grep -r define.* cc-for-target *’ in the source tree to find definitions in general. <Guest12>but it built succesfully after i imported guix utils <Guest12>didnt learn much tho since i just copied the original and barely edited it lol <civodul`>apteryx: i just had this thought: there's an OpenSSL graft on core-updates-frozen that would be nice to undo in the world rebuild <sneek>civodul`, you have 1 message! <sneek>civodul`, apteryx says: I've now included the gdk-pixbuf loaders commits, if you'd like to take a peek <Guest12>lmao guix has soooo many advantages over arch <Guest12>wish guix had a bigger community tho <Guest12>i think the fact that default guix installer doesnt support most modern hardware is pushing people away <podiki[m]>the hardware support is on manufacturers to be more open, Guix/FSF has a very clear stance tehre <podiki[m]>it is unfortunate how little hardware is truly open, but on the other hand nearly everything for a "standard" desktop or laptop will work with Guix I think (wifi and GPUs being the big exceptions it seems) <jpoiret>i mean, in arch you have the whole AUR and a gigantic collection of officially supported packages, whereas here you need to learn guile+guix beforehand (and packaging is harder than on other distros) <Guest12>true but last time i tried to install guix like a few months ago i had a hard time and got so anxious that i just decided not to ever try again <singpolyma>I haven't tried guix installer to be honest, but Debian main is also all free and works in most hardware to I expect it would be similar? <Guest12>yesterday it took me the whole day to figure it out <Guest12>i built an iso with nonfree channel on arch and flashed it from there <podiki[m]>I enjoy Guix packaging, but I also love Lisp so... (Arch's pkgbuilds are pretty easy too, but never got into it, or needed to much) <robin>Guest12, ah, the Makefile hardcodes the include path for freetype. nothing substitute* can't fix <singpolyma>jpoiret: guix packaging being easier than other distros is the only reason I'm here :) <Guest12>im here for the reproducibility mostly lol <Guest12>plus i couldnt run binaries that i installed from the web which was so weird lol u can only use packaged software <Guest12>and it had so many dns issues i have no idea why it was so weird <singpolyma>I'm afraid I might like the nix language a lot so I don't look. Would rather avoid the analysis paralysis <jpoiret>singpolyma: by that i meant that it's more forgiving. i may look like i'm rambling here but protonmail-bridge in arch is just make clean && make install <jpoiret>Guest12: if you want to run binaries from the web then i have bad news for you <singpolyma>jpoiret: well, you could get a working guix package mostly the same way, no? Just not policy compliant <Guest12>no i meant a binary that i got from github <jpoiret>guix has the same exact drawback as Nix on that matter <Guest12>but i could run create_ap just fine which i got from github <jpoiret>well you don't have anything at the right place <jpoiret>it looks like a bash script that runs only basic binutils programs so it should work but ymmv <singpolyma>Binaries designed for one OS sometimes work on another, but it's hit-or-miss <raghavgururajan>Guest12: To run a non-packaged binary, I think you'd have to setup correct environment using `guix environment`. <jpoiret>i didn't realize LD_LIBRARY_PATH was also used for dynamic linking. raghavgururajan: guix environment should just simply work then for most needs then <robin>the Makefile isn't terribly well-written (zero uses of pkg-config, for starters) <robin>i think they'll also find running 'binaries from the web' isn't easy under guix either <podiki[m]>on that front, is an FHS-like service/environment something that would make sense in Guix proper? or is it too far from the guidance of sources and building <robin>vivien, maybe we should move (web uri) discussion to #guile btw, if there is more. agreed re: requests and responses. time for guix web 2.0? ;) (i started writing an http/2 client years ago but i don't think i got very far) <robin>podiki[m], imho yes, the alternative is requiring that everything be properly packaged for guix...i'm not sure how to best implement it though (haven't looked through the unofficial channel's implementation though it seems to work well) <podiki[m]>perhaps as a "guix environment"-like command? <podiki[m]>I too have only briefly browsed what is out there, but didn't seem so bad. I believe nix also has some sort of FHS-chroot for some packages (probably nonfree binary types though) <robin>yeah, something like that would be nice <podiki[m]>still, seems like it can be useful for testing or working around difficult packages as a stopgap <robin>something a bit like debian's debootstrap or schroot <podiki[m]>the service I was using no longer works in core-updates-frozen, but I think that is due to some package breakage; perhaps that is motivation to look at it for real <robin>packaging smlnj for guix is going to be difficult, for instance <robin>(mlton should be feasible if the polyml bootstrap works -- it does call itself from its own Makefiles to generate lists of prerequisites, but that can just be patched out) <podiki[m]>should lualatex work with just texlive installed? binary is there but it complains about Running mktexfmt lualatex.fmt with Unexpected non-option argument(s): lualatex.fmt 