<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...? <nckx>And support here aside, I really doubt the plugin installer would work on Guix. <lispmacs>nckx: dang. We got a supported printers list somewhere. I think I got my Brother printer working at home <nckx>(I had to jump through quite a few hoops to even get the regular hp-* tools working, and some of them are still bork.) <nckx>lispmacs: An on-line list? <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>nckx: They claim that linux is moving in a less freedom direction. <nckx>I honestly don't know. Turned your daemon off & on again? <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 <lispmacs>hmm, foiled from using my printer by proprietary drivers. I think I'm going to have to go out and start a free software movement. <kirisime>I think since we have internet you can stay inside while starting one nowadays. <joshuaBPMan>I do hope the guix starts to offer the Hurd as a kernel alternate, but it is not very likely if there does not exist some Hurd business... #unpopularopinion <nckx>joshuaBPMan: s/Hurd business/Guix business + &/. ‘Commercial success’ has had no effect on the kernels Guix supports, one way or the other. Guix/Darwin? Nowhere. Nix/Darwin? Big deal. <nckx>(And I'm fine with that.) <kirisime`>The pre-inst-env guix I have from a couple days ago doesn't resolve anything either. <kirisime`>Which reminds me of that test that would stall back then... <nckx>Guix/Hurd isn't limited by hardware support, which commercial success does usually improve, either. The one straight-up still doesn't run on the other. <nckx>(I haven't been around much the past weeks so maybe I missed the fun DNS bug.) <kirisime`>Oh, it really seems like only git-fetch is affected too. I could download geary with a mirror:// URL just fine. <kirisime`>I'm running the test suite again to see if it stalls at the same spot. If it does, what was wrong wasn't just temprorary. <kirisime`>Also, every source download that's in the guix source tree works, maybe because there's substitutes and mirrors. <joshuaBPMan>nckx: But isn't the Hurd limited by hardware support? It won't run on Arm or power for example... <kirisime`>What does terst/packages.scm test for anyhow? How long is it expected to take? <nckx>joshuaBPMan: Fair enough, I'm snugly within my x86 bubble where ‘hardware support’ == drivers. <nckx>‘Test the high-level packaging layer.’ So stuff like package expressions parsing & behaving as expected, all inputs being input, all outputs being output, grafts working… <nckx>As for the run time, I can't say. <nckx>It doesn't *look* like it should take particularly long compared to the rest of the suite though. <nckx>kirisime`: ☝ If anything it's probably I/O bound. <kirisime`>Too bad my laptop is too loud to be left running overnight. <nckx>ScaredySquirrel: I don't know, but remember that the Guix KDE ‘team’ is really just one ‘guy’, not plural. <kirisime`>error: this-package-does-not-exist: unknown package <kirisime`>error: package `coreutils@8.31' lacks output `does-not-exist' <nckx>That's likely the correct output the test is looking for. Maybe the next one is the one that's actually stuck? <nckx>(Thats ‘zzz’ for you non-Unicodians.) o/ <kirisime`>...I sure feel stupid now, packages.scm passes, pack.scm stalls because guix tries to offload something and the build machine is offline! <kirisime`>Name resolution with git-fetch is something else. <str1ngs>though it could be a libgit2 issues as well. what problem are you have kirisime` <kirisime`>str1ngs: Writing a new package definition and attempting to build it, if the source is to be downloaded using git, guix will fail to resolve the host. <kirisime`>Guix then tries to download from berlin and from software heritage, but both attempts fail. <kirisime`>Suspecting that it's an issue with DNS caching, I've restarted all releavant services and done a reboot. The issue even affects a pre-inst-env guix that's a newer version. <jackhill>sneek: later tell lispmacs cool! Do you think it's worth packaging the firmware also? <jackhill>sneek: later tell lispmacs how do you plan on using the hackrf? Do we need a gnuradio package definition. Anyways, great work, thanks! <brettgilio>nckx: how strange you push a commit for bigloo right when I was having a discussion about it in a private message. <nckx>Now we hope that the discussion was not ‘do not push that bigloo update, it is badly broken’? <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 <lispmacs>after I've created a new user by adding her to config.scm and doing a reconfigure, what is the easiest way to correct her home directory with all the correct files? <sneek>lispmacs, you have 4 messages. <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! <efraim>they should be created automatically from the skeleton file somewhere. In the past I've just gone through and manually fixed things as necessary <rekado>It looks like my troubles compiling a newer version of newlib with a cross-compiler based on GCC7 are related to the change in environment variables used to specify theinclude search path. <rekado>I can build the newer newlib (newerlib?) just fine with the cross compiler based on GCC 4.9 ***kirisime` is now known as kirisime
<raghav-gururajan>efraim I sent a revised patch for gnome-font-viewer. Wanted to make sure the patch is okay. Thanks! <efraim>raghav-gururajan: I'll try to take a look at it in a little bit <alextee[m]>You don't have write permissions for the /gnu/store/wd9fcab8pzc8l8bbw958yxa1hmfh0irk-ruby-2.5.3/lib/ruby/gems/2.5.0 directory <str1ngs>alextee[m]: can ruby gems use $HOME like pip --user for example? <str1ngs>alextee[m]: and the more guixy way is to not use ruby gems at all . but create a package of course :P <alextee[m]>You can even put "gem: --user-install" in your ~/.gemrc for rubygems to do that automatically on `gem install`. <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? <bgardner>"gnu/packages/mail.scm:779:28: error: guile-email: unbound variable" <leoprikler>how did you get your current ledger-mode installed? perhaps with an older guix? <bgardner>Yes, like 2 weeks ago I did 'guix package -i emacs -i emacs-ledger-mode -i (more modes here)" <leoprikler>can you switch your guix pull generation to the one you used back then and do guix pull from there? <bgardner>leoprikler: I haven't done generation switching a lot, what is the command you want exactly? <leoprikler>guix pull --switch-generation=N, where N is the generation used back then <leoprikler>If you don't know which one that is, you can run `guix package -l` and `guix pull -l` in parallel <bgardner>leoprikler: It's this machine I'm working on, so if this toasts irssi I'll come back. <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 <bgardner>leoprikler: Heh, I was about to ask that, <leoprikler>Now, I would advise you to ./pre-inst-env guix build emacs-ledger-mode before submitting your patch <bgardner>So just factor out the guix.d parts, test and submit a patch? <bgardner>Surely. Okay, I *think* I'm up to the task. Let me see what I can do, and thanks for the assistance! <leoprikler>I'm not sure if your build will succeed, given the error you've reported, which seems to haunt us for a while now. <bgardner>True. Okay, I'll watch the mailing list for updates on that. <g_bor[m]>I will do some local testing tomorrow, and if all goes well, we could try to upgrade nginx with the patch on berlin. <leoprikler>nvm I found the bug: It's #38715 and you should be able to test your patch by first reverting c7b2b539802eaa3f969e212c98eb671a1a75e9f3 <bandali>valignatev, indeed :) eli just cut the emacs-27 branch the other day, so the 27 release cycle has officially started <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>GUIX_ENVIRONMENT is set, so I should be in the right place <leoprikler>can you do `ls $GUIX_ENVIRONMENT/include/zlib.h`? <bgardner>One sec, going to back out and revert the branch to c7b2b539802eaa3f969e212c98eb671a1a75e9f3 <bgardner>Same thing. Is localstatedir=/var correct for a stock guix? <bgardner>Not sure where I'm going wrong then, I haven't done anything weird to my guix <bgardner>Just following the steps on the contributing page. <mjw>aha, a "pure" environment would be guix environment --pure guix? *mjw was just struggling with a similar issue. <mjw>With guix environment guix I got: configure: error: found development files for Guile 2.2, but /usr/bin/guile2 has effective version 2.0 <mjw>with guix environment --pure guix the configure step succeeds! <mjw>I get the impression I am making things really hard by not using Guix as "pure" distro... <efraim>after 'guix environment --pure guix' run ./bootstrap again <leoprikler>that said, you are missing out on some neat features <mjw>you "just" need to get all the environment variables right... <bgardner>leoprikler: Closed and reopened terminal, "guix environment guix" -> "./bootstrap" -> "./configure --localstatedir=/var" -> "configure: error: Guix requires zlib. See http://www.zlib.net/." <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"?) <leoprikler>on a foreign distro, you have to keep root's guix up to date to keep the daemon up to date <leoprikler>on Guix system, that is managed by `guix system` (heh) <bgardner>leoprikler: I'm wondering if my .bashrc is interfering, I have many env var settings there. <mjw>leoprikler, aha, but why the root user's guix? Isn't the daemon running as an unprivileged user? <leoprikler>nope, daemon is running as root and jobs are running as guixbuildNN <mjw>o, man. environment variables, profiles, and bashrc. So much confusion. <mjw>bgardner, if that is it, then you are certainly not alone :} <leoprikler>bgardner: you probably should put those into bash_profile <bgardner>leoprikler: Before or after "source $GUIX_PROFILE/etc/profile" ? <bgardner>leoprikler: K, let me review that and report back <leoprikler>but just so i know, what env vars do you adjust there? <leoprikler>`guix import` usually works for me, but not the nix importer <leoprikler>is there something different between nix libreoffice and guix? <bgardner>leoprikler: Moving my stuff to ~/.bash_profile, after "source $GUIX_PROFILE/etc/profile", fixed the zlib issue. Surprise: hole in foot caused by owner of foot. <mjw>bgardner, for what it is worth, I made the exact same mistake. Apparently "everybody" knows you set environment variables in .[bash_]profile, not .bashrc, except... <g_bor[m]>nginx did a new 1.17.7. seven releas, with the patch included. <leoprikler>Heh. I'm reminded of my first lesson in C++. "With C++, it's harder to shoot yourself in the foot, but if you do, your whole knee goes missing." <g_bor[m]>I will try to update it, and check if it works <nckx>mjw: Maybe, but ‘everyone’ remembers learning that at some point. There's a logic to it but it's not obvious until you find out the hard way. <nckx>So relax, you're in good company 😉 <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>bgardner: this block (at least the guix one) should already be handled by /etc/profile <bgardner>leoprikler: I suspect some of that came from a foreign distro (no longer in play) so in addition to house cleaning it may be time to pull some of this out of shared dotfiles. <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 :} <leoprikler>/etc/profile is the magic file in Guix that sources $GUIX_PROFILE/etc/profile, if that helps <mjw>so on a foreign distro you have to do that yourself (and have to understand from where), but if only you installed a real guix system all your troubles would have been taken care of for you. <bgardner>Unless you add bonus troubles yourself, after the fact. -.- <leoprikler>the easiest thing is to take some of the snippets from guix' /etc/profile and put it into your foreign distro's /etc/profile[.d] *mjw really should just do a system guix install one of these days. <mjw>leoprikler, grin, but if you are on a foreign distro, you don't have guix' /etc/profile... Or can I easily get it somehow? <leoprikler>you would have to grep IRC logs to find that one 😐️ <g_bor[m]>leoprikler: I have sometimes found that I have to put this to some disto specific session initialization script. Profile is not always sourced unfortunately. <g_bor[m]>For example on debian IIRC I used .xsessionrc <leoprikler>true, but you can always source /etc/profile from .xsessionrc if you want to <g_bor[m]>actually it is hard to find a receipt that always works. I believe it would be nice to share a working solution for major distros in the cookbook. Wdyt? <leoprikler>Personally, I think it's a good idea, but then again I'm not in charge of the cookbook. <g_bor[m]>but this is the kind of material I would expect to find there <g_bor[m]>I currently have debian systems, so I can easily set up a test evn for that and do short a writeup. <g_bor[m]>But it would be nice to know what we do expect to work, so that I can check that I don't miss anything cruical. <leoprikler>I think we should keep peanutbutterandcracker's basic setup, but explain from where it needs to be sourced (e.g. on debian) to make it work. <g_bor[m]>leoprikler: I agree. This looks like a good idea. <leoprikler>That said, it is quite minimal and definitely worth expanding. *raghav-gururajan --> Zzz <sneek>Welcome back efraim, you have 1 message. <sneek>efraim, raghav-gururajan says: Thanks so much for the pushing the patch. :-) <brettgilio>Hey all, I just dropped an email to guix-devel wishing all of us a happy holidays and congratulated many of us on our hard work! <bandali>indeed, big congrats and many thanks to everyone for making guix awesome(r), and wish y'all a happy holidays! <grillon>I'm trying to define and build my first package but there are few things I don't understand <grillon>my first step is local build, it seems easy <grillon>I have an idea I try then ask a question <pkill9>does ffmpeg fail the "lavf-fits" test for anyone else? <grillon>how can I search package depending on a lib? as for exemple packages depending on qt? <pkill9>grillon: `guix refresh --list-dependent qt` <pkill9>although not many packages depend on the 'qt' package, most use the qt sub-packages <rekado>turns out we were missing a patch for gcc-7 <str1ngs>pkill9: the monolithic qt 5 package is now depricated <brettgilio>Just updated Qutebrowser in guix from 0.11.0 to 1.8.3. if any of you want to test it <grillon>I suppose if my package depends on qt5 I have to read build details to know what I need <grillon>Build and install of my package works :) <grillon>when I launch my app a notification icon should appear and it doesn't <grillon>service works so I'm not surce it has something to do with my build <grillon>brb I'll try with another window manager <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. <pkill9>brettgilio: so far works fine for me <rekado>Guix is more interesting at the package level. <rekado>you can follow the progress by using higher verbosity <grillon>to be more precise I did "guix environment guix" <grillon>then I have cloned guix repo and did ./configure <grillon>but I get a message telling me localstatedir does not matcjh the current installation <grillon>hehe the answer was given in the error :p <NieDzejkob>rekado: Okay, my bad. I guess I want to look at the package, then? Except that when I ran `guix package -A disk-image` I got no results, does that mean that disk-image is not a package? <NieDzejkob>I suppose there isn't a way to switch verbosity mid-command :D <kirisime>grillon: gnome doesn't have a system tray since forever, but if you install the gnome-extensions package, the unite extension has one.