<civodul>janneke: did you comment on the 'basename' fix i proposed for Guile several days ago? <rain1>gnu/packages/terminals.scm:365:2: beep@1.3: probably vulnerable to CVE-2018-1000532 <rain1>probably best to just delete the beep package, what do you think? <rain1>on guix, the beep binary is owned by root but not suid so the cve does not apply <OriansJ>rain1: well it has it's uses on servers but outside of that special case there isn't going to be much demand for it but there is no danger in having a package definition available and just simply not providing a substitute <rk4>do people run into much problems just using the latest mainline kernel from kernel.org? <rk4>[why yes, work has issued me a non-ideal laptop...] <OriansJ>rk4: generally no, the kernel can generally be built rather easily <OriansJ>it just isn't recommended due to reasons related to freedom <bandali>quick question: is there an equivalent to nix's `nix-env -f $NIXPKGS xxxx`, where $NIXPKGS is a local clone of the nixpkgs repository <wigust>bandali: ./pre-inst-env guix ... <thomassgn>anyone encountered build errors with python packages from something called '/homeless-shelter'? I get error: [Errno 13] Permission denied: '/homeless-shelter' from trying to package proselint... <thomassgn>I'm just going to get breakfast, will check in soon :) <vagrantc>my hunch would be that it's a home directory specified when there is no real home directory ... perhaps a joke in slightly bad taste <janneke>vagrantc, thomassgn: /homeless-shelter is set in nix/libstore/build.cc; our version of the nix build daemon <janneke>HOME is set to that, so that build recipes that read /home (should never happen) get caught <efraim>we have a number of packages with (setenv "HOME" (getenv "TMPDIR")) <brendyyn>I believe it comes from the nix build daemon's default <brendyyn>Often it doesn't actually cause an error but a warning <thomassgn>Ah, ok. janneke do you know if there's anything I can grep for to get examples of workarounds/fixes? <thomassgn>hah, should have checked for 'homeless-shelter' first. there are several occurrences in the guix sources... :P My bad. <thomassgn>So for completeness sake: the other packages adds (lambda _ (setenv "HOME" "/tmp") #t)) after unpack phase or similar. <espectalll[m]>Hi, I'm trying to install GuixSD but have a weird issue with EFI <espectalll[m]>trying to boot 0.16 from an old iMac but the whole computer just freezes if the USB is in on boot <efraim>There are a couple of us with other macs <vagrantc>should "guix build guix" work? is that the guix that is built with a system configuration? <efraim>vagrantc: guix build guix should work, what errors are you seeing? <efraim>espectalll[m]: so it shouldn't be a 32-bit EFI issue <efraim>what if you press alt/option at bootup to give it a bit more time to recognize there's a USB stick <efraim>unfortunately I don't remember what I did with mine while experimenting <efraim>I know in the end I ended up installing debian and then installing guixsd on top of it <efraim>I still have issues with the broadcom wifi and the free firmware, but that's a linux-libre issue <vagrantc>efraim: test failures in several critical things <vagrantc>efraim: i didn't know there was a way to file bugs against specific things... <efraim>vagrantc: I meant against upstream <efraim>vagrantc: you're showing a backtrace that includes mit-scheme near the bottom? <efraim>0.16.0-4 is known to fail on non-intel architectures, missing catch-all case in mit-scheme in scheme.scm <vagrantc>efraim: i don't see anything obviously related to linux-libre in the bugs i'm talking about <vagrantc>i thought the missing catch-all case got fixed a few commits back <efraim>10.1.3-c is completely missing in mit-scheme upstream <vagrantc>966629a114fd90153784dfdbe5e332e0ac94f1bc <efraim>vagrantc: 'guix package -A' should be fixed now <pkill9>blender seems to have decided to bork <notnotdan>I've noticed that my $HOME/.guix-profile/ directory is owned by root, and is not owned by me. Is this by design? <OriansJ>notnotdan: if you run ls -hal $HOME/.guix-profile/ notice it is a symlink <vagrantc>could also happen if running sudo -E for the first guix operation <OriansJ>notice that it points to the /var/guix/profiles/per-user/ directory and how all generations are stored within it <OriansJ>Thus by design it should be immutable <notnotdan>The thing is, I want to put some files in my profile. I know this is very bad practice but I need this for my workflow :< <vagrantc>the symlinks appear to be owned by the user on my system <vagrantc>but the last thing the last symlink resolves to is immutable <OriansJ>notnotdan: then make a guix package definition for those files and then they will be added in the install <vagrantc>efraim: yup, that definitely fixed it, thanks again! <notnotdan>yeah but the thing is it's a library that I am working on so it's updated constantly <OriansJ>notnotdan: update versions is a nothing <notnotdan>so each time i want to install it i have to package it up, calculate the hash etc <OriansJ>notnotdan: write a script that does the steps and simply add an emacs hook. <jlicht>notnotdan: you can use the `--with-source=<source-dir>' transformation option <OriansJ>notnotdan: and I used to be terrible at walking when I was 2 but I put in the effort and got over it. Now it feels completely natural <jlicht>notnotdan: provided you use something like git, you can also write a simple `guix.scm' file and put it in the root of your project; you would only need to change it if the actual build steps for your project change as well, and none of this munging with hashes and checksums while you are hacking the good hack :) <notnotdan>jlicht: hm so how does that work? I don't think I can just get rid of the checksums in the .scm file <jlicht>exactly, with a git-related helper I stole from someone else <notnotdan>OriansJ: yeah, now I just need to quickly learn shell scripting, Emacs lisp and Guix API and I am set :P <OriansJ>notnotdan: Make failure cheap and cheap success will follow. You have the potential to do it ^_^ <notnotdan>jlicht: so in guile-semver you just bump the commit hash every time you install the package? <jlicht>notnotdan: I there would have been multiple actual releases, I would bump the commit and hash every time. But while hacking away, I just build from my local git checkout using guix. That is what the second package is for (guile-semver.git). <jlicht>so while workign locally, you have the best of both worlds; reproducible builds with guix and all other advantages (e.g. guix environment, rollback), while still being able to keep working on new features :-) <jlicht>notnotdan: In case I was not being clear; you subsequently build guile-semver from the current revision of the source with a simple `guix build -f guix.scm' while your working directory is at the project root. <notnotdan>I am just trying to understand the package definition. Basically the .git version differs only on the #select? parameter. <notnotdan>But then neither git-file? nor git-predicate mention the actual commit # <espectalll[m]>So I noticed the USB constantly lights up and down, so it looks like the EFI is trying to read data <jlicht>notnotdan: it just packages up the ~current state~ of your project <notnotdan>jlicht: I see. This makes sense. But why the difference (source) inputs then? <jlicht> notnotdan: because the non-.git version refers to the actual (online) released version, and the .git-version is only for local development e.g. you could put a slightly modified version of that file in your GUIX_PACKAGE_PATH, and guix would be able to do `guix package -i guile-semver' but for you this might not be as relevant. The `git-file?' + `local-file' part seems the most interesting <notnotdan>jlicht: ok, thanks for walking me through this <vagrantc>hrm... i want to do (setenv PYTHONPATH (string-append (find-files (assoc-ref inputs "python-pyelftools") "site-packages" ":" (getenv PYTHONPATH)))) <vagrantc>but it complains that find-files isn't returning a string ... <vagrantc>oh, maybe i need find-files-recursive... <jlicht>vagrantc: find-files would return a list, I guess <vagrantc>but how to convert items in a list to a string? <jlicht>in what sense? afaik, the items in the list that are created by `find-files' are already strings <vagrantc>in a sense that i can usefully stick them into PYTHONPATH :) <OriansJ>vagrantc: (list->string (list #\a #\b #\c)) <vagrantc>of course, maybe find-files is finding more files than i want... *civodul makes progress removing dust from the Hurd port <civodul>and i said this would be post 1.0! ;-) <janneke>civodul: i'm working up to a 0.19 mes release -- i finally got tinycc compiled using my latest mes. the amazingly good news is that tcc now compiles in ~8min (WAS: ~2h) <vagrantc>i'm still trrying to extract a PYTHONPATH from python-pyelftools so I can add it for a script run during tests <civodul>janneke: woow! how did you achieve that speedup?! <civodul>vagrantc: isn't it enough to add python-pyelftools and python to your inputs? <janneke>civodul: months of work, two major things: implement strings as array-of-bytes (WAS: list of char cells) and moving the scheme stack out of the arena ;so that pushing/popping stack frames does not imply creating cells/gc'ing cells but is only the moving of a pointer <civodul>how does it translate in terms of lines of code? <janneke>so there's probably no need anymore for the bootstrap-guile development package rewrite hack <janneke>civodul: i've added about 600 lines to the C core <janneke>however, i'm hoping to move macro expansion to Scheme now that the C core performs so much better <vagrantc>civodul: no, that apparently isn't enough. i've only been able to get it to build by explicitly setting PYTHONPATH <civodul>vagrantc: perhaps you should check the 'environment-variables' file in the failed build tree to see exactly what's missing from there <civodul>PYTHONPATH is supposed to be set automatically <ajtos>how capable tcc is those days? can you build glibc against it or you starting with uclibc/musl or something else? guess path to building modern gcc with tcc can be long - c++ dependency and so on. <janneke>ajtos: what i know is that tcc can build glibc-2.2.5 and gcc-4.7.4 <janneke>however, to build gcc-4.7.4, you need a decent glibc; tcc does not come with a libc <vagrantc>civodul: it appears to be all python2 paths, but python is 3.7 and python-pyelftools uses python 3.7 <OriansJ>civodul: the C code size of Mes.c isn't an issue thanks to cc_x86.s and M2-Planet. *vagrantc tries using a python2-pyelftools variant <OriansJ>the Mes.c binary isn't required once the M2-Planet->Mes.c step is complete and then the bootstrap binary will be reduced to just 431bytes on AMD64 <OriansJ>(We revised hex0 to eliminate the need for exec_enable and shell redirection) <vagrantc>civodul: yup, adding python2-pyelftools worked without problem <espectalll[m]>Tried a lot of stuff and decided to go with Super Grub2 Disk <espectalll[m]>So it may be related to how GRUB now makes images, compared back to when GuixSD 0.10 was the latest version (and it worked fine) <ajtos>janneke: i was out of loop when it comes to linux - i remember that rob landley was toying with idea of minimal bootstrap with tcc and musl libc few years ago - don't think anything came out of it <vagrantc>how to make python-build-system use python3 ? <civodul>vagrantc: you can use #:python python-wrapper, i think <civodul>OriansJ: ok, though i would expect the size of mes.c to be an important factor? <civodul>i mean if the C version is big, then the asm version will be big as well <ajtos>espectalll[m]: legacy bios or efi boot? i'm new to guix, but i'm guessing that guixsd introduced efi booting at some point? <OriansJ>civodul: we are going to eliminate the need for the asm version entirely <OriansJ>civodul: aka build the Mes binary from Mes.c using M2-Planet, which is considerably smaller and self-hosting in 16,370 Bytes <OriansJ>(4,395 lines of handwritten M1 assembly including copyright header, comments and blank lines) <ajtos>this is offtopic - i was having problems with wifi card on guixsd. seems like Atheros AR9462 is way more noise dependant than intel wifi card i used before. switching channels did the magic for me. <ajtos>RX drop was like 10% after switching cards. <ajtos>i installed guixsd without issues and guess that traffic hours affected connection to the point i couldn't get ip from dhcp server running on router. <janneke>ajtos: okay...they might be interested in where we are now? <ajtos>janneke: i don't have an idea. rob is still working with toybox i guess - minimal replacemnt for coreutils. that is still relevent to bootstraping i guess. <OriansJ>ajtos: Mes.c is the core of the guix bootstrap and we are updating the channel on changes relating to the generation of the Guix bootstrap binaries <OriansJ>aka reducing the total binary size down to just 431bytes for AMD64 systems <efraim>I thought toybox was to replace busybox with a weaker license <janneke>ajtos: toybox may be interesting, together with samplet and Rutger i'm working on a bash+coreutils replacement in Guile: Gash <ajtos>efraim: my memory can be iffy, but there were also maintaince issues with busybox and uclibc ant the time. musl libc started with gpl then switched to bsd license and toybox did happen. those are way smaller targerts than glibc/coreutils. <ajtos>i remember that rob used to maintain patches for kernel that didn't require perl etc. don't know what current state is. <dustyweb>time to work on trying to get my scanner to show up again <dustyweb>where are the udev rules written to so that I can inspect if they were done right? <dustyweb>guix does populate an /etc, but they don't appear in there <civodul>dustyweb: protip: run: sudo cat /proc/$(sudo herd status udev|grep Running|sed -es'/.*is \([0-9]\+\)\./\1/g')/environ <civodul>and get EUDEV_RULES_DIRECTORY from there <dustyweb>of course, what other command could I even think to run ;) <civodul>we could make that "herd rules udev" <dustyweb>I always find it so hard to mentally prepare myself for <dustyweb>especially because what methods are available may depend on your service <civodul>it works fine for things like "herd restart foo", and i guess that was the intent <civodul>but there are things that look weird, like "herd eval root '(+ 2 2)'" <civodul>POLA and REPL don't go together well <civodul>the Lisp-style REPL is really "sudo let me evaluate anything" <dustyweb>civodul: it's true especially when you have a mutable toplevel <civodul>there's (ice-9 sandbox) which is close to that <civodul>the shepherd's eval exists to do things like reloading services upon 'guix system reconfigure' <espectalll[m]>How does Guix install a new system? Does it install the latest substitutes online or whatever's on the GuixSD image? <civodul>typically a situation that's imperative and "ambient authority"-ish <dustyweb>it's of course "highly advanced user mode" though :) <dustyweb>hopefully we can distill more of those flows into common commands <civodul>well it happens without you noticing <civodul>espectalll[m]: the behavior hasn't changed <dustyweb>civodul: wait, does some other process call herd eval? <civodul>espectalll[m]: guix installs the packages it knows about <civodul>dustyweb: 'guix system reconfigure' makes an 'eval' RPC to PID 1 <dustyweb>and I guess it can construct the command on the fly <civodul>espectalll[m]: yes, or if you're installing from the 0.16 image, you do not have to run 'guix pull' <dustyweb>espectalll[m]: yes, apparently "herd eval root <lisp-code-here>" exists, I am just learning now myself :) <civodul>dustyweb: but think about it: "systemctl reload xyz" is about the same, you get to run code in PID 1 <ng0>dustyweb: that's why I like /etc/rc.d/$name $method and sometimes get lost with $name $method when it is an executable I have to use instead. <civodul>dustyweb: what *is* wild is running a REPL server in a separate thread in PID 1 as i posted a couple of years ago ;-) <ng0>ajtos: could be that these patches are abandoned since Rob stopped developing Aboriginal Linux <ng0>one post in april 2018 <ajtos>ng0: he replaced aboriginal with mkroot afaik. not sure what is going on there, since i have been off for long. when it comes to linux. <ng0>seems to me as if it's possible with some tinkering <espectalll[m]>It may have to do with how the boot is configured in the builds instead <espectalll[m]>And there's something that at least Ubuntu does right for Macs that GuixSD doesn't <espectalll[m]>Where can I look up how GRUB is configured for the GuixSD ISOs? <espectalll[m]>I just don't know why Ubuntu (and others like Void Linux, actually) would work fine but GuixSD wouldn't <dustyweb>gonna try rebooting but I tuink for whatever reason my uev rule isn't getting written out <atw>I'm having a problem which I think is intermittent DNS resolution failure. But I'm also seeing something that worries me a little more: <atw>"sha256 hash mismatch for /gnu/store/xbj4fhad0lnz0ziflwi90gyqbls8ains-nss-certs-3.39: expected hash: 101v69xp1qzw9v6pgmbhw7gfdaic8vvs4v5l567lx7f2mjp25rla actual hash: 08ziz714diyfq2klxy1nc0nhr5wa2vd356n9vizlq913a7an9a9s" <atw>has anyone else seen that? <espectalll[m]>The system also freezes if I boot into a somehow compatible EFI (like Void Linux's GRUB) and then insert the GuixSD USB <espectalll[m]>I definitely know it's not the hardware because I used the GuixSD images in all my media <espectalll[m]>And I also tried out all of my ports as well as the SD card reader <rain1>i would like to debug an audio issue in a program im packaging <rain1>what happens is that audio works first time, but then it's gone after exit and the program wont launch <rain1>i'm not sure which audio systems are used in GUIX desktop.scm, the program is alsa-lib but do i need to know about pulseaudio too? <rain1>and what tools can i use to diagnose the problem? something to dumb state which i can compare before and after maybe? <dustyweb>I find it very helpful for debugging these kinds of problems <dustyweb>it's basically pulseaudio mixer interface deluxe <rain1>it shows ALSA plug-in on while it's open <quiliro>anyone know why guixsd does not boot on a macbook air...previous versions did....wifislax boots...debian, trisquel, pureos do not boot <rain1>the problem did not occur today.. strange! <th-end>can someone point me to an example of a package that invokes autogen.sh before the configure stage in the gnu build system? <dustyweb>it was in that directory via that command you gave me <dustyweb>(I still haven't gotten the scanner working though) <rain1>th-end: if you grep the guix repo you will see many (system* "./autogen.sh") <rain1> (add-before 'configure 'autotools <rain1> (zero? (system "./autogen.sh")))) <th-end>will i need an additional dependcy for the package? <dustyweb>my scanner rule *does* appear in that directory <dustyweb>tthe bad news... actually I'm not sure even where the device would show up in /dev when I plug it in based on this rule :) <terpri>dustyweb, you can watch what udev is doing with "udevadm monitor -kup", which should print changed /dev paths as DEVNAME=... <rain1>I try to search the guix-help archives <rain1>but after the first time, search does not work <rain1> References: [ (can't open the index) ] is the error I get ***lostcoffee is now known as atw
<dustyweb>terpri: well that got me as far as being able to find the device <dustyweb>but now I still can't scan! simple-scan still isn't happy with it <dustyweb>but at least I can point simple-scan at it now... <rain1>I'm trying to build firefox 64 on guix <rain1> if anybody has tips or partial work i would use it <dustyweb>I'm getting the impression that the issue I'm having is somewhere on the sane side <dustyweb>however we don't seem to expose a way to configure sane <rain1>is there a way to union inputs together, like sdl-union but for others? <dustyweb>rain1: what's the desiderata? sdl-union is very painful IME but admittedly I don't understand why it exists :) <rain1>("sdl" ,(sdl-union (list sdl2 sdl2-ttf))) <rain1>I want to do this ("llvm" ,(union (list llvm-3.9.1 clang-3.9.1))) <terpri>rain1, (guix build union) maybe? <terpri>the problem with firefox 64 is that it requires the rust 'cbindgen' tool, which unlike the other rust dependencies is not vendored <terpri>you can install it in a profile with 'cargo install cbindgen' (using rust:cargo) along with the other dependencies and then build firefox manually, but that doesn't help for packaging <pkill9>does anyone else have an issue running blender, the GUI is blank and it outputs a bunch of errors in the terminal, and the splash screen links are replaced with some code <rain1>it was interesting that the data at the mozilla url has changed hash <rain1>wonder if they changed the code at all or just reordered file/creation date in the archive ***rekado_ is now known as rekado
<rekado>civodul: I just reconfigured one of the build nodes with the qemu-binfmt service, but it fails to start; throws a match error. <rain1>when i do: guix build sdl2 it prints 2 lines (XXX-sdl2 and XXX-sdl2-debug), how do i make it just do one? <janneke>rekado: it would be great if you could build my core-updates branch @gitlab <janneke>we'll have to verify the new mes-minimal-stripped-tarball hash and upload it to gnu.org too <rekado>earlier I tried the version that failed for you <rekado>(before the “fake bootstrap” switch had been removed) <rekado>can I just update and build mes-minimal-stripped-tarball? <janneke>great! i don't think you need to change anything this time <janneke>i don't want to push to savannah yet, as i changed the mes-minimal-stripped-tarball url to lilypond.org again... <rekado>congratulations on Mes 0.19! 8mins for tinycc is nothing short of amazing! <janneke>yeah! i've been dragging my feet for weeks to get down to this release and our hacking at R-B was just what I needed <janneke>i feel pretty bad for adding yet another arbitrary limit to mes..., hopefully we can remove that some time soon <janneke>meanwhile, samplet has pushed an amazing wip-merge branch for gash+geesh <janneke>rekado: there were so many things that prevented tcc to build, but they all turned out to be small silly problems <rekado>I’m now building %bootstrap-tarballs. <janneke>i'm hoping mes 0.19 is the last release before 1.0 <janneke>1.0 should brigde the gap between hex0 and mes.c <janneke>i intend to mainly work on Gash until M2-Planet is mature enough to build mes.c <civodul>rekado: re qemu-binfmt, could you send the details to guix-sysadmin or similar? *janneke looks what it should be <atw>still trying to wrap my head around MES, hex0, g*sh, etc :) <janneke>civodul: with the mes-0.19 release, i used lilypond.org urls for mes-minimal-stripped-tarball again...we'll have to redo the hash comparison and upload+change to gnu.org thing <janneke>the bad thing of not pushing my core-updates to savannah, is that each time origin/core-updates changes i must rebase on it and change the commit messages 'Built with ...' after actually re-building it <janneke>i want to do the right thing, though <rain1>I can't get a program to run, it says "No such file or directory" <rain1>ive added every dynamic library from ldd that it needs via LD_LIBRARY_PATH though <rain1>oh i think I need to change the interpreter from /lib64/ld-linux-x86-64.so.2 to something <rain1>i'm not sure how to do that because the string is longer so i can't just patch the binary <pkill9>try with `patchelf --set-interpreter`, i don't think a longer path will stop it, might be wrong <civodul>janneke: when you feel confident you can push to Savannah, and from there i/someone will rebuild the tarballs <civodul>BTW, i wanted to get rid of gnu/packages/bootstrap/x86_64-linux and use the i686-linux variant instead <civodul>i guess i should wait until we have the bootstrap tarballs to make such a change? <rain1>i got a weird error from it though <lsl88>does anyone have experience with ipfs? <OriansJ>atw: think lots of little pieces that work together and are built to standards to allow replacements and ports to occur transparently <civodul>i now have a couple of days of experience :-) <lsl88>civodul: hi :) I was reading emails and watching tutorials about it :) <lsl88>civodul: was it you who said that it is unencrypted? I mean, I have already launched the daemon, did not add anything. If I add files, will whoever that runs ipfs see my files? <lsl88>I mean by whoever, not only guix community <tune>what should bash scripts in ~/bin have at the top in order to work on GuixSD? <rain1>#!/run/current-system/profile/bin/bash