<lispmacs>nckx: I'm not sure why the filters are failing. The debug logs show the correct paths to the filters. The filter appear to be runnable executables with the correct permissions, though I'm not sure how to duplicate the exact environment used by the cups service
<lispmacs>nckx: the debug logs don't actually say anything about the filters failing, except entries showing to print the filter error message to the WebUI
<lispmacs>maybe I can get into the source and try to see what all exact things can cause a filter to fail
<lispmacs>nckx: something interesting is that debugging logs seem to expect a file to exist at SCRIPT_FILENAME=/gnu/store/4nhhcyf7cp4ca2lxwz2rzz3ca25i6y1f-cups-2.2.11/share/doc/cups/printers/HP_LaserJet_Professional_P1102w
<lispmacs>path /gnu/store/4nhhcyf7cp4ca2lxwz2rzz3ca25i6y1f-cups-2.2.11/share/doc/cups exists, but there is no printers/HP_LaserJet_Professional_P1102w subdirectory
<kirisime>All of a sudden guix is complaining about not being able to resolve "github.com".
<nckx>kirisime: Probably just a bad cache entry. Happens to me about once a year, I just toggle my wi-fi switch or run something like ‘sudo pkill dnsmasq’ (yes, that's a sledgehammer and I'm sure there's some clean signal I could send but eh).
<kirisime>nckx: So cache invalidation strikes again. I'll try these, I guess.
<lispmacs>nckx: erm, hmm... would those proprietary drivers even install on Guix, or would I need to create my own package defintion for it?
<lispmacs>It was working on Debian free... I guess they must have just looked the other way...?
<lispmacs>my brother printer works at home with Guix, so I could get the same model I guess
<lispmacs>just might be hard to convince the boss as we've like 8 HP printers laying around
<lispmacs>maybe one of the other ones doesn't require proprietary drivers
<lispmacs>we've got a LaserJet 3800, but that doesn't seem to even be in the drivers list
<nckx>lispmacs: I am the worst person for printer support (my ♥ HP is from 2003 and if it ever breaks I will cry), but I see this one's at least networkable. No chance that it can just be used as an IPP Everywhere printer?
<nckx>CUPStream quite explicitly considers even the *concept* of drivers obsolete. Say you should use IPP with any ‘modern’ printer, which yours seems to be.
<kirisime>How likely is it that my guix can't reach github via git-download because it's a version from some ten days ago?
<lispmacs>nckx: the one attached to my computer is USB only. The other two are on the network
<lispmacs>nckx: I do not know how to set up IPP Everywhere connection to printer, but maybe something I could learn
<nckx>kirisime: Er, I don't immediately know of any bugs that would've caused that. And even then I'd be very surprised if that would result in name resolution failure.
<lispmacs>nckx: looks like CUPS handles this, so maybe I just need to figure out the IP addresses
<joshuaBPMan>Hey guix, have ya'll heard that hyperbola GNU/Linux may be migrating to an OpenBSD kernel?
<nckx>lispmacs: Assuming you have cups-filters installed (which you do), just select the ‘Generic’ Make and ‘Generic IPP Everywhere Printer’ Model when adding a printer. To actually find the printer, you can try the ‘Find New Printers’ button in the Administration tab (mDNS) or enter the ipp://xx.xx.xx.xx/vendor/specific/but/usually/print URL.
<nckx>I won't go into the IPP spiel here but: it *should* technically support every option of your vendor-specific driver hplip in a modern, vendor-independent way, which is why CUPS promotes it. In practice… vendors suck, which is why CUPS is a bit naive in doing so. So prepare to (possibly) lose some advanced options but at least you can print.
<joshuaBPMan>The hacker news commentary claimed that their reasoning is a bit premature. And I imagine it'll be hard to have nice up to date drivers...but still I do want to see where the project goes.
<nckx>‘[R]apidly proceeding down an unstable path’, sigh. Just come out & defend your opinion, Hyperbola. They tend to communicate like this a lot.
<kirisime>nckx: I herd restarted networking and nscd, but I guess I'm still connected here so...
<nckx>I'd suggest a reboot but (a) that's kind of shit, obvious advice and (b) might not even be an option.
<kirisime>Well now my wireless status icon is stuck as "?"
<kirisime>I guess I'll reboot and see what happens.
<lispmacs>nckx: IPP everywhere seems to be working for one of the HP printers. Unfortunately it is on the other side of the building
<valignatev>efraim: Omg then I'm definitely holding on. I'm 90% sure there's overlap between packages for alacritty and ripgrep. Although submitting graphics stuff (glutin and friends) should be pretty safe
<sneek>lispmacs, nckx says: Just to add to the confusion, hplip 3.19.x renamed some things in a way that's at least partially broken: https://bugs.launchpad.net/hplip/+bug/1843592 Although HP saying your printer needs a blob is probably the nail in all of this anyway.
<sneek>lispmacs, jackhill says: cool! Do you think it's worth packaging the firmware also?
<sneek>lispmacs, jackhill says: how do you plan on using the hackrf? Do we need a gnuradio package definition. Anyways, great work, thanks!
<bgardner>Good morning Guix; I just did a pull/reconfigure (and per user pull/package -u) then reboot and had a slight change - package emacs-ledger-mode is installed for my user but isn't getting the relevant link in my profile. I can see it in the store, but emacs doesn't load it since the link isn't present for /share/emacs/site-lisp
<bgardner>Double checked that I am sourcing $GUIX_PROFILE/etc/profile and all is well there, I just don't seem to have the site-lisp link anywhere. Not sure what I did to myself, or how.
<leoprikler>can you run tree on the directory returned by `guix build emacs-ledger-mode`?
<bgardner>leoprikler: 'guix build emacs-ledger-mode' crashes immediately, do I need to set up an enviroment first?
<leoprikler>guix pull -l takes time to figure out what changed, but guix build should be a no-op if you did everything correctly
<bgardner>Done, and tree <path> returned what looks like a proper tree to me
<lispmacs>jackhill: having a gnuradio package definition is not a bad idea, but not a dependency of libhackrf. In my project I use libhackrf directly. actually, to use libhackrf with gnuradio you have to also build another interface package which makes hackrf look like an osmocom block
<bgardner>Correct ledger*.el files in the right place
<leoprikler>can you paste the diff of that directory's contents and your profile's contents? (share/emacs-lisp in both)
<bgardner>Should I be switching back to the current generation first?
<leoprikler>no need to, guix pull does not affect ~/.guix-profile
<leoprikler>but you can, since you now know the build directory
<bgardner>Let me think a moment then, something weird here: I see the ledger-mode folder beneath my profile in 'site-lisp/guix.d/', but emacs is not loading it. I'm worried this is my mistake in some fashion and I don't want to waste your time if so.
<leoprikler>Ahh, it appears that ledger-mode has an outdated build
<leoprikler>We no longer use guix.d in recipes, putting the files directly into site-lisp instead. We also no longer scan directories recursively (sadly), as org-mode managed to break that setup.
<bgardner>leoprikler: Hm. And I realize now that I was dumb and didn't use -L on my find, which is why I reported ledger as not present in my profile. I see it now, but didn't expect it in guix.d, so I reported it missing.
<bgardner>Okay, I'm up to speed - what is the best approach to fix?
<leoprikler>Fix the ledger-mode package, so that files are installed directly into site-lisp
<leoprikler>also watch out for inputs that start with emacs-… those have to be propagated now
<cehteh>too bad the jit branch and/or guile emacs seem to be dead
<bgardner>Following the 'contributing' notes, and after "git clone ..." -> "guix environment guix" -> "./bootstrap" -> "./configure --localstatedir=/var" I get "checking for zlib.h... no" "configure: error: Guix requires zlib."
<bgardner>Did I miss a step, or are the docs incorrect?
<bgardner>That clearly made changes to my prompt and path, but the end result is exactly the same - "configure: error: Guix requires zlib. See http://www.zlib.net/."
<mjw>which brings me to a question, does the "daemon" need to be the same version as what the user uses? I had some oddness (bash not finding locales, but the bash that the daemon seemed to be running, not my user guix profile bash) that only went away when I made sure the root guix was the same version using guix --pull (as root... which ehm, seemed "unsafe"?)
<adflytapt6[m]>leoprikler: I've tried guix import nix with other package names - result was the same.
<leoprikler>I know. I tried it myself with telegram before emacs-telega was a thing.
<bgardner>leoprikler: To answer your question, this was the block I moved: https://paste.debian.net/hidden/60cdbb20/ As to why I did it, this is from my dotfiles, so shared among many machines (a couple of which are not guix, hence the if exists clause), so each contributes something. It may be time to house clean.
<leoprikler>I'm not really sure, what the setup for this would be. Perhaps running the nix-daemon itself is required, but why would I want to run nix if I have guix?
<leoprikler>there was recently a gist, that talked about foreign distro setups
<mjw>so, this is useful, at least to me. I never know which variables to set on a foreign distro and which are automatically handled by $GUIX_PROFILE/etc/profile (and then when or what would source that...)
<leoprikler>the idea of that was a similar (but stripped down) version of your file, but put into /etc/profile.d instead
<bgardner>Much of that code was required by a KDE Neon machine with guix stacked on top. Like I said, no longer used but hung around anyway. Likely most of this is needless on a pure guix box.
<mjw>leoprikler, when you say /etc/profile do you mean the /etc/profile on a real guix install, and/or is that the same as the user's $GUIX_PROFILE/etc/profile on a foreign distro?
<mjw>If I sound confused about all this, then that is because I am :}
<grillon>It's the first time I try on gnome I use to work on i3wm
<grillon>I guess my package is fine. I would like to share it but I cannot follow the direct checkout guide because I do not have pre-inst-env
<NieDzejkob>Hi, I'm new to Guix - currently waiting for my installation image to generate. It's currently at "building /gnu/store/longhash-disk-image.drv", so I figured I would try and see what's taking so long and how I could take a look at the progress. This makes me wonder: what's the best way to look at the source of a Guix derivation? Does Guix keep a checked-out directory of its source code somewhere?
<NieDzejkob>(I suppose I could open the repository in my browser, but then I still need to find the path in the source tree, and besides, as a "hackable" package manager, I'd expect that there would be a more streamlined method)
<rekado>NieDzejkob: a derivation is a description of a build. It references all its inputs, including build scripts and the like.
<rekado>the derivations are something you don’t really normally need to look at
<rekado>I only ever looked at them when I had to debug terrible bugs
<rekado>derivations are too low level to be of interest in Guix.