IRC channel logs


back to list of logs

<civodul>janneke: did you comment on the 'basename' fix i proposed for Guile several days ago?
<rain1>i checked the CVEs
<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
<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
<rk4>thanks :)
<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>my current definition is here:
<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/; 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>or anyone else for that matter.. :)
<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.
<thomassgn>thanks janneke
<janneke>thomassgn: ah you found it, good!
<thomassgn>aye, proselint now has a guix package definition. I'm not sure if I should send it in as a patch because I disabled tests (couldn't figure out the errors, also partly laziness). It is in my repo:
<espectalll[m]>Hi, I'm trying to install GuixSD but have a weird issue with EFI
<espectalll[m]>cannot anybody help please?
<espectalll[m]>trying to boot 0.16 from an old iMac but the whole computer just freezes if the USB is in on boot
<espectalll[m]>No success with rEFInd either
<efraim>Which version iMac?
<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?
<espectalll[m]>> Which version iMac?
<espectalll[m]>Late 2009
<espectalll[m]>efraim there you go
<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
<espectalll[m]>Yeah, it's a 64 bit Maxine
<espectalll[m]>The USB also boots just fine on a Surface
<espectalll[m]>Which is... huh
<efraim>what if you press alt/option at bootup to give it a bit more time to recognize there's a USB stick
<espectalll[m]>No, it freezes before I can do that if it's already in
<espectalll[m]>If I do that with the USB out and then put it in
<espectalll[m]>Well, it freezes
<espectalll[m]>And I can wait a bunch of minutes and it just won't respond
<espectalll[m]>Same thing with rEFInd
<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
<espectalll[m]>A bunch of versions ago it just worked
<espectalll[m]>I don't know if it was around 0.10 to 0.12
<espectalll[m]>And the firmware should be the same
<efraim>I still have issues with the broadcom wifi and the free firmware, but that's a linux-libre issue
<vagrantc>efraim: just filed a bug on it
<efraim>vagrantc: against linux-libre?
<vagrantc>efraim: test failures in several critical things
<vagrantc>guix package -A bash
<vagrantc>also backtraces
<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
<efraim>i mean't my broadcom bug
<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>maybe an incomplete fix
<vagrantc>#33768 is the one i just filed
<efraim>vagrantc: 'guix package -A' should be fixed now
<espectalll[m]>So I decided to reset the NVRAM
<espectalll[m]>let's see how that goes
<pkill9>blender seems to have decided to bork
<pkill9>the UI isn't showing toolsbars
<espectalll[m]>Alright, froze again
<vagrantc>efraim: thanks, will test!
<jlicht>hey guix!
<janneke>hi jlicht!
<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
<notnotdan>Yeah I undestand that.
<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
<notnotdan>OriansJ: what do you mean?
<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
<notnotdan>yeah I am terrible at scripting :P
<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>notnotdan: an example that I used to solve the problem you are running into:
<notnotdan>jlicht: ah, you use the `local-file' source
<notnotdan>jlicht: thanks, i'll study your 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?
<notnotdan>Also it's used only for versioning I think
<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>s/I there/If there/
<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>Yeah this is cool!
<notnotdan>I am just trying to understand the package definition. Basically the .git version differs only on the #select? parameter.
<espectalll[m]>Hey I'm back
<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
<espectalll[m]>Maybe I should leave it on like an hour or something?
<espectalll[m]>Or maybe I can install GRUB on macOS or something?
<espectalll[m]>(or something)
<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
<chrislck>quick question - if i install guix via (the shell script) - how do i cleanly uninstall?
<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>yeah, figured
<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...
<jlicht>or rather string-join :-)
<civodul>Hello Guix!
<janneke>hello civodul!
*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?!
<janneke>oh, ugh!
<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
<vagrantc>civodul: i'll try now!
<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
<janneke>that's about 10% more
<vagrantc>civodul: no, that apparently isn't enough. i've only been able to get it to build by explicitly setting PYTHONPATH
<civodul>janneke: this sounds promising
<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
*vagrantc checks
<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)
<espectalll[m]>Hi, so I'm having issues with booting GuixSD on a Mac
<espectalll[m]>The firmware just freezes when I put an USB with the system
<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]>Turns out that also freezes my Mac
<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
<espectalll[m]>ajtos EFI for sure
<espectalll[m]>This Mac doesn't support BIOS in any way
<espectalll[m]>It's not UEFI either since that didn't exist at the time
<espectalll[m]>And the firmware freezes just by having the boot there
<espectalll[m]>not by actually booting from our
<OriansJ>civodul: aka build the Mes binary from Mes.c using M2-Planet, which is considerably smaller and self-hosting in 16,370 Bytes
<espectalll[m]>Let me try something that should always work
<espectalll[m]>Maybe Ubuntu or even Windows if that falls
<espectalll[m]>Maybe it's unrelated to GRUB
<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.
<ajtos>he is still maintaing this:
<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
<janneke>hi dustyweb!
<espectalll[m]>Well uhh
<espectalll[m]>Ubuntu 18.10 doesn't freeze my Mac's firmware
<espectalll[m]>But GuixSD and Super GRUB2 Disk still do
<espectalll[m]>Any ideas on how to debug this?
<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
<quiliro>hello all
<dustyweb>found it
<dustyweb>in the profile's /lib/udev
<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>civodul: wow
<dustyweb>of course, what other command could I even think to run ;)
<dustyweb>thanks civodul
<civodul>we could make that "herd rules udev"
<dustyweb>side note
<dustyweb>I always find it so hard to mentally prepare myself for
<dustyweb>herd <method> <service-name>
<dustyweb>I always expect the reverse
<civodul>yeah, it's weird
<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
<dustyweb>for "universals", makes sense
<civodul>but there are things that look weird, like "herd eval root '(+ 2 2)'"
<dustyweb>... is there a herd eval built in?
<civodul>of course!
<civodul>what did you expect? :-)
<civodul>be careful though
<dustyweb>huh... POLA that ain't ;)
<dustyweb>but it's posix, so nothing is
<civodul>POLA and REPL don't go together well
<civodul>what an alphabet soup
<dustyweb>civodul: arguably Shill is a POLA REPL
<dustyweb>since the shell is a REPL
<civodul>the Lisp-style REPL is really "sudo let me evaluate anything"
<dustyweb>civodul: it's true especially when you have a mutable toplevel
<dustyweb>which is highly convenient but yeah
<dustyweb>civodul: actually, also
<dustyweb>if we *did* have a POLA system
<dustyweb>then eval *would* be safe :)
<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?
<dustyweb>civodul: ah
<civodul>typically a situation that's imperative and "ambient authority"-ish
<espectalll[m]>Has that behavior changed in specific versions?
<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
<dustyweb>oh ok
<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
<espectalll[m]>So I can guix pull and it gets whatever is online?
<civodul>dustyweb: 'guix system reconfigure' makes an 'eval' RPC to PID 1
<dustyweb>civodul: that's wild.
<dustyweb>and I guess it can construct the command on the fly
<dustyweb>because sexps
<civodul>espectalll[m]: yes, or if you're installing from the 0.16 image, you do not have to run 'guix pull'
<espectalll[m]>Wait, eval RPCs?
<espectalll[m]>civodul: alright, I'm going to use older images on purpose
<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
<espectalll[m]>To see if 0.15 at least boots up
<civodul>code is data and all that
<dustyweb>civodul: yeah I get it
<dustyweb>civodul: I just wasn't expecting it!
<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>search for "perl" here:
<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>kernel 4.16 patch
<ng0>seems to me as if it's possible with some tinkering
<espectalll[m]>0.15 also freezes my Mac's firmware
<espectalll[m]>So it's not due to a GRUB version
<espectalll[m]>I think, at least
<espectalll[m]>It may have to do with how the boot is configured in the builds instead
<ng0>here's a 2012 comment to the perl removal patches
<espectalll[m]>And there's something that at least Ubuntu does right for Macs that GuixSD doesn't
<ng0>ah woops. I've seen this before because i track the git repo.. for anyone without mercurial in their path.
<espectalll[m]>Where can I look up how GRUB is configured for the GuixSD ISOs?
<quiliro>espectalll[m]: in the manual?
<espectalll[m]>No lmao
<espectalll[m]>That doesn't tell me the actual script used by guix system
<espectalll[m]>I just don't know why Ubuntu (and others like Void Linux, actually) would work fine but GuixSD wouldn't
<dustyweb>maybe that's the cause
<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]>OK, more EFI weirdness
<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]>this is fine
<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>rain1: try using pavucontrol
<dustyweb>I find it very helpful for debugging these kinds of problems
<dustyweb>it's basically pulseaudio mixer interface deluxe
<dustyweb>np, hope it helps
<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 before the configure stage in the gnu build system?
<dustyweb>civodul: you're right
<dustyweb>it was in that directory via that command you gave me
<dustyweb>but I didn't expect that for sure :)
<dustyweb>(I still haven't gotten the scanner working though)
<dustyweb>(oh well)
<rain1>th-end: if you grep the guix repo you will see many (system* "./")
<rain1> (add-before 'configure 'autotools
<rain1> (lambda _
<rain1> (zero? (system "./"))))
<th-end>thanks rain1
<th-end>will i need an additional dependcy for the package?
<th-end>like m4 i think
<dustyweb>so the good news:
<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: oh wow!
<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...
<dustyweb>"Failed to scan"
<dustyweb>"Unable to connect to scanner"
<dustyweb>but it is pointing at the device
<dustyweb>and I do have the right permission
<espectalll[m]>So NixOS works fine
<espectalll[m]>I feel too tempted to install that now
<espectalll[m]>Help me avoid the dark side
<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>like how you can do this
<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)))
<rain1>there is also texlive-union
<terpri>rain1, (guix build union) maybe?
<terpri>rain1, this package should work for at least firefox 61 and 62:
<rain1>thank you
<rain1>that will help me a lot
<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.
<rekado>looks like this might be a bug
<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 too
<rekado>janneke: will do!
<rekado>do I need to change anything?
<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
<rekado>fetching now
<janneke>i don't want to push to savannah yet, as i changed the mes-minimal-stripped-tarball url to again...
<rekado>congratulations on Mes 0.19! 8mins for tinycc is nothing short of amazing!
*rekado runs make
<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
<atw>janneke: the nyacc link on seems broken to me
<civodul>rekado: re qemu-binfmt, could you send the details to guix-sysadmin or similar?
<janneke>atw: yeah, it's broken :-(
*janneke looks what it should be
<atw> ?
<atw>still trying to wrap my head around MES, hex0, g*sh, etc :)
<janneke>civodul: with the mes-0.19 release, i used urls for mes-minimal-stripped-tarball again...we'll have to redo the hash comparison and upload+change to thing
<janneke>it's both good and bad ...
<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
<janneke>and not push too soon
<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/ 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>on core-updates
<civodul>i guess i should wait until we have the bootstrap tarballs to make such a change?
<rain1>thank you
<rain1>i got a weird error from it though
<lsl88>hi guix!
<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>hello lsl88!
<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?