<alarat>samba has a --localstatedir config option, on other systems that points to /var. On guix currently it points to /gnu/store/...samba/var, which doesn't work as it's read-only, and samba tries to write lock files and log files. Where would the right place to put it be?
<nckx>alarat: You'll have to teach the build system manners.
<alarat>my limited time in guix has certainly given me ample excuses to learn more
<nckx>Sometimes Makefiles do a (silly and unnecessary) ‘mkdir $localstatedir’ for no reason, sometimes they do more and you can fool them by setting localstatedir to $out/share/doc-xxx/examples only during the install fase, etc.
<nckx>In the first case a simple substitute* to replace, say, mkdir with true is fine.
***wxie1 is now known as wxie
<alarat>I can patch them out (looks like one directory was already patched out with substite*) but then when will they get created? The program creates some of them at runtime but errors out on others if they're missing.
<nckx>(I don't just mean ‘read the fine code’, there's an actual docstring there too 🙂)
<nckx>I think it says all there is to be said, really.
<butterypancake>well now that I know what module it's in I can import it in the geiser repl and now the describe symbol at point thing works for it
<butterypancake>but how am I supposed to know which modules to import? I feel like I've been contantly asking questions on this IRC but I still don't know where I'd go for answers without this IRC
<nckx>I thought you'd given up on the geiser lyfe.
<butterypancake>it's not to intrusive. Emacs stopped freezing. It's just there in the background
<nckx>butterypancake: Hum, you… just know? I dunno, really. Build side things are in (guix build …), and the most common helpers are in its utils.
<butterypancake>It seemed like such a general function I kept thrifting through scheme manuals trying to find it :P
<nckx>‘Thrifting’. I picture sifting through dusty second-hand Scheme books.
<nckx>I wish my local thrift shop had Scheme books ☹
<butterypancake>lol, same. I grew up taking speach thearapy because I said all the words funny but I also just tend to use the wrong ones. I honestly thought my inability to use the english language was limited to verbal communication until I started to use IRC. I think I'm just bad at english :P
<nckx>butterypancake: Some people call them recipes. I call them packages, simply because I hate the word recipes. That's all there is to it. Call them what you like. (Packages!)
<butterypancake>I mean, I kinda feel like they are a recipe as they don't actually include the ingredients (you gotta go download those) but also I think web dev people use the term recipe so I don't like that term
<nckx>When forced to differentiate between the abstract concept of ‘the package’ and the actual Scheme code I say ‘package experession’. This happens roughly never.
<butterypancake>I added opendoas as a setuid program, and now I can use it to do root like thing!!!
<ericonr>Hey there! Anyone here have experience with packaging Guix for a foreign distro which does cross compilation? I'm not sure how I can tell Guix to search for bindings such as gnutls without having them installed in the host system as well
<ericonr>It fails with > configure: error: The Guile bindings of GnuTLS are missing; please install them.
<reepca>every package specifies a cryptographically-secure hash of the source used, and this is also verified
<reepca>ultimately though, the hard work of verifying these things is on the packagers, in verifying that the source they hash to put in their package definitions was written by the people it claims to be written by
<usney>Just making sure because my internet has been acting strangely disconnecting and reconnecting. Some sites I use regularly have reloaded unecrypted even though I use https everywhere.
<rekado>“The screen utility has an old code base that is not easy to maintain and with little activity in the upstream community. The tmux package was viewed as having a better code base to maintain and build new features upon. Maintaining both within RHEL was becoming increasingly unfeasible when considering keeping up with CVE security errata, government security certifications, and similar requirements. For those concerned with DISA STIG
<rekado>requirements, tmux satisfies the requirement as an alternative to screen.”
<roelj>rekado: I see it seems to start slow and increase gradually. So the longer your download the faster it gets.
<ennoausberlin>civodul: Is it common practice to "publish/export" such an package definition? There was not much to do after guix import pypi, so even guix/scheme beginners like myself can do this. On the other hand it might be convenient to have this package publicly available
<roelj>rekado: I'm happy to spend some more time to help debugging if that helps you in any way. :)
<PurpleSym>mbakke: If you have not looked at the CVE for json-c, I’d take a shot, but it probably requires a version bump and soname change.
<rekado>roelj: could you please send me tail of a traceroute? I’m curious to know how it differs from mine.
<mbakke>PurpleSym: we have a new version of json-c on the 'staging' branch, I was hoping to merge it shortly but the CI has not made a lot of progress
<mbakke>so maybe we should graft the fix meanwhile
<PurpleSym>Ah, ok, my bad. I only looked at core-updates.
<MSavoritias>so turns out the message I get from the Wifi adapter is [10681.700196] traps: telepathy-idle general protection fault ip:7f67241c8d22 sp:7fff4ee39ac0 error:0 in libgobject-2.0.so.0.6200.6[7f672419d000+33000]
<abralek>according to ABI policty gcc 3.3.1 is the latest one which ships with libstdc++.so.5.0.5
<rekado>I hit an obstacle in reducing the pandoc closure size.
<rekado>I’m now splitting static and shared libraries into different outputs
<rekado>this helps but I would like to link the pandoc executable statically
<rekado>just to see how much smaller that would be
<rekado>pandoc support static linkage with “-fstatic”, but linking fails for some reason
<rekado>I’m suspecting that GHC records the location of the libraries (in the “out” output) and doesn’t know how to find the static variants
<butterypancake>the guix manual mentions trying to build your package on other platforms, but it doesn't mention trying to cross compile your package. Is that not important? How do I test cross compiling?
<butterypancake>oh no, looks like I can't build my package using the arm qemu for some reason. It doesn't even start
<civodul>butterypancake: in practice a lot of software packages cannot be cross-compiled
<civodul>so we mostly focus on ensuring that "core" packages can be cross-compiled
<civodul>cross compilation is made by using the '--target' option
<butterypancake>I'm working on opendoas, which is going into admin.scm and is probably considered core
<butterypancake>I don't get it. I try to run a build using qemu, and it trying to run the system native guile executable and then compains about "No such file or directory"
<butterypancake>so I built a package using --target=aarch64-linux on an x86_64 machine. the build process spat out a path, and when I tried to run the executable I built at the end of that path, it worked. That means something is wrong right? I'm not sure how this could happen...
<lfam>I figure it wouldn't do anything but I don't think that '--target=aarch64-linux' is valid
<butterypancake>well yes. It works with --target=aarch64-linux but it fails with --target=aarch64-linux-gnu
<bricewge>butterypancake: Then it's fine. What I understand is when executing a foreign binary, the kernel will check the magic number, then look under /proc/sys/fs/binfmt_misc/ for an appropriate interpreter and execute such binary with it (here qemu).
<butterypancake>jesus. so guix is just magic. Thanks. didn't know it could do that
<lfam>I guess it learned how to automagically guess what you mean
*civodul finished 3h of video conf, ears bleeding, bah
<lfam>Ugh, the rise of video chat is a minor disaster
<lfam>Like, what the /gnu/store directory would be?
<jackhill>I mean, I did already, but even more so.
<lfam>Yeah, it's definitely a weak point for Guix these days
<lfam>It's a weak point for free software in general
<cbaines>bricewge, lfam as for the Guix Data Service having data regarding substitutes being downloaded, it doesn't yet.
<lfam>Especially since all the stuff under the hood (like codecs) is free software
<cbaines>although it's some data that would be nice to have
<butterypancake>so I think I know why --target=aarch64-linux would work but --target=aarch64-linux-gnu would not. It's becuase I set the compiler to be (string-append target "-gcc"). However, --target=aarch64-linux-gnu is actually running a c compiler, just one that can't acced glibc. --target=aarch64-linux is running a c compiler that can access glibc
<roptat>speaking of Java, I'm still working on my wip-maven-build-system branch, it's taking longer than expected because I need to check I don't break too many things
<roptat>I'm hopeful that this week-end I'll be able to push a first version of it
<jackhill>roptat: +1. I appreciate that work! woo!
<roptat>I had a hard time with junit, but in the end it turned out I shouldn't have updated it, then I spent most of my time rebuilding the java world...
<bricewge>Does the offload feature support building via binfmt?
<bricewge>When offloading does the client have to stay connected to the machine it offload to?
<butterypancake>Submitted my second patch :D How long does it usually take for people to review your patches?
<bricewge>Hopefully berlin's will be ready before mine
<str1ngs>hello, could someone check this diff for me? git show 9da87078417bb16ad82652a7d2efd72185c28220. seems to me the commit should have been v0.4.1-28-d459ca1 not v0.4.1-28-gd459ca1? or I'm miss understanding this change?
<civodul>in a nutshell, you're saying it doesn't make a difference, right? :-)
<civodul>but anyway, the image API can create raw disk images?
<civodul>so we can always use "qemu-img convert" to turn that in qcow2 images
<civodul>and then we no longer need all that stuff?
<butterypancake>lfam: It's quite possible. I'll try building it using libbsd. Now libbsd most likely does things in a free bsd way as that's the more popular OS, and opendoas is written by an open bsd guy so it might not work. But I'll see
<lfam>butterypancake: I don't think you need to try swapping out the code
<lfam>It's also my impression that libbsd is more freebsd-oriented
<str1ngs>nckx: I have a fix for the guile2.2 issues. and I semi reverted the change to get the right git hash see http://paste.debian.net/1149414. as far as I know only nomad uses emacsy-minimal. but I forget how to check reverse depends.
<butterypancake>--fallback means if you can't find someone who already compiled it, then do it yourself. So if your computer is really slow it might take a while because it has to compile something. But I don't think there is an alternative
<nckx>I'm still building my aarch64 build environment so thanks for the vision of things to come.
<butterypancake>I was debating trying to manually pass it the CROSS_C_LIBRARY enironment variables, but since I have a super standardized make phase it seemed like that's may or may not be an upstream bug
<nckx>Sigh. And this was looking like such a nice straightforward package 🙂
<ryanprior>I can't build guix from source right now. Following the instructions on "Building from Git" I ran `guix environment --pure guix` then `./bootstrap` then `./configure` but configure fails.
<ryanprior>checking whether Guile-JSON is available and recent enough... no
<butterypancake>It didn't like the struct or something. Also inspecting the object that made showed it was very different from the default setuid program objects. Even the g-expr copy pasted from the manual didn't work (I think you did have like 1 minor typo that I fixed). I ended up making the correct object in the exact same way the default setuid programs are made which was *one second*
<nckx>butterypancake: To answer your earlier question (I thought I did y'day): fast patch reviews are not our strength. Getting one within a day is a magical experience. Savour it. Real ones are closer to a week, or more. Sometime much more ☹ We need help.
<butterypancake>nckx: all I learned about execvpe was that it was added to glibc back in like 2.11 (our glibc has it). Basically, if the compiler can find glibc, you should be good. My problem with execvpe was actually that the configure script never checked for a compiler and was using cc. So the execvpe test was failing because it wasn't even using a compiler :/ now the aarch64-gcc should be able to see glibc I would think. However you'd h
<butterypancake>check the environment variables. I think the aarch64 glibc is actually in an environment vaiable called like CROSS_C_LIBRARY or something. I'm not sure exactly why the CROSS environment variables exist, but they don't show up without a target
<butterypancake>the silly thing is, I confirmed that the configure script is using the aarch64 compiler, and somehow is can indeed find execvpe. Now the flags in the configure script are quite different from in the makefile so you could look into that, but the configure script is so bad I'm not quite sure what the flags are
<pkill9>i want a ranger-style browser for browsing guix graph output
<nckx>pkill9: The lack of tooling (that I know of) for the dot format is rather disappointing. ‘Render it to a flat image, then drag that around the screen’ when it could be so much richer.
<kmicu>A capital invests in Nix infra. Who invests in Guix tho?
<nckx>lfam: Oh yeah, it's nothing fancy, it's guix publish + a caching proxy + some simple logic that populates the cache when the ‘CI’ system is idle. So users get a pre-cached hit or it's streamed straight from guix published (and cached), depending on load. Nothing fancy.
*nckx wonders if a proposal for GPL3+ code would be accepted.
<nckx>raghavgururajan: Inkscape's almost finished. However. I have pulled (guix d1fa24a + your ‘diff.diff’ patch). ‘guix build --dry-run inkscape’ returns /gnu/store/vzlyxgx8yascb5pay1s3giyxx1y5jiwn-inkscape-0.92.4.drv. That's not the same hash you posted above, so you won't get a substitute.
<nckx>You've changed something else, or we're not working from the same base commit.
<nckx> /gnu/store/a2l55bb1hwl4c10h0zz7ghbdav4yrpx7-inkscape-0.92.4 is ready.
<nckx>raghavgururajan: I wonder what other patches are in your ‘git log --format=oneline origin/master..HEAD’.
<nckx>lfam: I was wondering the same thing. I can't think of any security issues with regular user bayfront access.
<nckx>bhartrihari: Could you paste(.debian.net) your configuration & the error you get?
<raghavgururajan>nckx: After refreshing my local wip-desktop branch, `./pre-inst-env guix build clutter --dry-run` gives /gnu/store/wsxb8smh7yln0s6lpz0yknzkv43a15dq-inkscape-0.92.4.drv and /gnu/store/shi094v95an5h7vm2yj9hakgml1l3xjy-gtk+-3.24.14.drv
<nckx>I have the inkscape .drv but not the gtk+ one.
<bhartrihari>nckx: do you want me to paste only the package definition or the whole config?
<mjw>Feels oddly familiar, but also a bit confusing, since instead of one data-structure/language to rule them all, it uses a mixture of tools and languages.
*kmicu was very happy to see civodul mentioning Shake paper in a recent Guix post.
<Kozo>Hey Guix, I need help understanding the difference between --system and --target. What is the diff between build and cross-build? Aren't they both making something for an arch that isn't the machine that's building it?
<bricewge>Hey Kozo, I was wondering about it earlier in the day, so take it with a grain of salt.
<bricewge>--system allow you to build for the specified architecture only, while --target will give you result working on both architecture (the host and the target)