<mbakke>Sebastien-16199: for 'guix pack', you may have to convert your package.scm into a "manifest" by ending the file with (specifications->manifest (list python python-foo)), then you can 'guix pack -m package.scm'
<mbakke>having 'python' in the pack is important so that PYTHONPATH gets set up correctly
<derivates>does anyone know the fastest way to tackle a conversion from "(map specification->package ...)" to a list of variable-name-packages
<derivates>how do i use the "firstname.lastname@example.org" notation when using variables instead of specification->package ?
<lfam>I know we could do it faster if we prioritized these jobs, but it's still a pretty long time
<Sebastien-41173>Hi all: quick question, probably Scheme-related, what's the difference between (use-modules) at the top-level of a script and the #:use-module (...) within a top-level (define-module) ?
<lfam>Hi aaii[m]. From my point of view, the main differences are that Guix only includes free software, and it's (almost) entirely written in Guile Scheme, giving us access to a full programming language
<guixy>referring to the package manager, mcron, shepherd
<lfam>This is different from Nix which uses the Nix language, which is not really as complete, thus requiring use of other languages in various places
<aaii[m]><guixy "guix is nix's child"> The syntax of configuration is written by nix lang too?
<lfam>jgart[m]: It's been worked on over the years. We slowly remove functionality from the daemon and move it into other areas of the codebase. We do want to rewrite the daemon in Guile Scheme but it seems that nobody is focused on this currently
<jgart[m]>That package renders music notation in jupyter notebooks via lilypond
<guixy>jgart[m]: I have had some difficulties with the guix jupyter kernel.
<Sebastien-41173>Hi all, so I'm one step further on my journey of packaging a Python app as a container using Guix. I'm now properly getting through a `guix build -f package.scm` complete with dependencies. My next steps is: how do I run a command in that environment? In Nix I would do something like nix-shell package.nix --run "python -m mymodule"
<guixy>Sebastien-41173: I think `guix environment --container --ad-hoc -f package.scm` should take you to a shell in that container.
<guixy>Then `guix environment --container --ad-hoc -f package.scm -- python -m mymodule` should do what you want...
<guixy>info guix 'envoking guix environment' for more detailed options
<Sebastien-41173>@guixy I just tried that, it does build the derivation but does not seem to run the command. For instance `guix environment --container --ad-hoc -l package.scm -- python -c "print('hello, guix')"` does not output "hello, guix"
<guixy>python package doesn't include /bin/python. Try including python-container after --ad-hoc
<Sebastien-41173>@guixy Now something unexpected happened: I changed the code of my module `__main__.py` file to output a different string. I re-run `guix build -f package.scm` and then the same oneliner (`guix environment --container --ad-hoc python-wrapper -l package.scm -- python -m guixpythonapp`) but gets the outdated result
<Sebastien-41173>@guixy As if `package.scm` was not detecting the changes in the files. Note that I define the sources as `(sources (getcwd))` as I'm building straight from the repo.
<guixy>I'm not sure why that happens. Try deleting the package from the store. guix gc --delete `guix build -f package.scm`
<guixy>I've only been using guix full-time for 2 years, and I haven't contributed much to the code. I'm struggling to make a simple shepherd service work.
<lfam>Sebastien-41173: Your package.scm includes the source hash?
<guixy>I think the problem is the hash of the entire build process remains constant even though you updated the source. So the drv in the store isn't changed, and to save time you get the previous result.
<guixy>That should force the build process to rehash.
<Sebastien-41173>@guixy Yes, that's what seems to be happening. So this did not have an effect: `guix environment: warning: transformation 'with-source' had no effect on email@example.com`, I still get the same result
<Sebastien-41173>@guixy oh, I think I know why it did work: running `guix build -f package.scm` gives me bunch of extra warnings, but even with copy-pasting the derivation and doing a `guix gc --delete /gnu/store/pz644yfjandm3ccicdzpl4zdh92k2fqk-guix-python-app-0.0` I still get the same result
<jbv1[m]>jgart: nice ! I dont think I'll be free this saturday but I'd like to be invited just in case if that's possible.
<tissevert>rhou[m]: I think you need to have emacs and the package you want installed explicitely in the same environment (this happened to me when I had an interpreter installed, say python, on my system, then created an environment with python-numpy but python wouldn't find it because guix didn't set the package properly because python wasn't asked explicitly)
<jgart[m]>jbv1: We host one guix packaging meetup a month. We also have spontaneous guix packaging sessions over mumble/tmate. Just ask at #guix-packaging:matrix.org
<civodul>apteryx: is it deterministic? it must have worked before, when the armhf machines were still plugged in behind ci.guix
<apteryx>it always seem to hang in the test suite; that could be caused by QEMU emulation
<apteryx>I was in the process of trying it on the beagleboards machine we have now reconnected as offload machines on Berlin; I think it failed but I can't investigate (lost SSH access to berlin for some reason)
<apteryx>I'll try setting up an ARMn7 machine here later but I'm not sure how that'll go.
<zzappie>brendyyn: if it autocompletes while you typing then its probably company-mode
<davidl>civodul: Hi, I replied to your reply a while ago reg. guile2.2-bash but then I haven't heard back again, do you think you can take another look and let me know the requirement for the package being accepted?
<brendyyn>zzappie: i disabled company-mode and nothing changed
<brendyyn>i notice the guile process has an argument with some flycheck dir in /tmp
<zzappie>brendyyn: aah yes I had the same experience
<brendyyn>flycheck is enabled for me by the syntax module of Doom. its pretty useless so i guess ill turn it off
<zzappie>well flycheck-guile is useful. But it'll bake your silicon for the second time :)
<zzappie>it spawns guile process for each buffer. And my guiess is that if it happends that you jump around in guix source that hasn't been compiled fully it will mean there will be several guix modules compilations running in background
<guixy>Configurable. I think default would be /var/lib/jupyter/notebooks
<guixy>jupyter server is run by jupyter account. jupyter account's home is /var/lib/jupyter. I know sometimes the home can be cluttered, so I want to have the jupyter notebook root be /var/lib/jupyter/noteboooks
<civodul>but anyway, you need to make sure these are top-level definitions
<civodul>side-effect-free internal definitions can be optimized out
<civodul>as in (let () (define x 1)(define y 2) #t) => #t
<apteryx>That's exactly what syntax-parameterize does when using it with define-configuration and when the last form is #t (which is required else it complains that 'body should end with an expression'
<lfam>apteryx: Last night I sent you some private messages about accessing berlin, but I'm guessing you didn't notice them
<lfam>Anyways, like I said, I can check things on berlin such as logs
<apteryx>ah, sorry, I've seen it late :-) I doubt anyone can do much about it but the network team at the MDC, given it doesn't even *reach* the openssh server (IIUC)
<apteryx>but perhaps failban could trigger such a behavior?
<lfam>Just creating the derivation is a valuable step in validating your package definition
<apteryx>but if your build succeeds successfully in your /tmp/guix-build* failed build, chances are higher that it will :-)
<AleQu[m]>Thanks, I guess that's what I want. Of course I understand it's not a 'valid' derivation because it got interrupted etc.
<AleQu[m]>Just so I understand, will this `guix build $package --derivations --no-grafts` take up from the failed directory ? If so, at what point should I leave it ? It's a gnu make build, so I guess I don't do `make install`, right ?
<nckx>andreas-e: I honestly thought you added it...
<gr0n>nckx: the weirdest iptables rule i've had to debug was by far the simplest one, namely one that simply permits traffic in/out of a NATted network. somehow it was permitting out and in for everything except for an ICMP echo reply.
<gr0n>everything was working, but if you tried to ping you would never get a response (even though the server sent it)
<gr0n>it was a literal 1 liner, and it just magically started working after a reboot (i'd tried to flush before)
<nckx>That's cheating; NAT is the mind-f***er. It is the little-death of sane reasoning about packets.
<leoprikler>nckx: but doesn't wine-staging already inherit from wine? Should that not be trivial?
<AleQu[m]>Hey, just a short question: how to get the version of an input inside a package definition?
<AleQu[m]> I tried `package-version` but it's not defined inside `(package...)`
<apteryx>civodul: ah, uhm, cuirass doesn't currently have any armhf-linux worker (though I think mothacehe was working on it), so that won't help to know if Guix builds on armhf-linux for now :-/. We'll need to build stuff 'by hand', through the offload mahines.
<nckx>derivates: That's not the distribution's ‘job’, so nothing should change. Either your display manager loads it if it exists (all sane ones I know do), or you do so manually in your .xinitrc/.xsession etc.
<AleQu[m]>nckx: no luck... same error: `Unbound variable: package-version`
<nckx>Are you trying to run it on the build side? Share your code. (Pastebin in topic or, basically, anything not pastebin.com.)
<AleQu[m]>It's inside #:configure-flags . I had also tried `(package-version (assoc-ref %build-inputs "python"))` before but same error.
<nckx>andreas-e: ‘modern technologies’... iptables is a deprecated legacy now 😛
<derivates>nckx: alright, ill make use of that file, just curious if there was anything elss that handled this
<nckx>AleQu[m]: Records aren't (that) magical; variables don't become unbound inside of them. We'll need more context.
<rhou[m]><leoprikler "afaik, the current emacs should "> what do you mean by this? sorry I'm a emacs newbie and I don't get it to work with guix
<andreas-e>nckx: Exactly, but I still remember there was something like ipchains...
<apteryx>civodul: OK! It'll take some time, it's building on Beagleboards :-)
<nckx>AleQu[m]: Your code isn't actually calling package-version ‘inside the definition’, it's passing it verbatim as quoted data. The code isn't evaluated until much later on the ‘build side’, thus calling package-version inside the build environment. This is how you call it immediately, on the ‘host side’: <https://paste.debian.net/plainh/f365ed22>
<AleQu[m]>Oh, I see ... mmm ... ok, this made me understand better how/when the different parts are evaluated. :-) Gonna try that out. Thanks!
<nckx>The result is *still* building here. What a big C++ boy.
<nckx>So while variables don't spookily go in and out of scope in package definitions, they definitely (appear to) do so at different quoting levels.
*nckx must reboot because of stupid PulseAudio bug.
<apteryx>Do we have an upper budget for ARM CI machines?
<jackhill>ok, looks like Debian has patches. I don't think we have a bug yet for this, but "screen" is a difficult term to search for…
<AleQu[m]>nckx: as you knew, it works, thanks you =D
<AleQu[m]>So, if I got it right, the `#:configure-flags` gets evaluted on the 'build side' and that's why it's backquoted, and by adding the comma we make sure `package-version` evaluate early and thus on the 'host side'.
<nckx>I'd say ‘until’ to specify that 4.8.0 is immune.