IRC channel logs


back to list of logs

<opalvaults>i regret not getting a system76 laptop or something with the money i spent on the x1.
<opalvaults>just on sheer principal
<opalvaults>hey my t400 works just fine tyvm
<opalvaults>just don't you dare run gnome on it...
<unmatched-paren>opalvaults: since the system76 laptops run pop_os, which is pumped full of proprietary, i wouldn't be surprised if it didn't work with free wifi drivers
<opalvaults>oh really? :(((
<unmatched-paren>obviously i've never used one so i don't know for sure
<unmatched-paren>but that's my guess at least
<opalvaults>nah you're right unmatched-paren
<opalvaults>maybe i'm thinking of pureOS or something?
<unmatched-paren>the librem 13-15?
<unmatched-paren>those are so expensive though :(
<unmatched-paren>$1500 for the 14
<opalvaults>yeah, i think if i had to go again i'd have saved a bit more money but honestly it's not really worth it
<opalvaults>especially since i don't game, i should have gotten a t480 and been done with it
<opalvaults>live and learn! :D
<unmatched-paren>to be fair, they had to raise it because of the chip shortage i think
<opalvaults>that makes sense
<unmatched-paren>i think once that's over, it'll go down
<unmatched-paren>a little
<opalvaults>i hope you're right
<opalvaults>it'd be nice to get something even slightly less ethical dubious
<unmatched-paren>of course there isn't that much interest in a laptop that actually respects your human rights (for some reason) so i'd guess they don't have that many customers
<opalvaults>man i really hope guix works on this thing though. i can't wait for gnome 40 any longer just wanna break my shit all the time lets goooo
<opalvaults>unmatched-paren: which is surprising don't you think? there seems to be a surge of privacy awareness and such
<opalvaults>or maybe i just hang around cool nerds who give a shit too much lmao
<jonsger>if I would spend so much money on a freedom respecting laptop, I would go for MNT Reform rathen Purism...
<opalvaults>jonsger: i heard about that one! is it being shipped yet?
<opalvaults>it looks rather awkward.
<opalvaults>but really cool
<jonsger>opalvaults: yeah, they do ship in smaller batches but currently out-of-stock
<unmatched-paren>opalvaults: guix and nix are the only OSes where you *can't* break everything, at least with the package manager
<unmatched-paren>you can always roll back
<unmatched-paren>obviously the deadly sudo rm -rf is still a thing tho
<opalvaults>unmatched-paren: good point! jonsger re: dang, well i hope they do well in their initial sales. it's obvious peple are starting to get more and more interested.
<opalvaults>alias rm -rf to rm -rfi for christ sakes!
<opalvaults>okay fingers crossed this time the installation works
<opalvaults>success! now to go file a bug report
<unmatched-paren>the only reason the librem is not completely free is because recentish x86 requires some proprietary stuff, right?
<singpolyma>unmatched-paren: yes. Though while I like purism be aware their build quality is not amazing
<unmatched-paren>so in a sense this is our biggest problem:
<singpolyma>My mom's shipped with a DOA internal mic for example
<unmatched-paren>the amd patents over x86_64
<opalvaults>before i make this e-mail, does anyone know if there's a good format for bug reporting aside from the obvious?
<opalvaults>i dont see a template
<unmatched-paren>i haven't done it before/ever, sorry
<unmatched-paren>i think you just send them an email
<unmatched-paren>i think i've nearly finished wezterm :)
<unmatched-paren>i just need to import a few more crates
<unmatched-paren>wezterm uses a l o t of libraries
<unmatched-paren>even for a rust project
<unmatched-paren>oh no don't tell me that glium isn't in guix!
<unmatched-paren>oh it is
<opalvaults>bug report submitted
<opalvaults>hopefully that behavior gets patched in :D
<opalvaults>the intended behavior*
<unmatched-paren>never in my life have i seen a more incoherent name than rust-gmp-mpfr-sys-1
<unmatched-paren>what does it do???
<unmatched-paren>it sounds so cryptic for some reason
<unmatched-paren>oh it's just bindings to GMP and MPFR :P
<opalvaults>guix gimme dat gnome 40 alreadyyyy
<unmatched-paren>opalvaults: soon(tm)
<opalvaults>i need my tiling extensions
<unmatched-paren>as in on a branch in the repo
<unmatched-paren>not merged yet
<opalvaults>frozen still yeah?
<unmatched-paren>no not frozen i don't think
<opalvaults>someone sent me a link to an email chain saying it was due hopefully this week or next
<unmatched-paren>seperate branch methinks
<opalvaults>just do the rust thingy with the codey bits and then give me the gnome
<rekado_>hopefully soon
*rekado_ works on it right now
<opalvaults>rekado_: you're my hero <3
<unmatched-paren>it sounds like the kind of thing which should be hard but managable and then turns out to be a nightmare
<opalvaults>i should really join jgart for a packaging party so i can try and help maintain gnome since i really do like using it quite a lot
<opalvaults>just so i can learn the ropes
<opalvaults>jgart: end of the month usually yeah?
<unmatched-paren>gnome's stack extends far past the desktop afaik
<opalvaults>yeah it's kind of a giant garbage pile from what i can tell from afar
<jgart>opalvaults, yup
<unmatched-paren>the project is closely intertwined with basically the entire systemd stack
<opalvaults>i get the WHY, but it sucks for distros like GUIX to try and maintain
<jgart>opalvaults, We'll have a guix docs meetup next Sunday Dec 12
<jgart>I'll make an announcement soon
<opalvaults>jgart: what time typically?
<unmatched-paren>obviously we don't use systemd here (not because systemd is bad but because shepherd is better ;)) so i guess it's even worse
<jgart>dhruvin, roptat would Sunday be ok?
<jgart>opalvaults, 2PM ET
<opalvaults>ill wait for the announcement
<opalvaults>oh that's perfect
<jgart>The reason I'm moving it to Sunday is because I'm going to give a short presentation at FennelConf2021 on Saturday
<opalvaults>i think that's like...10ish PST
<jgart>opalvaults, I'd have to check
<jgart>I forget all timezones always
<unmatched-paren>guix actually had to extract part of systemd (evdev) into a seperate project to even get gnome to work
*jgart needs to finish packaging tz
<opalvaults>yeah that's typically what always has to happen with gnome and to a bigger extend most red hat backed projects
<unmatched-paren>i think it was evdev
<unmatched-paren>was it evdev?
<opalvaults>i get it, they want to standardize.
<sam_>i don't think so
<sam_>evdev was/is an input thing in the kernel and x
<opalvaults>i guess i coudl live without gnome i just don't like tinkering with DE configs that much D:
<sam_>you might mean udev and its fork eudev
<sam_>but that wasn't a guix project
<unmatched-paren>yes i mean eudev
<opalvaults>jgart: this looks neat!
<lilyp>did we do udev?
<jgart>opalvaults, you mean tz?
<lilyp>I always thought Gentoo did it first
<sam_>we did
<jgart>sam_, ha
<opalvaults>jgart: yeah
<unmatched-paren>OHHH it was elogind i was thinking of
<unmatched-paren>not eudev
<unmatched-paren>"Elogind has been developed for use in GuixSD, the OS distribution of
<unmatched-paren>GNU Guix."
<unmatched-paren>so yeah they had to extract that to even get gnome to work
<unmatched-paren>sounds horrific
<sam_>theere's a more active elogind fork but i do agree it's sad it's needed
<sam_>the elogind thing in particular feels kludgy (not the fault of the person doing it)
<sam_>seatd looks far nicer
<opalvaults>i wonder if the POP_OS desktop environment Cosmic will rely on systemd as much
<opalvaults>i suppose that remaking elogind and other bits to make gnome work is one way to gut gnome and make it compatible but i'd be curious if someone could just fork gnome, integrate the changes, maintain it, and let OG gnome do its own thang
<unmatched-paren>it will rely on rust, which means we'll be waist-deep in dependencies :)
<unmatched-paren>opalvaults: tbh that sounds like a lot more work
<unmatched-paren>extracting elogind looks to be easier than forking gnome
<unmatched-paren>one's a lot, lot bigger after all
<lilyp>Nah, depending on Rust is totally sane with all the cargo nightmare, only static linking, debatable bootstrap and no GCC support 😎️
<opalvaults>but how many more times is gnu/linux going to have to recreate a new dep just to keep gnome alive?
<opalvaults>s/gnulinux/the community*
<unmatched-paren>i think there's a project by ferrous systems to actually properly define rust so that it can be used in safety critical situations
<lilyp>there's nothing to do about gnome other than avoiding librsvg really
<lilyp>which'd mean compiling svgs to png with something else
<opalvaults>fair enough lilyp. you seem to know more than i about it
<unmatched-paren>"In order to support Ferrocene, it will be necessary to develop a specification document for Rust, which we refer to as The Rust Specification"
<opalvaults>rust really did open a pandoras box with cargo man. its safety/granularity is cool beans and all but man, it's way too easy to shove crap in your project that doesn't need to be there.
<opalvaults>when good package managers go wrong
<unmatched-paren>probably not the easiest thing to do though
<lilyp>people need to start divorcing programming languages from build systems and package managers again
<unmatched-paren>integrated build systems are fine imo so long as they don't add a package manager
<opalvaults>lilyp: what's the alternative though?
<unmatched-paren>that's when it seems to start getting painful
<lilyp>GNU Make
<lilyp>your thing to generate ninja here
<opalvaults>hm, i mean it's the only way i've ever manage deps so..i don't disagree
<lilyp>as for package managers there's guix of course :)
<lilyp>unmatched-paren: look at the hell, that is python and come back to me
<unmatched-paren>i also hate how the integrated package manager style means that users have to basically install the language's entire toolchain to install a user-facing binary
<opalvaults>i like python! but yeah, big woof
<unmatched-paren>lilyp: doesn't python have an official package manager though? pip?
<opalvaults>thankfully most common functionality is easy to create in the base libs
<lilyp>pip used to be an external tool and for the most part still is, so that doesn't count
<lilyp>same with stuff like conan for C++
<opalvaults>i've always thought pip was external
<opalvaults>i always have to install it extra
<opalvaults>vs something like racket where i install racket and get raco with it
<lilyp>cmake is also weird, because it does have capabilities to be a package manager, but meh
<lilyp>there is ensurepip, but distros rightfully throw it into the bin where it belongs
<opalvaults>i should really talk less about programming languages, and instead program more. im being such an armchair programmer right now lmao
<opalvaults>advent of code 2nite i guess
<unmatched-paren>i'm trying to learn c... but it just feels so ugly and uncomfortable
<lilyp>C is ugly and uncomfortable.
<lilyp>Though in my personal opinion Java and to a lesser extent C++ are uglier.
<opalvaults>thats why you just buck trends and use scheme for anything and everything
<lilyp>(C++ only due to the this pointer, though)
<opalvaults>racket is pretty cozy
<opalvaults>nice cup of cocao
<opalvaults>blanket, rain on the window
<unmatched-paren>i think many languages try to be _too_ modern
<lilyp>I like how every year's C++ con is like "yeah, do functional programming please, C++ supports that for some standards now"
<opalvaults>what is modern anyways?
<lilyp>modern is anything between the medieval and postmodern age
<opalvaults>safe memory management? generics? easy to grok?
<lilyp>no yes no
<lilyp>mind you generics are still 20+ years old, so meh
<opalvaults>well tell that to python, rust, and go
<opalvaults>still being used HELLA
<opalvaults>despite having various levels of any of those things
<opalvaults>i don't think there's gonna be a perfect modern programming language cuz that's pretty subjective anyways
<opalvaults>if anyone had a clue what it meant we wouldn't still be using C
<lilyp>For the most part, we don't use C though
<opalvaults>plenty of companies, software, and operating systems use C
<unmatched-paren>there's so many so-called c replacements and none of them can actually replace c :)
<lilyp>brb with an explanation
<opalvaults>i gotta get pizza anyways
<opalvaults>good conversation all :D
<unmatched-paren>rust, go, d, nim all pose as c alternatives
<opalvaults>u leave nim out of it
<opalvaults>that my perfect lil angel
<unmatched-paren>yes nim is nice :)
<unmatched-paren>unfortunately rust and go seem to have won over it
<unmatched-paren>no idea why
<opalvaults>corporate sponsorship dawg
<unmatched-paren>d was nonfree for aaaaages
<lilyp>add zig to the mix
<lilyp>so to explain
<unmatched-paren>i think d might have been as popular as the other two if digital mars hadn't been so stupid with dmd's copyright
<unmatched-paren>ah yes, zig
<unmatched-paren>i haven't looked at that one very much
<unmatched-paren>it looks very immature is the only thing :/
<lilyp>By the way, the one feature all "modern" languages share: Not fucking bothering with headers and suffering because f it.
<lilyp>but I digress
<lilyp>so to explain the C situation, you are of course correct to see it as indispensable
<lilyp>pretty much every ecosystem has some C core, sometimes larger, sometimes smaller
<lilyp>And by that I mean actual ecosystems, not islands carved out by programming languages for themselves
<lilyp>But you will also find a lot of code written in other languages, typically Elisp, Python, Lua, even Guile on top of those cores
<lilyp>Guix itself is special in that regard given that the core is already C++
<lilyp>Still a sane language to bootstrap, but anyway
<lilyp>there are also some ecosystems – again, real ecosystems, not language islands, centered around some piece of C++.
<lilyp>Think of Qt for probably the biggest out there
<unmatched-paren>aargh i can't be bothered with neatly arranging cargo crates in alphabetical order anymore
<unmatched-paren>it's driving me mad
<unmatched-paren>i think we need to split that file up a bit
<lilyp>unmatched-paren: have you tried building your rust packages with meson yet?
<lilyp>or is it just somthing you need to import for guix to make some command line tool work
<unmatched-paren>is that a thing you can do?
<unmatched-paren>i need to import a ton of crates to make wezterm work
<unmatched-paren>"alacritty's more bloated cousin", you might say
<unmatched-paren>it has ligatures and is one of the few terminals that renders jetbrainsmono correctly
<lilyp>in that case go ahead; I thought it was a personal project of yours
<unmatched-paren>i'll just put them at the bottom...
<lilyp>and yes, new meson (0.57 and up if I remember correctly) comes with an unstable rust module
<singpolyma>unmatched-paren: have you tried kitty?
<unmatched-paren>lilyp: no, after guix taught me how painful it was i will never be programming in rust again :P
<unmatched-paren>sigpolyma: kitty renders jetbrainsmono really thin and it's pretty ugly
<singpolyma>I love rust so much. it's sad people hate on it so often :(
<lilyp>we might want to try writing an optional lint pass, that sorts packages alphabetically
<singpolyma>unmatched-paren: ah, ok
<unmatched-paren>i like it as a language
<singpolyma>Rust in the language I spent decades hoping for and designing in my head. More or less
<unmatched-paren>and no doubt they put a lot of work into the safety features, which i love
<unmatched-paren>but have you *seen* that bootstrap chain?!
<lilyp>one of my lecturers or tutors (I don't quite remember) once referred to C++ lambdas as "line noise"
<singpolyma>The bootstrap chain is solvable if it mattered to anyone outside this room
<lilyp>Rust syntax looks even heavier on my eyes
<singpolyma>And some are even working on it
<lilyp>yeah, but those some have to play cat and mouse with core devs
<unmatched-paren>it matters to the guy behind mrustc, who is the only reason we aren't still packaging a beta rust as far as i can tell
<unmatched-paren>i like rust syntax
<unmatched-paren>it looks better than c at least :P
<unmatched-paren>ML is probably the syntax i like best
<unmatched-paren>variants are just:
<unmatched-paren>type some_variant = Hello | World of string | Foo of int * float
<unmatched-paren>i like ml a lot :)
<lilyp>I personally find GNU style C quite readable.
<unmatched-paren>shame that virtually nobody uses it except some company called Jane Street
<lilyp>Actually it's Street, Jane.
<singpolyma>unmatched-paren: half the world now uses what I like to call "shitty ocaml" aka swift, Scala, etc
<unmatched-paren>there is absolutely no chance of me ever touching the jvm :)
<lilyp>I hope Scala is bootstrappable by the time I'll be required to use it for something that really ought to be implemented in Scheme instead.
<lilyp>Maybe I should learn Haskell so that I can tell my professor "yeah, so you said we ought to implement this with Scalacheck, but I'm not bootstrapping a language and two build systems, so have this instead, I checked that it works reproducibly with GHC".
<unmatched-paren>haskell is nice but apparently it's pretty slow
<lilyp>because it's lazy
<unmatched-paren>it should really do some exersize
<lilyp>eat less bytes per pizza
<unmatched-paren>ocaml's got opt in lazyness i think
<singpolyma>unmatched-paren: how do you mean "slow"?
<unmatched-paren>both runtime and compile time. the first one i've heard about, the second one i can personally attest to.
<unmatched-paren>the one time i had to compile something in haskell, it took like 15 minutes
<singpolyma>Runtime performance is a reason I learned Haskell to begin with. It's no hand optimized C, but it's plenty fast especially if you're used to scripting
<singpolyma>Compile times are, fine? 15 minutes sounds crazy were you building all the dependencies too?
<unmatched-paren>yes i was following the instructions for a language server
<singpolyma>Not claiming ghc complies super fast, but I've seen wore
<unmatched-paren>it told me to `stack install blahblah` and it took ages
<singpolyma>Oh sure, if you compile half the ecosystem it can take awhile. My CI runs from scratch take 40 minutes on my biggest project. But building just my package takes under 2
<singpolyma>Most of my packages take basically no time but my biggest one is big and mostly in one file
<singpolyma>I may switch CI to just use guix eventually and never do the 40 minute version :)
<pyrotek45[m]>I was wondering if there was a simple command to rebuild my missing config.scm
<cehteh>your old one?
<cehteh>its backed up in the store
<pyrotek45[m]>Yes, I'm using guix in a vm and when I went to login and edit my etc/config.scm today
<pyrotek45[m]>It was empty
<pyrotek45[m]>Wondering where I can get it or if I can generate it back somehow
<cehteh>yes moment
<cehteh> guix system describe
<cehteh>will print configuration file: /gnu/store/gvijaaalkvy7fdj76c6hpid2vnyssksk-configuration.scm or something liker that
<pyrotek45[m]>Thank you that worked!
<pyrotek45[m]>Cheers man
<cehteh>heh i wished some time ago for a guix system --edit or something like that
<pyrotek45[m]>Yeah I would have thought there would be like guix system into myconfig
<pyrotek45[m]>Or something
<the_tubular>What does #guix thinks about immutable file system ?
<the_tubular>Sorry, if it's a bit random, I'm reading on Fedora
<dhruvin>jgart: 14:00 will be 00:30 (next day) for me in India, can't make it
<dhruvin>* 2PM PT is 3:30AM IST
<ryanprior[m]>Anybody getting ready to bump emacs-next to 29? I'm interested to try the precision pixel scrolling support that's on master and figure a Guix build is probably the easiest way.
<podiki[m]>ooo smoother scrolling!
<apteryx>if there are some pythonistas around here, you may want to review>.
<apteryx>I noticed the issue with pdbpp not working on core-updates-frozen
<apteryx>sadly it'll take a world rebuild if we want to slip the fix in the rext release...
<winning-luser>whats the minimum disk size and ram required for the base Guix image (1.3.0)?
<winning-luser>installation i mean
<pyrotek45[m]>Is guix not immutable?
<the_tubular>I don't know, is it pyrotek45[m] ?
<pyrotek45[m]>Not sure, I assumed it was since its sorta based off nix
<pyrotek45[m]>And I'm pretty sure nixos is immutable
<the_tubular>I should read more into it then, that's not what I though it was
<opalvaults>would immutibility require that the base system be set back to it's base configuration at each boot?
<opalvaults>guix is immutable in that you don't have to touch too much outside of /etc/config.scm (and there are likely ways around that, that I'm too new to this to know).
<opalvaults>unless your system becomes managed by puppet, or all of the root filesystem is read only, there's not much immutibility there
<the_tubular>Yeah, I though immutable was in the sense that it's completly read only
<opalvaults>that's the definition I also think of the_tubular
<opalvaults>i see that you already mentioned the fedora immutable spin, so that's my only knowledge of immutible distributions.
<opalvaults>s/immutible/immutable til how to spell immutable
<opalvaults>unrelated, guix home is so friggin' cool
<opalvaults>no more gnu stow :D
<jgart>dhruvin, oh sorry, I meant same time as Saturday that we had agreed
<winning-luser>guix immutability is about the software package builds, aka the store:
<winning-luser>(currently working knowledge, correct if wrong etc etc)
<jgart>dhruvin, 10:30 AM ET
<the_tubular>Would it be possible to make guix read only ?
<winning-luser>im currently trying to install guix on ramnode. so far so good, the bootloader just got successfully installed
<winning-luser>seems like entirely successful. full system install, good reboot, networking seems to work after a ping run and now doing `guix pull' just fine
<winning-luser>pretty excited about this since ramnode lets you easily upload custom ISOs very easily and quickly. Their web interface says it has a file option for isos (and other system image formats) but i was only able to give a url. but it took the official guix system 1.3.0 iso url perfectly. i gave it the minimum requirements of 15gb of disk space and a 320MB of RAM
<opalvaults>nice winning-luser, good to know guix werks in the cloud
<winning-luser>plans are to run a lil web server with guix, maybe some other stuff. gonna need a nice little guix logo and some text: Made with secret alien technology (Guix)
<winning-luser>uh oh, i dont think tramp is gonna work so well with guix haha
<winning-luser>>tramp-get-ls-command: Couldn't find a proper `ls' command
<winning-luser>so the battle begins
<pyrotek45[m]>I think the gnu/store is immutable
<pyrotek45[m]>In guix
<pyrotek45[m]>But I'm not sure about the rest of the system
<opalvaults>winning-luser: quick googling didn't provide anything useful. was that trying to dired into the remote host?
<winning-luser>opalvaults: yeah
<pyrotek45[m]>Still not sure if it is tbh
<opalvaults>i'm assuming you aren't on a windows client rn?
<pyrotek45[m]>Cant find any documentation on it atm
<ns12>Hi, which package do I need to install in Guix to run a 32-bit executable on a 64-bit x86 computer? In Ubuntu, I'd install the "libc6-i386" to do this. How would I do this in Guix?
<winning-luser>i can tell what the issue is looking at the code, for tramp
<winning-luser>its because it builds the path using `getconf PATH`
<winning-luser>the important function to look at is `tramp-get-remote-path' i believe
<winning-luser>opalvaults: nah, fedora
<opalvaults>ahh, so it's trying to look in the standard paths on the remote host?
<ns12>How do I install 32-bit libc on a 64-bit x86 computer using Guix?
<winning-luser>omg theres fucking perl code in tramp
<opalvaults>ns12: this may be of some help?
<ns12>opalvaults: Okay. I see that I will have to patch the binary, since the 32-bit binary was not compiled using Guix.
<winning-luser>i got dired working for guix
<opalvaults>debating on whether or not to do a guix pull --branch=core-updates-frozen....
<opalvaults>i want that gnome 40 man
<winning-luser>or sorry i mean, tramp
<winning-luser>for the ssh connection, and including dired too
<opalvaults>winning-luser: what was the fix?
<opalvaults>tramp gets really picky about stuff. i couldn't even have remote servers using zsh iirc because it would cause tramp to hang
<winning-luser>set the variable `tramp-remote-path' to what the $PATH is on the Guix host
<winning-luser>and this too: (setq tramp-default-remote-shell "/run/current-system/profile/bin/sh")
<winning-luser>then you're all set as far as i can tell
<winning-luser>dired and everything is working so far
<opalvaults>sweet, copy and pasted into a gist, thanks for the solution.
<lilyp>hi,where are Xcomposite et al.?
<unmatched-paren>hi guix \o
<unmatched-paren>how do i even _begin_ debugging 'missing closing parenthesis' when it doesn't even try to guess where the missing paren is???
<unmatched-paren>especially in crates-io.scm
<unmatched-paren>it has 64518 lines :|
<unmatched-paren>we really, *really* need to split it up
<unmatched-paren>crates/async.scm, crates/gtk.scm, crates/graphics.scm, crates/other.scm, crates/cli.scm, something like that
<unmatched-paren>crates/apps.scm, replacing rust-apps?
<unmatched-paren>or maybe we could have rust/ and then rust/apps.scm, rust/async.scm et cetera
<rekado>we don't need to split it up
<rekado>your editor should be able to tell you where your added packages have parens problems
<vdv>i accidently remove my whole filesystem with rm -rf ....
<vdv>i don't use btrfs snapshots (now i will..) are there chances that i can revert the rm -rf?
<unmatched-paren>i do not currently have a scheme LSP server....
<unmatched-paren>i can't find one
<unmatched-paren>a tree-sitter grammar would help, but there isn't one for scheme
<unmatched-paren>it's on my todo list, but it requires touching javascript which makes me feel physically sick
<winning-luser>some strong emotions for a programming language
<unmatched-paren>in javascript, there is == and ===. apparently, == is really bad to use because it has all kinds of strange semantics. so you have to type === for equals.
<unmatched-paren>you are allowed to redefine NaN and undefined before ecmascript v6.
<unmatched-paren>sorry, before ecmascript 5.
<lilyp>does anyone recall what's the proper fix for fegetround et al.?
<unmatched-paren>apparently, `this` has FOUR different meanings in js...
<lilyp>four? that's preposterous
<lilyp>we have to invent our own meaning of this, which addresses all use cases
<unmatched-paren>and there's two different variable definition keywords, one of which is discouraged
<unmatched-paren>`var` and `let`
<winning-luser>eq, eql, equal, equalp
<unmatched-paren>ok fair
<unmatched-paren>i don't like that either tbh :P
<unmatched-paren>lisp certainly isn't perfect either
<vivien>lilyp is referring to
<unmatched-paren>yes, i know :)
<vivien>I wrote that for the general public ^.^
<unmatched-paren>and finally, i've found the unmatched parenthesis :P
<unmatched-paren>(with git diff)
<unmatched-paren>who needs a fancy linter?? they're bloat!
<ns12>Hi, how do I substitute* two lines? What regex pattern should I use to substitute two contiguous lines?
<lilyp>ns12: you can't
<lilyp>can we use absolute includes in C?
<ns12>lilyp: So the only solution is to use a patch file to change two contiguous lines?
<lilyp>either that or do something completely tricky like matching the first line and the commenting out the second based on some other match
<lilyp>though patch files are typically less struggle
<ns12>lilyp: Is substitute* only for changing one line only? I think it has another limitation: it can only change the first instance of a match on a line.
<lilyp>you typically don't want your regexp to be ambiguous enough to match multiple parts of a line
<ss2>Is there a way to select the version of go in go-build-system?
<ss2>currently it selects 1.14.15
<lilyp>there should be #:go similar to #:python
<ss2>yes, apparantly there is.
<unmatched-paren>ohno one of the crates for wezterm depends on webpki D:
<unmatched-paren>what do i do now? webpki comes out as unknown-license, which is of course problematic
<simendsjo>I'm trying to upgrade syncthing from 1.16.1 to 1.18.4, but the check phase fails. I'm able to upgrade without running tests though. Not being a go developer, I'm not quite sure where to start. I get the error `vendor/ build constraints exclude all Go files in
<simendsjo>/tmp/guix-build-syncthing-1.18.4.drv-0/src/`, and `go run build.go test` returns 1
<unmatched-paren>looks like it's fine actually
<ss2>lilyp: I tried it with #:go ,go-1.16, but it fails.
<unmatched-paren>no it's not
<unmatched-paren>0.22 has ISC/BSD-3 license
<ss2>ah, quoting wasn't done right, but it still fails to find the variable.
<unmatched-paren>but some of the tests have an mit license...
<unmatched-paren>what do i do with this?
<ss2>okay, only had modules missing. Thanks lilyp
<unmatched-paren>do i just manually amend the license
<unmatched-paren>there's this:
<unmatched-paren>maybe i could patch the cargo.toml to use 0.21?
<unmatched-paren>not sure whether that would actually work
<rekado>vdv: power off your computer to prevent any more writes to the disk. Then attach it to a different computer (or boot a live disk) and run testdisk.
<rekado>testdisk may be able to recover deleted files if there haven't been too many writes yet.
<rekado>keep another disk ready to copy recovered files to.
<dhruvin>jgart: yes, 10:30 AM ET is fine
<phodina[m]>Hi, could somebody please help me, ran guix pull and later reboot ... now I'm stuck at this screen
*phodina[m] uploaded an image: (114KiB) < >
<unmatched-paren>how do i create a patch for a package?
<unmatched-paren>i tried a couple things but it rejected the patch
<unmatched-paren>I'm trying to patch rust-ndarray-0.14's cargo.toml to remove blas-src, which is nonfree
<unmatched-paren>the package for 0.13 does it, but they changed the cargo.toml since then and now the 0.13 patch doesn't work
<ns12>Use "diff" to create a patch. Is that what you are asking?
<unmatched-paren>i tried `diff`
<unmatched-paren>on the old cargo.toml and the patched one. it created a patch (when i gave it the correct arguments) but when i tried to build it it rejected the patch.
<unmatched-paren>this is the old cargo.toml:
<unmatched-paren>i'm trying to remove this line: blas-src = { version = "0.6.1", optional = true, default-features = false }
<unmatched-paren>and change this: blas = ["cblas-sys", "blas-src"]
<unmatched-paren>to this: blas = ["cblas-sys"]
<unmatched-paren>ndarray 0.13 does it, but i'm not sure how to create a working .patch file
<unmatched-paren>the 0.13 .patch doesn't work on 0.14 ofc
<unmatched-paren>blas-src is nonfree because it bundles a lot of proprietary BLAS libraries
<ns12>You can use substitute* to replace lines instead of using patch files.
<ns12>Could you share your patch file?
<phodina[m]><phodina[m]> "IMG_20211204_135109.jpg" <- Where there are changes recently for Btrfs or boiting on x86_64 in general?
<unmatched-paren>i generated it by cloning the repo then `git diff HEAD -- Cargo.toml > patch`
<phodina[m]>Also is there somewhere a manual for scheme at boot?
<ns12>unmatched-paren: What is the error message you are getting?
<ns12>unmatched-paren: How are you applying the patch? Is by doing something like: (package ... (source ... (origin ... (patches (search-patches "rust-ndarray-0.14-remove-blas-src.patch")))))
<unmatched-paren>yes, that exactly
<unmatched-paren>the patch is in gnu/packages/patches/
<ns12>Is your sha256 correct?
<unmatched-paren>i got the package recipe from `guix import` (and then adapted it to inherit from 0.15)
<unmatched-paren>so the sha256 is almost certainly correct
<ns12>Try guix build with "--keep-failed". Then, when the build fails go into the build directory and manually apply the patch to see if manual patching succeeds.
<unmatched-paren> strips the comments from cargo.toml!
<unmatched-paren>it works now \o/
<ns12>unmatched-paren: Great!
<unmatched-paren>that's weird... what could this 'unknown file' be?
<ns12>In which build phase does the error occur?
<unmatched-paren>just after extracting the tarball, it seems
<unmatched-paren>here's the recipe:
<unmatched-paren>it won't build for you because there are lots of rust crates that i needed to add
<ns12>I hope someone will help you solve the problem, since I am not familiar with Rust.
<unmatched-paren>it has fifteen gazillion dependencies. as you can see, it is a typical rust package.
<unmatched-paren>maybe checking the docs for cargo-build-system will help?
<unmatched-paren>...apparently not.
<ns12>Check the mailing lists and IRC logs.
<wigust>hi guix
***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
<unmatched-paren>how do i get the checkout directory of a package?
<unmatched-paren>i think i just need to delete the .cargo/config to make it work
<unmatched-paren>otherwise i'll just `fd` for .cargo/config in the checkout directory and look at them all
<unmatched-paren>i'm trying (delete-file ".cargo/config"), but that errors with 'no such file or directory', so i guess i have to specify the checkout dir too?
***hiruji is now known as aeka
<sailorTheCat>Hi. I want to test a new package's version. I've cloned the guix repo, cd here and run guix build command. See details
<sailorTheCat>There is an error. Is it because of code or I run the command wrongly?
***jonsger1 is now known as jonsger
<civodul>sailorTheCat: hi! you don't need "-L ."
<civodul>that confused guix
<civodul>so just: ./pre-inst-env guix build PKG
<sailorTheCat>ok, I'll try
<sailorTheCat>how to build 'pre-inst-env'?
<avp>Hello Guixers! Is there "logger" command that provides an CLI interface to syslog in Guix? Or is there any replacement for this?
<lilyp>avp it's in inetutils
<civodul>sailorTheCat: see
<unmatched-paren>i got the configure stage of wezterm to work, at least
<unmatched-paren>i did have to (remove-file ".cargo/config")
<avp>lilyp: Oh, thanks!
<unmatched-paren>how do i deal with rust git dependencies?
<unmatched-paren>do i just patch the cargo.toml to remove them and add some wezterm-glium-git package?
<unmatched-paren>..would that even work?
<unmatched-paren>i guess i could replace it with 'guix-vendor/wezterm-glium-git'..
<jgart>dhruvin, great!
<sailorTheCat>keep trying to understand. I've used instruction above and successfully build the hello package. Then I (to not spoil the current package) copy (define-public ...) definition and rename a package (both in define-public and (package (name ...)) places.) and ```./pre-inst-env guix build rtl8821ce-linux-module-my
<sailorTheCat>guix build: error: rtl8821ce-linux-module-my: unknown package
<sailorTheCat>what else should I do to build a new package?
<rekado>is there any other output before that?
<sailorTheCat>If important there is the definition (same as official just added '-my' at the name's end).
<slyfox>is it a new .scm file or existing one?
<slyfox>should work as is then. until guile is tricked into not rebuilding .go file out of it.
<sailorTheCat>can I specify where exactly take data to build? To exclude possibility, guix builds definition not from file I'm edited.
<sailorTheCat>yep, I've spoiled a commit id in old package's definition and guix builds the package as the id was correct. So it takes data from another place (probably a channel).
<avp>Finally I managed to prepare a patch for Guix that adds Guile-SMC:
<jonsger>lilyp: do you have a git address to pull the telegram patch from?
<unwell_quantum[m>Hello, does guix have a formulated security document / specification? I am looking for information about how Guix deals with security, beyond just patching.
***jonsger1 is now known as jonsger
<lilyp>jonsger git am rules
<jonsger>to lazy :)
<opalvaults>unwell_quantum[m: you might try the mailing list for a question like that
<opalvaults>long shot: anyone have a solid method of installing doom emacs properly with guix home? i'd like to not have to call doom install. is there a hook I can use or something?
<lilyp>opalvaults: I think it'd be adding doom to your packages and writing your init.el from guix home
<opalvaults>ooo, i'm unfamiliar with being able to add doom to packages.
<opalvaults>usually i clone from master and have to exec the binary in order to install
<davidl>is it possible to run a guix pull on some machine X and then reuse the results of it on some other machine Y if pulling both from and to the same commits?
<opalvaults>i'm getting ld: cannot find crt1.o: No such file or directory when trying to compile vterm for emacs. I have gcc-toolchain, cmake, make, libtool, and emacs-vterm installed (unsure if that is redundant)
<patched[m]>Is there a neat way to find out which packages depend on a given package in a channel?
<rekado>guix refresh -l
<patched[m]>Thank you!
<podiki[m]>is anyone familiar with the mesa drivers (dri)?
<podiki[m]>our package seems to symlink a bunch together that should be separate libraries I think :/
<podiki[m]>but the configure flags all seem correct
<unmatched-paren>microsoft's doesn't have a license in the repo or the files, but the cargo.toml specifies MIT OR Apache-2.0. Does that count as an actual license?
<unmatched-paren>i'll just patch it out of the wezterm-gui cargo.toml if not
<singpolyma>unmatched-paren: I don't see why it wouldn't, but IANAL
<unmatched-paren>doesn't the expat license need you to include a copy somewhere?
<unmatched-paren>or so i've heard
<singpolyma>unmatched-paren: it requires you not to remove any copies that may be present
<podiki[m]>ah okay, the symlinking is on purpose, mesa normally has hardlinks (apparently several drivers are all really the same file, interesting)
<podiki[m]>anyone handy with some guix/guile that could turn symlinks to hardlinks? or just using copy-file after removing the symlink?
<unmatched-paren>singpolyma: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
<WesterWest>Hi! Can I ask something. I have installed guix with disk encryption and set the keyboard layout to "cz" "dvorak ucw", but that doesn't seem to have written into grub, and it still uses the default qwerty for unlocking the luks partition
***lilyp_ is now known as lilyp
<podiki[m]>WesterWest: that seems to be a common comment here, not sure if there are good workarounds. I think some have made the password different so that it is the same physical keys between the different layouts?
<unmatched-paren>i'll just patch windows-rs out
<unmatched-paren>just to be safe
<singpolyma>unmatched-paren: yes, exactly. You can't remove if present for sure. Though every website on the planet does when they minify their JS :P
<unmatched-paren>it's fine either way. windows-rs is behind a cfg(windows) flag anyway, so its inclusion is only to appease the cargo dependency resolver.
<unmatched-paren>if i patch it out, cargo won't complain.
<awb99_>I am trying to add openssh service to my arm operating system definition. When I try to build it on x86 I get the error 'failed to build libfido2'. If I install openssh inside the running arm system it installs fine. Any ideas what this could be?
<atka>does the GUIX project foresee any issues with Microsoft having their own GUIX product? Technically they call it Azure RTOS GUIX but it is referred to as GUIX often.
<rekado>our Guix was first
<nckx>Morning Guix.
<nckx>atka: Nah.
<nckx>GNU Guix predates it by at least a month or so, maybe more.
<atka>2012 vs 2014 I think
<nckx>Not that comfortable.
<nckx>(I dug into this years ago.)
<nckx>WesterWest: The problem is that Guix's GRUB currently loads everything (keymap, kernel, initrd) from /gnu/store, which is… encrypted. It's perfectly possible to embed the keymap in the core image (in a tar file, similar to Linux's initrd), if you're looking for something reasonably fun to hack on!
*nckx ‘I'll just leave this idea here and walk away and maybe it will be gone in the morning who knows’.
<WesterWest>nckx: that sounds like a good workaround, but can I put something in /boot? doesn't it get overwritten?
<nckx>In /boot?
<nckx>By what?
<WesterWest>I don't know how exactly it works
<WesterWest>by guix
<nckx>And I don't understand the question.
<atka>rekado: do you think you'll pick up the mudita pure? I saw your open issue on their github.
<WesterWest>I don't know how to embed the keymap, and what is the core image
<nckx>The embedding would be done by Guix, so you'd want it to ‘overwrite’ the previous copy.
<nckx>Like Guix ‘overwrites’ most of /etc at boot.
<nckx>Here's the first hit for that which doesn't look downright wrong, although I didn't vet it further:
<rekado>atka: unlikely
<Gooberpatrol_66>This says if recursive? #t, then local-file will not change permissions
<Gooberpatrol_66>I did (local-file "ssh/guixrig_host_rsa_key" #:recursive? #t)
<Gooberpatrol_66>Yet it's still changing permissions to 444
<Gooberpatrol_66>What am I doing wrong?
<civodul>Gooberpatrol_66: dunno if that's what you're observing, but files in /gnu/store are always read-only
<civodul>did anyone eventually find a solution to the IceCat "robotic voice" issue?
<Gooberpatrol_66>civodul: the file has 400 permissions
<vivien>The manual for local-file is a little puzzling to be honest
*vagrantc used debian to build guix, to install guix system, to build a debian chroot, to build a debian live image on the pinebook pro
<vagrantc>why do i use computers at all?
<vagrantc>admittedly, some of those steps took months
<vivien>civodul, do you have an exemple of a robotic-voiced video? I never had that problem.
<vivien>Oh sorry there is one
<patched[m]>Some easy way to read build logs when an install fails?
<vivien>(unfortunately it doesn’t play without JS)
<KE0VVT>Is there a way to get GNOME extensions?
<jab>Hello you beautiful people!
<jab>Especially you Bob!
<vivien>civodul, the gtranslator URL has changed, it no longer includes the minor version number: