<truby>leoprikler: does what I'm trying to do make sense though? Basically, I spend a lot of time building LLVM and related projects with different compilers; it'd be really great to be able to use guix to manage these compilers and build environments. Unfortunately LLVM's build system sort of assumes you broadly follow the FHS in a lot of places :-( <truby>If I wrote a patch that implemented something like this as a flag for guix environment (-C) would this be something interesting to other people/something likely to be accpted? :-) <leoprikler>truby: the guix-y solution would be to patch the build system where necessary and use configuration for everything else <leoprikler>I think a more helpful patch would be one, that allows setting up an environment and running certain phases, specifically those before build. <leoprikler>(kinda like guix build -K but without a failing build) <truby>Yeah, I understand that for writing packages in guix. But I'm trying to use guix to make a build environment as a developer for coding/testing software that isn't going to be distributed as part of guix, like as a sort of much more comprehensive virtualenv. Maybe this isn't what guix is aiming to do but it's so close to being perfect for this use case <truby>leoprikler: that would work, but would also require the thing you're building (which might be a prototype) to have a guix package first. I guess that's not that much overhead, just approaching it from a different direction to what I'm thinking :-) <leoprikler>You don't have to have a fully working package for that. <leoprikler>And you don't have to write packages with the intention to contribute them to Guix itself. <leoprikler>You can write a rather simple definition for your package in some file and use guix environment -l FILE <truby>sure, but it's more overhead than what I'm thinking. My dream is to be able to do something like guix environment -C --fhs --ad-hoc gcc-toolchain@8 ncurses ... and git clone -> build a package that only cares that I have gcc 8 and ncurses installed and has no idea I'm using guix <truby>I'm more approaching this as a user of guix (the package manager) as opposed to guix (the system) <truby>because gcc would be in /usr/bin/gcc in my dream world :) <truby>so, for gcc it doesn't matter, we can get that from PATH right? But for ncurses? how is (x build system of this package) looking for that <leoprikler>specifically gcc -I /path/to/ncurses/include/... <leoprikler>some packages also have pkg-config files or <PACKAGE>-config binaries <truby>Maybe I wasn't clear, I know how gcc is going to find ncurses. But how is the build system of (x src) going to know where to find /path/to/ncurses <truby>(since it needs to pass it to gcc) <truby>right. Which is the problem :-) <leoprikler>most use pkg-config or the aformentioned programs <leoprikler>but even assuming you have hardcoded paths (bad idea) <leoprikler>you can do sed -e s#/usr/include/something/#/gnu/store/something-else# <truby>I fear that "most" isn't really true these days, cmake is probably the "standard" in C++ build systems these days, and that doesn't use pkg-config. then you also have waf/scons/custom makefiles :-( <truby>it doesnt. But to be fair CMake does generally work ok in guix environments <leoprikler>I just searched for it and it seems there is a pkg-config module for CMake <truby>for a concrete example, part of why I'm asking for this is the patch I posted today :-) While it'd be really great if clang behaved nicely in guix, currently it looks for its headers in very specific FHS locations that obviously don't work here. My patch specifically hardcodes clang to look for headers in /path/to/guix/libstdc++.. but this doesn't cover every use case <truby>yeah, CMake has a pkg-config module where you can ask in your build system to fetch paths from pkg-config. It's quite rarely used though, e.g. if I was writing a C++ program with a CMake build system I wouldn't ask cmake to give me boost via pkg-config, because CMake knows how to look for boost itself directly and using its built in mechanisms allows my build system to work on non-Unix platforms <truby>e.g. LLVM asks for zlib from CMake, this doesn't go through pkg-config but rather cmake's mechanisms for finding things, and this fails on Guix (there's a specific patch in llvm.scm to fix this) <leoprikler>will this built-in mechanism default to pkg-config if nothing else is found? <truby>It depends on how the FindX.cmake file was written. But at a cursory glance generally not (FindBoost.cmake and FindZLIB.cmake don't) <leoprikler>and there are no command line options like --with-boost-path=/path/to/boost? <truby>I feel like we're getting sidetracked from what I'm trying to say here. I totally agree that we want as much stuff in Guix as possible, and I'm more than happy to contribute packages for all the stuff I work on. But if I get a report from a user of my compiler saying "x version of gfortran and y version of flang builds my program but your compiler doesn't, what gives?", it'd be really nice for me to be able to check all this <truby>without fixing the build system on their code first <truby>and I have no way of verifying if they've written their build system properly :) <leoprikler>true, but there seems to be a bigger problem than that <leoprikler>assume bizzare-cc x.y.z on builds all the code (including fortran and flang stuff, because it's such an awesome compiler) on one distro (e.g. Debian), but not on another (e.g. Arch) <leoprikler>since neither Debian nor Arch are known for their reproducibility, that may very well happen <leoprikler>If you now come along with "HAHA, Guix saves the day", with or without proceeding to fix the build system, you will only introduce another build environment and one more vote on the "bizzare-cc works" or "bizzare-cc doesn't work" debate. <truby>I somewhat disagree, in that "well, if you run guix environment --manifest=... -C --fhs and then build your thing it seems to work, what's different about your system" is a useful datapoint. But it's also orthogonal to what I really mean. I'm saying that sometimes I need to test a code with multiple versions of different compilers, plus my own compiler, and see what they all do differently. Guix makes this really _really_ easy <truby>right up until the point where the code I'm trying to test's build system uses the FHS :( <leoprikler>"uses the FHS" or "makes inappropriate assumptions based on the FHS"? <leoprikler>for instance, the FHS mandates /bin/ls, which indeed is missing in Guix <truby>The latter is probably correct, but the distinction is not really relevant. I agree that if everyone wrote their build systems correctly then what I'm proposing wouldn't be at all necessary, but unfortunately that's not ever going to be the case <leoprikler>(it does mandate /usr/bin/python though, which is hilarious given that interpreters use /usr/bin/env python in spite of the FHS) <leoprikler>Making the world a better place, one build system at a time :) <truby>clang itself, for example, makes an innapropriate assumption that libstdc++ will be in /path/to/crt0.o/../include/c++ or similar. This obviously doesn't resolve in guix, so we have to patch not only the build system but the source itself of clang. (I have been thinking how we can fix this upstream in clang, and I totally think that's something that should happen, but I haven't got a concrete answer yet) <vagrantc>and python insists that /usr/bin/python should either point to python 2.x or not exist <leoprikler>which is funny, because some distros allow it to be set to python3 by default <truby>unfortunately if all I want is to build someone else's C++ software, but I want to manage all the dependencies with guix (because dependency management with anything else is, lets be honest, vastly inferior), I can't rely on their software not making these assumptions. So my dream would be to have a --fhs flag to go with guix environment -C so that if I do come across someone else's software I can build it :-) <truby>perhaps the mailing list is a better place for an RFC on this than irc? <leoprikler>guix environment --container --expose $GUIX_ENVIRONMENT/bin=/usr/bin <truby>ooo this looks promising, I'll have a look tomorrow! thanks :-) <leoprikler>it does not seem to work for /bin, but it does for /bin/ls <leoprikler>you also might have to repeat <stuff>, I haven't tested it more than running some ls <leoprikler>(which indeed does not work without <stuff>, in my case <stuff> = guix) <truby>I think I probably also need to sit down with the infrastructure team at work and see what they actually want, I'm not the one working directly on builds I'm just the one pushing guix as the solution to all our problems :-) <leoprikler>the sad thing is reproducibility on Guix does not guarantee, that it will run on Arch <truby>but, it should guarantee that it works for someone on arch that runs some guix manifest that I write? <leoprikler>I trust Arch to break Guix beyond any repair tbh <leoprikler>jokes aside, if you have guix, things should work out <truby>the main problem, that guix seems really obviously the solution to in my head, is we have shared systems where everyone needs different compilers/packages/etc and sometimes people sudo apt install things on these systems that break everyone else's workflows <truby>if everyone was on their own guix profile this problem trivially dissapears <leoprikler>the thing is, if you're building for debian-ish environments, you will eventually have to test Guix-less debian too, though <truby>I'm aware that we only solve part of the problem here, but baby steps! :-) <leoprikler>I'd also imagine you'd run into more "It works on my machine" troubles if people try building the same package with different user profiles. <truby>aha, but I can send everyone else my profile to prove it! :-) <truby>then all we need is to make guile faster on aarch64 :-(. Guile 3 seems like it may be much faster but I don't know if I can test that easily with guix <leoprikler>if you want to test/benchmark specific programs, replace the guile input with it <truby>I mean that I want to try running guix under guile 3. Could I do guix install guix --with-input=guile=guile-next? ***pikos is now known as shamangeorge
<leoprikler>you have read the manual on contributing, have you not? <leoprikler>now if you were to make a package guix-with-guile-next <leoprikler>you could use that to set up an environment to build guix <truby>guix pull takes a really long time on aarch64 compared to x86, even without substitutes :-( which is why I was looking in to performance. It spends a lot of time in e.g. libgc and other guile interpreter functions rather than actually building anything concrete <truby>and I'm hoping the aarch64 jit in guile 3 will fix this issue :-) but that may be optimistic <leoprikler>then time ./pre-inst-env guix build <something> vs. guix build <something> <leoprikler>not really sure, how to measure pull performance though <truby>I haven't done real concrete measurements but guix pull takes ~30 minutes for me on an AArch64 server and ~30 seconds on my x86 laptop, and it doesn't seem to be a lack of substitutes that causes the problem <leoprikler>tbh I'm kinda interested in those numbers myself <truby>but that's based on brief observations <leoprikler>the compilation of some of those things takes ages if substitutes are having a bad day <truby>Yeah, it's very variable. And it's possibly at least partly down to aarch64 having fewer substitutes <truby>If we start using guix for all the stuff I hope we will, I hope that's something we can help with <leoprikler>I'm not sure how possible that will be. Or at least I assume, that better runtime performance will mean worse compile times. <leoprikler>(And we already spend a lot of time compiling package modules.) <truby>What is it that the package module compiles during guix pull actually do? Is it compiling dependencies or guile code? <leoprikler>Packages, i would assume, i.e. the (define something (package ...)) code <truby>Ah right, so my assumption that the performance difference is due to guile not being so well optimised on aarch64 is probably correct? <truby>Guile 3 seems it should be a lot faster so that's why I was asking about it :-) <leoprikler>I have no numbers, so I can neither confirm nor reject this hypothesis. <leoprikler>Anyway, it's late and I've given my Guix some stuff to do. <leoprikler>I will now sleep to the sound of packages being built. <Gooberpatrol66>i have uefi enabled, and i can see the flash drive is 1st in the boot order <ArneBab_>Is there an alternative to ungoogled-chromium yet? Without an up-to-date chromium-derivative my Guix system isn’t suitable for Home office anymore :-/ <ArneBab_>Sadly icecat is no complete replacement: I have to test stuff on both browsers. <vagrantc>other than builds taking a long time, updated patches should be available to revive the old package against a newer version <ArneBab_>can you estimate the time it takes to update the version? Where can I find the patches? <vagrantc>it was defined in guix/gnu/packages/chromium.scm <ArneBab_>I’ve been looking into it the past 15 minutes, but am now running into my time limit … <ArneBab_>ungoogled chromium is now at 78.0.3904.97-2 <ArneBab_>(but debian at *-1, I don’t know why the discrepancy) <ArneBab_>the notes I took (maybe they help someone): <ArneBab_>(define %chromium-version "76.0.3809.132") ;; 78.0.3904.97-2 <ArneBab_>(define %ungoogled-revision "8eba5c0df1a318012e3deab39a9add252a0d56a3") ;; acaf16383f264d8a2f24142ad054c9b4355771d3 <ArneBab_>(define %debian-revision "debian/76.0.3809.87-2") ;; 78.0.3904.97-1 <efraim>git grep svn-download | cut -f1 -d':' | sed -e 's/scm$/go/' | grep go$ | xargs rm -- <efraim>if anyone else doesn't want to 'make clean' after the changes to svn-download <efraim>sneek: later tell jonsger here's the diff I have for my powerpc. 'GUILE_SYSTEM_COMPILED_PATH' is empty but it didn't fix the issues I'm having with my static guile <efraim>I'm looking at the icecat source derivation, can I do something similar to replace the rust crates inside other sources? <olivuser>so, again, after updating, I am prompted that it would be a good idea to "set the necessary environment variables". Can anyone explain to me how that works? <olivuser>I'm asking because initially I thought that I'd just put the line in .bashrc, but when sourcing, bashrc would get angry and say that the " . " syntax is bad. Thus, I thought I'd have to have both paths exported, with a colon separating both paths (export GUIX_PROFILE="/home/user1/.guix-profile:$GUIX_PROFILE/etc/profile"). But when I had this in my .bashrc, I was still notified to set my environment variables <leoprikler>olivuser: I don't think .bashrc is the right place for that <leoprikler>on Guix System, things /should/ work fine if you just spawn a new shell <olivuser>leoprikler, so essentially I can ignore this message? <olivuser>I mean the message that I was referring to earlier, which pops up sometimes after I installed stuff. <leoprikler>yes, but you might want to do those steps if you keep using the shell that you guix updated in <leoprikler>iirc this message pops up when a new path gets introduced that was not set yet, but i might be wrong about that <olivuser>leoprikler, while you, dear mister, are still watching, I've got another question. can you tell me how re-compiling (after configuration) works with suckless plugins in gux? <olivuser>or if it works any different than it would on normal machines? I am wondering since the store is not something I should tamper with. but somehow I still have to access the source code or have it in the same place as the config.h by which suckless plugins are configured <leoprikler>the guix-y way would be to write a package for that, e.g. suckless-tool-with-my-awesome-patch <olivuser>and to then point to the location of the config.h file? <leoprikler>you can generate the config.h file in a pre-build phase <leoprikler>(I imagine they put their default config.h somewhere in the source) <leoprikler>or for very complex setting you can include a .patch file and reference that in the (origin) <leoprikler>for the last one, you'd have to use a custom channel <olivuser>leoprikler, I have another, "non-technical" question for you. what is your (programming-related) background when going about guix? I'm asking because I'm not a programmer but a very interested and ideologically convinced sociologist willing to learn to program. And whenever I ask something here in the channel I get the feeling that I am about the only person sufficiently harakiri to try to invest time into a project only programmers invest time into <olivuser>and that I'd have to learn soooo much more before actually profiting from the answers that knowledgeable people like you give to me - or to ask for a very long time before I actually understand <leoprikler>to answer your question, I'm a Computer Science student, so my experience is certainly different from someone with no background in programming at all. <leoprikler>However, I am self-taught in both Emacs Lisp and Guile (also Guix by extensions), since you don't get to learn that in universities. <olivuser>yeah thats what I suppose, these are not the hegemonic languages told in university. <olivuser>but I guess knowing /a/ language is a big plus when learning guile/elisp. for me it is veeeery difficult to wrap my head around the core concepts of programming <leoprikler>In my opinion, it should be possible to learn LISP (dialects) easily, once one gets over one's irrational fear of parentheses. <olivuser>leoprikler, yeah thats what I think too, in principle. but still, I currently feel that my learning progresses like a snail, extremely slowly, because it has not yet clicked. Thus I am very frustrated when I ask someone (like you) and only remotely understand what the hell you are talking about <olivuser>even though the explanation is probably valid and not too complicated to understand, if it is not for fundamental basics missing <olivuser>leoprikler, well said, thanks for the headsup :) <leoprikler>No, that's my fault too, because I'm keeping things brief. <olivuser>leoprikler, well but who can expect people in irc to explain things in a very verbose fashion. after all, it is freetime that is spent in explaining things to people that they could, in principle, learn on their own <leoprikler>An overly detailed answer would probably be overwhelming at first sight too, but a proper walkthrough for some packages is the way one actually learns. <leoprikler>If you have no background in programming, what draws you to suckless tools? <olivuser>yeah, thats completely true. yet, it is a question who has the resources to do so. especially since I am probably not the only person asking entry-level questions. I already considered talking to guix devs to write an entry-level blog which really walks people through, to a point where it is boring as fck for experienced people, but the right level of verboseness for extreme newcomers <olivuser>leoprikler, because I like visual and programming minimalism. the former is less distracting on the eyes and the latter enables me to run very very old machines with a graphic interface <leoprikler>olivuser: For a more generic explanation, you can have a look at the Guix cookbook <olivuser>I switched to vim/emacs during my masters thesis because my eyes would be too distracted to concentrate on the writing process when using word or texmaker <leoprikler>For specific questions, e.g. "what is wrong with this package definition", IRC is a better help? <olivuser>leoprikler, yeah I already checked the cookbook. but I guess I wont come around actually learning scheme to make proper use of guix capacities <xd1le>olivuser: regarding learning scheme, sicp is a great book but idk maybe these days it's too old/not modern <leoprikler>I started with Elisp snippets before they became packages. <xd1le>but i think more so you would be spending more time learning guix-specific guile things, since scheme itself is arguably pretty minimal <olivuser>xd1le, I actually bought sicp and I am veeeeeery slowly working my way through it. doesnt really help that Im a lousy mathematician and kind of struggle with implementing mathematic formulae <olivuser>xd1le, my issue with guix is that my base-level programming knowledge is too limited, I feel. When I read through the manual, it kind of makes sense, but I would know how to do on my own - even when mostly copying from the manual -, and am easily confused in the debugging process <xd1le>honestly you probably don't need to finish the whole book to make use of guix? but I'm not sure I guess it's hard to assess from the other side. <olivuser>xd1le, yeah probably. I guess Im just a bit too impatient to accept that learning to program takes time - just as learning any other complicated thing does take time <xd1le>olivuser: if you like suckless projects, does that mean you know C? I find C much more difficult. But yeah guile debugging and just debugging in general can be tough. <olivuser>xd1le, hahaha. no, that would make learning guile a lot easier. I am drawn to suckless for its minimalism that makes it capable to run on old machines <leoprikler>Most people are not really excited when doing (fib n) <xd1le>yeah indeed, taking time is the biggest thing to accept I guess, not that it's too difficult for you to learn or anything. <xd1le>olivuser: ahh. I figured if you knew C I could give a comparison with it for guile. <olivuser>leoprikler, yeah, thats why I was excited about the suckless thing. but your suggestions, while probably legit, were kind of daunting for me. but then again, a newbs threshold is very low compared to a proper programmer. <xd1le>Guix using guile I feel is actually a great 'feature' though. But I guess that's easy to say when already knowing guile. <leoprikler>tbh I think packaging some suckless tool would be a great experience too <olivuser>anyway, I am very grateful for you to take your time to reply to my questions. thats what makes learning quite a bit less shitty, because you then feel less alone with those problems. I tell you, about no other social scientist I know gives a crap about linux/programming matters <leoprikler>that's hurtful as a programmer who gives a (admittedly small) crap about social science :( <xd1le>if you have no programming experience, I can highly recommend learning racket as I feel they are more newbie friendly with all the documentation/guides they have, compared to guile <xd1le>olivuser: but it's a similar language to scheme <xd1le>they even have a racket ide for complete newcomers to programmer, drracket <xd1le>or you can just use racket-mode with emacs, I saw you say you use emacs <xd1le>but their irc channel is less active I feel than #guix/#guile <xd1le>but they have a long history with teaching scheme (previously racket used to be a scheme dialect called PLTscheme) <olivuser>xd1le, so it makes more sense to learn racket instead of scheme? I was unsure, also because I have already bought sicp and thought that, after all, the difficulty to learn shouldnt be too different <olivuser>leoprikler, I know, it hurts me too. on the other hand, I can play the linux pope when their old computers dont support windows anymore :-) <leoprikler>Racket, like Guile, is a Scheme dialect, so the basics are the same <leoprikler>However, they diverge as soon as you consider extra features. <xd1le>racket isn't all that different from scheme (from what I know), so you can probably apply racket to sicp <dutchie>I think if you want to learn racket you should also consider How to Design Programs <olivuser>alright. Then Ill see how long I am able to follow sicp, and if Im no longer able to follow I will see how far I get with racket. I already found two introdutory books, one in english and one in my native language (german) <xd1le>in racket you can also just use r6rs scheme by putting "#lang r6rs" at the top of your racket file, but then yes it won't be racket anymore <dutchie>"As the years have passed the programming language Scheme has evolved. The language #lang sicp provides you with a version of R5RS (the fifth revision of Scheme) changed slightly in order for programs in SICP to run as is." <leoprikler>perhaps Guile should consider such an environment too <olivuser>dutchie, thats a good suggestion, I already have that on my "radar" in case sicp fails me (or I fail it, depends...) <olivuser>leoprikler, I would love this, because it would lower the threshold for people to, for instance, start packaging. <olivuser>I had already considered to suggest something like a "you have no clue, then read this"-blog for people who are as inexperienced as I am <olivuser>but I guess it will take me some more time until I am able to explain stuff to other people instead of getting stuff explained by people :D <leoprikler>btw. have you found programs in SICP that don't work like they should in Guile? <olivuser>leoprikler, I have not come past chapter 1, so I cant judge this. thing is that I wanted to minimise the chance that I get confused by things working differently in scheme and guile, because I would be unable to differentiate <xd1le>Guile is a scheme implementation, so it should work same as what the scheme language says <xd1le>but there are lots of scheme implementations, which is where you'll find many differences <leoprikler>Scheme is less of a language and more of a family of dialects <olivuser>xd1le, but a noob cannot differentiate between things not working because of a poorly or wrongly written program and an error related to a different implementation <leoprikler>given that there is no "standard" implementation whatsoever <leoprikler>you can ask more experienced people whether that's a bug in your program or of the interpreter <leoprikler>in fact, if you copy examples from a book and they don't work as expected, that's probably what you should do <leoprikler>(unless that book has been discredited before, which SICP has not afaik) <xd1le>Right, leoprikler basically just said what I was going to. <leoprikler>but even if that book has been discredited, you're not going to find out about that unless you're asking for help <xd1le>My main reason really for recommending Racket to newcomers is (probably) more internet resources regarding racket dedicated to newcomers. Other than that, should be able to use either Guile or Racket for sicp, but probably guile would be better since it is a scheme whereas racket isn't. <leoprikler>I'm not a teacher, but my personal gut feeling is to teach something that will later be useful. <leoprikler>To me it makes little sense to install Racket as a teaching aid if it's not going to be used elsewhere (as part of a project or whatever). <leoprikler>With the goal of writing simple packages already on the table, learning Guile and some of its specific oddities has its merits. <leoprikler>That said, I might be biased, because my university forces me to use Scala and I've learned to hate everything in any way related to the JVM. <olivuser>yeah I thought that sicp might be in a way closer to guile (since it is a scheme). <xd1le>yeah I was thinking learning racket could translate to scheme easily but I guess it could also trip you up. It's hard for me to judge as well since I don't really use racket anymore, but still use guile for guix. <leoprikler>Exercise 1.5 tought me something valuable about tail recursion. <olivuser>leoprikler, do you have a good resource for the answers to the exercises? because there is some exercises where I dont know what to do even after I have thought about it for like 2 hours. <leoprikler>The purpose would be to think them through (alone or as a group) though, instead of consulting a cheat sheet. <dutchie>olivuser: many many people have posted their solutions online, you can often find them on github or similar <dutchie>but definitely have a proper try on your own first <olivuser>dutchie, I have searched for solutions. but some of them were confusing to me and with some of them I was unsure whether they are right or not. Its mainly about having a source of reliable information where I can peek if i REALLY cannot come up with a solution or do REALLY not have ANY idea how to solve the issue. Another sad social scientist story, no one wants to learn scheme with me :> <dutchie>I've glanced at a few solutions and they seem ok <fps>what package do i need to install if gtk apps crash with e.g. (xfce4-terminal:793): GLib-GIO-ERROR **: 14:26:32.348: Settings schema 'org.gtk.Settings.FileChooser' is not installed <dutchie>oh, wait, that's a different error to the one I had <fps>is this considered to be a bug? the software is not functional without it. shouldn't it then be an input (not native-input, even transiently) <fps>also that package didn't help ;) <str1ngs>xfce has it's own settings daemon. though I think it's compatible with gnome settings daemon <truby>olivuser: I've heard good things about How To Design Programs for learning to program as a beginner, I think it's a little more approachable than SICP? It also uses Racket :-) <truby>Is there a way in a manifest file to pin to a specific commit of guix? E.g. if I want a fully reproducible build environment with --pure that I can commit to my repo and everyone can use <str1ngs>truby: to pin to a guix commit you need to use channels <olivuser>when I install an emacs extension (package) via guix, do I need something like "use-package-always-ensure" in my config file? <olivuser>does it also mean that if I commented out a package in my init.el and still have it installed in my guix system, it will still try to load and compile it? <fps>str1ngs: just the i3 window manager <dutchie>olivuser: no, it won't load it unless you tell it to. something like (for example) `(use-packge racket-mode :mode "\\.rkt\\'")` should do the trick if you have installed the emacs-racket-mode package <str1ngs>fps: after installing xfce4-terminal and restarting your X11 session does the problem persist? <fps>str1ngs: yes. it happens when i close the preferences dialog <fps>which also has nothing to do (on the surface at least) with the gtk file chooser <str1ngs>fps: so the terminal works but when you close the preference dialog you get that error? <fps>str1ngs: oh, hold on. i removed the package again. sorry. let me retry <str1ngs>fps: install the package, logout of your x11 session. long back in. just verify that still replicates the error <olivuser>do you happen to know why emacs cant find mit-scheme (or racket, or any other programming language installed via guix) when I try to run "M-x run-mit"? <dutchie>does your $PATH include $GUIX_PROFILE/bin? is emacs picking up the right PATH from the environment? <olivuser>dutchie, how would the second have to be done? <dutchie>depends on your graphical environment most likely <olivuser>would I have to add it to the "exec-path" variable in emacs? <ggoes>update - i installed guix successfully on a librebooted x200 with full LUKS last night, so that works okay. i know one or two people had issues. <dutchie>olivuser: that would work, but you probably want to make sure your PATH is properly set for all applications <dutchie>are you using a login manager (gdm, slim, etc)? <dutchie>hmm, iirc gdm is supposed to source ~/.profile and so on <dutchie>I also remember that it's a giant pita to figure out which of these files gdm is actually reading <dutchie>but in one of the ones sourced by gdm you want to have `export GUIX_PROFILE=$HOME/.guix-profile; source $GUIX_PROFILE/etc/profile` <dutchie>that'll set up all the environment variables you need <dutchie>(including but not limited to $PATH) <olivuser>dutchie, is that something that I would add to my bashrc or that I do just once? <fps>str1ngs: sadly, the error persists.. note: i have xfce4-terminal installed via the operating system config (and i just noticed, gsettints-desktop-schemas, too) <dutchie>olivuser: you want it somewhere so that both bash shells and your graphical environment see it <olivuser>dutchie, what would that be? if you say that .profile is read by dwm, then it would be .profile and .bashrc, no? <str1ngs>fps: if you click menu item Terminal and then click save contents.. do you get the same error? <olivuser>dutchie, I guess that I just reached my knowledge limit again. thanks for your time, will try when I have more nerve to investigate :-* <str1ngs>fps: ^ though I'm not sure if this will fix the problem. since I use a xfce session with i3 as my wm <fps>str1ngs: yeah, i only installed the xfce4-terminal package because i'm sick of rxvt. it was cool in 1994 :) <fps>oh, it's uxterm actually :) <str1ngs>fps: I suspect (service xfce-desktop-service-type) might resolve this <str1ngs>fps: the problem i suspect is i3 has not setting daemon. so you need to probably start one manually <fps>hmm, i'll look for a terminal package that actually works first :) <str1ngs>personally I just find it easier to use xfce session and use i3 as my wm. since I use xfce-panel anyways <str1ngs>fps: you can try with gnome-terminal but I suspect you will get the same issue <fps>lxterminal doesn't seem to immediately crash and burn. :) <str1ngs>yeah, this is more of a session issue <fps>i'll try the xfce-desktop-service route. <fps>thanks for your help! <str1ngs>fps: see if $ guix install xfce && xfsettingsd && xfce4-termina helps <str1ngs>though maybe you can't start xfsettings without a xfce session <fps>btw: what's this module-import-compiled-builder i see so often during guix operations? <alextee>texi2pdf worked! i was missing the hug texlive packages <alextee>i'll try to see which packages exactly because i installed a bunch of stuff <zimoun>Hi, the sources of the package gdsl (gnu/packages/datastructures.scm) are now down because gna.org is down (see bug#25913). Therefore, it is built using the source from ci.guix.gnu.org which currently works but it is not really nice. Given a look at Software Heritage, the sources are already inside. However, I do not know how to proceed: replacing the current source by the SWH one. Any advice or pointer? Thank you in advance. <bavier>zimoun: SWH will be used as a fallback if other sources disappear; to me it seems like not an immediate issue. <fps>hmm, is there a way to get access to the "guix describe" command in a package build? <fps>i.e. as native-input :) <fps>or some other way for the build process to know what guix version [commit] was used to build a package? <fps>hmm, maybe i can pass the guix version via #:make-flags in the package description <fps>but how to get the guix version inside the package code at guix invocation time? <zimoun>bavier: I am not sure that the store on ci.guix.gnu.org is reliable as source for building package. And the other sources already disappears. From my opinion, we have 2 choices: 1. put somewhere (Gitlab, Github, Savanah, etc) the source of GDSL (only required by the package bwa-pssm) or 2. use archive stuff (archive.org, SWH, etc). <fps>hmm, ok, so guix repl gives me a repl with guix modules loaded <fps>and i can actually (use-modules (guix describe)) <fps>but how to make use of that to get the commit string i don't know hyet <smithras>hi guix! I've got a question about packaging <fps>smithras: go for it! <smithras>I recently packaged minisat, a 10-year-old SAT solver that I needed for school. I have it in my personal channel at the moment, and I could submit a patch for guix, but I don't know if anyone else uses the package <smithras>Is there a set of guidelines for what should be packaged? <leoprikler>you can package anything as long as it's free software <leoprikler>as for how to package it and submitting patches, there is the Contributing section of the manual <fps>beware though, it's not the easiest to parse. best look at some example patches on guix-patches mailing list <roelj>fps: There's %guix-version in (guix config). Maybe you can use that to get the version of Guix in your recipe? <smithras>leoprikler: Thanks! I'll see if I can get a patch sent later today then, who knows, maybe someone will find it useful! <leoprikler>(by the way, you may want to add it gnu/packages/maths.scm, z3 is already there) <fps>roelj: yeah, just stumbled across that one, too. trying now :) <civodul>fps: you can do (profile-channels (current-profiles)) <fps>this doesn't work with #:make-flags <civodul>er, (profile-channels (current-profile)) <fps> #:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out")) (string-append "GUIX_VERSION=" %guix-version)))) <fps>i guess because it's in a gexp? still learning :) <fps>civodul: i guess the same problem would appear with that variant, too? <fps>civodul: i guess the same problem would appear with that variant, too? <roptat>fps, have you tried ,%guix-version (with a comma)? <roptat>in the arguments field of the package, you're probably inside an s-expression <fps>roptat: right, yeah, that made a diff <civodul>fps: ah no, you cannot quite use the Guix version in the package definition, otherwise the result of that package definition would depend on the Guix version in use, not something you'd wanty <fps>civodul: well, in this case i want it to depend on the version <leoprikler>in other words you'd have a package that would always need to be rebuilt? <fps>it's the fully reproducible article and it must include a version of guix in the text to be fully reproducible for outsiders.. <fps>need to run to a talk.. bbiab... <civodul>fps: ooh, i'm interested in that kind of stuff too :-) <civodul>the way i'd do it is by somehow including the output of "guix describe" along with a manifest in the article <civodul>actually, you can put these two files in a repo, and give the URL of that repo <pkill9>hmm, would it be a good idea to have guix error if it is asked to install the `guix` package (both from being added to the system config and from the `guix install`/`guix package --install` commands)? Maybe add a flag such as `--allow-install-guix` incase someone wants to install it to a profile for whatever reason? It might help eliminate problems newbies encounter <leoprikler>i.e. guix is hidden from install, but not environment <fps>hrmpf /gnu/store/azd3rg350gjkgzvzps3s4j3kpz5kxh57-texlive-bin-20180414/bin/mktexfmt: mkdir(/homeless-shelter/) failed: Permission denied <fps>oh well, guix pull'ing. let's see what gives :) <str1ngs>fps: if you are trying to use HOME in a build it is set to /homeless-shelter <fps>str1ngs: yeah, i figured. i suppose i might have to setup a temporary home for pdflatex to actually work <fps>temporary "fake" home <fps>hmm, if i use the full texlive package then it works. <rndd>does anybody use docker on guixsd? <rndd>dont really understandm how to use docker within guixsd <rndd>installed package with guix install docker <rndd>but have only dockerd and nothing else <vertigo_38>not tested, but there's also docker-compose available, maybe this could bring the common commands? <amz3>rndd: maybe explain what you want to achieve with docker? I you would like the run an existing docker image? or build you own? <pkill9>rndd: you also need the docker-cli package <rndd>amz3: run existing packages <rndd>amz3: "Cannot connct.. Is docker daemon running?". Usually I do systemctl start docker.service. How I can do something like with shepherd? <amz3>I am just trying to avoid the x/y problem <amz3>(fwiw, I think using docker on guix is... not natural. The guix way would be to create a package definition and service for sheperd) <amz3>rndd: if you don't have an answer here send a mail to the guix help mailing list. <rndd>amz3: I've installed docker-cli. After that I tried "docker run hello". In what I got "Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running". <vertigo_38>I just added another user to my system through config.scm and reconfigured. I can see the user in /etc/passwd and all the id-information is correct. After giving it a passwd, I also see it at the login screen (gnome), but there was no /home/USER created on the filesystem, so I can't really login. I also can su to the new user, but also from there only the home directory of the initial user is visible. Do I have to create the directory, <samplet>rndd: You need to add the Docker service to your operating system configuration. <civodul>it might give you an idea of how to tweak your config <leoprikler>vertigo_38: there is probably a service that needs restarting, but I'm not sure, which one <civodul>normally "user-homes" is restarted upon "guix system reconfigure" <civodul>so it should have created the home directory <vertigo_38>leoprikler: it is indeed, just was there ;) Thanks a lot for the hint! <vertigo_38>leoprikler: the only minor downside was, that one screen stayed black, just the mouse pointer showed up. I will logout now and check! <blisszs>I've been using the guix binary on my computer and it's been annoying having to update PATH everytime I install or remove a package. Is there a way to do it automatically, like nix? <nckx>blisszs: The same way as in Nix, by source'ing $GUIX_PROFILE/etc/profile. <sneek>Welcome back nckx, you have 1 message. <sneek>nckx, raghavgururajan says: Thanks! <nckx>blisszs: What do you mean by ‘having to update PATH’? <blisszs>every time I install or remove a package I have to source $GUIX_PROFILE/etc/profile <pkill9>possibly running hash will update the paths <Jalepeno_X>I chose the enlightment desktop but I'm confused on how to open a command prompt or download an application like web browser. <pkill9>but i suppose that still requires running a command <pkill9>Jalepeno_X: you add xfce-desktop-service <pkill9>blisszs: fish shell updates it automatically, dunno if you're willing to switch to it <nckx>blisszs: PATH doesn't change when you install or remove packages. <blisszs>PATH doesn't change but it won't show up in dmenu or in the shell completion unless I source it. <Jalepeno_X>has anyone used enlightment? I can't find where the terminal is. <blisszs>pkill9: Thats interesting. Maybe fish shell updates PATH everytime a command is ran.