<benjamin1>is there a way to get a debug repl for a failing build <benjamin1>I tried running 'package-derivation' in a guix repl, but the debugger it dropped me into was for the client, not the build daemon <mbkamble>Can anyone suggest how services launched from my home-environment (eg emacs daemon) see the env variables (specifically PATH) setup from ~/.bash_profile rather than just that of /etc/profile? I have packages in ~/.guix-extra-packages that I need to be accesible in emacs <lilyp>mbkamble: wrap them in a shell script that sources the relevant extra packages? <mbkamble>how I ensure that it gets source by shepherd? This is the pstree hierarchy of emacs: hepherd(1)───shepherd(2245)───.emacs-28.1-rea(2246) <lilyp>have shepherd launch a shell script or alternatively, since it's guile code, have shepherd setup the environment variables <mbkamble>understood. I think I have the skills to write the shell script and launch all my daemons through it (emacs, gpg-agent). I don't kow guile enough to achieve the env var setup for shepherd <nckx>Oops, sorry for the spam. <mitchell>When i cross compile for arm-linux-gnueabihf and run `file` on the output it tells me it's compiled for "GNU/Linux 2.6.32" How can i build it for other versions like 3.2.0? <sneek>mitchell, you have 1 message! <mitchell>wait it is not the problem. It is only guile that has a problem starting <mitchell>guile -v and -h work. but it crashes when launched normally <nckx>mitchell: You'd have to modify glibc but why would you ever want to do that? <nckx>mitchell: Do you know what that number means? If not, don't touch it. I don't see the connection to Guile so assume it's unrelated. <nckx>Sorry, just a bit worried you'd brick your system to make number go up :) <mitchell>However i've narrowed the problem down to my specific package. When i say "guile" i mean a c program i've written which links against the guile library <mitchell>when i pack guile, it works. when i pack my application it segfaults on cross compilation but works natively <mitchell>I'm sure the problem is in the way i've defined my package and not with guix or guile *nckx 's not that sure, but if you are... <nckx>Since you mentioned glibc (deliberately or not): you're not mixing host & Guix libraries in one process, right? That seldom works. <nckx>I must go, however, my 2h of sleep need me. <mitchell>No I was simply taking a stab at the dark and ran `file` on a binary that worked and on my program. The only difference was the glibc version (which i guess is what that number is) <mitchell>but i made another pack with some other stuff, including guile, and it all worked fine <nckx>It's the minimum Linux kernel version that the glibc the binary links against will run on. But even that is a bit of a lie in Guix, since the only '2.6' we support is actually heavily patched IIRC. Long story short it really isn't something you should worry about. <nckx>It's nothing to do with library versions. <nckx>What do you mean by pack, and where are you running this pack? <nckx>I doubt I'm going to generate ideas at this hour. <nckx>I'd ask you to share your complete package if I were sticking around, so if nobody shows up I suggest asking the help-guix mailing list and including more details & code. *nckx nodding off; good night. <mitchell> https://paste.debian.net/1245224 Here is my approximate package definition. This is a work thing and I cant share the sources with the outside world but i am not doing anything except calling scm_boot_guile which should drop me into a repl. I am cross compiling to a xilinx zynq-7000 which is a cortex-A9 armv7. I call the following `guix pack --target=arm-linux-gnueabihf my-guile guile htop tree`. I copy the resulting tarball to the <mitchell>device, unpack it, and source the profile. All the programs work as expected except my-guile which seg faults when not run with --help or --version. <mitchell>strace shows it trying to load a bunch of guile site files (and succeeding?) until it crashes <mitchell>the guile package itself has a lot of propogated inputs. Perhaps i should inherit those to my package as well <benjamin1>this is from a guix installation on top of void, and I wrote a runit script for the daemon myself <benjamin1>wondering whether the 'LANG' environment variable for the guix-daemon itself matters actually <benjamin1>it seems like that kinda breaks reproducibility, right? <benjamin1>if the locale of the host running the daemon affects the result *yewscion is back (gone for 06:57.44) ***piyo` is now known as piyo
<retropikzel>I'm trying to make package out of stklos. If I download the source and do ./configure && make it works. Put when building as package ./configure fails to recognise the OS and the build fails on compilation. Can I somehow make ./configure find the info even when compiling as package? <lilyp>"configure fails to recognize the OS" sounds rather cursed <lilyp>in any case, utils/shlib-options has the magic <maximed>benjamin1: FWIW, guix could detect that the UTF-8 hasn't been set up and bail out? <maximed>And there are some plans for making Guile support files with arbitrary file name encoding (independent of locale) which would make things more error-prone <maximed>Though as it is currently, it also seems a reproducibility problem to me. <retropikzel>lilyp, I can find multiple utils files but not shlib-options <jmes>Maybe a dumb question but where are .so files installed on guix? I need libffi.so to do stuff with CFFI in common lisp, but it's not found after installing with guix install. <jmes>unmatched-paren: right, so what is the guix way to have that in my PATH like it would be in a more traditional /usr/lib directory? <unmatched-paren>if you have them in your profile, they're symlinked to ~/.guix-profile/lib/ <jmes>oh, that's what I need! Thanks <unmatched-paren>Usually we use pkg-config files to figure out where libraries are in C builds <jmes>I'm still wrapping my head around guix as a noob <unmatched-paren>Everything you have in your profile gets symlinked into ~/.guix-profile <jmes>Yeah I think I knew that at one point but I just got back on guix after a hiatus <unmatched-paren>so if you install "hello", you'll have a bin/hello in your ~/.guix-profile <jmes>Perfect, I've been learned! <lilyp>retropikzel: it should be in the source tho... <civodul>mbakke: yay for all the core-updates stuff! <bjc>any committers around who can look at 55081? it's a tiny thing that allows me to use geiser with guix over tramp, and it's been sitting around for months *raghavgururajan updated Gajim <unmatched-paren>Could someone who's interested take a look at 55903? "[PATCHSET] Adding aerc" <mbakke>civodul: indeed! Feels good to be hacking on Guix again after a rough year :-) <efraim>not so happy with openntpd, I always need to restart it after booting up and then my clock jumps forward about 3 minutes <dhruvin>I am packaging guix for alpine. I got all (guile, and native) dependencies packaged already. I am able to build guix-daemon successfully too. I have a question and an issue I need help for. <dhruvin>The Makefile requires bash (due to ((line++)) and maybe some other bash specific stuff) and coreutils (cur --delimiter=":" and maybe some other stuff) <dhruvin>I worked around this problem using make SHELL=/bin/bash .. (and having binaries from coreutils available at build time) <efraim>I assume autotools assumes bash. So I'd guess it's not intentional on our part. <dhruvin>About the issue: ice-9/eval.scm:293:34: Throw to key `decoding-error' with args `("scm_from_stringn" "input locale conversion error" 84 #vu8(54 130 141 16 32))' <dhruvin>musl's libintl is too different from gnu's IIUC <dhruvin>this prevents guile from opening a port with encoding other that utf-8 <dhruvin>Similar problem was occured with boostrap guile and I saw a patch named guile-default-utf8.patch <efraim>Ooops on the path: /gnu/store/b6v0wp13h2mkq4533ir7l5ddflj9pxhb-openssl-3.0.4/share/openssl-1.1.1l/ <dhruvin>When I try to compile guix, the aforementioned error arises at "[ 14%] LOAD gnu/ci.scm" while trying to load 'gnu/system/install.scm' <mitchell>why are cross compiled packs so much larger than native ones? When i run `guix pack htop tree coreutils` the resulting tarball is 28M. When I run `guix pack --target=arm-linux-gnueabihf htop tree coreutils` it is 63M. <lilyp>probably some cross-compilation artifacts are kept in there, plus cross-compilation may not result in optimal codegen? <maximed>mitchell: Is this only for the pack itself, or for the cross-compiled software itself? <maximed>You could do "guix build htop tree coreutils --target=..." and then run the store items through "guix size" <lilyp>ahh, yes, the toolchain is also included in `guix pack', so you'd have to go with the size reported by guix build instead <maximed>I assume that including the toolchain is an accident, not the intended functionality? <mitchell>interestingly the arm htop is smaller by 100k <lilyp>maximed: I think `guix pack' means `guix pack everything' <lilyp>so, who can explain to me how (synopsis ...) ends up in the po files? <maximed>mitchell: du is not a good check, because it (presumably) does not include the references (≃ runtime dependencies, but not exactly) <mitchell>Its true, but guix size doesn't take the --target option <maximed>mitchell: You can do "guix size /gnu/store/...-htop-VERSION" <mitchell>ok guix size $(guix build) does the trick <maximed>lilyp: mitchell wrote "guix pack ... htop tree coreutils", so 'everything' doesn't seem to include the gcc toolchain here <mitchell>guix size includes two gcc's for the cross compiled one <maximed>po/guix/Makevars: --keyword=synopsis \ <maximed>po/packages/Makevars: --keyword=synopsis --keyword=description <lilyp>ahh, was looking at the wrong makevars <mitchell>i'm looking at just `guix size $(guix build htop)` <lilyp>as I said, it includes native-inputs too <maximed>Possibly a package accidentally records a reference to the native-inputs? <maximed>e.g. both a native and cross ncurses <maximed>You can use "file" on the shared libraries of both ncurses to see the architecture IIRC <mitchell>indeed one is for x86 and the other for arm <mitchell>actually the x86 one is the same in both packs <maximed>mitchell: To figure out in which package things go wrong, you can (IIRC) use "guix graph --type=references /gnu/store/$the-native-ncurses /gnu/store/$the_store_thing_from_guix_cross_build" <lilyp>I'll have a look at the GNOME extensions once I'm done with my current patch <mitchell>maximed: In this --references graph the arrows point to things the package is referencing? or things referencing the package. A->B means A references B or vice-versa <nckx>Not to hammer a dead horse, but now Microsoft 'GUIX' is #1 on DDG for 'guix git', and the real Guix is last, with the Microsoft GitHub mirror somewhere in between. <maximed>mitchell: I don't know the direction. Just give both a try, I guess: "guix graph --type=references --path /gnu/store/this /gnu/store/that" <mitchell>I put it through dot and ARM ncurses-> x86 ncurses and gcc-cross-arm-linux...-lib which both point to x86-gcc-lib <nckx>dhruvin: Patches to make the build scripts run on less common distributions are welcome! I don't find either example in the code, though, although there is an --output-delimiter example in a manual translation. <nckx>maximed: I have a script that tries both directions & prints the working one because I always forget it. <maximed>mitchell: Try: grep -rF /gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-6.2.20210619 /gnu/store/rlvkgvy9i0g9bz6k73nn2bxpm2941svy-ncurses-6.2.20210619 <maximed>Apparently it ends up in libncursesw.so & libncursesw.a and ncursesw6-config somehow <mitchell>It gives a warm feeling seeing you have the same derivations <maximed>FWIW it just downloaded substitutes from the build farm ... <nckx>mitchell: Late, but A->B means A refers to B <maximed>I mean, having the same derivation doesn't mean much except that we have the --system and a close-enough version of Guix. <maximed>For reproducibility, you need to do the hash over the output <maximed>(whereas /gnu/store/... is the hash over the inputs) <mitchell>I thought the store path was also derived from the contents of the output <maximed>mitchell: That's the intensional store model described in the nix paper. <maximed>We use the extensional model from the paper (if I got the terminology correctly) <maximed>(There's also the fixed-output derivation exception, for downloading source code) <nckx>Just don't expect future contributors to those files to test on every obscure distro under the sun. You might have to keep maintaining the Alpine compatibility. Though, these files don't change that much. <dhruvin>I won't expect. Thanks for the heads up. <nckx>Making bash/coreutils a dependency (if Alpine supports those) is equally fine. <dhruvin>nckx: For now, SHELL=/bin/bash with coreutils works. Any ideas/pointers on that `decoding-error` error? <civodul>weird thing: sometimes ERC stops notifying me in the mode bar about activity on #guix <civodul>i wonder if i fell asleep on the keyboard and hit some key combination i shouldn't have <nckx>No, dhruvin, I'm afraid I haven't a clue. I'm not a Guile contributor (hey, look, here's one!) but I'm not sure building it against musl [libintl] is even worth pursuing? <dhruvin>I didn't mean to bug you if you felt that way. Just asked you if you knew, since you seem to know about guix well. I apologize if that ping was unnecessary. <nckx>I this is about the ', dhruvin,' making me sound annoyed: I wasn't. I type differently (and much worse :-p) on a touchscreen. <nckx>I literally don't know, nothing more! Civodul might...? <dhruvin>I misjudged (or misinterpreted). We're alright. <nckx>(One advantage of these things. Emojoboards.) <dhruvin>Regarding binding it to musl, I don't know enought about it. I'll see if its uphill struggle from where I am at packaing guix for alpine. <nckx>mitchell: Right, I meant worth pursuing as part of bringing Guix (which will end up building *everything* it installs against glibc in the store) to Alpine. It could be a very long detour. <nckx>Basically what dhruvin said in the meantime. <nckx>The 'native' Guix package is always just a bootstrap Guix that normal users will use exactly once, to pull a Guix-built (and glibc) guix command. <constfun>Hello all. I'm having trouble adding an extra config file under /etc/libvirt, like so: <constfun>"(simple-service 'qemu-config etc-service-type <constfun> ,(plain-file "qemu.conf" "nographics_allow_host_audio = 1"))))" <constfun>I get a "symlink: File exists: "/etc/libvirt" which is self-explanatory enough, but I'm not sure what to do about it. Is that not the right location for qemu.conf? <maximed>nckx, dhruvin: and maybe to automatically set up the guix daemon <maximed>constfun: Are you also using libvirt-service-type? <maximed>constfun: Then you can use the configuration fields of libvirt-service-type <maximed>Apparently mixing libvirt-service-type and manually putting files in /etc/libvirt/... is not supported. <maximed>(maybe libvirt-service-type already makes a qemu.conf by itself?) <constfun>maximed: hmmm, I dont see a way to supply any options for qemu or any extra config files to libvirt-service-type configuration <maximed>constfun: Such an option could be added I'd assume. <james[m]>Hello I have just decided distrohop to GuixSD. (Its currently installing). <james[m]>I've used it before, a while ago. But now revisiting it. <james[m]>I intend to use Xen on it. So I will be looking into using virt manager with Xen. Inside guix. <maximed>james[m]: FWIW it has been named Guix System for some years. <james[m]>maximed: Ah. Yes it is. Sorry my mistake. <james[m]>I could have sworn it used to be called that the last time I used it. <constfun>maximed: /etc/libvirt is a regular directory though, so I'm not sure why etc-service-type can't add more files there <maximed>constfun: because (IIUC) /etc/libvirt/qemu.conf already exists? <maximed>Looking at (gnu services virtualization), Guix doesn't seem to touch /etc/libvirt/... at all <maximed>My guess is that etc-service-type created a symlink farm of all the configuration files it knows about, and then tries to point /etc/libvirt (as a symlink) to somewhere in the farm <james[m]><maximed> "yes, has been renamed" <- Does it usually take a while to boot on the first try? <james[m]>My computer is a librem 13v2 so it should be good enough. <constfun>plot thickens, it could be virt-manager perhaps <nckx>james[m]: It's not fast, but it shouldn't take minutes. <constfun>maximed: that sounds like a good theory, ill dig in, just wanted to make sure im not doing something stupid <nckx>james[m]: Maybe it's waiting for entropy for the SSH host keys? (Guess.) <nckx>I'd expect that not to be a problem on bare metal though. <james[m]>I've installed it fully. Now I've put in my encryption password. <maximed>Remember: GRUB doesn't support pre-decryption non-qwerty keyboard layouts yet. <maximed>So you might need to, during decryption in GRUB, type it as if your keyboard were qwerty. <nckx>It'll barf a friendly error message if it fails, though. <nckx>It won't/shouldn't just freeze. <nckx>Ah, but what about second brea^Wdecryption? <nckx>What kind of GPU does this thing have? <nckx>That's… not what I meant. <nckx>It's not struggling to raytrace the Guix logo. ‘Modern’ AMD GPUs are frequently troublesome, for example. <oriansj>Guix can run just fine on a pentium pro if you are able to be patient <nckx>You can try booting with ‘nomodeset’ on the end of the kernel command line (the very long line starting with ‘linux’ when you hit ‘e’ on the Guix entry in the GRUB menu). <james[m]>I think I will just try the install again. <james[m]>IDK. But its made by purism and its lts libre friendly. <james[m]>I never had an issue at least getting it to boot. I will try again... <nckx>Your time is yours to waste but I'd advise you try my suggestion first. <nckx>james[m]: Or! Just blindly type your passphrase at that empty screen. <nckx>Make sure you haven't typed anything (by accident) first, else reboot. <nckx>What's happening is that the drivers to display whatever went ‘wrong’ (which I just realised could just be the second passphrase prompt) aren't loaded yet, so the kernel can't tell you anything. <james[m]>I think its stuck in the grub boot or something. <nckx>I don't, but there's no way to tell. <james[m]>Because I selected the Linux libre kernel. <nckx>I wasn't kidding about second decryption. You need to enter your FDE passphrase twice on Guix System for extra security, but mainly because bug. <james[m]>It got as far as decrypting it and trying to boot the image. <nckx>And probably did boot it successfully. <maximed>james[m]: Yes, because grub currently has no way for passing the keyphrase to linux to luks <maximed>(possible unimplemented work-around I've heard of: ‘key files’) <james[m]>Yes. They should have the first part use passphrase. And the second. Use only the keyfile. That sounds like a good idea. <nckx>james[m]: I already explained why you don't see it. The driver isn't loaded (yet, we hope). <maximed>james[m]: nckx recommended nomodeset <nckx>That does not mean there's no prompt, only that there's no text mode to show it. <james[m]>I don't know how to get into recovery mode on GUIX. <james[m]>How do I edit the kernel parameter line in grub? <maximed>james[m]: see nckx message about the letter 'e' <james[m]>Okay I see the GNU with Linux libre config. But not the whole grub config. <nckx>Put your cursor before --root= and type ‘nomodeset ’. <nckx>So, spaces on both sides. <james[m]>Its the config for the image. Not the whole of grub. <james[m]>Its the generated config. Not the default one. <james[m]>I know guix it will be configured differently for that as its declarative. <nckx>I don't understand your two ‘Its …’ messages but let's just push forward with this for now. <james[m]>Just checking because I don't want to mess it up. <nckx>It's not permanent, only in RAM. <nckx>(So this is not a permanent ‘fix’ either, but one thing at a time.) <james[m]>Yea I know. I will need to edit the system config to make that perminant. Something with system-configure I think it was if I recall. <nckx>Looks good. Now hit Control + x to boot. <james[m]>I guess the kernel is not really booting or no way I can reach a tty yet. As still in grub type thing. <nckx>I really don't think so, but since we don't have output I can't prove it either :) <nckx>james[m]: You'd normally see the kernel log scrolling by, but… no graphix. And since file systems aren't mounted there are no log files at this early point. <james[m]>Will be nice when Hurd becomes suitable enough for my PC. <james[m]>At least if something crashes its quite tolerant to that. But that's a separate thing I won't go into. <nckx>james[m]: Reinstalling with the exact same set-up won't magically fix this. Reinstalling without FDE might. Can you afford to do so for now? We can also wait a bit for others to chime in; I'm currently out of ideas. <nckx>I don't own any ‘modern’ hardware and I don't really mind. But I'm sorry I can't be of more help. <nckx>james[m]: I understand. Sorry for the lack of ideas. <james[m]>Here is the config. Anyway. Just while I wait. <james[m]>What IDEs do you guys use for Software development? <james[m]>This is very much GNU, so I can probably guess. <nckx>Guilty, although I use it as a text editor more than an ‘IDE’. <lilyp>That being said, we did package gnome-builder for those who like pointy-clicky things *nckx AFK to fiddle with their own graphix. <james[m]>I am using pycharm and intelij. At the moment. The community edition. <james[m]>But I use Emacs for assembly language programming because it excells at everything if you configure it right. And if I only need it for assembly. Its less work and it works really well. <james[m]>Of course I use the community edition of them. No non free stuff on my PC of course. <lilyp>to be fair, it'd probably be simpler to configure emacs right than to get jetbrains anything to build from source :) <james[m]>lilyp: Does jetbrains have binary blobs BTW? <james[m]>Yea but even then I would would to contribute my patch as it would be useful to others as well. Someone was actually working in making a definition for it it was in some GUIX mailing list. <james[m]>I think its a good piece of software. The community libre edition that is. <lilyp>I don't think you'd get that far, what with the Kotlin bootstrap and everything <efraim>nckx: don't wait for me to review the other architectures of the patch. I always build out to mesa on all My platforms before a core-updates merge. <nckx>efraim: OK, I was just going to build-test them. <efraim>aarch64 has gotten faster over the years but riscv64 can be slow and powerpc is awful <efraim>I still need to get my mips64el box reconnected <james[m]>So do you guys think switching to emacs would be better? <james[m]>Could I make it feel similar to Intelij Idea? <james[m]>Not all of it. Just the main things I like. <nckx>podiki[m]: I tried to write a diplomatic comment for auto, because I don't blame upstream for being all ‘patches welcome’ on other arches. <lilyp>I think trying out GNOME Builder and reporting bugs might a good intermediate step if you need pointy-clicky <nckx>efraim: Do ‘we’ have any project-{owned,accessible} riscv64 systems? <james[m]>I've used gnome builder before. For C programming I mainly used it. <nckx>Jives with what I thought. <lilyp>but long term, emacs/vim will survive another three generations of new hype editors <james[m]>efraim: That's good. Yea I use vim as well sometimes, only know basic but I use it all the time on servers. But for IDE stuff its not what I am looking for. <maximed>What do people prefer: ‘build driver’ or ‘compiler’? <james[m]>lilyp: Yea. They are the best text editors in terms of power in my opinion. <james[m]>Different philosophies but its like ying and yang. Someone can at least be comfortable with one of them. <nckx>maximed: I know what one of those words mean, for example. <james[m]>Anyway. Time to see if my system will work.... <maximed>nckx: In the hare patch ‘Hare programming language build drier and standard library’ was used. <nckx>efraim: Interesting. I have no idea what to expect from something like that, subjectively, performance-wise. <maximed>I assume some kind of synonym for compiler ... <lilyp>fwiw I don't think the hare package includes the compiler <nckx>Seemingly not synonymous. <podiki[m]>nckx: glad mesa worked, and for wayland seems it is just that one test for you? <podiki[m]>nckx: and yes, a code comment for auto (besides commit message) makes good sense! <maximed>(OTOH, technically 'gcc' isn't the compiler but 'cc1' is ...) *maximed assumes yes, because we have logs.guix.gnu.org <nckx>maximed: I'm just quoting someone else. <lilyp>ahh, but it's the GNU compiler collection :P <james[m]>I know Emacs can do anything. But would these features be easy enough to setup? <lilyp>james, please try to send messages line by line rather than huge blobs <lilyp>it's somewhat annoying having to switch to a browser every time ^^" <nckx>Not a shooting offense, but a bit of friction each time it happens adds up. <nckx>(There are no shooting offences in #guix, I think, but people will start humorously listing ones if I say so out loud…) <james[m]>I forget people use more minimal clients or its just how IRC works with Matrix. <lilyp>anyway, for autocomplete, I'd suggest corfu, assuming that minimal is enough <rekado>(does this look good in any client other than matrix?) <nckx>james[m]: No apology needed, but now you're aware. <lilyp>other than that, you could try to set up lsp-mode, which mimics the way vscode does things <james[m]>rekado: Matrix is not a client. Its a protocol. I am not using IRC directly to be here. <lilyp>syntax-highlighting should be there ootb for most languages, includig python <rekado>I’m aware that Matrix is a protocol <lilyp>for graphical debugging, there's gud, which is really gud :) <james[m]>lilyp: Yea I've looked at that. But my problem with vscode was its not really a IDE in my view. <james[m]>lilyp: Yes it is. I like it very much. If you mean the one that comes with it. And uses gdb I think as backend. <lilyp>what counts as an IDE vs what doesn't subjective <lilyp>IIRC gud can also be made to work with the python debugger <james[m]>Yea I need to install something though. Right? <james[m]>lilyp: Everyone's criteria is different. But the idea is it needs to be suitable for full stack development. And stuff like a debugger is often a requirement for most people. <james[m]>Okay. Trying my system... Hope it works. <lilyp>I don't know if vscode has a debugger, but it does have "smart autocompletion" which is the one feature people use IDEs for. <james[m]>For something to be an IDE. There are some requirements which are common. <james[m]>Which just means its useful for programming. <james[m]>An IDE. Is integrated. Meaning its designed to work for that language, etc. The whole development process is taken into account. <james[m]>Okay my system works now. But I do need FDE. <nckx>They installed with, earlier, but boot stalled without graphics from the kernel (which was probably fine, but had no mouth to scream about that). <nckx>Now I wonder if adding the graphics driver module to the initrd would suffice. <nckx>Knowing that it works just fine. <unmatched-paren>maximed: "build driver" means "a program that organises the build and runs the compiler" <sneek>unmatched-paren, you have 2 messages! <sneek>unmatched-paren, jgart says: > (nonfree source) Matlab instead of (free source) Octave <sneek>unmatched-paren, jgart says: I don't really use any of thosse programs. That was mostly for dcunit3d_ who needs them. I'd probably use Octave but I imagine dcunit3d_ needs some feature of Matlab that Octave doesn't provide maybe or it's a requirement for some class or whatnot <unmatched-paren>with harec, you need to run it for every file, then `qbe` and `as` it <lilyp>oh, so it's just another make? ***ChanServ sets mode: +o litharge
***litharge sets mode: -bo $a:betelgeus*$#guix-fix-your-connection litharge
<lilyp>is this like the infamous all: cargo build makefiles? <unmatched-paren>Hare projects are arranged in a very regular way, so there isn't much point in writing rules for .ha -> .o in the makefile <unmatched-paren>The crucial difference that makes `hare build` not suck is that it doesn't try to download dependencies <unmatched-paren>Hare expects you to use a real package manager for your dependencies, thank goodness <lilyp>well, sure, but I still feel as though the accomplishments of hare build might be overstated? <lilyp>and that's exactly the point <lilyp>if you don't need to do much, you could for instance ship with the magic to make things work for autotools, meson, etc. <lilyp>focus on providing the necessary glue rather than adding yet another build system <maximed>From what I've heard so far, 'hare' looks like a wrapper around a compiler to me (to pass appropriate -L flags, etc.). <maximed>I count a basic wrapper around a $foo as a $foo (with the internal $foo considered an implementation detail) <unmatched-paren>hare build's job is to allow you to build things using a makefile without repeating the same logic again and again <maximed>(unless it supports tons of underlying compilers and you can choose or something) <maximed>unmatched-paren: Looks like 'make', except specialised to Hare? <maximed>If so (about 'make'), I don't see the ‘build driver’, unless ‘make’ and ‘ninja’ etc count as ‘build drivers’. <nckx>…oh, I missed your ‘not suck’ comment. <maximed>(Maybe they (= make, ninja) do, I'm not familiar with the terminology ‘build driver’) <unmatched-paren>I guess you could call the combination of `make(1)` and a makefile the build driver for your project <nckx>Intuitively, make etc. is a ‘build driver’. <unmatched-paren>of course, without the makefile, the user could still build your project <lilyp>autotools resolves depedencies, plain make doesn't <nckx>What else would you call it. <lilyp>fwiw gcc can be invoked to tell you that info <maximed>Does someone have a definition of ‘build driver’? I'm now wondering if 'driver' means the same there as when people speak about ‘using $OS as daily driver’ ... <unmatched-paren>nckx: Do you really think an Alpine Linux package maintainer would be particularly inclined to make a system that's incredibly annoying to package? :) <lilyp>that's what we're all trying to understand here <unmatched-paren>Seems like many of the annoying systems come from Mac and Windows users <nckx>‘Daily driver’ is an annoying meme than can die now. ‘Build driver’ is clearly trying to communicate that this is the tool top-level that coordinates the build by invoking lower-level ones. <unmatched-paren>Argh, I'm trying to `wl-copy` the hare(1) manpage, which will probably explain why it exists <nckx>Actually, it mostly works for me now, so I can't complain. <unmatched-paren>but outside the --pure shell I don't seem to be able to access the manpage? <nckx>…time for a non-pure shell? <unmatched-paren>Surely non-pure shells should reload the manpath or whatever it's called? <nckx>They should append to it IIUC. <nckx>Did you include man-db? Probably, if it works with --pure. <nckx>Señor Lag at your service. <unmatched-paren>Basically, the point is to figure out which files to compile, and then execute harec, qbe, as, ld on them <unmatched-paren>I guess it makes sense; it's a temporary solution while they get the self-hosting compiler working. <unmatched-paren>(Well, not exactly temporary; they plan to keep maintaining harec as a bootstrap path.) <nckx>unmatched-paren: <Do you really think an Alpine Linux package maintainer would> My complete Alpine experience is yesterday days old; I wouldn't know. I tried to apk add cowsay and it said no such package, so I wasn't impressed by their priorities so far. <lilyp>do they not even have lolcat? <nckx>It's in ‘Edge’, apparently. <lilyp>the fortune to cowsay pipeline is one of the most striking features of the modern linux distribution <nckx>unmatched-paren, lilyp: lolcat no (but also in ‘edge’), fortune yes. <nckx>Apparently the next release is going to be huge. *nckx adds lolcat to their log-in fortune invocation. <nckx>"A spokesman for the Lyon Group, producers of _Barney and Friends_, denied that Barney is an instrument of Satan." — looks even better in rainbow. <nckx>You'll have to use your imagilation. <lilyp>unmatched-paren: why not fortue | cowsay | lolcat? <nckx>lolcat turns off colours when outputting to a pipe. <nckx>So | lolcat | won't do nuffin. <nckx>Of course it confuses cowsay's width calculations. <lilyp>we need to patch cowsay to make this happen :) <nckx>That implies reimplementing a (likely buggy) parser for escape ANSI codes in cowsay. Seems fitting. Go for it. <mitchell>I think i found my new favorite way of displaying FOUO banners on my servers <unmatched-paren>lilyp: It is imperative that the text of the bug report is piped through cowsay before it is emailed to the list. <nckx>Oh weird, that run cut out stderr for absolutely no reason. <nckx>It said Error reading input file "guix/README": Invalid or incomplete multibyte or wide character <nckx>This is really great software 👍 <lilyp>guix show lolcat | guix shell lolcat -- lolcat <nckx>Clearly, it should automatically invoke TTS when encountering IPA. <nckx>I don't know how to break this to you <nckx>but top | lolcat works and you should all run it forever. <lilyp>it's june, all output shall be piped through lolcat <nckx>Pity htop, which I actually use, doesn't work. <unmatched-paren>although you have to use the emacs keybindings because the arrow keys don't work... <nckx>emacs -nw | lolcat is interesting, in that I can't say off-hand how it manages to completely control-code its way out of lol. <nckx>Oh, you had the same idea but more luck. *nckx switching to nano, oh well. <nckx>Nobody needs to see what they wrote in the past. <lilyp>interestingly not even emacs -batch | lolcat works <nckx>OK, ‘works’, but -ENOFUN. <nckx>sl | lolcat is nice but I'm clearly out of ideas. <lilyp>no, this needs to be documented for future generations <unmatched-paren>Let's create a transcript of this discussion and upload it to archive.org. <lilyp>"transcript", as though the logs weren't already public <unmatched-paren>Okay, let's upload today's log to archive.org. Unless it's already automatically archived? <nckx>But it belongs in a museum. <nckx>(should we move this to #guix-offtopic? :P) Found the cop. *nckx …I think it's OK as long as there's nothing else going on, but correct me if I'm out of touch. <the_tubular>nckx completly out of the blue, but could you show me how you made your website "homepage" one day ? <nckx>the_tubular: Thank you! However, what you view (source) is exactly what I wrote to index.html (in emacs). There's nothing more there. I didn't make the background; it's borrowed from a 64K demo (by… I want to say Mercury?) without permission. <nckx>I guess I should use CSS animations nowadays. I'm very confused that you like this non-thing. But flattered. <nckx>podiki[m]: I was about to report severe screen tearing with the new Mesa… but then noticed that the tear is baked into the video. Wat. <james[m]>Is it just me or is gnu icecat dangerously out of date. I have version 78.10esr. <james[m]>And I am on a fresh system ran GUIX pull and guix package -u <james[m]>Yea I know now. I just did an upgrade and its upgrading to 91.10. <james[m]>How do I make sure I get the latest version of software. <james[m]>Because I did a guix pull and guix package -u. Before I did any of this. <james[m]>How do I see the available versions for a package? <unmatched-paren>guix pull fetches the latest guix, guix package -u / guix upgrade updates the software in your profile, sudo guix system reconfigure /etc/config.scm will create a new system from the configuration file at /etc/config.scm, which will update system software <unmatched-paren>james[m]: sure it does. `guix show icecat` shows "name: icecat" then "version: 9.10.0-guix0-preview1" <james[m]>I am guessing this was from when the iso was made. <unmatched-paren>usually when you `guix install foo`, it'll be installed in the profile of the user that runs it <unmatched-paren>The Hurd is probably never going to be improved to the point where it's usable. That's my pessimistic (realistic?) viewpoint. <unmatched-paren>What I'm saying is: the Hurd was probably a lost cause from the moment GNU decided to use Linux. And even before then, it was getting nowhere (iirc) and being derided as vapourware by some. <james[m]>That's really unfortunate because its a good design in my opinion. I guess they just need more people working on it. <unmatched-paren>The efforts to get it working are valiant, but IMHO probably ultimately pointless. <james[m]>I think its the fact that people left that project to work on the Linux kernel. I mean if you look at the git logs there are not many people working on it. <unmatched-paren>james[m]: Well, the reason GNU eventually fell back to Linux was that Hurd was taking a loooong time. And, I think, the reason that Linux was created in the first place; apparently Linus wanted a UNIX that ran on x86 computers, but Hurd was nowhere near done. <james[m]>Its difficult. I think eventually it will be useful for daily use. <james[m]>When, I do not know. I will be following it at least. <james[m]>If you look at the design its actually very well designed. But I get how its difficult to do. <singpolyma>There are a lot of nice kernels around. Linux just has this bonkers amount of hardware support that no one can match <sneek>singpolyma, you have 1 message! <sneek>singpolyma, jgart says: I think I may have misunderstood how `hidden-package` works... <james[m]>The idea was to create something a bit like the Incompatible Time Sharing System. Type philosophy. Where users actually can't be restricted. Its all about freedom 0. As they said. <james[m]>unmatched-paren: I would still recommend that video I sent you. <james[m]>Its a bit of a chicken and egg situation. If you want it to get more development you need popularity and appeal. To get that. You need lots of development. And so on. <singpolyma>unmatched-paren: sure, but messages out of context make no sense. I only understand that one because I already saw it in my history on the other one <unmatched-paren>james[m]: I did find that interesting that they have plans. The question is whether those plans will ever be realized. <james[m]>Yes its being worked on. But not by many people. <KarlJoad>What is the proper way to specify a networked filesystem to be mounted? I understand it would go in the file-systems field of the OS definition, but am unsure if there is something special that must be done. <lilyp>you would need to set the nfs type and probably also make it not mount at boot <KarlJoad>Are other filesystem types supported? Samba/CIFS, namely. I have control over the server, so I can set up NFS, but am lazy. <lilyp>we do have samba packages, but I don't actually know the mount options to do things by hand <lilyp>(I usually rely on gvfs, which works as expected in Guix) <james[m]>Does anyone here have experience with virtualization in guix? <james[m]>I want to use Xen. And just wanted to know if anyone had issues setting it up or if its just as simple as on Debian. <maximed>james[m]: There's "guix system vm ..." that automatically create script for starting a VM from a given configuration (under QEMU, not Xen, I don't know Xen) <maximed>james[m]: You can also do "guix search xen" which lists some relevant packages. <james[m]>Okay. That's nice. But I want to essentially use my system similar to Qubes in that I want to compartmentalize stuff. <james[m]>I know that's hard in some ways. But basically I want the best way to interface with my VMs. <james[m]>I think this guix system VM thing is interesting. <maximed>I don't know much virtualisation beyond "do guix system vm-image and run it under QEMU / GUI wrapper for QEMU". <james[m]>I need a bare metal hypervisor with really strong security able to be achieved. <james[m]>Xen is the only hypervisor with the ability to achieve that. That I know of. <james[m]><maximed> "there's also a libvert-service-..." <- Yea. I might need some help with that. <james[m]>I know guix is tolerant to mistakes but I really don't want to mess things up in my system config. <justkdng>libvirt requires a running daemon for usage, libvirt-service-type basically starts that daemon boot <justkdng>you can use kvm and xen with libvirt it seems <james[m]>justkdng: Yes of course, I should have said that. Yes. Most hypervisors, libvirt supports. <james[m]>justkdng: I will be honest. My experience is once its installed and the daemon is started. It works. <james[m]>Its not much harder than KVM in my experience. As far as getting it working. <james[m]>I don't know about on Guix system though. I am used to Debian and Arch based distros. <justkdng>I guess you also need polkit configured to be able to auth to the daemon <james[m]>I hope Xen is similar to KVM as far as initial setup goes. <james[m]>Libvirt supports lots of hypervisors so if I only need to do libvirt stuff and just specify xen as a hypervisor it should work. Right? <james[m]>Could someone give me their config for virtualization? <james[m]>Even if its just KVM. I think it will help me learn a bit more. <james[m]>I am also looking at the manual. But this would complement it. <james[m]>You can redact the other system config stuff. I only am interested in the virtualization stuff that I need. <vagrantc>i seem to recall a bug in libvirt relating to it embedding the full path to qemu at creation time of the virtual machine (which would get guix gc'ed away out from under the virtual machine) <vagrantc>not sure if that was ever fixed to, say, use guix system's path in /run/... <vagrantc>i don't think libvirt can use a relative path ... otherwise that would be a better solution for guix <nckx>So libvirt VMs aren't even reliably portable across machines? <james[m]>Well at the moment I am still on the updating process using guix refresh. <james[m]>It keeps saying service not found or something. Then the guix refresh stops. I run it again. And it gets furthur. But happens again at some point. <james[m]>Well, at least its updating the definitions. <james[m]>I don't feel great about github being the main place free software resides. <james[m]>Too centralised. What would happen if suddenly all github servers were destroyed somehow or corrupted? <james[m]>Its unlikely. But in that case. I think it would cause a lot of problems. <jpoiret>that same issue would happen with any other host, and you could argue that GH is the one that's least likely to go offline <james[m]>jpoiret: Don't know what that is. But I am glad there is a fallback. <james[m]>jpoiret: I was not suggesting we replace github with another host. <james[m]>jpoiret: I mean. The git protocol is decentralised. So why not make the git interface that too. <james[m]>Maybe its something to be made in GNUnet. It would be a good place to experiment with something like that as its the right environment. <mitchell>does anyone know why glibc doesn't install man pages? man 2 printf does not return anything <maximed>james[m]: I've done some work on that (actually, for fixed-output derivations instead, but for Guix that would be sufficient for downloading source code), not completed though ... <maximed>(the Scheme interface to GNUnet services need more work) <maximed>mitchell: I don't think glibc has man pages at all <maximed>You might be searching for 'man-pages' (IIRC) instead, which is independent of glibc <mitchell>oh. Where does ubuntu get its man pages for the libc functions? <justkdng>This page is part of release 5.13 of the Linux man-pages project. <jpoiret>james[m]: there are experiments to use IPFS and other decentralized file systems in Guix <james[m]><maximed> "james: I've done some work on..." <- Nice. Yea. At the moment I only know enough to do minor bug fixes and stuff. Its quite intimidating as I am new to that. I also attended the virtual hacker week that happened when everything when online. <james[m]>Also I keep getting errors when I do a guix refresh. Is that normal? <justkdng>I believe the apropiate way to update guix is to guix pull then hash guix and then sudo guix system reconfigure ${system conf} <justkdng>at least that's how I've been updating my system packages <maximed>james[m]: Error reporting in Guix often isn't great, but that's a bug, not some intended feature. <james[m]>Okay. Will do that. Also latest version for Python is 3.9.9. <james[m]>I need pattern matching and switch statements(match). <maximed>Also, for sharing text, I recommend something like paste.debian.net *yewscion is back (gone for 15:45.31) <james[m]>maximed: I figured. But sometimes errors just happen due to user error and are minor. Is what I meant. <james[m]>Because it would continue to try and fine new versions. <maximed>james[m]: That, and just say 'gnu/package/...: xlockmore could not be investigated because the remote server is inaccessible (name resolution failed)’ or something like that. <maximed>Looks like there's quite some things that can be updated ... <james[m]>How do I get Python 3.10.0 then. Because it said that 3.9.9 was the max? <maximed>Maybe "guix refresh" looks in the wrong place? <maximed>The refreshing logic for where to look & how to detect versions can be fragile and heuristic at times. <maximed>Which can sometimes be corrected by setting some appropriate package properties. <maximed>Or maybe something else is going on. <maximed>james[m]: IRC does not have multi-line messages. <justkdng>someone has to send a patch to update it to 3.10.x <justkdng>I was using guix package -u to update user packages <james[m]>I am teaching someone programming and it would be very good if I could use 3.10 because of the pattern matching. <james[m]>Its the last thing that python was really missing that was essential. <james[m]>Using if statements or looping through an array is not good practice to teach. For switch statements. <james[m]>There are not really any good practice workarounds. *mbakke has plans to upgrade Python on the 'core-updates' branch, but it won't land in 'master' until a couple of months <maximed>james[m]: FWIW, you can make a _local_ ‘variant’ of the 3.9.9 definition (for 3.10) <maximed>and put it in a manifest or something <maximed>then do "guix shell -m manifest.scm -- python3" <james[m]>mbakke: That's too late. They will be back at school by then. And I will be at uni. And will be busy. <maximed>(so waiting for it to be applied in Guix isn't needed) <james[m]>So I edit the file where the definition is stored on my system. Then run that on it. <maximed>(package (inherit (specification->package "python")) (source ...)) may be useful here ... <maximed>james[m]: You can do it that way, but that's more complicated, you have to make a git clone of guix and run ./configure & make etc <maximed>So I think for now doing things locally in a manifest would be simpler. <james[m]>I am new to this. So I think I have a lot to do already. Getting xen working. And intelij idea. *maximed searches for example ... <james[m]>I am a newbie. And I don't write guile scheme. I have used racket before which is based on scheme. But did not become great at it. <james[m]>I think if I made this manifest file and it worms, I will post it somewhere because likely someone else has this issue. <james[m]>Perhaps on my website as well as guix mailing list or something. <justkdng>for intellij I think getting jetbrains-toolbox to work is the simplest solution <justkdng>then again, jetbrains-toolbox is just a glorified web application that just extracts itself to /tmp <james[m]>justkdng: That promotes nonfree software. I can't add that to guix as a patch. <james[m]>I think I would be denied that request because of the FSDG. <james[m]>I want to help myself but also others. So it has to work for them. <justkdng>you could help fellows that like guix but need non free software, but that's offtopic here <vagrantc>nckx: well, it's trivial to change the full path in the virtual machine .xml definition ... but under a system using FHS or whatever, the path to qemu doesn't usually change very often <james[m]>justkdng: I am not going to promote nonfree software to people. I want the free software to work better and more of it to be available. <james[m]>Nonfree software only unfortunately can be a dependency if the hardware is an issue. Through nonfree drivers. <james[m]>I have an ongoing project to make Microsoft Access databases work in libreoffice Base. Out of the box. <james[m]>Using Jackcess and UcanAccess as the back end. The goal is people won't need to use MS Access anymore to connect to those databases. Whether remote or file. <james[m]>But this will also include Forms,Queries and Reports. Not just tables I should point out. <james[m]><justkdng> "you could help fellows that like..." <- We can replace the nonfree software in most cases. <james[m]>Sometimes its really difficult to do. But that does not mean we should give in and just distribute it. <james[m]>My solution is to replace it. Or make a compatible program with the file format so it can be used in similar programs. <justkdng>nonfree firmware can't be replaced sadly <justkdng>I had to use nonfree blobs for my gpu and wifi to work <james[m]>In the case of intelij. The core is free software. <james[m]>But they make variants of it which are proprietary. <james[m]>So the intelij idea IDE. Is actually libre. <james[m]>Pycharm is also just Intelij Idea with Python stuff. <james[m]><justkdng> "nonfree firmware can't be..." <- Embedded software can't be replaced in practice. The free software foundation makes a distinction. <james[m]>If the hardware has embedded software which they can't change. That's separate. <james[m]>As long as the software on the computer is free software. Then its considered a free system. According to them. <james[m]>I am guessing its nvidia for GPU or something. WiFi is also a problem. Generally if you don't have a laptop bought with this in mind. <justkdng>I believe only old intel gpus don't need blobs <james[m]>Is that integrated or dedicated graphics? <singpolyma>AMD GPUs work great without blobs, but not for accelerated 3D <justkdng>I'm running guix in a laptop with a 4700U <singpolyma>james[m]: Nvidia you also need nonfree drivers usually even just for 2d accel <james[m]>I understand support for binary blobs of firmware and drivers might be worth someone doing. <james[m]>To make it so they can use a free operating system at all. But the user needs that to be known to them. <james[m]>Beyond that. I don't think people should spend time trying to get proprietary ELF binaries. Etc. To work on GNU/Linux. <james[m]>We have replacements and ways to read the file formats quite often. If not. Someone can work on that. <maximed>justkdng: antioxidant is a Guix build system, intended to replace cargo-build-system, avoiding some current problems with cargo-build-system <maximed>A basic form of incremental compilation (but not what rust means with incremental compilation), less messy dependencies in general ... <maximed>TBC, antioxidant is independent of rust bootstrapping. <james[m]>Nice to meet you guys. I will probably be back tomorrow. And hopefully have all my stuff working. <james[m]>If I make any patches I will let you know. But might be a few weeks because I have not done guix for a while. <maximed>FWIW, there is an effort in GCC to support Rust. <maximed>(being GCC, I assume GCC's Rust support is implemented in C++, not Rust, so presumably that would resolve boostrapping trouble) <maximed>There was some update some time ago on mrustc, for shortening the chain? <maximed>Also, mrustc now works on aarch64-linux, so (assuming it is already merged), you can built rust stuff for aarch64-linux!