IRC channel logs


back to list of logs

<jpoiret>especially when it's only for convenience
<jpoiret>with all of that, I'm going to bed (if someone told me i'd be arguing over hygienic/unhygienic macros in an IRC chat someday i wouldn't have believed them)
<lfam>Welcome to the future :)
<lilyp>lfam: We're also fighting against the C++ compiler here, which will attempt to aggressively inline compile-time constants
<attila_lendvai>jpoiret, i agree, with the addendum that it's not "only for convenience". it translates to overall programmer, and team efficacy, and *that* is what one should optimize for. bugs/debugging undoubtedly lower it, but so does code verbosity and uncaptured abstractions in the name of purity.
<lilyp>jpoiret: Any discussion pointing to a good part of Rust should come with a big fat disclaimer that any perceived benefit of the language is almost immediately discarded thanks to static linkage
<attila_lendvai>jpoiret, good night, and thanks for the insights!
<lilyp>Also, Rust's "unsafe" keyword is not revolutionary at all, C# has been doing that since the start of the millenium
<unmatched-paren>yay! 'Welcome to utop version %%VERSION%% (using OCaml version 4.13.1)!'
<unmatched-paren>the %%VERSION%% looks weird, but ok
<unmatched-paren>i guess i'll substitute it
<unmatched-paren>i like rust-the-language (rust-the-ecosystem is uncomfortably npm-like...), but not for the safety; i like it for the 'better C' features like traits and the functional things like pattern matching and closures
<unmatched-paren>zig does those things better tho
<unmatched-paren>it's extremely stupid that rust has no spec, which destroys any chance of using it in a safety-critical environment (the places where safe memory management matters the most) and makes implementation of alternative compilers really hard (mrustc, gccrs...)
<lilyp>I'd still say C++ is better than Rust in that regard, even with all of its undefined behaviour.
<singpolyma>Rust is just so nice after having to worry about malloc and free in a former life
<lilyp>so is std::vector
<unmatched-paren>is there some way i can get the `version` variable from within a `(modify-phases)`?
<unmatched-paren>without redefining it...
<singpolyma>unmatched-paren: splice it in
<unmatched-paren>c++ inherits c's ridiculous syntax
<bdju>hey, guix. is it safe to update these days? I know in the last few days some people couldn't log in or boot or something. I'm probably a week or maybe a little more behind.
<unmatched-paren>except it's even more unreadable...
<lilyp>unmatched-paren: #~(modify-phases ... #$version)
<lilyp>you call Rust readable?
<unmatched-paren>lilyp, singpolyma: thanks!
<lilyp>C++ lambdas are line noise, sure
<lilyp>but Rust is a block cipher
<ulfvonbe`>reject modernity, embrace ada
<unmatched-paren>lilyp: yeah, i like rust's syntak
<lfam>bdju: This bug is still open: <> "Guix System hangs after boot with linux-libre 5.15.17"
<lfam>I don't know if everybody experiences it or not bdju
<rekado>ulfvonbe`: seems to go the other way around:
<bdju>lfam: thanks. that's a little bit scary. maybe I'll hold off...
<singpolyma>Rust syntax always feels simple and natural to me. It will depend on other languages in your background I guess
<unmatched-paren>it's not as good as [[o]ca]ml
<lfam>bdju: It doesn't seem to matter, because you can rollback
<unmatched-paren>but it's decent
<lfam>bdju: But, we still have no idea what's wrong
<bdju>lfam: that is a good point. another question: if I don't reboot, will I experience the issue? I tend to go 1-3 months between rebooting
<lfam>Since it's a kernel bug, you presumably will not experience it unless you boot an affected kernel
<bdju>if the issue is with early boot type stuff then maybe not rebooting would leave me safe anyway
<bdju>okay, cool. maybe I'll update later then
<singpolyma>unmatched-paren: I would call rust yet another poor man's ocaml, except that it has actually unique features so it can't be quite "yet another" like most of them are
<unmatched-paren>syntatically: ocaml > nim > zig > lisp > rust > c > c++
<civodul>lfam: should we just revert to the previous kernel?
<singpolyma>unmatched-paren: forgot Haskell on the far left ;)
<unmatched-paren>(oh no, i'm going to get burnt at the stake for not putting lisp at the far right...)
<lilyp>those are some weird orderings you have there
<unmatched-paren>singpolyma: hey, i like haskell! the only reason i don't use it is it's not bootstrapping
<jpoiret>disclaimer: i do not like rust very much either
<lfam>civodul: I can't tell what's the right course of action... it seems like only a few people are affected, and I can't even see the messages of the kernel panic
<lfam>It's very confusing
<lfam>And I'm starting to feel overwhelmed by all the bugs I'm hitting lately
<singpolyma>unmatched-paren: the languages in your list are a bit incomparable though. Like, I can't use ocaml or nim for the things I would use rust or c for
<lilyp>I'd rather code m4 in three quote layers than look at a single line of Rust code for longer than three minutes.
<unmatched-paren>yeah, i mean purely based on syntax
<singpolyma>unmatched-paren: for sure
<unmatched-paren>oh god m4
<unmatched-paren>we do not speak of m4
<unmatched-paren>or auto{conf,make}...
<singpolyma>The *amount* of people using rust is a bit surprising, but even more people use C or C++ so 🤷‍♂️
<lilyp>speaking of make, if you can't write a makefile for your programs, your toolchain sucks big
<lfam>lilyp: Regarding audacity / ffmpeg, I confirm the bug is fixed by removing that "L"
<unmatched-paren>i can write a makefile for rust programs, it looks like this:
<unmatched-paren>`all: cargo build`
<lilyp>lfam: test on CI first before pushing to be safe
<singpolyma>unmatched-paren: don't need cargo
<singpolyma>Just use rustc
<unmatched-paren>singpolyma: yeah, i know you can use raw rustc
<civodul>lfam: i can sympathize :-/
<jpoiret>Haskell and friends are too theoretically interesting for me not to rate them the highest, but that's just my maths background speaking :)
<singpolyma>Just like for Haskell in guix we use gnc and not cabal
<lilyp>I'll make an exception if you know how to generate a Ninja file instead
<lilyp>or ant if you're into that
<lfam>civodul: I noticed that some other kernel changes broke use of the 4.4, 4.9, 4.14, 4.19, an 5.16 kernel series unless you override %base-initrd-modules. So the bugs compound each other
<singpolyma>I do agree that some projects seem unable to write makefiles and use some unholy mess like autotools instead
<civodul>lfam: because some modules became built-in or something?
<unmatched-paren>i personally prefer meson for c projects, not as unholy as autotools, not as bloated as cmake, and not as manual as raw make
<jpoiret>Autotools can be a step up from plain makefiles sometimes, but m4 is a pain and some things just don't add up
<infty>How can I query the location of my guix configuration file? For context: I am running guix inside a VM from the website
<lilyp>cmake syntax looks like someone took autotools and asked themselves "that's great, how can we make it worse and still collect praise?"
<unmatched-paren>it would be cool to use guix as a build system, but asking people to install guix just to build stuff is a bit unreasonable
<lfam>civodul: It's the same issue I mentioned here, about the coreboot framebuffer: <>
<lilyp>I agree though that meson is the most reasonable "Makefile" generator out of those three
<lfam>civodul: I think I'm just going to revert that coreboot framebuffer stuff for now, after a few weeks of no assistance with it
<singpolyma>unmatched-paren: not any more unreasonable than other stuff that gets asked these days
<fnstudio>Zelphir: sorry, i should have mentioned this bit: (org-babel-do-load-languages 'org-babel-load-languages '((scheme . t)))
<singpolyma>But guix can't be a build system because it always builds from clean
<lilyp>ahem, GWL
<lfam>lilyp: Would you write "* gnu/packages/patches/audacity-ffmpeg-fallback.patch: Fix typo." for that part of the commit message? Is it a typo?
<ulfvonbe`>guix could be a build system if the package explicitly split up every build target into a separate derivation
<fnstudio>Zelphir: does that change anything?
<unmatched-paren>singpolyma: 'ok so you need to install npm.' 'right, ok, sounds easy and simple.' 'type npm install' 'ok i'll do thaAAAAAAAAAAAAAAAAAAAAAAA'
<lilyp>It is a typo, but a particularly evil one :)
<lfam>Sure :) I give the details in the rest of the message
<jpoiret>infty: /run/current-system/configuration.scm i'd say?
<lilyp>Then it's okay.
<jpoiret>Here's a (baffling) autotools bug i reported last year
<unmatched-paren>also: 'so the recommended way of building my application is using `cargo install`. you need to install the rust toolchain.' 'umm, just to install an app?' 'yes. also the recommended way of installing rust is a curl | bash that installs a fancy shell script thing which handles toolchain installation.'
<jpoiret>I can't believe software that uses autotools does work
<lfam>civodul, all: I actually wonder what's the best course of action regarding the coreboot framebuffer stuff. We added it in December to make Guix System work by default for certain hardware / BIOS environments. If I understand correctly, it did fix a bug that someone had. But it introduced some other bugs, and we aren't making progress fixing those regressions. Is the best thing to revert those commits, unfixing the original bug?
<lfam>I'd appreciate peoples' opinions and guidance about this type of situation
<unmatched-paren>or: `just run this docker image right here. trust me! it'll be fiiiiiiine....`
<jacereda>OMG, I need this: Anyone got emacs-eaf running on Guix or are there plans to package it?
<lilyp>jpoiret: the insides of autotools might be ugly, but the outward behaviour is very sane
<lfam>Another complication to this question is that the person who added this work seems to be taking a break from Guix, so I don't want to keep pinging them about it. At least, that's what I'd want, if I were in their position
<singpolyma>unmatched-paren: yeah. Compared to anything language specific guix is a dream. And it can handle all those cases and more
<jpoiret>lilyp: that bug is exactly outward behaviour not being sane
<infty>jpoiret: Thank you. There is indeed a file at this location. I will examine it.
<unmatched-paren>hm, `unbound variable: gexp`; i have `guix gexp` used...
<lilyp>which bug?
<jpoiret>The one i linked above
<singpolyma>ulfvonbe`: that is an interesting idea. Can one package be composed of a bunch of derivations like that?
<podiki[m]>lfam: yeah, that's tough. maybe a discussion on guix-devel to see if any objections or better course of actions? we do have time-machine and the git log, at least (for someone to pick it back up)
<lfam>Yeah, we can always reuse the reverted work, later
<jpoiret>singpolyma, ulfvonbe`: wouldn't a single derivation be sufficient? Although with more you would get incremental compilation
<lfam>It's hard choose to to reintroduce one bug to fix some others
<singpolyma>jpoiret: that's the point. You need incremental compiles to be a useful build system
<the_tubular>jacereda I've been trying for a few days without much progress :(
<unmatched-paren>a guix extension (in the style of gwl) to automate such things would be cool
<unmatched-paren>`guix local-build`
<podiki[m]>it seems to be causing more problems than it has fixed, but that's based on what you said and recent bugs, and coming from someone that is not running that kernel.... so 🤷
<the_tubular>But yeah, the browser looks tasty
<lilyp>guix gwl is already incremental
<jpoiret>Yes, but with multiple derivations you would have some performance loss because bringing up a whole container + guile for each would be expensive
<jpoiret>s/each/each file/
<ulfvonbe`>"package" in the wider software sense, not necessarily in the sense of a guix <package> record. I imagine splitting a <package>'s builder into multiple derivations would require some modification of the <package> 'lowering' process
<singpolyma>jpoiret: that's true. Though if I have enough cores (and I do) it might amoritize out
<lfam>podiki[m]: You're right, I should raise it on guix-devel. It's tempting to just revert without asking,but on the other hand I know that's not quite right.
<lfam>That's why I haven't done it yet, really
<lilyp>well, let's be honest here, what works for a build system is typically exactly the opposite of what you'd want for a package manager
<podiki[m]>lfam: and then if not much response or push back, then it was all public and out there
<lilyp>there's only little overlap in what they both want
<jpoiret>I think a guile library for building proper build systems would be good, guix is not really suited for this itself
<lfam>I guess the other dimension of my uncertainty is that I don't want the person who did the work to feel like they have to come back from their break and deal with it
<lilyp>let's call it "please not another build system"
<lfam>So I'm wary of alerting them
<lilyp>or pnabs for short
<singpolyma>I agree. I'm always on the fence when writing a big guix build phase vs writing more make and just doing invoke make
<podiki[m]>is there a way to have those changes perserved besides in the history? like separating out a kernel version? or is that kind of messy and a bad precedent too?
<lfam>podiki[m]: Can you clarify what you're suggesting?
<lfam>Like, a kernel variant linux-libre-for-coreboot?
<jacereda>the_tubular: have you noticed ? Maybe that could save some time...
<unmatched-paren>hm, gexp still isn't working...
<lilyp>unmatched-paren: paste
<podiki[m]>I say this with no knowledge of the changes involved so far :)
<the_tubular>Yes, It is a good starting point
<podiki[m]>lfam: especially if it is for coreboot, seems something guix would want to support
<lfam>I mean, perhaps it could be done, not "perhaps we want to support coreboot"
<lfam>I would ask whoever wants that support to do the work
<lfam>As they already tried to do :)
<podiki[m]>I'm just thinking what makes it easier for you (thanks for taking care of all this! it is appreciated) while making it easy to continue that work
<lilyp>unmatched-paren: look at your code
<lilyp>now at my #$version
<lilyp>now at your code
<lilyp>now at my #$version
<lilyp>sadly, your code does not have #$version
<jacereda>the_tubular: do you have your work so far available in some repo? Maybe I could help...
<unmatched-paren>lilyp: i tried your version with #$version, it didn't work either
<lfam>I'd like to get more people involved in maintaing the kernel packages. Already we do get patches adding support for this or that, but I'd like to make this area of the codebase more collaborative
<unmatched-paren>lilyp: my code does have #$version
<unmatched-paren>it's bound to `version` in a let... oh wait
<lilyp>well, that's just silly
<podiki[m]>I've been wanting to play with alternative kernels, though sadly not libre due to hardware needs
<singpolyma>unmatched-paren: you can also use a normal quasiquote and splice
<lilyp>but the quasiquote ruins it
<unmatched-paren>nope, doesn't work
<podiki[m]>but still, something I would like to learn more about in guix land
<unmatched-paren>neither works
<lilyp>use list or ,#~
<civodul>lfam: for me the regression was roughly last week, not in Dec. (though i didn't upgrade this machine every week)
<singpolyma>I did a quasiquote and splice for version in a build step just yesterday
<unmatched-paren>ah, the unquote! :)
<unmatched-paren>it works now :)
<lfam>civodul: It's a different regression under discussion onw
<lfam>There are two different issues in our kernels
<the_tubular>jacereda no, sadly. I scrapped most of it as I'm still very new to lisp and I didn't get far at all
<unmatched-paren>...and bizarrely utop still displays %%VERSION%% even though i substituted it... oh well, i can live with it
<the_tubular>But if you check the logs of the channel, there was people talking about it the other day
<lfam>First, recent versions of 5.4, 5.10, and 5.15 panic during boot for some users. Second, the %base-initrd-modules is incompatible with the 4.4, 4.9, 4.14, 4.19, and 5.16 kernel series
<lilyp>there's also the fact that many of us had to drop the framebuffer from our %base-initrd-modules anyway
<lfam>That's the 2nd regression
<civodul>hmm ok
<lfam>The base modules should work with all the kernel packages, by default
<civodul>so should we revert the thing that led to this issue?
<lfam>It was a mistake to allow that to break. Mea culpa, at least in half. I didn't test the build of all the series
<civodul>heh, np!
<lfam>That's the question, civodul. It will reintroduce problems for at least one user, who uses coreboot and spurred this work originally
<lfam>I do have a patch prepared to revert (it wasn't trivial). I'll send it to the tracker now
<civodul>great, and you can link to the original discussion
<civodul>it's certainly a difficult situation to be in
<lfam>Yes, it's the "trolley problem"
<lfam>Which users should suffer bugs today?
<fnstudio>lfam: lol :)
<lilyp>well, could the coreboot users be helped if we add a coreboot configuration and a coreboot initrd?
<lfam>It's made worse by the kernel panics some of are experiencing, because it makes it harder (but possible) to use older kernel series that may not have the panic
<lilyp>sure, it won't be "OOTB", but at least be configurable
<lfam>It would be great if it would work OOTB, but I can't advise on the solution
<lfam>I just don't understand the overall situation well enough
<lilyp>fair enough, i was just waving my hands around too
<podiki[m]>I'm just avoiding flashbacks to my gentoo kernel configuration days....
<lilyp>hah, those were fun
<lilyp>particularly because you'd spend two days compiling to check whether they broke stuff
<lfam>Ah, the bugs were reported earlier than I remembered
<lfam>So it's been ~6 weeks
<lfam>Here is the patch ticket for the reversion: <>
<jgart>for anyone interested in setting up guix on alpine linux:
<jgart>no nscd service required
<jgart>guix install: error: while setting up the build environment: getting attributes of path `/etc/nsswitch.conf': No such file or directory
<jgart>does anyone know how I can make that error go away?
<rekado>nscd is required if you want accounts (beyond those in system files) to work. You can get away without it in many cases.
<rekado>but if your host system uses SSSD or LDAP for user accounts you should use the host system’s nscd
<jgart>rekado, so, should I just continue not using nscd on alpine?
<rekado>pretty sure you don’t need binutils
<jgart>ah ok thanks
<jgart>I'll remove that one
<rekado>have you tried “touch /etc/nsswitch.conf”?
<rekado>doesn’t say what it wants from that file, just that it wants to access it
<jgart>some of that was a heavy-handed copy paste
*jgart trying
<jgart>rekado, ah that worked!
<jgart>no more error
<jgart>it happened when I was trying to install a package from a custom channel
<lilyp>why would you want Guix on alpine when sourcehut has a Guix-based CI already?
<jgart>Should I document "touch /etc/nsswitch.conf" as necessary for an alpine install or is there some fix that can be made to guix or alpine to mitigate that issue?
<jgart>but what if you're not using sourcehut?
<jgart>alpine is not tied to sourcehut
<jgart>and I was pining for it
<jgart>for Guix on alpine
<jgart>then I can run Guix on my pinephone with
<jgart>my fav pinephone distro
<lilyp>real hackers install guix system on their phones :)
<jgart>:) Can't wait to see Guix System on pinephone some day:
<jgart>until then, I'll hack pmos/sxmo
<rekado>any Haskell bootstrap fans here? Got new patches to play with at and some docs:
<jgart>Is the haskell bootstrap story going to be real someday?
<jgart>Does it sound doable?
*jgart reads
<rekado>summary: no light at the end of the tunnel; I just have an older version of Hugs now that works, but cannot load all the compiler sources to compile the compiler with itself.
<the_tubular>Can't wait for emacs on my phone
<jgart>Are you interested in working on the crystal bootstrap story?
<rekado>don’t know crystal
<jgart>the_tubular, why wait?
<rekado>there’s a simple way to get GHC 4 right now: take the generated C files and build from there
<the_tubular>What do you mean ?
<rekado>it’s bad, but probably better than using the humongous GHC 7 blob we have now.
<podiki[m]>for emacs on mobile: termux on android maybe? (i've used that and even an X server on a tablet for emacs)
<jgart>"As slick as ruby as fast as C"
<jgart>crystal depends on llvm
<rekado>some years ago I lost my ability to get excited about new programming languages
<podiki[m]>was it when you saw lisp for the first time? :)
<rekado>when I started using it productively
<podiki[m]>similar for me, mostly I see something and think "but it is not lisp"
<podiki[m]>jgart: cool
<the_tubular>I meant guix and exwm ;)
<the_tubular>Not android and google spyware :(
<jgart>pinephone is the future of procrastination
<jgart>I recommend everyone to get one now
<the_tubular>Is the "pro" one out ?
<jgart>we just need a nice guix gui "app" so we don't have to be thumbing guix commands all day
<the_tubular>Or whatever it's called
<jgart>I just ordered one
<jgart>it's the best impulse buy I've ever made
<the_tubular>I'm guilty of ordering a librem 5 a long time ago
<the_tubular>But I'm one of the very lucky one to actually have received it.
<lilyp>back to programming languages, I'm immediately suspicious of any language that allows less than one bracket per line
<the_tubular>Yeah my bad lilyp, we hijacked #guix for a second
<lilyp>don't worry, it's a shared space, I just wanted to say that
<lfam>A Guix GUI would be amaaaaazing. Even if it was just for simple package management
<the_tubular>I think there's better place to put effort into
<KE0VVT>lfam: Too bad GNOME Software doesn't work.
<the_tubular>Guix is already very hackerish, I doubt people are waiting for a GUI, but that's just my opinion
<lfam>the_tubular: Motivation is not fungible. If somebody wants to work on a GUI, we can't transfer their motivation to something else
<lfam>Maybe existing Guix users aren't waiting for a GUI, but many people who don't use Guix might be
<KE0VVT>Ew, hackerish. That mentality is narrow.
<lfam>Hard to say, until we try :)
<the_tubular>I also don't understand how a GUI would work at all ...
<jgart>Use NixOS Without Coding
<KE0VVT>Adding support to GNOME Software would be great.
<KE0VVT>It would also help the issue of not being able to install Flatpak apps as a single user.
<lfam>I envision a GUI interface where you can search for packages to install, manage your package generations, and manage `guix pull` generations
<KE0VVT>lfam: GNOME Software.
<lfam>Just a simple subset of what Guix can do. But, for most people, they only need the basics
<KE0VVT>Add GNOME Software support. Might cost $500, but I'd save up to pay someone to do it.
<lfam>And also an interface from which to launch the apps
<lfam>Sounds like we should do it by integrating with GNOME Software :)
<singpolyma>lol, if $500 is all it would take that's not gonna be a problem
<KE0VVT>It would probably cost more to pay someone to integrate Guix with GNOME Software.
<podiki[m]>KE0VVT: what do you mean about single user and flatpak?
<KE0VVT>podiki[m]: GNOME Software only supports global installation with Flatpak.
<singpolyma>GNOME software integration, especially on foreign distro, I would like for sure
<KE0VVT>podiki[m]: GNOME Software's backend currently has no notion of a per-user installation.
<KE0VVT>Imagine updating Guix from GNOME Software.
<lilyp>To whom it might interest:
<jgart>I'd like a GUI for streamlining making a Guix System ISO and burning to disk maybe with opinionated templates for System configs
<KE0VVT>Rolling a new GUI sounds ...
<jgart>mumble server, xmpp server, etc...
<jgart>s/burning to usb
<singpolyma>jgart: you old man, what is a "disk"?
<podiki[m]>I've never used gnome much, so I guess I don't know
<singpolyma>podiki[m]: gnome software is just an application, can run outside of gnome
<lilyp>it's also the basis of the Ubuntu App Store IIRC
<KE0VVT>GNOME Software is the most conventional app on GNU/Linux for graphically managing software.
<KE0VVT>So integrating it would be the best way.
<KE0VVT>Not making some standalone obscure app that has its own UI.
<lfam>I agree, it would be awesome to integrate with it
<lilyp>yes, plus it has packagekit standardized
<lfam>And it would be great to try to bridge the gap between GNOME and ourselves
<ulfvonbe`>can new "backends" be added to gnome software at runtime? Since apparently it doesn't understand non-global installation, perhaps it can be told there are backends "guix/profile1", "guix/profile2", "guix/home/user1/.guix-profile", etc?
<jgart>I run gnome-2048 from dwm/dmenu when board
<KE0VVT>I miss the polish of GNOME. Perhaps I should just go back to Fedora, haha.
<lilyp>ulfvonbe`: It's all in the docs
<the_tubular>How do you think we can make guix more popular?
<KE0VVT>How much would it cost to pay someone to integrate Guix and PackageKit?
<KE0VVT>the_tubular: Pretty GNOME UIs.
<tschilptschilp23>I'm very fond of guix's gnome 40 as it is :)
<singpolyma>KE0VVT: first question would be *is* there anyone we could pay
<KE0VVT>singpolyma: True.
<KE0VVT>Guess can't have nice things.
<vagrantc>some nice things are not universally nice.
<lilyp>for the record, it appears as though gnome software now uses its own plugins (of which packagekit is just one)
<the_tubular>I think right now Guix is hard to come across
<the_tubular>Just like Nix
<lilyp>so there's two bridges one could cross
<vagrantc>even though i think guix is great, i get worried about aggressivly promoting it because if you get someone to try guix for someone who just isn't a good model for, you're going to be doing both guix and the person a disservice
<vagrantc>guix has tradeoffs, like anything, and there are downsides to a guix and/or nix model (there are also huge upsides)
<vagrantc>e.g. "why do i have to re-download this package at the same version for the Nth time?!" "why is it building packages rather than just downloading them from a mirror?"
<vagrantc>and even "why doesn't my wifi work?"
<the_tubular>Yes I can see that.
<vagrantc>so any effort to promote it's use needs to be very aware of issues like that, and so many more
<the_tubular>I wasn't hinting towards "promotion", but I don't know what would be the best way to bring in more users
<the_tubular>I was just thinking out loud more than anything
<vagrantc>i had a phase of overzealous free software advocacy a couple decades ago and so feel i have learned some lessons from that :)
<the_tubular>What I did notice is that all the guix talks were from Europe. Maybe that could help spread if their is talks in NA
<vagrantc>and i also don't want to suggest guix should stay some elitist small group of people; there are ways it really could benefit people in general that would be interesting to explore ...
<the_tubular>But they are all available online so I don't know the impact it would have
<the_tubular>Yes, definetly
<vagrantc>there are quite a few fosdem talks that i'm very curious to see, but yeah, timezone offsets are hard. :)
<vagrantc>thankfully, they should be recorded, and a side-benefit of an online conference is it's slightly more likely that the recording will be able to hear the speaker :)
<the_tubular>Ohh I though it was worse online than in-person
<lilyp>Well, actually I'd say that Guix can be configured just right to the likes of Windows users.
<lilyp>Just enable unattended upgrades and GC.
<vagrantc>and rules to only pull in substitutes, and ...
<lilyp>those two
<lilyp>nothing more, nothing less
<the_tubular>Does that exist vagrantc ?
<the_tubular>I'd be interested
<vagrantc>i guess windows users are used to their computer cranking the fan up all the time while it does who knows what? :)
<vagrantc>the_tubular: there are some scripts to do that sort of thing, but it assumes that your substitute will ever be available
<vagrantc>and you have to definte what you're actually needing substitutes for ...
<the_tubular>Umm, are there packages that substitutes will never be available ?
<the_tubular>Why ?
<vagrantc>because the package doesn't build?
<vagrantc>or doesn't build fast enough, and it times out on the substitute server ...
<the_tubular>What do you mean it doesn't build ?
<vagrantc>you try to build it and it breaks
<the_tubular>Umm, I see. Didn't know packages could timeout
<vagrantc>syntax errors, library incompatibilities, just about anything
<the_tubular>Got it, but those packages shouldn't be pushed upstream, it's not a problem of buildfarms though no ?
<vagrantc>oh yeah, guix being a rolling release ... that is not for everybody
<vagrantc>the_tubular: sometimes they used to build, but something in the toolchain broke building them
<the_tubular>Umm ...
<vagrantc>on any given day, some sizeable double-digit percentage of guix packages do not successfully build.
<the_tubular>Is there a way to lower that number ?
<the_tubular>Except manually patching ....?
<vagrantc>dramatically increasing the number of people fixing bugs?
<vagrantc>the_tubular: you're asking a universal question to problems of arbitrary complexity ... there's no magic bullet to solve it, or it would have been done.
<vagrantc>fact of the matter is maintaining a colleciton of 10000+ is hard and takes continual work :)
<the_tubular>My bad, I didn't know about the tons of packages breaking
<vagrantc>of packages...
<vagrantc>it's even rougher on the less conventional hardware architectures, i686, aarch64, powerpc64le, hurd, etc.
<the_tubular>Yeah, definitely
*vagrantc finds it curious that i686 is now an "offbeat" architecture
***califax- is now known as califax
<breathe>Hello! I have a guix channel where the git repo is stored locally on my machine. Is it possible to run guix pull to just update the channel without also updating the core of Guix?
<breathe>When I try creating a test channels.scm file without the default-channels, I get this error:
<breathe>hint: Make sure your list of channels contains one channel named `guix' providing the core of Guix.
<podiki[m]>breathe: I don't know, I don't think so. you could pin the guix channel to a commit though (so it won't change)
<podiki[m]> I believe
<podiki[m]>or I think
<breathe>podiki[m]: Thank you very much! That works for what I'm trying to do.
<pinoaffe>hi guix! could someone please review my #53622 series of emacs-xyz patches?
<Ribby>Hi guys, I'm going to start using guix os. I hope things go well enough. I'm probably putting too much weight taken for granted, but here it goes. See you in a few moments.
<mroh>welcome Ribby!
***aya is now known as gyara
<janneke>the #fosdem-minimalistic devroom chat is already open, still pretty silent though
<rekado_>oh, I totally missed that FOSDEM is today
<pinoaffe>rekado_: thanks for the reminder ;)
<dlowe>Trying to install clamav, and my system wants to build llvm (despite there being an available llvm sub). However, it's not even doing that, with an error while loading shared libraries: no such file
<dlowe>Okay, well, one mystery solved - clamav uses llvm internally to compile its rules, and it needs a really old version to do so
<f1refly>how can I modify the arguments given to cargo install in the cargo-build-system?
<f1refly>I'd like to install it with `cargo install --path helix-term`
<mroh>f1refly: there is #:cargo-build-flags in the cargo-build-system, see `guix edit tectonic` for an example.
<avp>Hello Guixers. :-)
<f1refly>thank you mroh, I took a look in the rust-apps.scm but didn't spot it.
<KE0VVT>Heh. rust-apps.scm
<f1refly>is there something wrong with it?
<f1refly>also apparently it's not a build flag but an install flag :/
<mroh>Then, I think, you need to replace the install phase and invoke cargo there. You can take a look at the rav1e package, except you need to replace 'install instead of 'build.
<phodina[m]>I just encountered issue when packaging rust. The package cargo-audit depends on abscissa-core which depends on color-backtrace in version 0.3 but I added phase to package abscissa-core to use newer 0.5.
<phodina[m]>As I built the cargo-audit pkg it still looks for the version 0.3. Any idea why? Should I just package also version 0.3 of color-backtrace?
<jpoiret>apteryx, civodul: seems like the culprit is, called in's main through removeduppaths
<jpoiret>and abspath in Lib/ (!!) uses normpath, which does lexical dot-dot
<f1refly>can I cd before executing a build step? I found nothing regarding that in the other package definitions
<jpoiret>f1refly: you can use chdir
<f1refly>okay, i was searching for anything containig cd or directory
<singpolyma>phodina[m]: if you are using cargo-inputs to include it, switch to regular inputs or your phases won't run
<abcdw>KE0VVT: hi, I currently refactor sway related features to get rid of hardcoded things and then need to finish a few technical tasks to make an iso, I expect to deliver it somewhere in the March.
<tschilptschilp23>On the one hand 20h chromium rebuilds eating all my memory make me really question if I need this program. On the other hand lessing up and down a 700-line ld.ldd command has a meditative effect on my mind...
<asdf-uiop>hi guix!
<civodul>jpoiret: ah ha, good catch!
<jpoiret>civodul: i'm currently trying to patch it
<jpoiret>the annoying thing though is you cannot just move out lib/python3.9 and change because the module is "frozen" (whatever that means)
<civodul>"move out"?
<jpoiret>so I'm trying out just subsituting it in the package definition, but had to make clean first :p
<civodul>problem is that it's a world rebuild
<jpoiret>yes, just copying $(guix build python)/lib/python3.9 somewhere else and use PYTHONHOME to there
<civodul>why would we do that?
<civodul>we could "just" replace the unwanted normpath use, no?
<jpoiret>I thought it'd let me modify in place without needing to rebuild the package
<jpoiret>oh yes, that was just for quick and dirty testing
<civodul>i see
<jpoiret>also, PYTHONVERBOSE=2 is pretty good to see what is getting loaded
<civodul>i do a lot of dirty testing, but it's rarely quick :-)
<jpoiret>and also, you can see that when you do `python3 -S`, sys.path is good
<jpoiret>so it's definitely
<civodul>BTW, is it expected that the first element of sys.path is the empty string?
<civodul>sounds like a security issue
<civodul>(assuming it's equivalent to ".")
<jpoiret>iirc from the code i read it is equivalent to .
<jpoiret>apart from that I don't know what it entails
<civodul>so i guess we should look into that while we're at it
<civodul>adding "." to the search path is never a good idea
<civodul>users can end up executing random code that just happens to be in $PWD
<jpoiret>about the path_hooks thing, it appears that python's import semantics are very customizable, ie you can just find/load the modules however you want to!
<jpoiret>the default one creates a new module and execs the code in it
<jpoiret>I don't know how we could leverage this to make it guix aware, but there's definitely something there
<ajarara>anyone experimented with running a guix vm on unsupported hosts (like macOS)? Emacs + tramp to communicate over ssh?
<jpoiret>i'm worried about how it would play with packages that interface with python in C or launch python in weird ways though
<singpolyma>jpoiret: indeed, you can even use these hooks to allow importing code in different syntax. That's how the xonsh loader works
<civodul>jpoiret: i'd suggest keeping things simple though
<jpoiret>yeah, let's just try to fix that nasty bug for now :p
<jpoiret>i don't even use python that much
<tschilptschilp23>ha, there's just enough memory left to listen to the cds I bought today to get rid of this cobainish 'ape me' whispering ;)
<phodina[m]><singpolyma> "phodina: if you are using cargo..." <- Thanks, I tried as you suggested to list rust-abscissa-core in input list in rust-cargo-audit. However, I still have to list it in the cargo-inputs otherwise no package is found.
<phodina[m]>Here are the two pastebins:
<phodina[m]>> <> phodina: if you are using cargo-inputs to include it, switch to regular inputs or your phases won't run... (full message at
<dlowe>Is there an easy way to query the package definition on a machine?
<jpoiret>`guix edit somepackage` ought to do it
***jonsger1 is now known as jonsger
<jpoiret>civodul: initial testing suggests that s/abspath/realpath/ is enough, I'm currently trying to `guix pack -RR python python-numpy` but i'm rebuilding glibc right now :(
<jpoiret>i've built python with that change and `sys.path` has the expected directories
<jpoiret>I can `import warnings` (or any standard module) whereas it wasn't possible before
<jpoiret>i'll raise the issue upstream once i finish testing this
<badcodec>is it just me or doesn't emacs geiser format the code buffer
<badcodec>oops wrong channel meant to ask in #guile sry
<jgart>badcodec, you might get quicker answers to guile basic questions in #guix sometimes but yea
<jgart>badcodec, does geiser have an irc channel?
<badcodec>jgart: nope
<jgart>maybe ask in their issues page
<jgart>on gitlab iirc
<badcodec>thanks. anyway
<badcodec>jgart: how would you go about building a custom kernel in guix
<badcodec>do you copy someone elses config for the package from a repo, and modify it?
<badcodec>I mean in terms of workflow
<jgart>read/peruse this directory:
<badcodec>thank you!
<tschilptschilp23>mpf. building chromium after last evening's pull (guix d7e1c5a) failes like this: (4 cores, 8GB RAM laptop). I guess I shouldn't have opened some browser tabs and VLC at the same time. Will wait for substitutes to be ready...
<tschilptschilp23>Which makes me ask -- how would I check ahead of time, if the new versions would be built from ground up on my machine, or if there a substitutes ready already?
<tschilptschilp23>By ahead of time I mean, before I see the tar.gz being downloaded :)
<tschilptschilp23>For smaller packages I do not care, but llvm (almost), ungoogled-chromium (especially), and gimp (a little) bring my laptop to its limits. I would be totally easy to be patient, but do not know the command to properly anticipate...
<tschilptschilp23>(this was not the first time that this happened, just posting it for the first time)
<jpoiret>tschilptschilp23: guix weather is the command you're looking for :)
<jpoiret>you can check individual substitutes availability with it
<tschilptschilp23>jpoiret: perfekt, thank you -- I will monitor the weather from now on more diligently :)
<tschilptschilp23>this sounds like a very appropriate name :)
<manimacro>anyone here use qutebrowser?
***jonsger1 is now known as jonsger
<apteryx>civodul: re '.' to the sys.path; that's default behavior when invoking python directly, e.g. python -m something; it's very useful to run a local project without having to mess with PYTHONPATH manually.
<cwebber>hi hi
<apteryx>civodul: you can see it in action with 'python -m site'
<apteryx>jpoiret: nice work w.r.t. to the python issue!
<jpoiret>it works properly after rebuilding everything, i'm currently working on opening a bug upstream with a fix
<jpoiret>but it looks like the bug won't be resolved until the next core-updates cycle
<jpoiret>by the way, we'll also need to update to use realpath on the inferred site directory too. I'll send all of that in a follow up email
<jpoiret>this abspath code has been there for 21 years :)
<apteryx>they may not want to change it (many things must rely on this behavior now)
<jpoiret>I'm not sure there are many python installed in the wild with a prefix containing ..
<jpoiret>but yeah, there might be some friction there
<jpoiret>it's definitely a bug though
<apteryx>a documented one, as you noted :-)
<jpoiret>for abspath, yes, but definitely not for sys.path!
<jpoiret>we'll see what the maintainers have to say about it, as the patch itself is trivial
<apteryx>true! It'll be interesting to follow.
<fnstudio>hey, sorry, i'm on a foreign distro (but i've moved all that i can to guix); i'm having issues with dunst and dbus; i think i isolated the issues to the way i use dbus
<fnstudio>is there any recommended way to launch dbus on a foreign distro?
<fnstudio>i run a relatively lightweight system, using i3 as a wm
<KE0VVT>fnstudio: Use Sway.
<jpoiret>the foreign distro's dbus or guix's?
<fnstudio>KE0VVT: is it an alternative to i3? would that solve my particular problem with dbus+dunst? would i need wayland instead of x?
<jpoiret>fnstudio: yes, no and yes
<KE0VVT>Wayland is the future. Death to my X!
<jpoiret>although you never "need" wayland, as it's only a library/protocol, not a whole server
<fnstudio>lol, then that's for another day :)
<fnstudio>i'll be very happy to try it but i'd like to figure out this annoying dbus issue first, but thanks for mentioning it
<fnstudio>jpoiret: with regard to your question (foreign distro's dbus or guix's), i think that's an excellent question, let me find that out
<singpolyma>Ugh. I hope the Wayland fad ends soon :P
<KE0VVT>singpolyma: Fad? I've been using Wayland for years.
<KE0VVT>singpolyma: X has security issues.
<singpolyma>Everything has security issues :)
<fnstudio>jpoiret: `which dbus-launch' would point me to a guix installed package
<fnstudio>well, s/points/would point/
<jpoiret>do you use a DE on the foreign distribution?
<fnstudio>jpoiret: nope, i launch x with startx and i have i3 started (as part of my xinitrc i think?)
<jpoiret>okay! then dbus-launch is the way to go, you may add it to the line that starts i3, most likely `exec dbus-launch --exit-with-session -- i3`
<fnstudio>jpoiret: splendid!! let me try that, thank you sooo much!
<jpoiret>i say that with a confident tone but it comes with No Warranty™
<fnstudio>lol, that's fine and anyway appreciated
<fnstudio>ah right
<fnstudio>i should ask, should i have anything in particular in my .bashrc or .bash_profile with regard to the dbus-related env variables?
<jpoiret>what do you mean by dbus-related env variables?
<jpoiret>dbus-launch should set them properly in the child process it launches
<jpoiret>note though that if you start other processes in your .xinitrc, they won't have access to the dbus
<jpoiret>you'd need to launch it from i3 itself, either in its configuration file or manually
<fnstudio>among my many attempts, i also tried adding a `eval $(dbus-launch --sh-syntax --exit-with-session)' line in my .bashrc
<fnstudio>which was causing each shell to have a different session, i think
<apteryx>is there a way to use offloading while running 'make check-system'? It seems to build everything on my machine.
<jpoiret>fnstudio: yes!
<jpoiret>more generally, bashrc should not start anything
<fnstudio>ok, will try straightaway and remove that line from basj
<jpoiret>bashrc shouldn't even have much apart from customizing the shell itself
<jpoiret>everything else belongs in .bash_profile
<fnstudio>oh, right, good to keep in mind... and maybe something to doublecheck after i've fixed dbus+dunst
<fnstudio>jpoiret: i can't believe it... it works! i'm so happy!! ty ty ty!
<bdju>is there a reason the guix package conflicts seems to happen more and more lately?
<bdju>I can resolve them okay but I don't recall it being a problem before. like clearly if I apply my manifest that I didn't change after doing a guix pull, it's two packages I had before without issues
<bdju>I hit one earlier, openssl and freerdp
<bdju>why did I have openssl explicitly installed? who knows... but it could've been important in the past. removed it. hopefully all is well
<apteryx>bdju: you should probably sync all the packages in your profile to the same guix revision, by uprading them all with 'guix upgrade'
<bdju>are you sure applying a manifest after a guix pull doesn't do that? because I'm pretty sure if you use manifests you never have to use upgrade... besides when there's an issue so you're doing partial upgrades or something
<bdju>I'm essentially just upgrading everything in the text file at once
<bdju>well, removing anything not in the file too and so on
<tex_milan>hello, anyone can help me with client side mounting nfs on demand? can you share your config? is it possible to do it in home-manager?
<apteryx>tex_milan: why do you mean by 'on demand' ?
<bdju>sshfs is super easy to use and solves a similar problem to nfs. just a friendly suggestion. not sure how to help with nfs
<apteryx>I'm not sure that helps, but if you have the mount points available in /etc/fstab and the nfs-utils installed, you should be able to use nautilus to mount the shares, at least it works on Guix System
<jpoiret>bdju: indeed, -m should upgrade everything at the same time
<civodul>apteryx: indeed; "python -m site" shows no empty string in sys.path
<civodul>so i guess we're safe?
<jpoiret>I haven't encountered any package conflicts yet myself
*civodul is a total Python noob
<jpoiret>my Python issue is ready, I'm waiting to see the results of the test suite on my 4 line patch before submitting it
<mroh>tex_milan: do you mean a autofs conf?
<tex_milan>well, i want to mount it when i get to the mount point. like if I used x-systemd.automount option.
<jpoiret>we don't have automounts in guix yet, they're tricky to do
<podiki[m]>anyone have any thoughts on this patch series?
<podiki[m]>in particular, working around the pciutils hardware ids (better a separate package with just that?)
<tex_milan>used sshfs, but it is slower (very slow server side), and unstable (on very unstable wifi connections - bad driver which crash a lot). nfs behaves more nicely.
<mroh>tex_milan: autofs does this. you can copy the conf with an etc-service...
<singpolyma>sshfs is pretty bad. If that's something one wants rclone can do similar pretty stable. Neither is the same kind of thing as NFS of course
<tex_milan>is it possible to mount it in home-manager / after a user login? i see, I probably need to configure my desktop to do that, not the OS.
<tex_milan>mroh: thanks, will try autofs.
<jpoiret>automounts are a kernel feature, so it's hard to use
<jpoiret>i recommend rclone with the sshfs backend though, it is more stable and faster than usual sshfs for me (no idea why)
<form_feed>Does the default Guix installation image include LVM2?
<jpoiret>at least it automatically restarts the ssh process when it bricks (for example because it lost connection)
<jpoiret>form_feed: yes
<form_feed>jpoiret: hm, thanks. I have switched to a tty and can't find pvcreate and friends. Do you know if I need to perform any extra step to access them?
<jpoiret>hmmm, if it's not in the default system profile, it's at least somewhere in the store, you can use `guix shell lvm2` to enter a profile with it in it
<jpoiret>you shouldn't have to download anything normally
<jpoiret>i thought it was there by default though...
<badcodec>it's good to only include things you need, I don't use lvm2 so it's less bloat
<mroh>tex_milan: I use something like this The config files (local-files ...) are autofs confs.
<jpoiret>badcodec: in your own system, yes, but for an install image it's better to have the tools people will need :p
<badcodec>jpoiret: ok that makes sense
<tex_milan>mroh: thanks!
*badcodec is wondering how to go about with installing Rust, to do it the idiomatic Guyx way. The version in the repo is 1.57 so I need the latest 1.58
<singpolyma>badcodec: could try --with-latest if you absolutely need bleeding edge
<jpoiret>singpolyma, badcodec: not sure that will work outright, as Rust version N almost always needs version N-1 to build
<badcodec>singpolyma: I typed guix search rust and it only finds 1.57, the --with-latest doesn't work, is there a hidden version of the latest?
<jpoiret>no, --with-latest tries to use the current package definition but with the latest available sources
<badcodec>jpoiret: oh yeah, the stage 1 compiler
<singpolyma>jpoiret: well, it this case they do want the very next version
<badcodec>yeah Rust is evolving so fast so that you want the latest bells and whistles
<badcodec>it's at 1.60 nightly, I prefer to use nightly too but thought that "stable" could be fine if it's the latest
<singpolyma>badcodec: I would think the opposite. Better to stick with a stable version, since newer compilers have a good backwards compatiblity story
<badcodec>singpolyma: a lot of Rust code requires nightly features
<singpolyma>I try to never use any feature of any ecosystem newer than I find in Debian stable. Helps other people be able to use my code
<jpoiret>yes, but you'd have to compile it with version N-1, not with version N-2 like for version N-1
<badcodec>singpolyma: it's a bit different with Rust
<badcodec>singpolyma: for example Rocket, a very big and popular framework, it reqires nightly
<singpolyma>badcodec: I'm talking about rust. I do indeed write rust code :)
<badcodec>1.4 million downloads
<badcodec>it says in the first paragraph "Rocket is a web framework for Rust (nightly)
<singpolyma>Other people choosing to use newer features doesn't mean I have to
<badcodec>singpolyma: we're still discovering how to use Rust, wiggling a bit for legroom, grasping for air with the latest rust that provides what we need
<singpolyma>Rust has provided all I need for a decade already :) I don't mind some of the new features, but "grasping for air" seems very extreme
<badcodec>singpolyma: just attempted to dscribe the use-case and find it odd that you don't experience the same thing
<jpoiret>doesn't seem great that a popular crate _requires_ nightly
<singpolyma>If you need rocket you will need nightly of course. My solution would be to avoid rocket for now
<jpoiret>still, you can try to package 1.58
<jpoiret>warning: packaging rust is not the easiest thing in the world
<badcodec>jpoiret: it will definitely be a long-term goal to have the rust installation in my config, I'd estimate I'm about 6 months away from Guile experience to integrating it myself
<badcodec>it looks like the best approach is something in the guix home config, that invokes rustup to install the toolchains
<singpolyma>Is there a good way to export the guix equivalent of a "source package" that I could put on another computer with guix and use it to build the package with no internet?
<jpoiret>badcodec: there's a high probability the toolchains won't work as is
<badcodec>jpoiret: I'll check it out
<badcodec>the way Gentoo packages Rust is is provides the rustup tool, then you can install stable and nightly toolchains through it, I'll see if it runs at all
<badcodec>but also provides the rust packages that are older
<jpoiret>yes, that won't work in guix
<jpoiret>for multiple reasons: guix doesn't follow the FHS, which tools like these assume 99% of the time
<jpoiret>Guix also uses a bunch of low-level mechanisms to ensure that binaries load specific shared libraries, using RPATH for example
<jpoiret>without those (often with precompiled binaries), even the proper glibc won't be found
<jpoiret>and so on and so forth
<badcodec>oh so the best approach is to compile it
<jpoiret>the rule of thumb is: if it downloads a binary from the internet, that won't work
<jpoiret>yes, packaging it to suit Guix's way of life
<jpoiret>nightly will most likely never be available in Guix (maybe in some channels), as it's too much of a burden to update it daily
<badcodec>ok I understand the issue, so nightly needs to be downloaded and it won't work
<singpolyma>Unless someone finds a way to automate someday maybe
<badcodec>it's part of what I do, so it's something I'll need to engineer to be able to use rust somehow, but I'm useless at Guile at present
<badcodec>perhaps with some minor assistance we'll get a grasp on how to build packages, and the workflow
<jpoiret>building packages is not the main issue i think
<jpoiret>having automated commits every day will clobber the git history among other issues
<jpoiret>and if people start depending on the nightly package but it suddenly stops building because it would require a new guix specific hack, it would be annoying
<jpoiret>but you could definitely automate that and put it in a channel!
<singpolyma>Definitely would need to prove any strategy in a channel
<jpoiret>if you plan to do so, I'd recommend trying to package the latest stable first though :p
<badcodec>jpoiret: ok, it doesn't sound worth the effort then
<singpolyma>I might get involved in guix rust stuff eventually, but for now I've tricked myself into doing JavaScript
<badcodec>where would I find the source code for the rust guix package, as a starting point? Do I check out a git repo, is there a guix command?
<badcodec>the "Packaging Guidelines" of the manual describes how to create one, but I'm not sure how to modify an existing one
<singpolyma>badcodec: guix edit rustc probably
<badcodec>oh cool thanks
<jpoiret>note that it will open a file in the store which will thus be read-only
<jpoiret>if you want to modify or add packages, you'll need a git checkout of the guix sources to work on
<jpoiret>(or you could work on the package in a standalone .scm file, but for rustc that might not be enough)
<rekado_>for the haskell bootstrap I’m tired of restricting myself to (gnu packages commencement) just because that’s where the old GCC and old glibc are. Is there a way to reference them in another module at all?
<rekado_>the module says “To avoid circular dependencies, this module should not be imported directly from anywhere.”
<rekado_>may I lazily reference some variables?
<jpoiret>the github mirror hasn't been updated in 11 days it looks like