<apteryx>I'm guessing there's some policy bit involved that I'm blind to <rekado_>apteryx: no route to host. Could be that the network interface isn’t connected to the right switch <oriansj>rekado_: have an amazing time, don't spend 1 second thinking about anything but having a great time <johnjaye>hmm. i wonder what build deps guile itself has. is it a lot? <johnjaye>the github page just says libgc, mp, ffi, unistring. <Zambyte>johnjaye: this expression gave me the list of all transitive dependencies required for building guile `(cdr (cadadr (manifest->code (package->development-manifest guile-3.0))))` <Zambyte>This is the list `("pkg-config" "libffi" "bash-minimal" "libunistring" "libgc" "tar" "gzip" "bzip2" "xz" "file" "diffutils" "patch" "findutils" "gawk" "sed" "grep" "coreutils" "make" "bash-minimal" "ld-wrapper" "binutils" "gcc" "glibc" "glibc:static" "glibc-utf8-locales" "linux-libre-headers")` <Zambyte>There probably is an easier way to get that :D <apteryx>rekado_: thanks, and have an enjoyable time off work :-) <gabber>rekado_: thanks, cool! i'll take notice and do better next time :) <VIVelev>Hi! Are there any GUIX ISOs for aarch64? I am trying to run GUIX on a VM on my M1 mac. <zamfofex>I don’t think so, then. I could try to cross‐build one for you, but it might take a while. <zamfofex>If you’re using a VM anyway, is there anything that prevents you from using x86‐64? <VIVelev>My M1 and the fact that I want to use Parallels Desktop, which does not support emulation. <johnjaye>VIVelev: i've used an M1 a bit. tried to get some emulation working on it but only got qemu. <johnjaye>parallels is basically like virtualbox right, it's virtualization so only aarch64? <VIVelev>So I suspect UTM will work too? (Since it's QEMU underneath) <VIVelev>Yes, parallels supports only virtualization. <VIVelev>Are there any plans to make official ISOs for aarch64? <VIVelev>I mean ones that you can just download from guix.gnu.org/en/download <zamfofex>VIVelev: An alternative could be to use ‘guix system init’ manually, I think. <johnjaye>i think a lot of the bootstrapping stuff in guix is x86 only <johnjaye>i don't totally understand how it works. something about a mes compiler that compiles scheme and scheme compiles it <zamfofex>johnjaye: I think the full source bootstrapping is available only for x86(‐64), but that doesn’t impede Guix from supporting other platforms. <unmatched-paren>GNU mes only supports x86 32-bit, so we have to run the bootstrap up to gcc there, but once we have gcc we can cross compile whereever we like <johnjaye>i don't understand. i thought the bootstrap was one of the central goals of guix <zamfofex>It feels more likely people would want Aarch64 than the currently available i686 images. <VIVelev>Thanks for the help guys! I will play with guix in utm for a start and see how it goes from there. <zamfofex>VIVelev: I hope you can have fun playing around with it! <VIVelev>When Scheme is involved, there is always fun :) <unmatched-paren>johnjaye: the only component that doesn't work on aarch64 is mes/mescc afaik <johnjaye>VIVelev: let me know how well it goes, i've been avoiding my M1 for awhile but would like an excuse to use it. the screen rocks <unmatched-paren>so if we get that working, we can have a full source bootstrap for aarch64 <zamfofex>unmatched-paren: You mean people running on actual non‐AMD64 x86 CPUs, or people who prefer to use i686 for some reason? <unmatched-paren>e.g. I think GNUtoo might still be running an x86 CPU (they're not here at the moment though) <johnjaye>unmatched-paren: are they both in asm correct? <zamfofex>johnjaye: I think ‘mescc’ is written in Scheme and ‘mes’ is written in C. <unmatched-paren>johnjaye: no, mes is a scheme interpreter written in a subset of C (we can run it on m2-planet using the mes-m2 fork) and MesCC is a C compiler written in C <johnjaye>so scheme->asm compile in C and C-asm compiler in C <unmatched-paren>for obvious reasons we want to use a portable/highish-level language fairly quickly <johnjaye>it gets confusing when you have the build language the host language and the target language <zamfofex>johnjaye: Note that MesCC is written in Scheme, not C. <zamfofex>From what I understand, Mes is written in a smaller subset of C than MesCC supports. So that it can be bootstrapped from a simpler C compiler, then used to run MesCC to compile programs that aren’t written in such a subset. <zamfofex>Can’t Mes be rewritten to fit current M2? <janneke>unmatched-paren: that's been resolved with the mes 0.24 release <janneke>on core-updates, mes is bootstrapped from m2-planet <zamfofex>Also: Is there any reason there needs to be a C *compiler* early on, rather than a C *interpreter*? It could be made into a simple wrapper that simply embeds the source code in the generated output file (which could be a shebang executable) then interprets it. <zamfofex>This interpreter could replace the role of MesCC, being written in Mes Scheme, for example. <unmatched-paren>A C interpreter running on the Mes interpreter might be a little slow :) <zamfofex>I suppose so. 🤔 But does that matter? It’d be only used that way for bootstrapping. <zamfofex>What features of C89 does M2 not support? Are there any meaningful unsupported language features, or does it come down only to unsupported library functions? <johnjaye>ah idk about m2planet but gnu mes has a giant manual. i guess i'll have to read it to understand guix <unmatched-paren>the bootstrap is ultimately independent of guix (see #bootstrappable and bootstrappable.org <zimoun>sneek later tell civodul: the recent update a couple of days ago to manifest at version 4 leads to a severe bug: it breaks the time-machine; it means once pulled, it becomes impossible to go back. See https://issues.guix.gnu.org/56441 <unmatched-paren>We would use the time-machine to stop us from introducing the bug in the first place, but... <jpoiret>i know it's a big commitment but instead of band-aiding some breakage every couple of guix updates, we should really rethink how the different guix versions interact <sneek>Welcome back civodul, you have 2 messages! <sneek>civodul, zimoun says: the recent update a couple of days ago to manifest at version 4 leads to a severe bug: it breaks the time-machine; it means once pulled, it becomes impossible to go back. See https://issues.guix.gnu.org/56441 <zamfofex>jpoiret: Ough this not to be resolved by thorough tests? Or am I missing something foundational? <jpoiret>zamfofex: they'd need to be very thorough, and in a local dev setup it's quite hard to do <jpoiret>I just realized I forgot to add one paragraph about an example case where it's really hard to test <jpoiret>the thing is, not everyone will test their patchsets against all combinations of guix pull, guix time-machine, upgraded guix package, etc. <zamfofex>Would it be unreasonable to have ‘guix pull’ optionally (though by default) only work if there is a substitute? Then, if something breaks in a commit, at least ‘guix pull’ wouldn’t be affected. <jpoiret>well, i don't think it'd be reasonable with the way it works now, as computing the derivation already takes a long time <jpoiret>and if once you have the derivation, you realize there are no substitutes, and you try another commit or error out, it'll be terrible UX <jpoiret>and, I think the thing to avoid in the first place would be to merge commits that introduce errors <jpoiret>the point of my point was rather that we should end up with a solution that makes everyone more confident about the patchsets they merge <jpoiret>(ie. you don't have to worry about the dozen internal subtleties that interact with each other at the level of building guix) <jpoiret>"it builds once on my setup so it builds the same in all contexts" should be something we can rely on <zimoun>jpoiret, I agree. To me, the only pragmatical fix with the resource we have is to decouple where devs push and where users fetch. Currently, both are master. <zimoun>And we could have master for devs, and main for users; where main is lagging by 7 days from master – 7 days, the mean time for build farm to build and time for dev to fix. <jpoiret>zimoun: i don't think that would even resolve much! Few people (mainly maintainers) test the other branches before big merges, and if we had a 'dev' tag, developers wouldn't test more, and the bugs would just appear with a delay <jpoiret>many of these bugs are not discovered by CI <zimoun>Well, cbaines proposed something similar long time ago; decouple what is “production” to what is “testing”. Today, we “test” directly with the “production”. For sure, sometimes the tests fail. ;-) <jpoiret>i think with `guix pull` generations and particular commit pinning for channels we should keep the 'move fast and break things' approach, but users should be made more aware of these options <jpoiret>even I forget that you can rollback the guix pull generations <zimoun>No, for you, it would change nothing, you would still use what I named master. However, people wanting more “stability”, they would use “main”. <jpoiret>what I'm advocating is not really directly about stability of master, but rather of a way to reduce the possible bug sources to a minimum <zimoun>I do not think rollback is an acceptable fix. I have many examples where the generations had been GC before discovering an issue. <jpoiret>i never gc my guix pull generations because i simply forget <zimoun>to me, stability is about less possible bugs. ;-) <zimoun>As I said, I am not aware of any complex system that makes their test directly in production. It is the Guix workflow though. :-) <zamfofex>Would it be unreasonable to want pinned minor versions? E.g. consider “Guix 1.4.0” then “Guix 1.4.1” then … then “Guix 1.4.87”, etc. Or conversely to waive the concept of versioning for Guix. <zimoun>zamfofex: I think it is too much work compared to the manpower the project has at hand. <jpoiret>zamfofex: well, versioning is already a bit useless in Guix. 1.3 for example only matters when installing <jpoiret>other than that, there's no difference between 1.3 and any other commit <zamfofex>zimoun: Would it really take more than just merely labelling the commits as such? <zimoun>zamfofex: If it is just labelling with tests it work, then it is just the same I propose with the branch main lagging back from master. :-) <zamfofex>jpoiret: I suppose. I meant that I feel like it’d give a reason for Guix to abide to versioning at all, since then versions would be something that actually matters to users. <zamfofex>zimoun: Yeah, that’s exactly what I meant, but just in order to justify having versions at all. <zimoun>unmatched-paren: no, the fixes imply a version/tag bump – although I think tagging would be useless. ;-) <jpoiret>my opinion is that we should take the big machine with hundreds of interlocking cogs of various sizes and shapes, and replace it with one with 2 identical cogs <jpoiret>we just have to decide on the right cog shape and create it <zamfofex>I was just thinking out loud, by the way. It’s just strange that as it is, versioning has no big role in Guix. It feels like it either should be given a significance, or abandoned in favor of fully adopting the “rolling release” model. <jpoiret>the only 3 pros of having point releases i see right now are: stability of installer (ideally, it should follow the same model as the rest of guix, so we should expect it to be stable at any given time), announcements of new features/big bug fixes and being able to advertise them <jpoiret>wrt the installer, imo the latest installer is way more stable than the 1.3 one right now, even though there are still a couple of issue <jpoiret>but yeah, if you look at other rolling release distros, they don't have versioning at all <jpoiret>right, and it's pretty useful, you don't want to sift through git log just to find roughly when the feature was introduced <zimoun>jpoiret: to me, the main point of Guix release is about communication and announcements; because it appears on LWN and elsewhere. <zimoun>One of the issue is that we do not have the manpower to release often, say twice a year. Similarly as core-updates merge BTW. <cbaines>hopefully that situation will improve if we can do more continuous quality assurance <zimoun>Yeah, but in the meantime, we should improve the current workflow. <zimoun>Both are not opposite but complementary, IMHO :-) <cbaines>I think improving the workflow is how we get to doing more continuous quality assurance <zimoun>Moreover, using Guix in production in my lab, one of the main drawback is the lack of predictibility of “guix pull”; for instance, after a recent “guix pull”, most of the Julia packages were lacking. So it is painful (rollback, time-machine elsewhere, etc.). <zimoun>About workflow, I mean: where patches are pushed and where users pull. <zimoun>It is not possible to have a continuous quality following the current rate of commits. <cbaines>zimoun, I'm hoping very soon to start building packages from patches on bordeaux.guix.gnu.org, which should be a step towards both avoiding breaking things, and ensuring substitute availability when changes are merged <zimoun>cbaines: I agree and I am very thankful about all ths tough work. I remember the first time we met, back on Dec. 2018, you were already busy with this work. I mean, despite all the hard work over the years, we are not there, so maybe it means CI is not enough to fix all the isssues we are discussing. Well, I do not really know. Hard topic. :-) <cbaines>zimoun, I'd like to believe that it's taking so long as I'm not able to put that much time in, rather than a problem with the approach <cbaines>another reason why it's taking so long is that I'm flip flopping between doing things quickly, and doing things properly. Packages from patches were being built in the past, but since then, I've been putting time in to setting up bordeaux.guix.gnu.org, wrangling hardware and writing the nar-herder <zimoun>cbaines: yes, I totally agree. And you already made hard (under-the-hood-) work as Data Service, instance of Patchwork, etc. Somehow, my point is: I think that the manpower and resource is a parameter to find the implementation that works for the project. <zimoun>cbaines: No blame! :-) It is not your responsabilty but a collective one. <cbaines>hopefully some of these investments will start to be realised soon, as all of this stuff should start to come back to benefit testing patches <cbaines>on top of the value it has for substitute availability for example <roptat[m]>if you pull from two weeks aho, you get the issues from two weeks ago, so you should have exactly the same probability to have issues with master and pulling from two weeks before <roptat[m]>unless the number of issues is constantly increasing ;) <cbaines>I think the theory here is that other people are hitting and fixing issues within that 2 week period <cbaines>actually... I see your point, you're delaying getting the issues, but also delaying getting the fixes ***califax_ is now known as califax
<roptat[m]>right. at least you're more likely to get substitutes ***califax_ is now known as califax
<bost>Hi. It looks like 'guix home reconfigure' keeps on adding fish-shell abbreviations instead of recreating them. IOW 'guix home roll-back' and/or 'guix home switch-generation' don't correctly restore the previous / desired state. <bost>Can somebody test it please? <necrophcodr[m]>Does Guix have a built-in Nix Flakes alternative that I'm not aware of? Or is there a smart way of defining an environment akin to what a Nix Flake would contain? It doesn't have to be as expansive as flakes, of course, as I'm very much mostly looking for an easy way to setup a development environment for easy reprodicibility, that goes beyond simply defining a package manifest or a list of packages. <civodul>necrophcodr[m]: hi! to reproduce your environment, you'd capture the channels in use with "guix describe -f channels" <civodul>and then you'd pass that to "guix time-machine" <civodul>it's not the same approach as Flakes <civodul>bost: hi! it may be a bug with the fish service; could email details about the issue to bug-guix@gnu.org? <civodul>if you'd like to figure out why it misbehaves, you can run "guix home edit home-fish" and start from there <bost>civodul: Sure. I just wanted to have somebody quickly try it out before I write bug report and realize it's a PEBKAC. <necrophcodr[m]>I suppose time-machine would indeed suffice for my use cases, so thanks! <bost>civodul: I tried to debug it a bit already. To me it looks like as if the fish would internally store the abbreviations somewhere, ugh. <civodul>bost: fun; i don't use fish so i can't really tell if it's PEBKAC, but it doesn't look like it <bost>unmatched-paren: Thanks, interesting. I'll have a deeper look later. <apteryx>civodul: hello! do you know if it would be possible to publish our packages.json file via Tor? <apteryx>is there a command line tool for fetching files from Tor? <bost>civodul: I think I'll write a bug report. (Thanks for helping me out so far) <civodul>apteryx: the interesting thing is that repology get others to work for them :-) <apteryx>all traffic to guix.gnu.org (MDC host) is blocked from Russia, so there's little they can do short of hosting their stuff outside of Russia <apteryx>civodul: what do you mean by "both routes go to ci.guix.gnu.org" ? <sk>I'm having trouble getting exwm to load/merge my `~/.Xresources` (or execute `~/.xinitrc` or `~/.xprofile`). For xfce, it's quite simple as `startxcfe4` calls the included `etc/xdg/xfce4/xinitrc`, which runs `xrdb -merge` on, among others, `~/.Xresources`. <apteryx>sk: I'm guessing exwm must have its own rc file? <sk>apteryx: `exwm.desktop` calls `emacs-exwm-package/bin/exwm`, which runs `xhost-package/bin/xhost +SI:localuser:$USER` and then `dbus-package/bin/dbus-launch [...] emacs-package/bin/emacs [...]`. Did you mean these by rc file? <apteryx>OK. I don't know exwm; I run ratpoison and it uses an ~/.ratpoisonrc file; but in my case I do not need to be X-related stuff in that file, as it honors .xsession <sk>Either I'm not getting the whole picture or `emacs-exwm-package/bin/exwm` should also check for `~/.Xresources` and run `xrdb -merge` if the file exists <sk>Ah ok, I tried with .xsession, but then GDM just ran that and didn't continue with exwm.desktop <apteryx>I think at the end of .xsession if you 'exec exwm' it should launch it <apteryx>at least that's what happens for ratpoison <apteryx>even when choosing GNOME as the session type in GDM, if I have that in my .xsession, ratpoison is run *apteryx is a total Tor newbie <cbaines>apteryx, there was some plan to host the guix website on bayfront <sk>apteryx: Ok, then it's the same. Does the `.xsession` simply find the binary `exwm` or do I need to take care about the `gnu/store/XYZ-emacs-exwm/bin`-path? <apteryx>sk: if it's part of your operating-system packages list, it'll find in from PATH <sk>apteryx: Thanks, that'll do as a workaround. I might need to find some alternative though, as I sometimes need to switch to other WM/DEs <apteryx>sk: I'd be interested in your findings if you find a better way :-) <apteryx>cbaines: thanks! perhaps this can do for now <apteryx>hmm, what is the Host header useful for? <cbaines>guix.gnu.org doesn't resolve to bayfront, so that wget command queries the machine at bayfront.guix.gnu.org, but the HTTP Host header tells nginx that the request relates to guix.gnu.org <cbaines>otherwise nginx would use the configuration for bayfront.guix.gnu.org, and respond with a 404 <ZhuAisi[m]>Hi, does Guix channel authorization supports commits signed by NIST P-384? <apteryx>sk I think I had issues with "$1" in the past, but perhaps they're no more :-) <ric342[m]>civodul: the tor substitutes in the cookbook didn't work for me <sk>apteryx: `exec "$1"` at the end of the `.xsession` worked like a charm. Thanks :) <apteryx>great! I'll update my personal copy too, thanks for the update <apteryx>actually, I'm using slim as my login manager, so perhaps it's not passing the session name as arg 1 <abrenon>I'm getting errors on packages using the ocaml-build-system during the build phase: the ocamlbuild executable is missing <abrenon>isn't it included by default in ocaml-build-system compilation environments ? <abrenon>I can fix it by adding ocamlbuild in the (native-input …) list but should it really be necessary ? <abrenon>so do package using ocaml-build-system actually leverage dune ? <abrenon>I imported a package and got a package named ocaml-dune-configurator added to the propagated-inputs <unmatched-paren>abrenon: I'm not sure what ocaml-build-system does; it's dune-build-system that uses dune <abrenon>I was looking at the dune.scm build system <johnjaye>how does guix isolate all these build systems anyway <abrenon>it's as bad as it seemed from a distance : ) <abrenon>I know they happen without network, so I'd guess containers maybe ? <unmatched-paren>you've still got the same view of the filesystem, just most of it isn't shared to the container so it isn't visible <abrenon>yeah, the path displayed in the error messages is consistent with the folder left when used with -K <abrenon>wait what ?! now the last package of the series runs ocamlbuild for build, I forgot to add it to the native-inputs, and yet it runs somehow <abrenon>doesn't that smell like leaky propagated-inputs ? <abrenon>no, it's not in (propagated-inputs …)of any dependencies of my package <abrenon>oh, or a dep that was already present in guix <abrenon>is there a quick way to check the deps tree of a guix package ? <abrenon>ahhh there had to be one way of doing it <abrenon>I just want to grep, basically so : ) I'll simply add coreutils to my guix shell <unmatched-paren>abrenon: Well, I'm doing something which you might find helpful, should be ready soonish <unmatched-paren>it lists them in an order such that a package never appears before one of its dependencies <abrenon>I guess I should still add ocamlbuild to the native-inputs, because it's just a "happy coincidence" that it gets included from ocaml-migrate-parsetree <unmatched-paren>(this is why i was trying to add support for extension-paths in channels...) <abrenon>oh, so, bottom-up traversal of the deps tree ? <unmatched-paren>but i was trying to add support for listing such paths in a .guix-channel file <abrenon>"mkdir -p /usr/local/…" : haha, good one, installer <rekado_>unmatched-paren: what’s the obstacle? <unmatched-paren>Seems like there's more moving parts with the Guix build than I expected. <unmatched-paren>I can't just import a module from another module in the same directory and expect it to work, apparently :) <unmatched-paren>Hmm, is it okay to license my extension under AGPL-3.0-only or does that conflict with Guix's license? <acrow>vagrantc: I did not know that patch files had licensing. Maybe I should save that for last. <sneek>acrow, trevdev says: Oh it absolutely works. Part of what I like about guix is that it is portable. I am on Guix System now. If there were any reason for me not to be, I have my config :) I just feel challenged by learning the packaging, mostly. <abrenon>I never know how to pick the right license for the stuff I write <unmatched-paren>I usually use AGPL-3.0-only for software and CC-BY-SA-4.0 for docs/data <unmatched-paren>but in this case i think it might not be possible to use AGPL-3.0-only <abrenon>yeah, because of the "contamination" of GPL ? <unmatched-paren>also i think restricting to one version would count as 'more restrictive' <two[m]>i installed some programs with guix install <two[m]>oh i'm sorry, after guix updated they do <two[m]>thank you very much for making this this is awesome software <roptat[m]>not sure about agpl, but in gpl3 or later, it means you can chose gpl3 or you can chose a later version. so you car restrict to gpl3 only when you redistribute it yourself <abrenon>has the way of setting make-flags changed in the course of this year ? <unmatched-paren>abrenon: make-flags are usually set with #:make-flags #~(list ...), aren't they? <roptat[m]>it doesn't mean gpl3 and gpl4, it really is gpl3 or gpl4, whichever is most convenient to you <abrenon>I tried re-using an old snippet I had in a file somewhere to pass PREFIX set to (assoc-ref %outputs "out") <abrenon>unmatched-paren: yeah, I've seen a huge number of new examples using gexps <abrenon>but I'm still trying to post-mortem to understand what works and what doesn't and why <rekado_>the whole gpl2 + gpl3 debacle convinced me that the upgrade clause should have been the default <roptat[m]>the syntax changed to ase gexps a few months ago, though the old syx is still valid <abrenon>because I've found the hevea package which apparently still doesn't use gexps but still builds ?! <rekado_>it is very unfortunate when you can’t combine two pieces of free software, both under the GPL, just because one doesn’t allow upgrading. <abrenon>it uses %output directly, instead of a call to assoc-ref <abrenon>but when I do that it yields error messages I cannot understand listing packages as "unbound variables" <rekado_>but it’s not impossible that gpl4 exists in the future, and then we’d be having a hard time building a system that fully uses gpl4 <abrenon>yeah, I just wanted to make my point clear before <abrenon>because there'll be several pastes since there are several scenarios <roptat[m]>the whole unbound variables usually happens after a syntax error. you have to find the first error in the list <roptat[m]>it's usually one line above what you think the first line is :p <abrenon> http://ix.io/41XZ contains the package definition using the same syntax to set make-flags as hevea which manages to build <rekado_>you use backticks in your modify-phases expression <roptat[m]>missing a ) at the end of the #:make-flagsthink <abrenon>wow thanks for the general feedback ! <roptat[m]>like I said, I think you're missing exactly one line in the second paste <rekado_>proper indentation would really help hee <rekado_>on the (delete `check) line you’re closing the (arguments …) expression <rekado_>and then the #:make-flags thing comes out of nowhere <abrenon>that's funny because I usually never have these kind of errors, writing my definitions step by step and controling parenthesis and stuff as I go <abrenon>but this is an old attempt I unearth once a year, and I badly copy-pasted parts I had found here and there <abrenon>sorry for disturbing you for trivial errors like these <abrenon>I just wished the error messages provided would be more helpful, I really thought I had something big going on here <lilyp>The first rule in Lisp is you never type out the closing parens by hand. <lilyp>I still find it weird that nxml-mode doesn't insert closing tags. <abrenon>roptat[m]: I still don't understand your remark about the missing line in the error log <unmatched-paren>lilyp: Sadly Vim users sometimes don't have a choice... vim-paredit is, eh, rather unreliable. <abrenon>you mean the first one with a warning saying "invalid field specifier" ? retrospectively it makes sense, but there's no mention of #:make-flags as being the culprit <lilyp>Don't make me quote the zeroth rule of lisp :( <abrenon>so anyway why the new syntax ? since I should use gexps, I might as well try and understand what it does I suppose <roptat[m]>yes invalid specifier is the aetual error. because of unbalanced parenthesis, arguments ended up having 2 values *abrenon doesn't know the zeroth rule but probably wouldn't understand it anyway <abrenon>roptat[m]: ok, sorry about missing that one <abrenon>ok, fixing my dreadful copy-paste and trying the actual thing with the "hevea syntax" still has guix complaining about that unbound variable %output <abrenon>is it something specific to the gnu-build-system ? <abrenon>don't build systems have the same variables ? <abrenon>I don't see anything declaring that variable in hevea's declaration <abrenon>more precisely, I get http://ix.io/41Y5 (sorry for the long log but since I'm not able to figure out what's relevant and what isn't here, goes) <abrenon>except unmatched-paren's one: why shouldn't #:make-flags expect a list ? that's apparently what it does expect in hevea's definition <roptat>abrenon, no all build system's don't declare the same variables <roptat>%output is an old one that was removed from some build systems after gexp build systems were merge <abrenon>great : ) thanks for the explanation it makes sense <roptat>so it's still in gnu-build-system because all packages haven't been converted to use gexps, while ocaml-build-system doesn't have it anymore <roptat>unmatched-paren, I don't think so: the quote will be unquoted and copied to the derivation file <abrenon>it does a string-append and all so it gets evaluated <roptat>if it doesn't say "list", it'll be a procedure <abrenon>I was starting to doubt my understanding of the `/, tandem <abrenon>but then, since I pasted a ` without any need for check and configure flags without even batting an eye <roptat>unmatched-paren is technically correct in most contexts, just not for the staging that happens in guix packages <unmatched-paren>Was this kind of confusion/unintuitive behaviour one of the reasons for switching to gexp syntax? <abrenon>then it means I don't understand what is going on here : ( <chumpy>hey everyone. I'm trying to build a project and I'm not real sure of what I'm doing. The project is failing to build on a 'cc' command. I have gcc-toolchain installed. Do I need to link cc to gcc somehow? <abrenon>oh right, I had that once, yeah, gcc-toolchain doesn't provide a binary called cc <roptat>chumpy, gcc-toolchain doesn't provide a cc binary / link, usually you can be explicit and pass CC=gcc to the make flags or configure flags <abrenon>builds flawlessly, thank you everyone once again <roptat>I think it's because you don't have enough in #:modules <roptat>you overwrite the list of modules, so (guix build gnu-build-system) is not present, it's the one that defines gnu-build which is used in the build phases <roptat>you'll find examples of reusing the modules declared in gnu-build-system ;) <cbaines>unmatched-paren, strace is probably what you need to use to debug that <johnjaye>that question about if cc should be linked to gcc was somewhat disturbing to me <johnjaye>i guess a lot of the old unix programs though have become "socially constructed" in a sense. you can set it to any compatible program <rekado_>apteryx: on node 129 could you please run this as root: lldpd & and then lldpctl <rekado_>we’re interested in the output for eno3 <rekado_>then compare with the output on berlin (for eno4) <rekado_>this is to confirm that these interfaces are in fact connected to the correct switch <rekado_>I’m packaging python-lap, which uses cython. In the build output I see that compiler settings include -march=native and sse4 and all that stuff. <rekado_>but I don’t see any of this in the code of python-lap <rekado_>does anyone know how to control the compiler settings when cython is used? <rekado_>gabber: FYI: pushed your ack patches <rekado_>gabber: do you have more patches that await review? ***Dynom_ is now known as Guest7403
<chumpy>thanks for helping me earlier. I have another problem now. I need gdk-3.0. can that be found in the guix package repository? ***mark_ is now known as mjw
<unmatched-paren>rekado_: how does gwl register itself as a guix extension? i don't see anything special to do that in the gwl makefile or recipe, but my package that also installs an extension into $out/share/guix/extensions doesn't get registered <unmatched-paren>are you just supposed to set GUIX_EXTENSIONS_PATH manually until someone figures out automatic loading? <rekado_>unmatched-paren: yes, as I wrote before GUIX_EXTENSIONS_PATH must be set manually at this point <rekado_>apteryx: thanks. That looks like the wrong switch.