IRC channel logs

2021-10-25.log

back to list of logs

<civodul>vagrantc: damnit! is the shop providing patches, for the t-shirt?
<jgart>jonsger, 751b68981c57031d6f093dda688f92ebdbf50848, fixes a build phase in the lilypond package
<jgart>but it's still at 2.20.0
<jgart>but maybe that will help nonetheless for the next upgrade of lilypond
<vagrantc>what's default python on core-updates?
<jonsger>3.9.6?
<jonsger>is what guix show python says...
<vagrantc>jonsger: thanks!
<jgart>jonsger, you mean guix show python in a core-updates checkout? with ./pre-inst-env prefixed to the command
<jgart>or do you do you use guix show in some other way outside of a guix tree to show versions in different branches?
<singpolyma>With time machine, probably
<jgart>Ah ok. I'll give that a test drive again. Last time something failed with time-machine. Can't remember now what
<vagrantc>nckx: hi! in the last diffoscope update, you removed a bunch of #t from various phases ... when attempting to upgrade to a new version, guix spits out deprecation warnings for all those phases now ...
<vagrantc>specifically https://paste.debian.net/1216639/
<roptat>vagrantc, the deprecation warning is deprecated :p
<vagrantc>wheee.
<roptat>more specifically, the phase no longer needs to return a boolean in core-updates-frozen
<vagrantc>yeah, i vaguely recalled something along those lines as a change ... but a bit awkward to be committing changes in master while the deprecation warning is still emitted
<vagrantc>and i never am confident enough when soemthing like that pops up that i know what i'm doing :)
<singpolyma>Yeah, I have #t on all mine until master stops complianing about it
<vagrantc>what i can see is diffoscope 188 introduced some tests that fail in guix :/
<vagrantc>i suspect they're python-version specific
<jgart>Can css frameworks be package for guix upstream?
<jgart> https://github.com/vinibiavatti1/TuiCss
<jgart>This recommends using npm but it also suggests just copying the files into your project
<jgart>Could a guix workflow be made to automatically source a css framework? What would be the best approach to make it happen?
<vagrantc>where does the output of guix lint go ... it doesn't appear to be stderr or stdout ...
<jgart>For example, I'd like to also eventually package Drew Devault's antiweb css framework for guix: https://git.sr.ht/~sircmpwn/antiweb
<singpolyma>jgart: probably just package with copy-build-system ?
<jgart>singpolyma, I was thinking of that too but then how can we automate sourcing the files?
<jgart>copy-build-system will copy them to the store
<singpolyma>Sourcing in regular css or in scss or something that gets built?
<singpolyma>You'll need a preprocessor of some kind to rewrite paths to point at the store
<jgart>hmmm
<singpolyma>Unless you just want to install the framework to a profile and then reference it from an unpackaged app
*vagrantc is confused about stdout/stderr ... seems to be stdout now
<jgart>I want the experience to be something like `guix environment antiweb`
<jgart>and then source the css from the html files
<awb99>My guix system from time to time gets completely unresponsive. I think it is related to me running guix updates automatically in the background.
<awb99>Is anyone else experiencing similar issues?
<jgart>but then that will probably not work in production. I'd need a way to vendor the minified css when ready to deploy
<awb99>IT is so bad, that even a terminal window where I start htop freezes.
<awb99>so I dont know anything.
<singpolyma>jgart: well, if you package your stuff then use antiweb as an input you could use sassc -l
<jgart>hmmm, what if you disable that service and try upgrading manually to see if it still happens? Are you out of space? `df -h` Hard to tell what's going on from just your description.
<singpolyma>Since scss is a strict superset it css it will work even if you don't need scss features
<jgart>singpolyma, -l, --line-numbers Emit comments showing original line numbers.
<jgart>why -l
<singpolyma>Dev mode with guix environment could use sassc too, then you would need to make up a search path var to pass to sassc
<singpolyma>Oh, maybe not -l I just looked at the manpage maybe too quickly :P
<singpolyma>One is for load path
<jgart>ohh you meant --load-path
<jgart>the flags look similar
<singpolyma>Yeah, maybe it has no short version
<jgart>it does have a short version
<singpolyma>Oh
<jgart>it just looks very similar
<jgart>and I got confused
<jgart>-I and -l look very similar
<singpolyma>Indeed
<jgart>ha
<jgart>so the load path would point to the store path?
<singpolyma>Right
<jgart>and we would need to automate the in the package definition?
<singpolyma>Which in a package definition you can get from the inputs
<jgart>cool
<jgart>so maybe we need a css build system
<jgart>or just copy-build-system
<singpolyma>I'm not sure I've ever used that switch so may need to play with it, but seems easy
<jgart>would do
<jgart>might be nice to abstract with a css build system if we end up writing the same code over and over again when packaging css frameworks
<singpolyma>Well, you need to invoke sassc somehow, but you probably want that in dev too so a Makefile or similar with two lines that takes an optional var to set the load path or something maybe?
<jgart>so using substitute* with css frameworks in the wild?
<jgart>we probably don't want to patch a Makefile for every css frameworks we package?
<singpolyma>For packaging the framework itself you probably don't need this
<singpolyma>Just copy build system
<singpolyma>But for the web thing that uses the scss then you would use sassc
<jgart>Drew's css framework has a Makefile that calls sassc
<singpolyma>Oh, interesting. So it's written in scss itself
<jgart>so I guess in that case maybe just use gnu-build-system
<jgart>with modified phases
<singpolyma>Yeah
<jgart>and make sure sassc is available in the build phase
<singpolyma>Probably best to put the css in the store so using an scss processor is not required, unless it's a framework that provides scss vars/functions you may want to use downstream
<jgart>antiweb still has a lot to go but I might package it in a channel for now
<jgart>the repo doesn't have css unless you compile it
<jgart>doesn't have the end user css, that is
<jgart>it compiles all the scss modules to a base.css file
<singpolyma>Right. I was mostly talking to myself about why to use gnu build system here vs copy the scss to the store
<jgart>the Makefile also produces a base.min.css
<singpolyma>Bah. Min.
<singpolyma>Why do people still minify things?
<jgart>It's not good practice?
<singpolyma>Not IMO, it breaks view source
<jgart>does it help with performance/asset size?
<singpolyma>You can get the same benefit from just compressing
<jgart>ahh ok
<singpolyma>Serve gzip and/or brotli versions
<jgart>I'm not familiar with compressing css
<singpolyma>Browsers support both if you deliver right header
<jgart>but I should probably look into it
<jgart>cool
<singpolyma>Minify is mostly for obfuscation IMO
<jgart>hmm, yeah, maybe we should stop obfuscating our css
<jgart>if that's all minify is for
<singpolyma>sassc -texpanded will give the most readable CSS IMO
<jgart>cool, I'll try that next time I compile some scss
<rekado>FYI: I’m trying to fix python-jupyter-client on core-updates-frozen; I probably won’t have time to work on fixing python-pandas, though. I’d love to get some help with that one.
<jgart>what's wrong with pandas?
<jgart>or it just needs some attention?
<apteryx>rekado_: i tried python-pandas on my local cufbc branch, and it fails on the cythonization with 3 errors like: pandas/_libs/reduction.pyx:340:16: Assignment to a read-only property
<apteryx>is this what you are seeing too?
***jonsger1 is now known as jonsger
<jgart>apteryx, here's a clue to some tests that might be problematic: https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/python-modules/pandas/default.nix#L95
<jgart>in case it helps
<excalamus>good evening, Guix
<kozo[m]>vagrantc Yo, do you have guix system running on your PBP?
<vagrantc>kozo[m]: yes
<kozo[m]>Oh, there is a download for it now on latest
<kozo[m]>Most excellent
<vagrantc>kozo[m]: never used the image, but *should* work :)
<raghavgururajan>What would I need for MTP support on Guix System?
<raghavgururajan>MTP/PTP
<vagrantc>more TLA!
<raghavgururajan>TLA?
<vagrantc>Three Letter Acronym
<kozo[m]>Hahaha
<raghavgururajan>xD
<kozo[m]>Did you take a config.scm and build an aarch64 version of it vagrantc?
<vagrantc>raghavgururajan: a more constructive question might be "what are MTP and PTP?"
<vagrantc>:)
<raghavgururajan>The protocol that supports mounting phone's internal storage.
<raghavgururajan>and file transfer
<vagrantc>kozo[m]: yeah, i did a fair amount of the work adding support for pinebook-pro to guix ... so i built various images on other machines and just copied over to it
<raghavgururajan>PC <--> Phone connection.
<vagrantc>kozo[m]: and then once nvme support was working, i initialized that OS from the one running on the microSD with guix system init ...
<vagrantc>kozo[m]: curious to hear how using the prebuilt images works
<apteryx>jgart: thanks, but in my case it doesn't even got to the test
<apteryx>didn't even get*
<vagrantc>i've never really figured out how to debug diffoscope's python test suite failures on guix
<vagrantc>and diffoscope 188 is failing a few new tests :/
<jgart>vagrantc, does this help? https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/tools/misc/diffoscope/default.nix#L67
<jgart>maybe there's some failing tests in common that can point to a clue
<vagrantc>i saw someone import a patch/workaround from nix from an earlier version
<jgart>has anyone ever gotten this? ice-9/eval.scm:293:34: In procedure abi-check: #<record-type <origin>>: record ABI mismatch; recompilation needed
<kozo[m]>vagrantcI will let you know how it goes
<vagrantc>jgart: nothing obvious to me there ... none of the failing tests are mentioned
<jgart>Would anyone be interested in meeting up over jitsi to discuss with Lars-Dominik Braun regarding supporting pyproject in the python-build-system?
<jgart>He was working on some patches
<jgart>There's a number of python packages that are blocked in guix for me because they no longer support setup.py
<robin>hm, i can't seem to find existing examples of python-build-system packages that wrap PYTHONPATH (for user-runnable scripts) rather than simply using propagated inputs
<robin>which i assume might be related to this comment in python-build-system.scm: 'As a draw back, the magic of the .pth file of linking to the other required packages is gone and these packages have now to be declared as "propagated-inputs".'
<robin>but i don't know enough about python/python-build-system to know whether python-library inputs *have* to be propagated-inputs and therefore fiddling with PYTHONPATH in a wrap phase won't work
<robin>(i don't really like introducing propagated inputs except where they're basically necessary)
<robin>i guess i'll be lazy and use propagated-inputs for now, and maybe someone will come up with a fix for python-build-system later, allowing python-build-system-related propagated-inputs to be changed to regular inputs en masse
<jgart>end user applications in python usually don't use propagated-inputs
<jgart>see jrnl for example
<jgart>guix edit jrnl
<robin>jgart, oh, does python-build-system actually DTRT with python library inputs and PYTHONPATH then?
<jgart>jrnl is one of the packages that is blocked from an upgrade because it no longer includes a setup.py so the package is pretty old now
<jgart>what is DTRT?
<robin>do the right thing
<jgart>not familiar with that acro
<jgart>ah ok
<robin>(also a great movie ;))
<robin>i wondered if that was the case, because the app in question (yt-dlp, youtube-dl fork) simply crashed on startup before i added the necessary python library inputs (that youtube-dl doesn't require)
*robin builds and checks the wrapper script
<jgart>yup, you have to wrap binaries sometimes to ensure they can be referenced from the store path
<jgart>s/sometimes/usually
<robin>export PYTHONPATH="/gnu/store/z3zi7bmckk3pcblpf4idzzy72n863mg7-yt-dlp-2021.10.10/lib/python3.8/site-packages:/gnu/store/48ligdpg6s8l5yk5iglp3byqpy
<robin>i4b8jg-python-mutagen-1.45.1/lib/python3.8/site-packages:/gnu/store/c9xx34f0b2q8ihq7wpvysibf1av2f7a6-python-pycryptodomex-3.11.0/lib/python3.8/sit
<robin>e-packages:/gnu/store/4gv1mpc0af145r5983brak5xnkvwkm0n-python-websockets-8.1/lib/python3.8/site-packages:/gnu/store/sd2ic7bpv8fx3imy1j8xcjclx71sv6
<robin>q0-python-3.8.2/lib/python3.8/site-packages${PYTHONPATH:+:}$PYTHONPATH"
<robin>er, sorry for the long paste
<robin>but it does set PYTHONPATH to include the inputs!
<robin>which doesn't explain why e.g. streamlink, to pick a random python package, uses propagated-inputs for its python libraries...maybe just historical reasons
<jgart>streamlink can also be used as a library
<jgart> https://streamlink.github.io/api_guide.html
<robin>aha
<robin>apparently youtube-dl/yt-dlp can be too...so propagated-inputs it is
<robin>thanks for clarifying all that jgart
<jgart>someone else might have a lower-level answer/clarification than I can give
<lilyp>robin: The normal usage of youtube-dl/yt-dlp is not as a library, so propagated inputs ought to be avoided imo.
<robin>lilyp, ok, i'll leave as normal inputs for now
<robin>i copied the test suite invocation from https://issues.guix.gnu.org/issue/51363 (as there aren't test errors, though not running download-related tests means only ~10% of the test suite is run...)
<drakonis>right now i'm excited that i finally found out how to declare envvars for packages
<drakonis>which means i can set up tesseract correctly
<robin>a <10 line change doesn't need a copyright comment, right? (iirc it wouldn't require an *assignment* for packages that use that system)
<robin>(a minor change to run the test suite, not an APL program or anything ;))
<robin>i'll leave it out and just add Co-authored-by, someone can correct me on the bug tracker if I'm wrong
<apteryx>robin: that's correct
<robin>apteryx, ty
<vagrantc>one of the diffoscope comparators uses "pdfdump", but guix's python-pdfminer-six includes "pdfdump.py" ... i *think* they may be compatible ... should i patch diffoscope to use pdfdump.py in guix (e.g. not upstreamable) ... or should I add a symlink in python-pdfminer-six in guix to also work as "pdfdump"
<vagrantc>or... patch diffoscope to support either...
<vagrantc>maybe upstreamable
<vagrantc>er, dumppdf ... anyways
<robin>vagrantc, if pdfdump = pdfdump.py (i.e. other distros just rename it and it's not a different package altogether) a symlink sounds good, otherwise i'd modify diffoscope (upstreamably or not) or package the other pdfdump
<robin>s/pdfdump/dumppdf/
<vagrantc>yeah, adding a symlink to the package sounds cleanest ... doesn't require maintaining patches in diffoscope indefinitely
<tom444>Hello. I'd like to keep an allowlist of setuid-programs that applies across all services. I believe this amounts to introspecting my operating-system's setuid-program-services and aborting if there is a setuid-program that isn't in the allowlist.
<tom444>Given an operating-system, how can I inspect it's graph at evaluation time?
***yang is now known as Guest5872
<tom444> https://issues.guix.gnu.org/27155 would let me do this.
<tom444>Can likely do this with just operating-system-derivation, and traversing that.
<tom444>Or operating-system-services, which is higher level than a derivation, and so possibly easier to analyse. Allows me to use service-type to filter the setuid-program-service-types.
<tom444>I'll play around and write something up on the cookbook.
<rekado_>sneek: later tell vagrantc The diffoscope test failures seem to be due to a problem in libfile.
<sneek>Okay.
<PurpleSym>jgart: Huh? I’ll be participating in a meeting?
<jgart>sure, if you'd like
<jgart>trying to plan something out
<PurpleSym>jgart: Not really, sorry. I prefer to stay in the background and just write code. Happy to answer any questions regarding my changes to python-build-system though.
<PurpleSym>I haven’t found the time to turn it into a wip-python-build branch yet.
<jgart>cool, you can always do both but that's cool no worries
<jgart>do you have it available anywhere?
<jgart>the branch
<PurpleSym>jgart: There’s one here: https://github.com/PromyLOPh/guix/commits/work-python-build-pep517
<PurpleSym>It’s quite old though and very much needs a rebase onto master or core-updates-frozen (urgh).
<PurpleSym>But, if I remember correctly, the python-toolchain approach was not well-received.
<jgart>what's wrong with the toolchain approach?
<jgart>PurpleSym, does the jupyterlab package in guix-science work well?
<jgart>Is it usable?
<PurpleSym>jgart: We’re using that JupyterLab package in production and I haven’t had many complaints yet.
<PurpleSym>jgart: Wrt toolchain approach: I think Hartmut was uncomfortable with having such a package (https://issues.guix.gnu.org/46848#3)
<PurpleSym>I also did some research into getting rid of PYTHONPATH entirely. It’s possible to hook Python’s module loader and inject a search path relative to the current file. We could symlink all dependencies into site-packages, as we do for node, and write a loader that looks exactly there.
<jgart>that sounds promising
<abrenon>hello guix
<qzdlns[m]>hi guix
<wleslie>(define-public global ; a global variable
<wleslie>well played, whoever is packaging gnu global
<efraim>I found out the hard way it's actually a warning, it's hard to reference the global package because it's also a variable in guile
<wleslie>ah
<efraim>git blame suggests it dates to at least March 2015, when it was moved to that file
<civodul>Hello Guix!
<abrenon>hi civodul
<attila_lendvai>when i guix environment --ad-hoc libffi then in the shell LD_LIBRARY_PATH is not updated to include libffi. what am i missing?
<civodul>attila_lendvai: LD_LIBRARY_PATH is never used in Guix; in general, it's a "dangerous" variable because it affects run-time behavior
<civodul>or did you mean LIBRARY_PATH? (used by GCC & co.)
<attila_lendvai>civodul, my high-level goal is to be able to run/build (common lisp) non-guix stuff in the shell the old way that wants to dlopen libffi.so.7
<civodul>ah
<civodul>the way this is usually addressed is either by passing absolute file names to dlopen
<attila_lendvai>then i guess i'll need to write a small shell script that enters the env, and updates LD_LIBRARY_PATH, right?
<civodul>or by having another, focused environment variable, like GST_PLUGIN_PATH for gstreamer
<civodul>try hard to avoid fiddling with LD_LIBRARY_PATH; this will affect sub-processes as well, and then things could go wrong
<attila_lendvai>i just want to run this thing and be done with it... how can i get the store path of a package?
<civodul>you can do: export LD_LIBRARY_PATH=$(guix build libffi)/lib
<efraim>you can also check `guix environment --ad-hoc libffi -- ls \$GUIX_ENVIRONMENT/lib` to see if something like that would work
<efraim>ok, I got useful results with this: guix environment --ad-hoc libffi -- sh -c 'ls $GUIX_ENVIRONMENT/lib'
<attila_lendvai>excellent, thank you!
<attila_lendvai>is there a way to tell bash to enter interactive mode after -c? this doesn't work: guix environment --ad-hoc libffi -- bash -i -c "export LD_LIBRARY_PATH=$GUIX_ENVIRONMENT/lib"
<attila_lendvai>FTR, guix environment --ad-hoc libffi -- bash --init-file <(echo "export LD_LIBRARY_PATH=\$GUIX_ENVIRONMENT/lib") as per https://serverfault.com/questions/368054/run-an-interactive-bash-subshell-with-initial-commands-without-returning-to-the
<efraim>you can switch to `guix environment --ad-hoc libffi` and then just run everything interactively
<attila_lendvai>i want a script called lisp-env that sets this up. i'll use this a gazillion times...
***Guest5872 is now known as yang
<efraim>a previous message got cut off, what about turning it around?
<efraim>bash --init-file <(echo "guix environment --ad-hoc libffi -- sh -c 'export LD_LIBRARY_PATH=\$GUIX_ENVIRONMENT/lib'")
<attila_lendvai>this works good enough: guix environment --ad-hoc libffi zlib openssl libfixposix sdl2 sdl2-gfx sdl2-image sdl2-ttf graphviz -- bash --init-file <(echo "export LD_LIBRARY_PATH=\$GUIX_ENVIRONMENT/lib; source ~/.bashrc")
<civodul>so, how 'bout merging "guix shell" today?
<civodul>looks like there are no more comments, which i'm tempted to interpret as "go ahead"
<civodul>mothacehe, efraim, nckx, apteryx, mbakke: thoughts? ↑
<civodul>it's at https://issues.guix.gnu.org/50960
<attila_lendvai>civodul, as a newcomer when i saw --ad-hoc i was completely clueless. the addition of guix shell is a perfect moment for finding a better name for --ad-hoc
<civodul>attila_lendvai: "guix shell" has no --ad-hoc, that's its raison d'être even :-)
<civodul>see the intro message above
<attila_lendvai>civodul, oh, sorry, i misread the diff. great!
<mothacehe>civodul: hey! afaic, i think you can go on!
<civodul>mothacehe: cool, thank you :-)
<civodul>i'll prepare a blog post so users know about it, the rationale, and how to migrate
<efraim>rekado_: I think I have a fix for python-pandas on core-updates-frozen, testing it now
<efraim>civodul: no more comments looks good :) I vote go ahead
*efraim still needs to hunt down a (target-riscv64?) bug before pushing wip-riscv to core-updates-frozen
<civodul>efraim: yay, thanks!
<mbakke>civodul: yay! not happy that I have to create ~/.config/guix/shell-authorized-directories ;) -- but there are valid concerns against auto-loading, so a safe default makes sense.
<civodul>mbakke: ah good, thank you too :-)
*mbakke would like to propose a corollary to the oft-quoted Zen of Python: "implicit is better than none at all" :P
<civodul>creating shell-authorized-directories should be mostly okay: you just need to copy one "echo ..." line that the hint displays
<civodul>heh :-)
<efraim>I recently had to do the same thing to create some .exrc files in guix repos to autogenerate GTAGS and load them into vim
<civodul>the "Zen of Python" is the new "Unix philosophy"
<civodul>(i admit i feel as many ties to Unix than to Python, which tells a lot :-))
<abrenon>writing a lot of guix environment --ad-hoc today writing some code and I'm excited to see the new guix shell command coming up : )
<civodul>heh
<rekado_>efraim: superb!
<rekado_>I’m still struggling with python-jupyter-client
<rekado_>upgrading is not trivial as that introduces more loops
<rekado_>(e.g. ipykernel -> ipyparallel -> ipykernel)
<abrenon>I'm trying to reproduce an older state of my package which I build from a local definition: (source (origin (uri "/some/local/path")…)…)
<abrenon>I checked an old commit in the repos at /some/local/path, now I get issues with versions conflicts for base because the ghc package moved, so I'm passing a #:haskell argument to the definition of the package to override it
<abrenon>the correct version of base is now found, but I still get missing dependencies for another library (optparse-applicative) (which has always been in the (inputs …) of my package. Isn't it supposed to "follow" the version of ghc ?
<abrenon>what could be missing ?
<PurpleSym>rekado_: I tried upgrading the whole jupyter universe a while ago, but got stuck at python-jupyter-packaging, which needs a newer setuptools. Do you have a workaround for that?
<Guest2>how do i check the log of a specific herd unit
<Guest2>like in systemd we have journalctl -u <service-name>
<rekado_>PurpleSym: no, I haven’t gone nearly as far.
<rekado_>I just want it to compile on core-updates-frozen with the smallest amount of effor
<rekado_>*t
<rekado_>I get test errors like this: TypeError: get_msg() got an unexpected keyword argument 'block'
<rekado_>and I think this must be some API mismatch in some asyncio input
<wigust>hi guix
<rekado_>close: it’s actually defined in kernel.inprocess.blocking
<rekado_>I think the versions are all messed up
<rekado_>python-ipython is at version 7.27.0, and ipykernel is at 5.5.6 (with my upgrade), though 7.x already exists
<rekado_>these things must be upgraded together
<rekado_>right now they span different eras
<Guest2>any idea how to get emojis working
<rekado_>PurpleSym: does your WIP apply on top of core-updates-frozen?
<Guest2>tried download every emoji related package lol didnt work
<PurpleSym>rekado_: No, I think it was on top of master.
<abrenon>Guest2: no, I usually use ibus for that on other distributions but I haven't managed to make it work on guix yet
<rekado_>PurpleSym: re setuptools: we have 52.0.0 (at least on core-updates-frozen). Would that be enough?
<rekado_>you may need to use that same setuptools for all packages, lest the old setuptools propagated by some other package is found first
<jpoiret>isn't the architecture always appended to the store name when cross-compiling? i'm doing `guix system image -t hurd-raw template.tmpl` and the store names look normal (with ofc the hash being different)(
<PurpleSym>rekado_: The problem on master is that Python itself bundles setuptools, but I think Python 3.9 (3.10?) has a version that is new enough.
<Guest2>[1:52:44 PM] <Guest2> how do i check the log of a specific herd unit
<Guest2>[1:52:58 PM] <Guest2> like in systemd we have journalctl -u <service-name>
<attila_lendvai>if i pick up an issue and fix the patch, then how shall i credit the original author in the commit message? just some free flowing text mentioning the fact?
<excalamus>good morning, Guix
<excalamus>for some reason, the icons for Plover don't show in the gui. I can run find and see that they're in site-packages.
<PurpleSym>Can someone add the branch wip-stackage-18.14 for i686 and x86_64 to the CI?
<civodul>PurpleSym: done! https://ci.guix.gnu.org/jobset/wip-stackage-18.14
<PurpleSym>Thanks, civodul! Hm, it only evaluates the branch when I push again, right?
<abrenon>if I understand correctly, the problem I'm facing is because the current definition of ghc-optparse-applicative relies on ghc, not ghc-8.6, and, hence, isn't visible from ghc-8.6
<abrenon>I set out to inherit ghc-optparse-applicative to redeclare an older version for that package, and, likewise, I face problems with its dependencies
<PurpleSym>abrenon: Yes, you have to rewrite the entire tree recursively to use GHC 8.6.
<abrenon>isn't the (arguments `(#:haskell ,ghc)) supposed to apply to the whole dependency tree ? is there a way to tell guix to replace the compiler ?
<abrenon>(everywhere, I mean)
<abrenon>PurpleSym: thanks for the confirmation
<PurpleSym>No, it’s just for that specific package.
<PurpleSym>You can have a look at `package-with-explicit-python` in `guix/build-system/python.scm`. We don’t have anything equivalent for GHC right now.
<abrenon>ok ! thanks !
<civodul>PurpleSym: hmm i suppose it'll start evaluating soon?
<civodul>not sure why it's not doing it already
<PurpleSym>I tried to repush. Let’s just wait a little.
<civodul>i'll monitor the Cuirass logs
<civodul>so far it just seems to be doing something else
<abrenon>wow, package-with-explicit-python looks very handy
<mothacehe> civodul: the Cuirass remote-server is trying to fetch 633 items from workers, so looks like there's some kind of obstruction on berlin's guix-daemon
***stikonas_ is now known as stikonas
<civodul>mothacehe: obstruction or contention?
<mothacehe>not sure and I cannot investigate it right now sadly
<civodul>mothacehe: i don't get the context though; did you notice that berlin was slow? is there some intensive activity going on?
<civodul>or does it have to do with wip-stackage-18.14?
***owen is now known as bobrossrtx
<zimoun>hi!
<rekado_>PurpleSym: if you could share your WIP for the jupyter upgrades I could attempt to transplant it on top of core-updates-frozen.
<roptat>hi guix!
<abrenon>hi zimoun and roptat
<zimoun>We were chatting with civodul about an expiration date of “guix environment” – a real date as may 1st 2021 vs at release v1.5 time – and civodul raises the releasing scheme: plain integers as Firefox, GCC, systemd and others vs major dot minor. Since Guix is “rolling release”, release is only public communication. What do people think about release numbering?
<zimoun>chat was happening on #guix-hpc <http://logs.guix.gnu.org/guix-hpc/2021-10-25.log>
<roptat>guix 1532 would be crazy :p
<roptat>(well, if we actually manage to release often enough to get to that version)
<zimoun>I am waiting version 42 which will be the answer :-)
<roptat>to me, switching from 0.xx to 1.xx was meaningful, as would be changing major version later
<civodul>Guix 1532 would be released in 2142 according to the current release rate
<roptat>not so distant future :)
<civodul>(at that point we'll have quantum computers working on paper because all natural resources will be exhausted anyway)
<civodul>roptat: for example i wonder whether the next one should be 1.4 or 2.0
<zimoun>especially burning a lot when compiling Guix ;-)
<civodul>heh
<rekado_>I find ISO 8601 ordinal dates neat as version numbers.
<roptat>what I like with major.minor is that most releases can be communication, and some of them convey a message about the goals we reached
<civodul>i guess the question is: how do we convey the magnitude of changes introduced since the previous release?
<zimoun>rekado_: as Ubutun for instance ?
<civodul>roptat: yeah, exactly
<rekado_>civodul: NEWS
<roptat>with a date or number change, we don't convey anything
<rekado_>a date conveys recentness.
<rekado_>1.3 could be 10 years old or 2 days. I don’t know.
<zimoun>to me, release should be based on calendar. Every 6 months or so.
<civodul>rekado_: we need a bird's eye view though
<civodul>e.g., Phoronix won't talk about 1.3.1.4, but it's more likely to talk about 2.0
<vivien>Guix is a program too, so it needs major updates and minor updates.
<civodul>it's a set of programs, a set of libraries, and a distro
<rekado_>oh, yeah, speaking with my dusty GWL hat on: big API changes must be visible.
<vivien>To maximize phoronix coverage, maybe we should number the guix system and guix differently
<vivien>But I don’t think it’s a valuable metric ^^
<civodul>i'm taking Phoronix as an example, but i don't want to imply that it should be our main criterion either :-)
<roptat>or delay guix system release by one week, so we get a news for guix, and one for guix system :p
<roptat>(now that would be confusing ^^)
<abrenon>I like major and minor version numbers to convey information about the amount of change in the "shape" of a program (breaking changes), like in semantic versioning
<zimoun>to me, we should release around the date of FOSDEM because we often have audience, and then 6 months later. Whatever the numbering.
<roptat>we could also have more releases, maybe that would reduce the work needed for each of them?
<zimoun>roptat: yes, I think.
<vivien>Also, big numbers start to be confusing. For instance, if I say I’m running systemd version 224, do you think I’m up to date?
<zimoun>I think we should release after each core-updates merge (~once a year) and another in the meantime.
<vivien>(Of course, I’m not, I’m running the almighty shepherd)
<zimoun>systemd 224 is more recent than the one running on my Debian stable ;-)
<zimoun>civodul: I prefer an ISO 8601 numbering than a plain integer.
<zimoun>and I like the Linux kernel project way.
<vivien>Since there is a link between the release date and the software in the distribution, the date is a better option than an increment.
<nckx>Morning, Guix.
<nckx>zimoun: Random major bumps whenever Linus^Wcivodul feels like it?
<vivien>What about MAJOR.MINOR, where MAJOR is increased for each world rebuild on master?
<vivien>And MINOR is nckx’ solution
<zimoun>nckx, no it is not random major bumps. After minor 19, it is hard to count so bump major. Somehow. :-)
<nckx>I claim no credit for the YOLOversioning scheme; I feel like many projects got there before me.
<nckx>zimoun: That's what I meant 😛
<nckx>(Which, by the way, is probably a fine versioning scheme for Linux. It's not like semver makes any sense.)
<nckx>zimoun: <expiration date of “guix environment”> What's that about?
<nckx>Don't say “guix environment”.
<civodul>nckx: the deprecation date i proposed in v3 at https://issues.guix.gnu.org/50960
<civodul>but see, version numbering is such a difficult topic!
<nckx>You won't believe me, but I literally painted a shed today. If any expertise would be needed.
<zimoun>2 hard things: cache invalidation and naming stuff. ;-)
<nckx>civodul: OK, I had somehow missed that environment would be deprecated too.
<vivien>civodul, for guix shell you propose that it has shepherd services, do you mean that when we run guix shell and there’s a guix.scm file it should start these services?
<vivien>(the services defined in guix.scm)
<nckx>Today's backlog is scrumptious! So much on-topic #content vs. the usual ‘is startx Leninist?’ chats. I'll make coffee & read & answer you civodul.
<PurpleSym>rekado_: I pushed it as-is here: https://github.com/PromyLOPh/guix/tree/work-jupyter-update Sorry, not in a good shape :(
<civodul>nckx: sure!
<civodul>draft post about 'guix shell': https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/guix-environment-to-shell.md?id=4b3e8ead2d3a2daafc4d2eec679578d48f2313f1
<civodul>feedback welcome!
<zimoun>civodul, “guix environment -l guix.scm” is replaced by “guix shell -D -f guix.scm”. It allows “guix shell -f guix.scm” which was not possible with “guix environment”, right?
<Olivetree>typo in line 19: "how it differs form" -> "how it differs from"
<civodul>zimoun: yes
<civodul>Olivetree: noted, thanks!
<jpoiret>it really took me that long to find out ludovic backwards was civodul
<jpoiret>now i feel like an idiot
<zimoun>civodul, maybe it is worth to mention, no?
<zimoun>civodul, LGTM.
<civodul>jpoiret: heheh, it's always fun when people say this (you're not the first one) :-)
<civodul>zimoun: yes, why not; thanks!
<vivien>> Just run `guix pull` to get this shiny new `guix shell` thingie!
<vivien>Is it in another branch?
<jpoiret>nckx: apologies for the ugly looking reply, thunderbird did not cooperate at all. I've setup notmuch with emacs now, following mails should be properly formatted
<Olivetree>Is it possible to replicate `guix environment python2-numpy python2-scipy --ad-hoc python-2.7 -- python` with the new guix shell?
<Olivetree>perhaps with `guix shell -D python2-numpy -D python2-scipy python2.7`? I know it's a contrived case, but just wondering
<singpolyma>Yes, I think that's it. You just reverse --ad-hoc and -D
<Olivetree>And --ad-hoc is used for all of the packages following it, while -D is only used for the next package. Notice I used 2 -D as there were 2 packages non-ad-hoc. Is that it?
<Olivetree>If that is the case, maybe it should be mentioned in the post. It is not clear to me, at least
<civodul>Olivetree: -D is only for the immediately following package so yes, you need -D twice in this case
<Olivetree>Cool, thanks!
<civodul>it's the first time i see a plausible example use of with several development packages
<civodul>plausible to me at least, i don't know much about numpy/scipy
<civodul>is it a feature that you used so far?
<Olivetree>Nope, it was just the least stupid example I could think of and was based in the manual
<singpolyma>If guix.scm and manifest.scm are both present, which will guix shell use?
<civodul>Olivetree: ah, see? :-)
<civodul>singpolyma: it looks for guix.scm first, manifest.scm second
<singpolyma>Hmm. That's unfortunate
<civodul>why?
<civodul>i haven't put much thought into that
<singpolyma>Because if I put my program's package in guix.scm it would be nice to provide a manifest for the inputs + dev tools
<civodul>+ dev tools that are not already inputs?
<singpolyma>Right, like linter etc
<civodul>hmm i see
<Olivetree>civodul: hehe, still, someone might need it. document today, avoid pain tomorrow xD
<civodul>Olivetree: yes, i've added a note in the post (will push later), and it's documented in the manual
<civodul>singpolyma: but then, what would you use guix.scm for?
<civodul>guix build/install?
<singpolyma>Yes
<civodul>ok, makes sense
<civodul>manifest.scm is more expressive too, so it prolly makes sense to prioritize it
<civodul>right in time for fine-tuning :-)
<Olivetree>when will guix shell be available?
<civodul>i'm going to push it soon
<civodul>that's why i was asking people earlier today if they had anything left to say
<thorwil>hi! how do i find out which version of a library will be used by a package? perhaps by adding pkg-config to my profile, then calling it with its full path to get past the distribution’s pkg-config?
<roptat>the package will use libraries defined in its inputs
<roptat>so you can try looking at the dependency graph
<roptat>you can also use ldd to look at exactly which libraries will be used by a binary
<roptat>since guix doesn't install libraries by default, pkg-config will not find them anyway
<thorwil>ah, ldd works niceley for my purpose. thanks, roptat
<thorwil>strange how inputs to this package include gtk and webkitgtk, with no trace of those in ldd’s output
<vivien>These libraries are loaded via typelib
<vivien>I guess
<thorwil>anyway, i wrote a package for bespokesynth (https://github.com/BespokeSynth/BespokeSynth). it build and starts, but so far i don’t get audio output
<thorwil>and there’s an offset between mouse pointer position and where the app thinks the pointer is
<thorwil>what’s the policy regarding such a package? submit to guix-patches with a note?
<vivien>Given the name, I doubt having it without audio output will be very useful ^^
<thorwil>it shouldn’t be added in that state, but anyone else writing a package from scratch would be a waste
<roptat>yeah, you can send to guix-patches with a note, maybe even mark it WIP
<nckx>‘As for ‘--update’, I prefer the behavior implemented here because it’sstateless and thus more predictable.’ Yeah, deffo. civodul, I have zero thoughts, which is good (I'd been following it in the background but now it's suddenly about to become real :)
<civodul>nckx: heh, alright, thanks for taking a look!
<civodul>but yeah, we've been talking about change along these lines for years, and finally it's coming
<civodul>alright, guix shell's in the house!
<lilyp>woo, party hart!
<podiki[m]>who can I bug about patch review (series of flatpak patches, submitted more than 2 weeks ago)?
<podiki[m]> https://issues.guix.gnu.org/51100 for reference
<civodul>podiki[m]: sure, pinging is welcome, thanks for the heads-up!
<podiki[m]>no problem! (I have some new packages to submit too, now that I'm getting the hang of patches I think)
<civodul>podiki[m]: it LGTM, but, for p11-kit-next, with replace --without-trust-paths by --with-trust-paths=/etc/ssl/certs/ca-certificates.crt ?
<civodul>i'd remove the 'arguments' field altogether, otherwise it's more than a mere update and would need discussion
<civodul>if we can clarify that, i may be able to apply the series :-)
<podiki[m]>that is due to this bug: https://issues.guix.gnu.org/49957
<podiki[m]>civodul: I wasn't sure what the reasoning is for --without-trust paths, presumably that is important for something? (nix also made this configuration to --with-trust-paths for at least flatpak I saw)
<podiki[m]>so if we don't want to have --with-trus-paths for p11-kit in general, then should we have a separate p11-kit just for flatpak due to this bug?
<podiki[m]>(sorry the flag wasn't in the commit message, it should be)
<civodul>oh i see
<civodul>hmm
<civodul>--without-trust-paths was added at the beginning in 27e86bed5371630d5b74ea839115aa39a11f852d
<civodul>the motivation got lost in time
<podiki[m]>yeah, I don't know enough about p11-kit to know why this is/was important
<civodul>perhaps it was to mimic the default behavior of things like GnuTLS, which don't do that by default
<civodul>ok, so i'll split that patch of yours in two parts: adding p11-kit-next, and adding --with-trust-paths
<civodul>sounds good?
<civodul>with a link to the bug above
<podiki[m]>sounds good to me
<podiki[m]>with the note about why the configuration change?
<podiki[m]>then p11-kit-next can be tested against in core-updates for the next p11-kit?
<civodul>why the note? so our future selves know why we did this
<podiki[m]>do we have anywhere to record something like that, so when next core-updates comes around we have a hint of things that might break? or is is the -next naming enough
<civodul>for core-updates, i don't know, prolly too late
<podiki[m]>i mean next cycle
<podiki[m]>trying to save future selves work :)
<podiki[m]>but I guess the commit message and -next naming should do that
<civodul>yeah
<podiki[m]>civodul: thanks! should I (can I?) go through and close a few Flatpak bugs referenced in that series?
<podiki[m]>(there were some on the portal updates I recall)
***CompanionCube is now known as CrazyCube
<civodul>podiki[m]: sure!
<civodul>i just realized p11-kit has few dependents, so we could update it wholesale
<civodul>on master
***CrazyCube is now known as CompanionCube
<podiki[m]>I was just looking at that, but what about packages that use it indirectly (not sure through what), like flatpak?
<podiki[m]>is that something that is problematic?
<thorwil>i wonder if i should submit this one again, cleaned up and as a series (which i don’t know how to do, yet)? or should i look into replacing those patches with substitutions? https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48632
<civodul>thorwil: could you send a v2 with a "clean up" commit log, without 'native-search-paths' (it's redundant i think), and with patches added to gnu/local.mk?
<civodul>i won't review/apply everyone's patches just tonight but happy to defer
*civodul looks around
<thorwil>not familar with gnu/local.mk, yet
<podiki[m]>local.mk was new to me too, noted for future reference!
<Olivetree>fellow guixers, I'm still having an issue with nss-certs: it won't install, terminates with exception: Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert wide string to output locale" 84 #f #f)'.
<roptat>thorwil, you'll find a list of patches in the file, just add yours there (in alphabetic order)
<thorwil>is there a failed attempt to line up the closing \ in local.mk, or is there any relevance to the whitespace?
<Olivetree>I have glibc-locales in root and my profile. my locale is en_US.UTF-8
<roptat>thorwil, it's tabs, with 8-spaces per tab
<roptat>should align at 81 chars I think
<thorwil>ah, ok 8-)
<roptat>Olivetree, hi, sorry I don't know what's wrong...
<Olivetree>civodul: found this in my search https://lists.gnu.org/archive/html/guile-user/2013-08/msg00077.html
<thorwil>what’s the best way to submit the patch files themselves, though?
<roptat>I remember this being an issue a long time ago, or you on a very old guix?
<Olivetree>Ah, meanwhile I have also installed guile through guix (was using version 2.2 from my distro)
<roptat>thorwil, what do you mean? just commit them together with the change that introduce them?
<Olivetree>roptat: I have Guix on top of Void. Installed 1 week ago :)
<roptat>yeah, couldn't be that easy :p
<thorwil>roptat: ok.
<roptat>Olivetree, is this locale also used for root?
<roptat>void doesn't use systemd, does it?
<Olivetree>Yes, root also has en_US.UTF-8. No systemd, I try to avoid dictatorship in my computer.
<roptat>can you try adding this to whatever launches the daemon: GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale LC_ALL=en_US.utf8
<roptat>and restart the daemon with that, of course
<Olivetree>Hell yeah it worked!!
<civodul>Olivetree: nss-certs won't install, as a substitute?
<civodul>oh well, you found out :-)
<civodul>the systemd file sets GUIX_LOCPATH and LC_ALL so normally you can't encounter that problem
<roptat>Olivetree, was the variables? which init system do you use?
<roptat>civodul, unless you don't use systemd :p
<Olivetree>Yes, it is as a substitute. I use runit. When I sudo su - root I have GUIX_LOCPATH=/root/.guix-profile/lib/locale LANG=en_US.UTF-8 ... will try to see if runit interferes with that
<civodul>ah runit, now that's original :-)
<civodul>actually i think only LC_ALL is needed because guix embeds glibc-utf8-locales
<podiki[m]>(closed a couple flatpak/portal bugs, including an old one in the 3700 range)
<Olivetree>If I remove glibc-utf8-locales I start getting "hints" when running guix install
<civodul>oh
<Olivetree>oh dang... nss-certs requires relogin :'(
<roptat>civodul, could I do "guix time-machine -- shell ..." for a pre-guix-shell commit? or does it use the guix from back then, so I can only use guix environment (and conversely, can I time-machine forward to try guix shell from a guix that's not yet at that commit?)
<roptat>(it's not a comment on guix shell specifically, I'm just curious how the time-machine works)
<vagrantc>civodul: i was wrong about the typo in the typo poem, it looks perfectly wrong.
<sneek>vagrantc, you have 1 message!
<sneek>vagrantc, rekado_ says: The diffoscope test failures seem to be due to a problem in libfile.
<vagrantc>rekado_: oh, thanks!
<civodul>vagrantc: pfew, i feel better knowing that you were wrong and that the text is indeed wrong
<civodul>this typos allows to sleeep well
<civodul>roptat: yes, time-machine goes back entirely, you get all the bugs and missing features
*vagrantc wonders if these are test suite failures on the current diffoscope version in guix, of if rekado_ tested updating to the newer version
<civodul>roptat: there's a discussion at https://guix.gnu.org/en/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/
<vivien>Hi, I don’t remember if I posted it or not, so I’ll risk repeating myself. I use guile-gi for my program, and I think it’s broken on core-updates-frozen*, but I don’t know why: the tests seem to pass, but the check phase fails.
<roptat>civodul, thanks
<vagrantc>ooooh, guix shell has landed!
<civodul>yup!
<podiki[m]>and just saw core-updates-frozen-batched-changes is building on the CI woo
<Olivetree>Yeah, guix shell in da house! Gonna see if I can try it out tonight :D
<vagrantc>what does python build system typically run in the 'check target?
<vagrantc>python setup.py test ?
<vagrantc>if i want to pass -vv as an argument, do i have to replace 'check and then call whatever i want generally, or is there a test-flags or something?
<vagrantc>alternately, would it make sense to pass the -vv argument to tests by default?
<vagrantc>(only learned about this because that's essentially the default in debian with recent debhelper versions)
<vagrantc>i had wondered why the tests information for diffoscope was so much more readable in debian :)
<Olivetree>I just wanted to say thank you for the work you've done with Guix and environment/shell! I just saw about about 96 packages which I'll never use outside the scope of these particular (2 for now, more to come) temporary projects (with many more to come) getting installed in a profile, without messing my main system and without duplication of install
<Olivetree>ation in each of the projects folders. It's just... orgasmic
<Olivetree>I've also been wanting a per-user package management system for more than a decade now
<Olivetree>I'm feeling Zen
<vagrantc>i mean, you could already do that with "guix environment --ad-hoc package1 package2 ..." although guix shell saves you from typing --ad-hoc and "shell" is shorter and easier to type than "environment" :)
<vagrantc>also a few other improvements along the way
<Olivetree>Yes, but I started using Guix less than a week ago. Never really got the time to go into guix environment, but I did mention the command right before shell. And because it auto-loads manifest.scm I just type guix shell.
<Olivetree>Now, if I could just auto-create a manifest.scm from a pyproject.toml
<lilyp>python-build-system does not handle pep 517 (yet)
<lilyp>No idea whether it already does on c-u-frozen
<Olivetree>My boner just disappeared :( Guix is on python 3.8 and 3.9 is required for the project
<vagrantc>i think 3.9 is in core-upates ... also, guix makes it *relatively* easy to support multiple concurrent versions of things
<Olivetree>yes, but they do have to exist
<b3>Hi, how can I search for a package that installs a particular binary? For example I want to install the dig utility, but I am not sure what package includes it. Is there a way to search for all packages that will install a binary named "dig"?
<vagrantc>Olivetree: they're not crazy hard to add
<Olivetree>For a beginner short on time, it is
<Olivetree>But I found an easier way: change the python version requirement.. I'm sure it was that one just because it's the latest
<vagrantc>yeah, that often works too