<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 ...
<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
<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)
<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...
<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
<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?
<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.
<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 ?
<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?
<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?
<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
<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
<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)
<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>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.
<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.
<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
<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
<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