IRC channel logs


back to list of logs

<apteryx>I'm guessing there's some policy bit involved that I'm blind to
<johnjaye>policy bit? like a literal bit
<rekado_>apteryx: no route to host. Could be that the network interface isn’t connected to the right switch
<rekado_>I’ll ask my colleague to check
<rekado_>(I’ll be on vacation)
<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>26 total
<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 :)
<johnjaye>ah that's convenient
<VIVelev>Hi! Are there any GUIX ISOs for aarch64? I am trying to run GUIX on a VM on my M1 mac.
<zamfofex>VIVelev: I don’t think there is for latest Guix, but otherwise yes, it seems! <>
<zamfofex>Oh, wait, you mean Guix System?
<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
<johnjaye>yes i used UTM successfully
<johnjaye>homebrew not macports though
<johnjaye>honestly i have no idea.
<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>like the asm stuff
<unmatched-paren>we just cross-compile over to other archs once that's done though
<johnjaye>i don't totally understand how it works. something about a mes compiler that compiles scheme and scheme compiles it
<unmatched-paren>it doesn't really affect anything
<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
<unmatched-paren>sure, but it might not be ready for other platforms yet
<unmatched-paren>people _are_ working on it
<zamfofex>It feels more likely people would want Aarch64 than the currently available i686 images.
<unmatched-paren>there are several i686 users still :{
<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 :)
<johnjaye>hmm i see
<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
<unmatched-paren>but as you'd imagine, porting a c compiler is difficult :)
<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>zamfofex: the former, i think.
<unmatched-paren>e.g. I think GNUtoo might still be running an x86 CPU (they're not here at the moment though)
<zamfofex>I see. Well, fair enough, then.
<johnjaye>unmatched-paren: are they both in asm correct?
<johnjaye>x86 that is
<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
<unmatched-paren>s/compiler written in C/compiler written in Mes/
<unmatched-paren>only the very early things are asm
<johnjaye>so scheme->asm compile in C and C-asm compiler in C
<johnjaye>er C->asm
<unmatched-paren>for obvious reasons we want to use a portable/highish-level language fairly quickly
<unmatched-paren>johnjaye: nah, Mes doesn't compile
<unmatched-paren>it's just an interpreter
<johnjaye>it gets confusing when you have the build language the host language and the target language
<unmatched-paren>like Python
<zamfofex>johnjaye: Note that MesCC is written in Scheme, not C.
<zamfofex>And Mes can run it.
<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.
<unmatched-paren>But currently it's not simple enough for M2, so we have mes-m2
<unmatched-paren>it's going to be simplified until m2 can compile vanilla mes
<zamfofex>Can’t Mes be rewritten to fit current M2?
<janneke>unmatched-paren: that's been resolved with the mes 0.24 release
<unmatched-paren>janneke: Oh, nice, thanks for the correction :)
<janneke>otherwise, fully correct
<unmatched-paren>zamfofex: Well, apparently it has been :)
<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>That’d make it easier to port, I think.
<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 :)
<unmatched-paren>but were it written in M2, that would make sense I think?
<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?
<unmatched-paren>zamfofex: structs on the stack are a pretty big one
<unmatched-paren>and yeah, m2libc is pretty small
<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>johnjaye: no, you don't really :)
<unmatched-paren>only if you're interested in the bootstrap
<unmatched-paren>the bootstrap is ultimately independent of guix (see #bootstrappable and
<johnjaye>i see
<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
<sneek>Will do.
<rekado_>sneek: later tell civodul Here’s some WIP for fixing the time machine:
<sneek>Got it.
<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
<jpoiret>it'd ease local dev as well
<jpoiret>i'd love to see more discussion about that at
<civodul>Hello Guix!
<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
<sneek>civodul, rekado_ says: Here’s some WIP for fixing the time machine:
<unmatched-paren>civodul: hi!
<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.
<zamfofex>With appropriate tests, I mean.
<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
<zimoun>zamfofex: I do not know what ’substitute?’ means, if it is a substitute for a package or substitutes for “guix pull”. For “guix pull”, the fature already exists
<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>hmmm, right
<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?
<unmatched-paren>zamfofex: we'd have to backport fixes
<unmatched-paren>which would be pain
<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
<zimoun>yeah :-)
<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>issues *
<jpoiret>but yeah, if you look at other rolling release distros, they don't have versioning at all
<zamfofex>It took me a while to find it, but this reminds me of this issue: <> The summary is that people want something called “CSS 4” exclusively to have it serve as a milestone of progression.
<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, which should be a step towards both avoiding breaking things, and ensuring substitute availability when changes are merged
*civodul looks at, terrible
<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, 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
<zimoun>Neat! :-)
<zimoun>BTW, I am using a kind of workflow I am proposing, I guix pull with 2 weeks of delay from HEAD. Each time I just run “guix pull” against HEAD, I hit somehow issues. Maybe I am an unlucky guy. :-)
<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
<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
<unmatched-paren>bost: It seems like fish does behave weirdly sometimes:
<bost>unmatched-paren: Thanks, interesting. I'll have a deeper look later.
<unmatched-paren>why doesn't this work? in guix/ui.scm:
<unmatched-paren>sorry, actually guix/describe.scm:
<apteryx>civodul: hello! do you know if it would be possible to publish our packages.json file via Tor?
<civodul>apteryx: sure: it should be at https://r4mdnnhdof4jvbm6bucdjdqkrc5uxcjnttixi5ltczzpernlsz6xjuyd.onion/ or http://4zwzi66wwdaalbhgnix55ea3ab4pvvw66ll2ow53kjub6se4q2bclcyd.onion/ but currently both routes go to
<civodul>we need to fix our nginx config
<civodul>4wz* is documented at
<apteryx>is there a command line tool for fetching files from Tor?
<civodul>"torify wget ..." :-)
<apteryx>I'm trying to come up with a solution to
<bost>civodul: It seems like my impression "fish internally store the abbreviations somewhere" was right. Fish documentation says "Each abbreviation is stored in its own global or universal variable."
<bost>civodul: I think I'll write a bug report. (Thanks for helping me out so far)
<abrenon>hello guix
<civodul>hi abrenon!
<civodul>apteryx: the interesting thing is that repology get others to work for them :-)
<apteryx>all traffic to (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" ?
<sk>Hi all,
<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>civodul: should this work? 'torify wget https://r4mdnnhdof4jvbm6bucdjdqkrc5uxcjnttixi5ltczzpernlsz6xjuyd.onion/packages.json'
*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
<cbaines>I think bayfront is still building the website, and it looks like the packages.json file is available: wget --header "Host:"
<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> doesn't resolve to bayfront, so that wget command queries the machine at, but the HTTP Host header tells nginx that the request relates to
<cbaines>otherwise nginx would use the configuration for, and respond with a 404
<sk>apteryx: Your tip with the `.xsession` sent me into the right direction: According to you can simply use `exec "$1"` to run the session in the display manager. Will give it a spin and see whether that works out :]
<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
<apteryx>we'll see
<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 ?
<unmatched-paren>abrenon: it isn't
<unmatched-paren>ocamlbuild is iirc a legacy build system mostly superseded by dune
<unmatched-paren>so it's not a default input
<abrenon>oh I see
<abrenon>thank you !
<unmatched-paren>obviously there'll still be some packages that use it :)
<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>ok : )
<unmatched-paren>ah, comment in guix/build-system/ocaml.scm explains
<abrenon>ah, missed that sorry
<abrenon>I was looking at the dune.scm build system
<unmatched-paren>the part labeled Commentary:
<johnjaye>how does guix isolate all these build systems anyway
<abrenon>very instructive
<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>probably containers
<unmatched-paren>it's not chroots, because / isn't changed
<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 ?
<unmatched-paren>abrenon: perhaps
<unmatched-paren>ocaml-migrate-parsetree includes ocamlbuild as a propagated-inptu
<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 ?
<unmatched-paren>abrenon: guix graph, maybe?
<abrenon>ahhh there had to be one way of doing it
<abrenon>thanks again
<unmatched-paren>guix graph produces a dot file, which can be viewed with xdot
<unmatched-paren>or turned into an image with dot
<unmatched-paren>okay, i'm giving up on adding extension-paths.
<abrenon>I just want to grep, basically so : ) I'll simply add coreutils to my guix shell
<unmatched-paren>it's too frustrating
<unmatched-paren>abrenon: Well, I'm doing something which you might find helpful, should be ready soonish
<abrenon>haha well done it's there
<abrenon>ohhh what is it ?
<unmatched-paren>a small extension
<unmatched-paren>for viewing dependencies as a linear list
<unmatched-paren>with filtering
<abrenon>sounds cool !
<abrenon>thanks for working on that
<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 ?
<abrenon>what are extension-paths ?
<unmatched-paren>abrenon: basically a load path for new Guix subcommand
<unmatched-paren>$GUIX_EXTENSIONS_PATH already provides it
<unmatched-paren>but i was trying to add support for listing such paths in a .guix-channel file
<unmatched-paren>it was too hard :)
<abrenon>ohhh that's too bad : /
<unmatched-paren>Soooo i'll just make it a standalone program :)
<abrenon>as long as it works right : )
<abrenon>"mkdir -p /usr/local/…" : haha, good one, installer
<rekado_>unmatched-paren: what’s the obstacle?
<unmatched-paren>rekado_: Can't figure out this issue with autoload
<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?
<unmatched-paren>If not, would GPL-3.0-only be okay or just GPL-3.0-or-later?
<acrow>vagrantc: I did not know that patch files had licensing. Maybe I should save that for last.
<sneek>acrow, you have 1 message!
<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.
<unmatched-paren>i think i'll play it safe and use gpl3+
<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>mhm, it doesn't allow more restrictive licenses
<unmatched-paren>(like AGPL)
<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]>they cannot download anything
<unmatched-paren>two[m]: which ones?
<two[m]>oh i'm sorry, after guix updated they do
<unmatched-paren>okay :)
<two[m]>thank you very much for making this this is awesome software
<unmatched-paren>I agree :)
<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>it triggers wild syntax errors
<unmatched-paren>abrenon: paste please
<abrenon>unmatched-paren: yeah, I've seen a huge number of new examples using gexps
<abrenon>so I thought it may have changed
<roptat[m]>you can't use %outputs in the gexp though
<unmatched-paren>abrenon: it should be #~(list (string-append "PREFIX=" #$output))
<abrenon>yeah, apparently
<abrenon>but I'm still trying to post-mortem to understand what works and what doesn't and why
<unmatched-paren>prepend an unquote if the arg list is quoted
<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.
<two[m]>there's gpl4?
<abrenon>it uses %output directly, instead of a call to assoc-ref
<roptat[m]>no, it was a silly example
<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
<roptat[m]>can you paste the whole thing?
<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
<unmatched-paren>why does this fail with 'unbound variable `guix-build`'?
<abrenon> contains the package definition using the same syntax to set make-flags as hevea which manages to build
<unmatched-paren>abrenon: remove 'list' in the make-flags list
<unmatched-paren>it's being treated literally as 'list i think
<rekado_>you use backticks in your modify-phases expression
<abrenon>and it yields
<rekado_>should be '
<roptat[m]>missing a ) at the end of the #:make-flagsthink
<abrenon>wow thanks for the general feedback !
<rekado_>you have one closing ) too many
<roptat[m]>like I said, I think you're missing exactly one line in the second paste
<rekado_>check the parens after `check
<rekado_>proper indentation would really help hee
<rekado_>are you using Emacs?
<abrenon>no of course not
<abrenon>: )
<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.
<abrenon>: (
<abrenon>that's why I'm so bad at least
<abrenon>sorry : (
<roptat[m]>I do :p
<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 :(
<unmatched-paren>lilyp: Use Emacs?
<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 (sorry for the long log but since I'm not able to figure out what's relevant and what isn't here, goes)
<abrenon>meanwhile the package definition has become, taking your remarks into account
<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
<unmatched-paren>abrenon: surely since it's quoted it should implicitly be a list
<roptat>%output is an old one that was removed from some build systems after gexp build systems were merge
<unmatched-paren>'(#:make-flags (,foo ,(bar baz)) ...)
<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
<unmatched-paren>(I forgot to add that you should unquote the members)
<abrenon>except for the "implicit" list part
<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
<unmatched-paren>roptat: Ah, I see. Never mind then.
<roptat>if it doesn't say "list", it'll be a procedure
<abrenon>ah, thanks !
<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
<abrenon>I could've been mistaken
<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
<two[m]>chumpy: set CC=gcc
<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>btw, this issue with parenthesis would have been caught by
<roptat>any reviewers ? :)
<unmatched-paren>I'd be happy to but I'm not confident that i'd be able to
<unmatched-paren>btw, anyone know why i get that 'unbound variable `gnu-build`'?
<roptat>where is it?
<unmatched-paren>Oh, huh, got distracted and never posted the link :P
<unmatched-paren>this is the guix.scm for that guix extension
<roptat>I think it's because you don't have enough in #:modules
<unmatched-paren>oh! yes, thanks
<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
<unmatched-paren>i remember having this problem before
<unmatched-paren>thank you! :D
<roptat>you'll find examples of reusing the modules declared in gnu-build-system ;)
<unmatched-paren>now my modify-phases is apparently wrong :)
<unmatched-paren>Ah, (delete ...) can only take one symbol
<abrenon>see y'all later
<unmatched-paren> <- now install-manpage is hanging...
<cbaines>unmatched-paren, strace is probably what you need to use to debug that
<unmatched-paren>cbaines: ok
<unmatched-paren>yep, it's reading forever, as i though.
<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?
<lilyp>chumpy: gtk+@3
<chumpy>lilyp thank you
***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?
<unmatched-paren>Ah, seems like it.
<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.