<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 <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>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>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 <unmatched-paren>is there some way i can get the `version` variable from within a `(modify-phases)`? <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. <lilyp>unmatched-paren: #~(modify-phases ... #$version) <lilyp>C++ lambdas are line noise, sure <lfam>I don't know if everybody experiences it or not bdju <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 <lfam>bdju: It doesn't seem to matter, because you can rollback <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 <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>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. <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" <lilyp>lfam: test on CI first before pushing to be safe <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 <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 <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 <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 <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? <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....` <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. <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 <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 🤷 <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 <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 <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? <podiki[m]>I say this with no knowledge of the changes involved so far :) <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>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... <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 <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 <podiki[m]>but still, something I would like to learn more about in guix land <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 <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 <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 <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? <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>particularly because you'd spend two days compiling to check whether they broke stuff <lfam>Ah, the bugs were reported earlier than I remembered <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 <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>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 <lilyp>real hackers install guix system on their phones :) <jgart>until then, I'll hack pmos/sxmo <jgart>Is the haskell bootstrap story going to be real someday? <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. <jgart>Are you interested in working on the crystal bootstrap story? <rekado>there’s a simple way to get GHC 4 right now: take the generated C files and build from there <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" <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" <jgart>pinephone is the future of procrastination <jgart>I recommend everyone to get one now <jgart>we just need a nice guix gui "app" so we don't have to be thumbing guix commands all day <jgart>it's the best impulse buy I've ever made <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 <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 <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 ... <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 <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. <jgart>I'd like a GUI for streamlining making a Guix System ISO and burning to disk maybe with opinionated templates for System configs <jgart>mumble server, xmpp server, etc... <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. <KE0VVT>How much would it cost to pay someone to integrate Guix and PackageKit? <singpolyma>KE0VVT: first question would be *is* there anyone we could pay <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) <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>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 <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 <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 :) <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 ... <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 ? <vagrantc>or doesn't build fast enough, and it times out on the substitute server ... <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 <vagrantc>on any given day, some sizeable double-digit percentage of guix packages do not successfully build. <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>it's even rougher on the less conventional hardware architectures, i686, aarch64, powerpc64le, hurd, etc. *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) <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. ***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 <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: libLLVMTableGen.so: 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. <f1refly>thank you mroh, I took a look in the rust-apps.scm but didn't spot 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>and abspath in Lib/posixpath.py (!!) 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 <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... <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 site.py because the module is "frozen" (whatever that means) <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>we could "just" replace the unwanted normpath use, no? <jpoiret>I thought it'd let me modify site.py in place without needing to rebuild the package <jpoiret>oh yes, that was just for quick and dirty testing <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 <civodul>BTW, is it expected that the first element of sys.path is the empty string? <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 <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. <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? <jgart>maybe ask in their issues page <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? <tschilptschilp23>mpf. building chromium after last evening's pull (guix d7e1c5a) failes like this: https://paste.debian.net/1229710 (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>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 :) ***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. <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 sitecustomize.py 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>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 <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? <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>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 <KE0VVT>singpolyma: Fad? I've been using Wayland for years. <KE0VVT>singpolyma: X has security issues. <fnstudio>jpoiret: `which dbus-launch' would point me to a guix installed package <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>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>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 <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]>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. <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) <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 <jpoiret>badcodec: in your own system, yes, but for an install image it's better to have the tools people will need :p *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 <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>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>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>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>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 <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 <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