<marusich>Question about cross-compiling C code. If I need to cross-compile a piece of software for a target architecture, and this software needs to link against some library named libfoo is it normal to link against the same libfoo when cross compiling, or do you have to link against a special version of libfoo that has been built specifically for cross-compiling to that target architecture...? <marusich>I mean, is it normal to link against the same libfoo you would normally link against when not cross compiling. <marusich>My understanding is that gcc is "special" and has to be told when it is built what the build, host, and target triplets are, but for other libraries (like the hypothetical libfoo), that dance is not necessary. <leoprikler>it's compilers and build tools in general, that make that distinction; otherwise it's more or less just host vs. target <marusich>So, although I realize this may be a somewhat trivial question, is my understanding correct? That if libfoo is like most libraries, you would generaly link against the same one (e.g., the same .so file or .a file that you have on hand) regardless of whether you are cross-compiling or not? <marusich>i.e. the linker options would not need to change <leoprikler>I'm not quite sure if I understand, but you'd link against target libfoo regardless of host/build IIRC. <leoprikler>I.e. you don't care if an i686 or amd64 produced your m68k code, but you have to link against m68k. <leoprikler>Which would imply the "linker flags not needing to change" safe for stuff that depends on the architecture (like e.g. needing some arcane linker scripts) <marusich>I guess what I mean is, if I'm on a given system and I'm just compiling for various targets, because I have multiple cross toolchains installed and I can do that, would I be using the same libfoo every time? <marusich>Or, would I have to also install a different libfoo for each target architecture, which I then link when cross-building the software? <marusich>I get that I need multiple cross toolchains, one for each target. <marusich>What I am asking is, would I normally need one libfoo per target, also? <marusich>I think the answer is "no" and am just hoping someone can confirm. <leoprikler>I think the answer is "yes", your inputs need to match the target architecture. <leoprikler>(Hence the distinction between inputs and native-inputs in Guix.) <marusich>If that's the case, then why are so many c libraries listed as "inputs" in package definitions? <marusich>e.g. emacs has many "inputs" and no "native-inputs" defined. <marusich>But it has a lot of inputs that are just c libraries. <leoprikler>Because "inputs" are those, that are built for the target. <marusich>ok, i see. So, it is probably the case that if you have some libfoo and you are compiling for 3 different target architectures, you actually would need to compile libfoo 3 times, once for each target architecture, and then you would also have to tell the linker to use the right one, in each of the 3 cases, right? <marusich>For example, in a world where you had built 3 cross compilation toolchains manually and you manually built your libfoo. It sounds like you are saying you would have to cross-compile your libfoo 3 times, for the target architecture, to get 3 different libfoos, each specialized or the target architecture. <leoprikler>yep you'd have to "make libfoo-target-alpha libfoo-target-beta libfoo-target-gamma" <marusich>Anyway, thank you for hepling me to understand. I wasn't sure about that, so I'm glad I asked. <marusich>I don't do a lot of manual cross-compilation, so it isn't exactly obvious to me. <leoprikler>As far as Guix is concerned, the difference between inputs and native inputs w.r.t. cross-compiling is actually explained in the manual. <leoprikler>I used to cross-compile a lot at work, but that was abstracted away by some really obscure Makefiles. <leoprikler>Other than that I recently built stuff with mingw for the lulz and then executed it in Wine because I'm not actually running the MS OS. <marusich>But it's kind of like the Guile manual in that regard: it provides correct information. <marusich>I won't complain much about it because I should try to improve it if I care that much, but my point is, if you aren't already a cross-compilation expert, that section of the Guix manual is not quite satisfactory. <marusich>I've had to explain that section multiple times to people, and although I think I understand it correctly now, it took a while to sink in. My lack of cross-compilation experience probably didn't help. <marusich>I wonder if it would be nice to have a brief intro to cross compilation, but that seems rather out of scope for the guix manual. <leoprikler>I get where you're coming from, but in my personal opinion the manual does quite well. <leoprikler>If you let it sink in long enough you'll eventually get it, at least in my personal opinion. <marusich>I mean I agree, I just wish I knew more about cross-compilation I guess. <marusich>My experience trying to understand cross-compilation using Guix has been frustrating, since a lot of information out there assumes you are using a "standard" GNU/Linux system like Debian. <marusich>So, trying to learn about cross-compilation while also trying to learn about Guix was rather frustrating. <marusich>I guess I would recommend to my past self: go and try cross-compiling things manually using the traditional approaches and learn it first. <leoprikler>I don't think that's strictly necessary, when Guix already takes care of that via --target <leoprikler>Of course if you're interested in cross-compilation for its own sake, then yeah, learning the traditional way is not wrong. <leoprikler>And despite all its weirdness, Guix actually still lets you do a lot of stuff the traditional way once you've figured out that you need gcc-toolchain in some form or another. <marusich>Well, that's true, but there have been times when I've been hacking around and some code wants to use a library internal to gcc, and then things get complicated pretty fast. <marusich>I can't remember, but I think it was libgcc or something <leoprikler>But yeah, learning both Guix and cross-compiling at the same time is harder than doing it sequentially (imo both sequences should work equally fine). <marusich>Still, I hear you. Guix is very remarkable, and I definitely prefer it. <leoprikler>I haven't yet had problems with weird packages wanting to link to libgcc, but yeah, weird packages exist. <leoprikler>I tried packaging fragment the other day (a bittorrent client) and it interferes with transmission in quite interesting ways. <leoprikler>Particularly, I had to unbundle transmission and then modify it on top to even get it to build, because it links statically against transmission and all of its dependencies. <kozo[m]>Hello, I've been testing an issue for 2 days now. If anyone is willing to participate, I'd like to know if the following command works for you: guix environment --ad-hoc --container --no-cwd --network hello. <kozo[m]>Whethere it works or not, I'd like to know what kernel you are using, please and thank you <kozo[m]> * Whether it works or not, I'd like to know what kernel you are using, please and thank you <lfam>It works for me on Debian with 5.11.4 stable kernel <lfam>My guix is commit 8fc36d82271946bf5e327b0f2feef9f65ce91701 <timmydo>has anyone tried to package zig before? ***iyzsong-- is now known as iyzsong-w
<raghavgururajan>timmydo: You might need to patch the installdir. Its trying to install something outside of output. <timmydo>raghavgururajan: ok thanks, will look into that ***rekado_ is now known as rekado
***iyzsong-- is now known as iyzsong-w
***apteryx_1 is now known as apteryx
<sturm>hi folks, I just did a `sudo guix pull` and `sudo guix system reconfigure` and got "guix system: error: aborting reconfiguration because commit 090456dacb76160280a630d53f4f47b421281c66 of channel 'guix' is not a descendant of 8a920dc6716599e58776d41f73b0aff4281530ed" <sturm>I'm not aware of anything unusual that may have led to this <civodul>sturm: hi! this is preventing you from downgrading your system <civodul>you're currently running commit 8a920dc6716599e58776d41f73b0aff4281530ed, which is newer than the other one <civodul>note that when you run "sudo guix system reconfigure", you're running the user's 'guix', not root's <civodul>IOW, you're not running the one you got with "sudo guix pull" <civodul>try this instead: "guix pull && sudo guix system reconfigure ..." <sturm>ooooh right, thanks for explaining - I did understand this a while back and forgot :) <civodul>heh yw! sudo can lead to confusing situations <leoprikler>Also, how is copy-build-system's install defined? <leoprikler>It actually does the opposite, it splits the tail argument (a list) into more arguments. <leoprikler>You will need apply here, but you also need arguments to apply. <leoprikler>Perhaps there lie some stray arguments around somewhere in the build-system code, that could potentially be caught in a variable. *raghavgururajan 's head is spinning <jeko>I am trying to build a local custom package and guix return error with current message <jeko> ice-9/boot-9.scm:1669:16: In procedure raise-exception: <jeko>no code for module (guix packages) <jeko>Here is the used modules in the package definition : <jeko> (guix build-system guile) <jeko>leoprikler: from the command line with guix build --file=guix.scm <jeko>(guix.scm it my package definition) <leoprikler>can you spawn a guix repl and do ",use (guix packages)"? <jeko>scheme@(guix-user)> ,use (guix packages) <leoprikler>okay, so the issue seems to be with guix-build and your package file <leoprikler>do you have the definition somewhere? (pastebin, version control, ...) <leoprikler>pastebin of course meaning a Guix-approved paste such as debpaste or gnome paste <jeko>is this fine? else I will paste it in gnome paste <leoprikler>apart from you not cleaning up ports, there doesn't seem to be an issue with this code sadly <leoprikler>It tries compiling the guix.scm inside the build. <leoprikler>You can a) exclude it from source, b) delete it after unpack or c) use a modules subdirectory for guile-build-system. <jeko>leoprikler: that makes sense !!! Ok so I will try a) or d) haha. and I will clean the pipe ;) <jeko>some differences but I don't know how they impact the bsd compatibility <leoprikler>If I read this correctly, it's a find-and-replace with the copyright holder, right? <allana>Hi everyone. Are there any ungoogled-chromium users here? I may be having an issue with it. I say "may" because I am having quite a few problems at once that may be related. I am getting these errors when running chromium and visiting a site: [5508:5508:0308/111526.288773:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process. [5511:5530:0308/111529.047398:ERROR:ev_root_ca_metadata.cc(841)] <allana>And I have seen on reddit a similar issue where they say there is a problem with the recent glibc <allana>Hopefully it's not against policy to share a link to reddit. if so, I apologize <leoprikler>According to this thread, we'd have to apply some upstream chromium patch. <pkill9>does there exist an overlayfs that can be created by unprivileged users? <leoprikler>does Guix offer mechanisms to repackage static libraries as dynamic ones or are we lost? <civodul>mothacehe: hi! could you add wip-build-systems-gexp, "core" subset, on ci.guix? <civodul>looks like the /admin web interface is empty now and i have yet to translate my cuirass/sql knowledge to pg :-) <jlicht>kozo[m]: FWIW, I ran your guix environment command and it reported "Operation not permitted" on linux-libre 4.14.223, guix @ c4195a10783 <leoprikler>And the Turing award for "most confusing error message" goes to… zig! <jlicht>leoprikler: meh, I think guix will be a strong contender for the forseeable future though :-) <leoprikler>Guix at least gives you stack traces, so you'll have a vague idea where stuff might be going wrong. <leoprikler>zig just prints "Access denied" like modern day ed. <daphnis>how should one install a firmware package? (not using guix system) <jlicht>daphnis: what do you mean when you say firmware package? And install it where? <pkill9>it seems pipes work between containers, woop <edgarvincent>Is it possible to receive notifications related to a given issue by email? <leoprikler>you can subscribe to the ML, but then you'll get everything <leoprikler>if it's something you submitted or contributed to, people will quite likely CC you <efraim>IIRC gnu's version of debbugs doesn't have per-issue subscriptions like debian's does <edgarvincent>Thanks. I was thinking about issues/patches I do not participate in but would like to be notified about. Doesn't debbugs support that? <civodul>uh, graphviz depends on guile@2.0, maybe not very useful? <zimoun>“make release” leads to this error «convert-im6.q16: not authorized `doc/images/coreutils-size-map.eps-tmp.eps' @ error/constitute.c/WriteImage/1037.». Something I miss? <efraim>I got stopped at: make[3]: *** No rule to make target 'po/doc/guix-manual.pot', needed by 'distdir-am'. Stop. <zimoun>efraim: yes, master. You first need “make doc-po-update” <jlicht>it also prevents me from using ropta_t (no ping) Android Studio workaround, so that's why I ran into it today <avalenn>I wonder waht is "build systems on gexps" that cidovul talked about some time ago. <daphnis>jlicht: on the system. there's a package (openfwwf-firmware) i'm hoping might fix a wireless issue, but i don't think installing it for a user will do anything. <koleesch>hello, is it possible to install non-free software to guix, e.g. wlan drivers or codecs? <jeko>I have a custom package definition and I would like to create an environment with this package included. is there a way to do so? ***stikonas_ is now known as stikonas
<ison>jeko: There's lots of options for that. But assuming your package is just a single file the easiest way is just "guix environment --ad-hoc -l <your_file>.scm" <leoprikler>koleesch: w.r.t. your question earlier, it's technically possible, but we can't in good conscience tell you (how) to do it <koleesch>leoprikler: thx. jonsger told me it is possible. i understood your conscience. But i use old hardware and i want to run guix on it. <nckx>Oh, I missed that question. Wasn't ignoring you, koleesch! We believe that non-free software is harmful, and don't believe in harming (or helping to harm) people in our IRC channel or mailing lists. <alextee[m]>does guix use some kind of established standard for its commit message format? <nckx>alextee[m]: Very much so. It's based on the GNU ChangeLog format with our own culture/traditions on top. <nckx>See (guix)Submitting Patches, although the linked ‘standards’ manual isn't available for me. I don't know which package provides it. <alextee[m]>thanks! considering doing something similar for my projects too <nckx>alextee[m]: Those aren't our rules, although I try to stick to the 50/72 rule. Others don't. <nckx>‘imperative mood’ same: I use it but I've noticed some people (civodul) sometimes use ‘foo barbalates’ instead of ‘make foo barbalate’. <nckx>leoprikler: Subject 50 chars max, body wraps at 72 e-mail stylee. <nckx>I guess the 50 is an allowance for ‘appending crap like [PATCH v1/54]’. <nckx>‘The subject line should be capitalized’ → no. <alextee[m]>how do you handle merges then? do you never do merge commits? only rebase? <alextee[m]>you have to press a whole extra key to capitalize things! <nckx>alextee[m]: We always rebase (including wip-branches), with exception of master - staging - core-updates merges. <nckx>alextee[m]: You must be some kind of wizard, I have to press caps lock at least twice for that. <nckx>And sometimes it gets out of sync and I have to reboot :( <nckx>I see you've met my father. <mothacehe> civodul: just added the wip-build-systems-gexp branch! <Artemix>I was wondering about something... say I have a pretty long configuration that I would like to version / attach to my system config.scm, where should I usually store it? A subdirectory in /etc ? <roptat>Artemix, personally, I have a git repository with all my config, and I store it in /root <nckx>Artemix: It's entirely up to you. I put my entire Guix System configuration in /etc/guix, with my system.scm in a /etc/guix git repository along with about 20 other configuration files (I dislike writing them in Scheme). <nckx>Guix doesn't have an opinion. <Artemix>I think that making a versioned /etc/guix with all my scheme/txt config would fit my way of working, I'll try that <roptat>that's all my systems, so there's more than one os config <roptat>I put some of the common stuff in modules/, and I load them with -L on reconfigure <Artemix>since I'm using guix server-side for now (static website hosting VM), I'm thinking about packaging the websites as guix packages, that could work well <roptat>we do something slightly different for the guix website <Artemix>I haven't gotten a hang of packaging yet, I should get back into the manual. <roptat>basically, it's a cron job that periodically pulls the repo, build the website to the store, and symlinks a known directory to the result <Artemix>My memories of packaging are .tar.gz/.deb level for now (ie building a release version, zipping it, and putting it on a mirror), I find it simpler and pretty cool to avoid installing build-only tools on my prod systems <Artemix>I was originally thinking about making a small guix package mirror for the same deployment model <nckx>Noisytoot: I'll take a look! Tip for next time: please use the ‘-v’ option to git to make it clear which patch is newest and should be applied. <nckx>It will show up as, e.g., [PATCH v2] in the subject. <nckx>I think all (most?) patch-related commands take the option. <nckx>Indeed: git format-patch as well. *nckx AFK but patch LGTM and will push after building. <Noisytoot>Why does markup.scm not use the license: prefix for licenses like everything else? <nckx>Because there's no need for it yet. <nckx>There are no conflicts (e.g., [package] zlib vs. license:zlib). <nckx>We sometimes use #:prefix license: ‘just because’ but it's not universal [yet, maybe, some day, perhaps]. <Artemix>ok, gonna spend some time playing with packaging, cya <koleesch>when are the newest gnome packages available? <lfam>koleesch: There's no ETA on newer GNOME <pkill9>is it possible to pass the `guix environment` command a previously built guix profile? <pkill9>so this would mean not needing to rebuilt it I think <roptat>safinaskar2, I think you can get more than just gnu software :) <safinaskar2>roptat: is it possible to have self-contained install entirely of gnu packages <roptat>for the base system, I think you can get a running system with only gnu stuff, though some build dependencies for the bootstrap include non-gnu stuff <roptat>well, you could test by building a bare-bones hurd system and checking "guix graph" <roptat>(or "guix size", which has less output) <roptat>it will give you the list of runtime dependencies in the system, and exclude those build-only deps I'm refering to <safinaskar2>so, we already passed the point when we can create gnu-only install? was this specially announced? <lfam>It's not clear what is "GNU only" <roptat>also, if you want to rely only on gnu software, you can't use dhcp (ISC, not GNU), you'd probably have to remove some of the base services, ... <safinaskar2>lfam: install consisting only of packages from gnu.org/s/... <lfam>Hm. It will be lacking many many things <lfam>In my experience, GNU considers the "GNU system" to be whatever free software it chooses to use. There is not a clear distinction between things distributed on gnu.org or elsewhere <roptat>not sure it's worth announcing ^^ <lfam>The home page of gnu.org says "The GNU operating system consists of GNU packages (programs specifically released by the GNU Project) as well as free software released by third parties." <lfam>I think that the strategy of GNU does not mean that every program has to come from GNU <lfam>It would be interesting to create a system that was all GNU and see what it could do <leoprikler>Plot twist, you'd still have a fully functioning operating system (Emacs). <nckx>Sign me up for Emacs on bare metal 👍 <lfam>leoprikler: What about Emacs dependencies? <lfam>Few of them are from GNU <leoprikler>Just trust my statically compiled blob, it'll work. <leoprikler>(For emacs-minimal, only pkg-config seems to be the issue) <lfam>There are also non-GNU dependencies via gnu-build-system <lfam>Check %final-inputs in gnu/packages/commencement.scm <lfam>Namely, xz and file, if not others <leoprikler>you could potentially just use gzip instead of xz tho <nckx>lfam: I wonder if we'd get there by defining ‘GNU’ == GPL... It's ‘the’ GNU licence after all. <nckx>That would swallow xz, at least. Mmm, viral. <nckx>(And yet expanding it to ‘BSD stuff we can also redistribute as GPL’ feels hella cheaty. Weird.) <lfam>The whole premise is somewhat arbitrary, since even GNU doesn't claim to have developed a full OS on its own <roptat>right, it's actually GNU/xz/file/Linux ;) <nckx>Oh, this whole conversation is somewhat arbitrary. Where's the fun otherwise. <lfam>Well, the GNU software *is* somewhat foundational <lfam>glibc, coreutils, GCC, make, etc <lfam>When you add a kernel, you have something that works <lfam>Well, xz is a relatively new invention, likely developed on pre-xz GNU/Linux <lfam>File is just its own weird thing <lfam>My point was that GNU + Linux gives you something that boots and could be used to "start over", in terms of OS development <lfam>But, linux-libre depends on Python, and upstream Linux likely has other dependencies too <lfam>I would point out the 'gnu/packages/patches/openssl-1.1-c-rehash-in.patch' patch <lfam>A crucial but perhaps forgotten workaround <apteryx>is there a way to create a symlink in a container created with 'guix environment -C', so that coreutils' bin/env be available as /usr/bin/env in the container? <apteryx>lfam: linux libre doesn't actually depend on Python <apteryx>because of its fast start time (as stated in the sources) <apteryx>it also supports perl or awk and I think another one <apteryx>we could add Guile support for the fun hack <apteryx>it could be used as a Guile regex benchmarking tool ;-) <shcv>how hard would it be to make a user-local daemonless guix for foreign distro use without root access? <nckx>‘sysctl-explorer.net.’ ‘...huh.’ <apteryx>lfam: by the way, sorry for not having yet taken the time to look at your QEMU patch; the Go stuff has been taking its toll on my evenings <dannym>pjotrp[m]1: Hmm... are you still using the non-root guix? I tried proot right now and I get a cryptic error message <nckx>Does anyone know off the top of yer heads which graphics driver (module name) a standard ‘guix system vm’ uses? It would save me an hour building one and I'd be super obliged. <dongcarl>Hi all, I want to check if `guix` can find a `guix-daemon`, this check will run in a script. What would be the best Guix invocation for this? <vagrantc>wow, no idea guix-daemon could be running remotely <dongcarl>vagrantc: Right. I want to check if `guix` can reach a `guix-daemon`, but in a script so hopefully no building a package <dongcarl>Also in a way that respects GUIX_DAEMON_SOCKET and such <cbaines>maybe guix repl could be used to run some Guile code to check <cbaines>I wonder if a command like guix gc --list-failures might also work as a quick test <dongcarl>cbaines: True! Any modules/procedures I should look at? <shcv>or `guix processes`, and check the error status <dongcarl>shcv: Unfortunately `guix processes` does not fail if guix-daemon is not running, it just outputs nothing (error status =0) <rekado>dongcarl: (import (guix store)) (open-connection) <rekado>dongcarl: this works on our HPC cluster which does not have a local daemon <rekado>(GUIX_DAEMON_SOCKET is set to a remote location) <dongcarl>Does it return an error code if things aren't working? <cbaines>I think open-connection should raise an exception, but since you're running arbitrary Guile code, you should be able to do what you want <rekado>it raises an exception otherwise <rekado>so (begin (import (guix store)) (or (false-if-exception (open-connection)) 'oh-no)) <cbaines>maybe there could be a Guix script that connects to the daemon and outputs some info <cbaines>someone would just have to come up with a meaningful name... <dongcarl>Would also be useful to fetch number of build users <shcv>or there could be a whole set of `guix daemon` commands; I don't know what other controls you might need though <dongcarl>rekado: Oh! Do I need to close the connection or will guile know to do so automagically? <rekado>dongcarl: I guess it closes the handle automatically, but if you want to be explicit about it you could just do (close-connection (open-connection)) <dongcarl>shcv: If I end up needing more than 3 things... I'll write a patch :-) <pkill9>how do you build a profile in guile? <pkill9>hmm I have a simpler way around this <pkill9>actually no, i need to generate aprofile in the store <cbaines>I think (guix profiles) is the relevant module to look in <pkill9>actually i don't need to build the profile immediately <pkill9>can i use a profile as an input to a package? <cbaines>I don't think the code for constructing package derivations supports that, I could be wrong though <cbaines>given a profile is just a store item, there's nothing preventing that in principle though <cbaines>how come you want to have a profile as an input to a package? <pkill9>i only need the path to the profile in the store (and to prevent it being garbage collected) <pkill9>I'm making a script that generates scripts that run guix containers with those profiles <pkill9>and i will collect all those scripts into another single profile <cbaines>I don't really follow, but using g-exps, might offer more flexibility <pkill9>but those initial profiles I want to be gneerated <pkill9>i don't know if gexps would be treated as profile by guix environment <pkill9>yea, a profile has search paths as well <lfam>apteryx: Don't worry about it. I think you should focus on the thing that's on your mind <pkill9>i'm gonna do this outside the store firs <pkill9>how do i use functions that take a 'store' variable in scripts/