IRC channel logs

2021-04-21.log

back to list of logs

<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 "emacs@27.2" notation when using variables instead of specification->package ?
<derivates>emacs-27.2 doesn't seem to work right
<civodul>derivates: variable names don't have to match package specs
<civodul>in this case, the variable is just "emacs"
<civodul>you can see that by doing "guix edit emacs" or "guix show emacs" and clicking on the 'location' hyperlink
<derivates>alright, so I cannot pin that version using this syntax?
<nckx>derivates: As a rule Guix doesn't keep older versions of packages, so ‘emacs@27.2’ won't pin much either. It will break as soon as someone updates emacs to 27.3.
<nckx>Good night, Guix o/
<derivates>oh okay!
<bdju>if I've added a service to my system config and done a system reconfigure but it still isn't running or listed at all in `sudo herd status`, do I have any options besides rebooting?
<roptat>bdju, it should appear, did something fail when reconfiguring?
<bdju>nothing failed
<bdju>just been wrestling with trying to get a keyring going, and I added the gnome-keyring-service
<bdju>ah wait I already got a response about this on the mailing list. it's not supposed to appear
<bdju>slipped my mind already. been putting off rebooting which may or may not fix it
<lfam>AleQu[m]: I was afk for a while. I just saw your question about the difference between the 'gcc' packages and the gcc-toolchain metapackages
<lfam>gcc-toolchain is basically what a human would use if they were developing a program on Guix and wanted to, for example, run `make`.
<lfam>It's kind of like Debian's build-essential metapackage. It's a full GNU development toolchain
<lfam>The 'gcc' package is just GCC, and it won't work properly on its own, if you were developing a program and wanted to use other Guix packages to provide your program's dependencies
<lfam>However, adding the version of gcc that you want to native-inputs is the right thing to build a Guix package with a particular GCC version
<lfam>I hope that helps
<AleQu[m]>lfam: it does help, and I guess it's what one would expect from the package names =) Thanks you!
<lfam>Cheers!
***bkv is now known as bqv
***iyzsong-- is now known as iyzsong-w
<lfam>After starting the evaluation of the ungrafting branch on April 17, we only *just now* finished the building the Rust package, on April 20
<lfam> https://ci.guix.gnu.org/build/198420/details
<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 Sebastien-41173
<lfam>I'm no Scheme expert, but my reading of the Guile manual suggests that they are equivalent
<lfam> https://www.gnu.org/software/guile/manual/html_node/Using-Guile-Modules.html#index-use_002dmodules
<lfam> https://www.gnu.org/software/guile/manual/html_node/Creating-Guile-Modules.html#index-define_002dmodule
<lfam>By the way, I find this page really useful, the Guile Procedure Index: https://www.gnu.org/software/guile/manual/html_node/Procedure-Index.html
<lfam>You can get good Guile Scheme advice here, and also in the #guile channel
<lfam>The '#:' syntax is a "keyword"
<lfam> https://www.gnu.org/software/guile/manual/html_node/Keywords.html
<derivates>I just burned my iso and got a kernel panic, what could i be doing wrong
<lfam>The kernel panic while booting the ISO?
<derivates>yeah i choose option on booting list and insta error
<derivates>ofc it built fine (and so i dd
<derivates>dd'd)
<lfam>How did you make the ISO? Or did you download it? And exactly what command did you use for dd
<derivates>i made it
<derivates>guix time-machine --channels='./guix/channels.scm' -- system --load-path=./ disk-image -t iso9660 ./systems/asus.scm
<derivates>I really wouldn't think it's the command itself
<lfam>Did you use conv=fsync with dd, or sync after dd exited?
<derivates>no, just udo dd if=image.iso of=/dev/sdb status=progress
<lfam>Otherwise, it's possible that the data was not completely written to your flash drive before you removed it
<derivates>you're right i usually add && sync but forgot
<lfam>The manual recommends running `sync` after dd exits. I use conv=fsync. I'm not sure if they are different or not
<lfam>This has broken things for me before
<derivates>never tried conv=fsync, will try again with an extra "&& sync"
<lfam>Cool
<lfam>Btw, the dd man page says this:
<lfam>fdatasync: physically write output file data before finishing
<lfam>fsync: likewise, but also write metadata
<derivates>ill add that as well then
<lfam>I started using it after I had trouble with dd and ISOs
<derivates>use both
<lfam>Sure, it can't hurt
<lfam>Let us know how it goes
<derivates>does the order matter
<lfam>No
<derivates>just append at the end?
<lfam>Yeah, add "conv=fsync"
<derivates>sometimes I don't see a progress, the dd command is weird sometimes
<lfam>Also, you can test your ISO in a VM with QEMU
<lfam>You could try `guix system vm --load-path=. --channels=./guix/channels.scm ./systems/asus.scm`
<derivates>yeah i thought about that as well but kinda just want to try on metal to see everything goes okay
<lfam>Sure, but it's a nice sanity check :)
<derivates>ill do that in the meantime for dd
<derivates>don't think it will interfere much
<lfam>`guix system vm` creates immutable VMs, but there is `guix system image` if you want to actually use the VM
<lfam>Sure
<derivates>(i still need an SSD tho)
<derivates>yeah, i've used vm feature once
<derivates>amazing tool
<guixy>hello guix
<derivates>hi
<guixy>I'm trying to make a jupyter service for guix
<guixy>it crashes when it starts
<guixy>How can I make sure I have the correct environment variables?
<apteryx>lfam: are you able to connect to berlin?
<apteryx>the ssh times out for me
<lfam>Yes, I just connected
<lfam>But, I often get timeouts around this time of day
<lfam>It's weird
<lfam>Usually it comes back after a little while
<lfam>guixy: Do you know which environment variables you need to set?
<aaii[m]>Hi Guys, What's differences between nix os and guix?
<guixy>Probably PYTHON_PATH. It says it can't find six.
<guixy>guix is nix's child
<aaii[m]><aaii[m] "Hi Guys, What's differences betw"> I meant except free softwares...
<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>No
<aaii[m]><lfam "No"> So what's that?
<lfam>Guix is a "child" of Nix in the sense that it was founded by somebody who used to work on Nix
<lfam>We borrowed the nix-daemon and still use a modified version of it, but everything else was written from scratch in Guile
<guixy>Isn't it a fork with almost nothing left of the original?
<lfam>No guixy
<jgart[m]>lfam: Do you happen to know if anyone is doing work on converting the daemon to guile?
<lfam>The only part that was forked is the daemon. Nothing else was taken from Nix
<jgart[m]>s/converting/porting/
<aaii[m]>What's the language of configuration of guix?
<lfam>Guile Scheme
<derivates>GNU Guile
<aaii[m]><lfam "Guile Scheme"> Thanks I'm gonna search and read about it..
<derivates>actually GNU+Guile
<guixy>Guile's a gnu package...
<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]>is there a branch for work on it?
<lfam>Off the top of my head, I don't know. I recommend doing `git log nix` to see commits like "daemon: Delegate deduplication to 'guix substitute'"
<lfam>jgart[m]: https://git.savannah.gnu.org/cgit/guix.git/log/?h=guile-daemon
<jgart[m]>I've been trying to understand the worker protocol. Do you happen to know of any resources I can checkout besides the source code regarding implementation details for that?
<jgart[m]>thanks for the link above
<lfam>The Cuirass workers?
<jgart[m]>I'll do some digging around
<jgart[m]>no
<jgart[m]>Nix worker protocol implementation for interacting with remote Nix store via nix-daemon.
<lfam>Ah
<lfam>There are people who know! Maybe some are here now, maybe during the European daytime
<guixy>I'm testing my jupyter server in a vm. Here's the output dump. https://paste.debian.net/1194487
<jgart[m]>lfam: I mean understanding worker-protocol.hh
<lfam>guixy: Maybe jupyter needs to depend on six
<lfam>Right jgart[m]
<jgart[m]>In /guix/nix/libstore/
<guixy>It works when I log in as a user and call "jupyter notebook"
<lfam>It may be something that the Nix people can help with, too
<lfam>jgart[m] ^
<jgart[m]>I've been hanging out at a NixOS meetups learning whatever I can pick up
<lfam>Nice, in Miami?
<jgart[m]>I just run this on Thursdays at 2PM to join the meetup: nix-shell -p mumble --run "mumble mumble://$USER@lassul.us/nixos"
<lfam>Ah, virtual meetups :)
<derivates>lfam: no luck, kernel panic again, it wasn't that. Also the vm works? could be this anything related to the file-systems (somehow?)
<jgart[m]>It's organized by packagers who live in Berlin
<lfam>Could be derivates
<jgart[m]>but people show up from everywhere
<lfam>I'm curious about Miami things because I am from Miami (although I moved away a long time ago)
<jgart[m]>mic92 and lassulus organize it
<lfam>derivates: Maybe if the file-systems were not set up correctly, something could go wrong and cause a kernel panic
<jgart[m]>That's cool! I grew up in Miami
<lfam>Ah, so we both left?
<jgart[m]>I live in Miami, currently
<jgart[m]>I was studying in England last year and returned home for now
<lfam>Oh, that's what I thought based on the libremiami stuff
<jgart[m]>after finishing my studies
<jgart[m]>just in time before the pandemic hit
<lfam>At least you were able to finish them
<lfam>I know some people who had to quit their programs early due to covid
<jgart[m]>I took the last flight out of England before they locked down the airports for a bit.
<lfam>Oof
<lfam>Similar story from my friends
<jgart[m]>Literally the day before that happened
<guixy>I'm testing my jupyter service in a vm with the os definition here https://paste.debian.net/1194489
<guixy>jupyter-service-config is defined on line 68.
<guixy>So many requirements because I thought they might be a problem, but now I know they aren't.
<guixy>aren't necessarily.
<apteryx>lfam: strange, I still can't connect to berlin
<lfam>apteryx :(
<lfam>When I said it comes back "after a little while", I meant something like 30 minutes to an hour
<lfam>I've wondered if there's a fail2ban type thing set up. I often mistype my SSH key password a couple times...
<gry>downloaded guix-system-vm-image-1.2.0.x86_64-linux.xz, qemu doen't take it, says https://dpaste.com/2BV8BKQYT.txt and then in the window 'no such file or directory' 'no bootable device'
<lfam>I've also wondered if the MDC datacenter's peering is not quite as robust as we sometimes expect
<lfam>gry: Did you decompress it? Like, `xz -d guix-system-vm-image-1.2.0.x86_64-linux.xz`?
<lfam>apteryx: Can you traceroute to it?
<jgart[m]>Guix Jupyter Kernel is supposed to work out of the box with any python packages, etc... It just replaces the underlying package managers to be managed by guix instead?
<jgart[m]>I'd like to to test guix jupyter kernel out soon with this package http://issues.guix.gnu.org/47818
<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...
<Sebastien-41173>@guixy, the -f option is not recognized in my version (1.2.0)
<guixy>-l instead?
<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
<guixy>sorry, python-wrapper
<lfam>To clarify, the 'python' package provides `python3.8`, which is what upstream has written their build scripts to create
<lfam>We offer python-wrapper to provide a `python` executable
<lfam>(Guix tries to accept what upstream provides)
<Sebastien-41173>@guixy that did work!
<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>Source hash would slow things down...
<guixy>Unless there's a way to automatically calculate source hash...
<lfam>I'm asking if their package.scm includes the source hash, because not changing it can result in surprising problems like "not detecting the changes in the files."
<Sebastien-41173>@lfam No it doesn't, I'm building straight from the repo... the idea is to use Guix as the build system for the container
<lfam>I see
<lfam>I didn't even realize one could do (sources (getcwd))!
<Sebastien-41173>@lfam I could get my makefile to generate some kind of hash from the sources, but that would mean re-generating the package.scm each time from a template.
<Sebastien-41173>@lfam I thought I learnt that from you ;)
<lfam>It sounds like Guix doesn't think anything has changed
<lfam>But, I don't know how it works in this scenario
<guixy>guix hash generates hashes, doesn't it? See what it calls on whatever it points to.
<guixy>$ guix hash /gnu/store/00cx77cskgh3l705ibhfa63814xq886d-shepherd-console-font-tty9.scm
<guixy>0jii6q56hl1zp7pgglj22gj7c8g2npnhljzqa09wy1y0bzdz28cl
<Sebastien-41173>@lfam Yes, I imagine it's not really expanding the sources from the `setup.py` and computing the signature from the set of input files?
<lfam>It's really hard to say, because I don't really know what you are doing :) I was giving advice as if you had written a standard package definition
<Sebastien-41173>@guixy The problem is that I'm relying on Guix's python-build-system to find my input files. They're described in the `setup.py`.
<lfam>I have to go afk, sorry. I hope somebody else can help out!
<Sebastien-41173>@lfam Thanks for your help, have a good one!
<lfam>Bye!
<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>Try adding --with-source=package=$PWD
<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 guix-python-app@0.0`, I still get the same result
<Sebastien-41173>(I did run guix gc --delete `guix build -f package.scm`)
<guixy>Odd, it usually works for me.
<guixy>I should be going soon.
<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
<Sebastien-41173>@guixy no problem, thanks a lot for your help!
***bkv is now known as bqv
<bdju>anyone ran into new shells printing out "No selection" for seemingly no reason?
<tissevert>hi guix !!
<brendyyn>hi
<tissevert>bdju: nope. bash ?
***bkv is now known as bqv
<rhou[m]>how does my emacs pick up my emacs packages installed via guix?
***iyzsong-- is now known as iyzsong-w
<tissevert>rhou[m]: because they are all in the subfolder share/emacs/site-lisp of your profile (c.f. $GUILE_LOAD_PATH/guix/build/emacs-build-system.scm)
<bdju>tissevert: zsh
<tissevert>not using it and haven't seen this message so, maybe it's zsh-specific ?
<derivates>im having a weird issue, after reinstall I don't net anymore, but I can ping 1.1.1.1, but nothing else than that
<wonko7>Hi all!
<rhou[m]><tissevert "rhou: because they are all in th"> Is there a general emacs setting to look into this folder?
<wonko7>I'm making a profile for xmonad, and making good progre
<wonko7>ss
<wonko7>nevermind
<mothacehe>hey guix!
<derivates>hi
***apteryx_ is now known as apteryx
<mothacehe>apteryx: hey! I removed ppc64 and armhf systems for the version-1.3.0 specification as we don't have any machine to build those
<tissevert>rhou[m]: I don't know because I use vim but I would imagine so ? In vim and our packages are installed in share/vim/vim82 and vim loads them automatically
<tissevert>are you having any trouble getting a package you installed to load in emacs ?
<rhou[m]>yes assumed it would load automatically, for example i installed the emacs-guix package but it does not load into emacs
<leoprikler>perhaps you don't have EMACSLOADPATH set up yet?
<leoprikler>afaik, the current emacs should just accept your ~/.guix-profile being overwritten
<leoprikler>be warned, that it won't after the wip-emacs merge though
<jbv1[m]>hello guix ! Is somebody working on packaging julia 1.6 ? if so how can I help ?
<jgart[m]><wonko7 "nevermind"> wonko7: https://github.com/jsoo1/dotfiles
<jgart[m]><jbv1[m] "hello guix ! Is somebody working"> jbv1: If you'd like to work on upgrading julia 1.6 in a group setting I'd like to invite you to a guix packaging meetup happening this Saturday https://events.nixnet.services/events/27955ca1-0aee-4ec5-be20-48e6c45fd0f6
<wonko7>jgart[m]: ah, thanks, plenty of interesting things in there
<jgart[m]>We have a guix packaging kanban board here: https://board.disroot.org/project/guix-packaging/kanban?kanban-status=12312
<jgart[m]><wonko7 "jgart: ah, thanks, plenty of int"> John Soo also hosts a very nice functional programming meetup every Monday at 10PM EST at https://meet.jit.si/orange-combinator
<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
<jbv1[m]>ok
<wonko7>I tried installing cairo, lua & lua-lgi but I can't use cairo module from lua, does anyone know how lua stuff works?
<leoprikler>nckx: why is wine-staging still on 5.x when wine itself is on 6.0?
<leoprikler>s/6.0/6.6
<mbakke>rekado_: I noticed your libcxx work yesterday, do you plan to upstream the patches?
<rekado_>mbakke: certainly!
<rekado_>I’m still having some problems, though
<rekado_>I think it’s unrelated to the libcxx stuff
<mbakke>rekado_: great, I need libcxx and libcxxabi for an LLD 12 upgrade :-)
<asdf-uiop>Hi!
<mbakke>hello, asdf-uiop
<rekado_>mbakke: I only have libcxxabi-6 and libcxx+libcxxabi-6
<rekado_>no later versions
<rekado_>but I think it shouldn’t be too hard to swap out the source and adjust to later versions
<mbakke>rekado_: oh, OK. The libcxxabi work will still be useful, I think.
<rekado_>will push them in a moment
<rekado_>mbakke: done
<mbakke>rekado_: smooth, thanks!
***rekado_ is now known as rekado
<Ikosit>Has sb also problems with java not finding shared object files e.g. libXcursor.so.1 ?
<Ikosit>And has sb a solution for it :'(
<brendyyn>somehow running the same guix environment command, but removing "-E ^SSL" results in guix need ing to download 3 new substitutes. i dont understand how its even possible
<user`>hi everyone! i tried "guix package -i racket -p opt/racket" but got "guix package: error: rename-file: Is a directory"
<wonko7>is guix pull broken for other people too? I get "guix-package-cache.drv failed"
<brendyyn>wonko7: works for me
<wonko7>thanks
<user`>also no profile file in opt/racket
<user`>
<apteryx>nckx: for the last 10 hours or so I can't connect to berlin via ssh anymore (times out). Any idea?
<leoprikler>user`: since `guix build racket` would just substitute the package, perhaps opt/racket is not a suitable profile?
<leoprikler>does it exist already and is it a symlink?
<user`>leoprikler: ohhh, this is just a directory
<leoprikler>if it's empty just rmdir it
<user`>did it
<user`>so, how i create profile in my home directory?
<brendyyn>guix install does that
<user`>brendyyn: i mean in directory, for example ~/opt/
<brendyyn>you can use --profile=/path/
<user`>"guix install racket --profile=~/opt" returns "guix install: error: open-file: No such file or directory: "~/opt.lock""
<roptat>user`, you should use a directory that's inside a directory owned by your user
<roptat>usually / is owned by root, so you can't use /opt as your profile
<roptat>oh sorry, I misread
<user`>roptat: hi, =)
<user`>yeah
<user`>~/opt
<roptat>~/opt is not expanded as you expected
<roptat>so guix doesn't find a directory named ~
<user`>yup, i found some notes about guix
<roptat>use $HOME/opt instead
<user`>hmmmm
<user`>roptat, well, it creates opt dir, opt link and opt lock in my $HOME
<user`>whicj is great
<guixy>hi guix
<user`>but no profile file in opt which i can source
<guixy>Working on jupyter service
<user`>guixy: hi
<guixy>How can I make sure I have the necessary PYTHONPATH without hard-coding it?
<roptat>guixy, if you have python in the environment, it should be set for you automatically
<roptat>user`, it should be in $HOME/opt/etc/profile
<guixy>in a shepherd service?
<roptat>guixy, oh
<user`>roptat: wow, that's great
<user`>i should edit that notes
<roptat>guixy, maybe you need to add a wrap phase when building the jupyter package, if you can do with a fixed PYTHONPATH
<roptat>otherwise, you'll have to hardcode it, or define it a configuration time
<guixy>I see jupyter already wraps itself with PYTHONPATH. I guess I need some other environment variable.
<guixy>Maybe GI_TYPELIB_PATH?
<guixy>*installs jupyter to a dummy profile and inspects etc/profile*
<guixy>Yes, I'll try that.
<user`>roptat: thanks, works great
<mothacehe> dover is finally connected to Cuirass, thanks andreas!
<andreas-e>mothacehe: Amazing, thanks for all your work!
<guixy>Added the variables. Now it isn't loading :(
<guixy>s/loading/booting
<lubrito>cbaines Hi. Could you give some more directions about my next steps on contributing?
<lubrito>I was taking a look, are the functions on comparison.scm the relevant ones for me?
<cbaines>lubrito, I'm busy at the moment unfortunately, but I'll be free to talk either via IRC or email later on today
<lubrito>cbaines I understand. It`s ok, thanks.
<apteryx>civodul: It seems Guix is not currently buildable for armhf-linux as the python-minimal test suite fails there
<guixy>I have a working jupyter service!
<guixy>It's nowhere near configurable enough to send to guix though.
<civodul>apteryx: ouch
<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.
<apteryx>ARMv7
<efraim>My bug in the libiberty test suite got fixed upstream
<efraim>I'll probably pull it back to binutils on core updates and skip the whole phases dance I had going on.
<brendyyn>Everytime I type in emacs in the guile repl it spawned starts using 200% cpu for a bit making my computer fans crank up for 10 seconds or so
<guixy>Is there a way to make system accounts with specific profiles in a config file?
<guixy>Then load them before starting a shepherd service?
<guixy>That would help with service independence when possible.
<civodul>apteryx: i'm trying /gnu/store/hb7ni81y9mg0gx56ran655jf5vm4s17s-guix-1.2.0-21.4dff6ec.drv on berlin, via normal offloading to physical armv7/armv8 boxes
<civodul>apparently python{,-minimal} are already in store
<civodul>yeah for instance: https://ci.guix.gnu.org/7gd6irr40c9ib6rwdvrd8q6yxb7817a7.narinfo
<apteryx>OK, so it must have passed. Perhaps there's no problem after all. I was at the point of testing manually the 'guix system image -t iso9660 ...' command for armhf-linux
<apteryx>it passed for x86_64 and i686
<apteryx>if it passes form armhf-linux I have I hopes that a first RC is achievable soon.
<apteryx>for*
<civodul>apteryx: we don't do Guix System images for armhf-linux though
<civodul>only x86_64 and i686
<apteryx>ah, right: GUIX_SYSTEM_SUPPORTED_SYSTEMS ?= x86_64-linux i686-linux
<apteryx>then 'make release' may be working already!
<civodul>neat!
<civodul>BTW, wip-ungrafting is in a rather good shape: https://ci.guix.gnu.org/
<apteryx>yes! Should we merge it into the version-1.3.0 branch?
<civodul>i think so
<apteryx>brendyyn: Geiser/Emacs sadly has really bad performance problems
<civodul>we'll have to double-check "guix weather"
<apteryx>brendyyn: you'll want to clear the buffer output often with C-c M-o
<civodul>Geiser works well for me, but the big issue is when you have long lines in the REPL
<civodul>that's a limitation of Emacs and font locking
<apteryx>which happens quite often
<apteryx>when introspecting objects
<civodul>yeah, that's really annoying
<brendyyn>apteryx: i dont have a C-c M-o, whats that do
<apteryx>civodul: it's not purely a font locking thing though, as it works "fine" in other Emacs scenarios (M-x shell)
<brendyyn>i dont have anything in the repl, i just opened fresh emacs
<brendyyn>i mean whats the symbol for it
<zzappie>this wa driving me mad lately. I swithed to truncated print in repl but it doesnt solve problem with long giux daemon ouputs
<apteryx>civodul: I think it's probably related to the use of comint library of Emacs
<apteryx>perhaps it can be profiled, elisp has nice debbuging support
<brendyyn>could the repl be made to use vterm for speed?
<zzappie>giser spends 95% time in geiser-repl--output-filter
<brendyyn>any idea what guile is doing when im just typing, is it auto complete?
*zzappie M-x profiler-run; (guile-user)> (iota 3000); M-x profiler-stop; M-x profiler-report
<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
<apteryx>for me: comint-output-filter 242 55%
<brendyyn>i havent even run run-geiser. its just the internal repl from when i ran guix-find-package-definition
<zzappie>brendyyn: I gues guix-emacs using geiser anyway
<apteryx>brendyyn: C-c M-o just clears the Geiser REPL buffer
<brendyyn>i think it might have been flycheck-mode
<apteryx>it usually helps to make it more snappy again after it accumulates a some output
<brendyyn>turning off flycheck-mode stopped it
<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
<brendyyn>it never stops though
<zzappie>yeah this is like M-x fork-bomb
<brendyyn>its like it doesnt compile at all but is running in some slower interpreted way
<guixy>I need files to exist in certain locations for a service to work. Which services should I extend to do that?
<brendyyn>guixy: which location?
<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
<guixy>s/var/run
<guixy>actually, no. It's /var/lib
<brendyyn>might be the special-files-service-type
<guixy>I need it to be a directory
<brendyyn>not sure. i have to go sleep though, hopefully someone else can help
<guixy>Looks like I also want to put a .bash_profile script in /var/lib/jupyter/
<zzappie>guixy: maybe there is beter way to do it but I think you could write simple activation service that uses file-union
<zzappie>like this (simple-service 'place-things activation-service-type %things-gexp)
<guixy>I want it associated with my jupyter service
<guixy>So I'll have it extend activation-service-type.
<zzappie>this is the beter way then :)
<lfam>The web-based manuals and the cookbook are failing to build again
<lfam>It fails to build /gnu/store/sr3pc9xxjm19jpzkp5y4ydcf7n8rsyxm-guix-translated-texinfo.drv
<lfam>Here is the log file of the failing build: https://paste.debian.net/1194565/
<roptat>the warnings are expected, but mmap(PROT_NONE) failed is not expected
<lfam>It's the same as before: <https://bugs.gnu.org/47428>
<lfam>I guess we have to make sure these builds are single-threaded
<lfam>I'll see about building it "by hand"
<lfam>But, it would be nice if we could mark this derivation with #:parallel-builds? #f
<yoctocell>Is there a way to wrap a program without having to compile it?
<guixy>Make the wrapper script yourself?
<vagrantc>just pushed a bunch of spelling/typo/grammar fixes to master ... would be nice to have in version-1.3.0, but ... does that basically amount to cherry-picking and re-signing each commit?
<yoctocell>guixy: Yeah, but then I have to recompile the program again.
<lfam>vagrantc: The strings are frozen for the release
<lfam>And also, yeah, we can't rewrite commits that landed on the master branch
<guixy>yoctocell: I meant write the script yourself, not dependent on a wrapper phase.
<vagrantc>lfam: ah, oh well. :)
<yoctocell>guixy: Oh, sorry for missunderstanding. But how would I do that with guile?
<vagrantc>only 22 typos i recall since 1.2.0 ... compared to the 80-100 from the last release cycle :)
<yoctocell>I don't want to just write a bash script, I want to be able to declare it in my a manifest or something.
<vagrantc>at least, that i noticed
<guixy>yoctocell: Set the environment variables and call the command. There should be plenty of sample wrapper scripts you can look at.
<vagrantc> https://issues.guix.gnu.org/44675 would be really nice to have for guix 1.3.0+N :)
<yoctocell>guixy: Could you point to any?
<civodul>davidl: i think Dmitri explicitly wrote they stopped working on guile-bash
<civodul>so i think if you maintain a fork, you'd rather maintain a "real" fork
<civodul>i.e., make fixes/improvements such as 3.0 support
<civodul>vagrantc: i considered implementing the checker (based on regexps) but then thought it's a good task for a newcomer or a newschemer
<civodul>(it's also a good excuse, isn't it?)
<guixy>Most of the actual wrapper scripts are bash. Usually `export VAR1=/gnu/store/hash-package-version/bin/program1; program`
<vagrantc>civodul: yeah, that makes sense.
<yoctocell>guixy: How would I declare something like that in a manifest? I would like it to automatically be put in the store and end up in my $PATH.
<vagrantc>someday maybe i'll aspire to be a newschemer :)
<lfam>Alright, I built that derivation "by hand" with --cores=1, roptat. I'll monitor the cronjobs to make sure the rest of the process is working. And I reopened the old bug about this
<civodul>vagrantc: heheh :-)
<guixy>yoctocell: I'm no expert on manifests. But IIUC you can just append a gexp to the end of the manifest. I have no idea though.
<guixy>You could make a simple package with what you want.
<vagrantc>heh. i've apparently submitted 240 typo/grammar/spelling fixes so far ... maybe i really should try to fix it in guix lint myself ... heh.
<yoctocell>guixy: Hmm, I try something like that and report back. Thanks!
<guixy>It's only guessing, but I hope it works.
*vagrantc adopts yet another guile (guile-lib) package in Debian to support the Guix habit/addiction/hobby
<vagrantc>hmmm... kind of pedantic, but shouldn't guix pull/reconfigure/etc --allow-downgrades actually be --allow-downgrade ... when you're downgrading, you're only downgrading a singular thing, no?
<guixy>yoctocell: The gexp was just a shot in the dark. I really don't know if it will work.
<apteryx>vagrantc: it applies to all channels
<apteryx>(I think)
<yoctocell>guixy: Hmm, I used (program-file NAME GEXPS ...), but it doesn't seem to work.
<yoctocell>It only accepts <package> record types.
<lfam>I think that --allow-downgrades sounds more natural
<guixy>Not sure then. If you're going to use a manifest, you will probably recompile anyway.
<yoctocell>Nix has a `writeScriptBin' function which does pretty much what I want. Maybe Guix has some hidden gem I haven't yet found. ;)
<guixy>yoctocell: I think guile-studio is a wrapper package. You could look at that?
<guixy>It would be nice to have a contained shepherd service type. Specify the inputs you need and other parameters, and run the daemon in a container.
<civodul>yoctocell: there's wrap-program and wrap-script
<civodul>though i realize it's missing from https://guix.gnu.org/manual/en/html_node/Build-Utilities.html
<guixy>A lot of stuff is missing from the manuals.
<yoctocell>civodul: Yeah, but that requires me to recompile the package I am wrapping.
<guixy>Whenever I asked the mailing list about adding more to the manuals they say just use ,describe for everything. Never mind how the syntax-generated functions have #f documentation.
<civodul>yoctocell: ah, maybe i misunderstand though; what are you trying to achieve?
<yoctocell>civodul: I want to set an environment variable by wrapping the program in a script, but I don't want to recompile the program just to wrap it.
<civodul>yoctocell: you mean as a personal customization, right?
<guixy>yoctocell: You could use the trivial-build-system in a separate package that depends on whatever packages you need. It won't rebuild the dependent packages if they're already in your store.
<yoctocell>civodul: Yeah.
<guixy>s/dependent/dependency
<yoctocell>With Nix I could do something this: https://nixos.wiki/wiki/Nix_Cookbook
<yoctocell>I can just use `writeScripBin' and do something like "export ENV=VAR; /nix/store/...program/bin"
<yoctocell>This won't recompile the program
<yoctocell>guixy: That might be a good idea, I will give it a try.
<civodul>ah i see
<civodul>yoctocell: you could write a function that does that
<guixy>Sounds like a feature that would be fun and useful to implement.
<civodul>(define (wrap-thing program) (program-file "my-wrapper" ...))
<yoctocell>civodul: That's what I did, but `program-file' returns a <program-file>, and I want to put this in a manifest so I the wrapped thing is in my $PATH.
<civodul>'wrapped-dbus-service' is an example along these lines
<civodul>yoctocell: you can also create a manifest entry around a non-package thing
<guixy>g2g. Lots to do.
<zzappie>sorry for pluging it here, but my suggestion for the manual would be to explain `with-imported-modules/with-extensions` edge cases and maybe add examples
<yoctocell>civodul: How would I do that for a <program-file> object?
<civodul>yoctocell: (manifest-entry (inherit (package->manifest-entry pkg)) (item (wrapped-thing pkg)))
<civodul>another example: 'wrapped-package' in (guix scripts pack)
<yoctocell>civodul: Ok, will give it a try :)
<zzappie>... things lik why use ((guix config) => ,(make-config.scm)) or why not import (ice-9 ...). I spent enourmos amount of time figuring it out and still dont most of it :)
<zzappie>s/still dont/still don't get/
<yoctocell>civodul: Hmm, the builder fails when trying to build it https://paste.debian.net/1194572/
<civodul>yoctocell: yes, your programs needs to be put in a sub-directory
<civodul>(program-file "start-xdg" ...) yields /gnu/store/...-start-xdg as a regular file
<civodul>and you cannot have that in a profile
<civodul>so you need a (computed-file ...) that puts that program in a bin/ sub-directory
<civodul>a bit of boilerplate
<yoctocell>civodul: You mean that I need (computed-file "startx-xdg" GEXPS) instead of `program-file'?
<yoctocell>That returns "guix package: error: reference to invalid output 'out' of derivation '/gnu/store/jd2ql17xa8ski68mz0nppv8fp0bigivd-startx-xdg.drv'"
<apteryx>b
<apteryx>civodul: it seems if syntax-parameterize ends by #t, it'll return just this end the earlier expressions won't be honored (e.g., definitions won't be realized)
<civodul>apteryx: hmm i'd need more context
<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?
<apteryx>fail2ban
<lfam>We have an iptables kind-of clone of fail2ban, but I'm not sure that's being triggered here
<lfam>I tried looking for your IRC IP address in the logs, and did not see it
<lfam>Your IRC whois reported a different address last night
<apteryx>I think it changes every night around 3 AM.
<apteryx>it's a dynamic one
<lfam>apteryx: The weird thing is that I don't recall anybody in Europe having this prolbem
<yoctocell>civodul: I am still a little confused about the `computed-file' thing you mentioned.
<davidl>civodul: Ok. I hope one day Ill be able to maintain it appropriately but it won't happen in the foreseeable future, so if you want to close it, it's #47528.
<lfam>And for testing purposes, I successfully logged in just now
<lfam>It's really weird
<apteryx>civodul: more context: https://paste.debian.net/1194579/
<apteryx>so the trailing #t at the end of the without-field-serialization syntax definition appears to be spoiling things, yet if we take it out, it fails to compile.
<AleQu[m]>Hey all, is there a way to conclude a `--keep-fail`ed `guix build` ? I'm debugguing a package definitinon for a library that takes hours to compile.
<apteryx>AleQu[m]: you'd cd /tmp/guix-build-thepackage*; source environment; cd src; make, or something similar
<AleQu[m]>right, I've already done that
<apteryx>I'm not sure I understand the question then :-) but the answer is probably no
<AleQu[m]>I want to be sure that it would create the derivation without troubles.
<lfam>If you literally mean "create the derivation", you should use `guix build $package --derivations --no-grafts`
<lfam>That will just make the derivation, which is the low-level build instructions
<apteryx>AleQu[m]: there's no way to know that something will build in the Guix build environment without having it build there
<apteryx>built*
<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 ?
<lfam>nckx: You missed <https://bugs.gnu.org/47904>
<nij>Hello #guix! How would I start my sshd on my guix system? On archlinux it's `sudo systemctl start sshd`.. but I'm not sure about herd.
<lfam>You would use `sudo herd start sshd`
<lfam>But normally, it should be started when the system boots, assuming you've included the SSH service in your config.scm
<nij>I did have (service openssh-service-type) in a reconfigured config.scm..
<lfam>That should do it
<nij>$ ssh nij@192.168.0.22
<nij>ssh: connect to host 192.168.0.22 port 22: Connection refused
<lfam>That's not conclusive
<nij>Hmm I'm not sure where's wrong. Is there anyway to test it? On arch it always worked out of the box so I didn't learn to deal with its failure..
<lfam>Is sshd running on the computer that you're trying to connect to/
<lfam>?
<lfam>`ps aux | grep sshd`
<nij>I'm trying to connect to my guix system. 192.168.0.22 is the ip of my guix system.
<lfam>Right, but you must be able to interact with your Guix System, since you added openssh-service-type to config.scm and reconfigured
<lfam>So, access it however you did before, and check if sshd is running
<nij>lemme try. thanks :)
<lfam>Other problems could be NAT, firewalls on your LAN maybe, that kind of thing
<raghavgururajan>Hello Guix!
<lfam>I also like to reboot after reconfiguring, but maybe this isn't necessary anymore
*raghavgururajan rubs his eyes and wakes up
<lfam>Good morning
<nij>good morning
<raghavgururajan>o/
<nij>Reboot works :D thanks lfam
<lfam>Great :)
<lfam>Some things "just work" after reconfiguring, but others require rebooting
<lfam>It's inconvenient but it's nice to have clear ideas about to improve :)
<lfam>About what to improve
<nij>:)
<apteryx>civodul: I've launched a build locally with the wip-ungraft branch merged in
<apteryx>I'll report when it finishes
<AleQu[m]>(Sorry, I see my question was confusing, I meant the output of the derivation, not the derivation.)
<nckx>sneek: later tell lfam: Yes, yes I did. Sorry.
<sneek>Got it.
<zzappie>is system-test-value gexp evaluated in context of marionete vm or I need to use marionete-eval each time I want execute code in vm?
<nckx>leoprikler: Because nobody's updated wine-staging to 6.x.
<nckx>apteryx: And now? I could connect just fine right now.
<apteryx>nckx: still no go
<nckx>apteryx: I see this has been continued over e-mail.
<nckx>Oh.
<apteryx>it's weird; seems I've tripped some IP blocking mechanism
<nckx>Make sure something's not retrying. Berlin has a very harsh firewall rule that limits you to 3 connections per N minutes.
<nckx>You may think, so what, but ours is super-secure and includes successful connections just in case 😒
<nckx>^W^W^W because it's a very dump iptables line.
<andreas-e>I have seen this kind of rules before. Very annoying!
<gr0n>the simplest iptables rules never work...
<apteryx>nckx: I don't think anything's retrying on my side. I had a session, it dropped, can't connect anymore for the last 12 hours or so.
<apteryx>nckx: are you able to see which IPs are currently blocked by the firewall? If so, is mine in it?
<nckx>I'm no iptables wizard. I grepped /proc/net/xt_recent/SSH for your IP with no result. For anything beyond that I'll need gentle hand-holding.
<nckx>gr0n: Well, ‘it works’.
<nckx>It hits the foot with 100% accuracy.
<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?
<nckx>leoprikler: Try it!
<nckx>If the thrust of this question is ‘why didn't you update wine-staging harder for me, lazy boy’ I'm opting out.
<leoprikler>Well, I'm not actively using wine-staging, but it is somewhat confusing.
<apteryx>civodul: build of /gnu/store/c57f7x6kz2v4jlc2k2ydsgkgja7nrv0m-openssl-1.1.1j.drv failed
<apteryx>for emulated armhf-linux
<apteryx>I'll just refresh the branch and let Cuirass takes care of it
<apteryx>take care*
<apteryx>the error was: ../test/recipes/30-test_afalg.t (Wstat: 256 Tests: 1 Failed: 1)
<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.
<apteryx>machines*
<derivates>hi, how are launch programs dealt in guix? i used make use of the .xprofile file before switching
<andreas-e>nckx: Stop joking, I and touching iptables rules? I know nothing about anything, and certainly not about these modern technologies.
<nckx>AleQu[m]: Maybe, and this is just a wild idea: (package-version (car (assoc-ref (package-inputs this-package) "the-input"))) will side-step the issue by running entirely host-side.
<AleQu[m]>nckx: thanks will try that
<civodul>apteryx: yes, though i think mothacehe + jas4711 were working on it
<civodul>BTW the armhf guix.drv build i started earlier today is still running, building some texlive thing
<civodul>(on berlin)
<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.
*nckx AFK a while.
<AleQu[m]>Sure, I'm creating the paste right now. Sorry this is my first package definition. ;-)
<AleQu[m]>here we go : https://paste.debian.net/1194598/ (line 41, it's still incomplete, I know I must split/join the result afterwards to get the string I want)
<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?
<apteryx>rekado: ^
<jackhill>Can someone help me understand "GNU Screen through 4.8.0" (from CVE-2021-26937) Does taht mean version 4.8.0 is affected by the problem or not?
<jackhill>English is hard
<apteryx>jackhill: I think so
<apteryx>(affected)
<nckx>jackhill: I think so too.
<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.
<nckx>AleQu[m]: That's basically it!
<AleQu[m]>=)
<jackhill>nckx apteryx: yeah, ok, makes sense. I'd probably say less than or less than or equal to :)
<nckx>That would be the less ambiguous choice. Some reporters even explicitly add ‘4.8.0 is not susceptible’ just to make sure.
<jackhill>nckx, apteryx: ah, but our package definition has a screen-CVE-2021-26937.patch yay!
<nckx>I'm all for using English as she is rich, but this is not the place to explore her many charms & valleys. People who hardly speak English deserve peace of mind too.
<nckx>jackhill: Yay!
<nckx>A fruitful excursion!
<andreas-e>Mathematics! screen version <= 4.8.0
<nckx>^W^W independent audit.
<jackhill>thanks to Efraim[m]!
<nckx>Non-euclidian multiple-floating-point mathematics.
<nckx>4 + 3 + rc1 = ?
*nckx guesses 6.99.0.
<jackhill>now to figure out why `guix lint -c cve screen` results in: https://paste.debian.net/1194603/
<mdevos>nckx: do cryptographic libraries use elliptic version numbers?
<nckx>No, you never actually know the version number. You exchange random-looking numbers with upstream until you both know which version you have.
<nckx>Reporting bugs is tedious.
<mdevos>nckx: What form do version numbers take in physic libraries? They define a frame of reference first!
*nckx feels like they stumbed into some 1990s HKRJOKES.TXT.
<civodul>apteryx: /gnu/store/c57f7x6kz2v4jlc2k2ydsgkgja7nrv0m-openssl-1.1.1j.drv (armhf) successfully built on berlin!
<nckx>(It's hosted on a case-sensitive Unix system & the name is ironic.)
<mdevos>Has anyone here had time + expertise + interest in reviewing <https://issues.guix.gnu.org/47693>? ([PATCH]: Use 'cc-for-target') It has been two weeks since I sent it.
<mdevos>nckx: what does "HKR" stand for?
<nckx>I think it's short for hacker, mdevos.
<mdevos>that would make sense, nckx
<nckx>I think so too, mdevos.
<apteryx>civodul: good!
<civodul>jackhill: the "guix lint -c cve" issue you found is interesting
<civodul>apparently the newest CVE data breaks previous assumptions about the schema
<civodul>for example, CVE-2020-10020 (rejected) lacks "reference_data"
<jackhill>civodul: ah, interesting indeed. I hadn't had time yet to look at the data or code…
<civodul>jackhill: i looked out of curiosity, and it seems problematic since (guix cve) fails to parse today's streams
<leoprikler>rhou[m]: what does "get it to work with Guix" mean exactly here?
<civodul>and CVE-2020-0534 is buggy (one node lacks "cpe23Uri")
<jackhill>terpri__: another person with the flatpak certs problem: https://lists.gnu.org/archive/html/help-guix/2021-04/msg00223.html
<xgqt[m]1>Hi! I was wondering if it is possible to include a script, purely written in guile using the guix API, in a repository of some software that users would run and install dependencies.
<xgqt[m]1>All that I found was a function "build-packages" but I have no idead how to execute it to install pkgs. any help? :D
<lfam>jackhill: They said they installed openssl, nss, and p11-kit, but they didn't say that they installed any certificates (nss-certs)
<sneek>lfam, you have 1 message!
<sneek>lfam, nckx says: Yes, yes I did. Sorry.
<guixy>Where does jupyter look for notebook json files?
<guixy>I'm quite frustrated because guix isn't as cooperative as I'd hope. I need a jupyter service that can run the jupyter guile kernel by next week.
<civodul>guixy: are you sure you need a service?
<civodul>you can run it with something like: guix environment --ad-hoc jupyter -- jupyter notebook
<civodul>(maybe with additional packages)