<str1ngs>awww I might have confused the issue I thought CAS as needed for ipfs. that's even better <str1ngs>at least interns of implementing IPFS <drakonis>"Content-addressed derivations: RFC 62 is necessary for using IPFS to its full potential, so we’ll be working with existing community efforts towards content addressibility." <drakonis>okay so, things that have taken place after flakes, there's support for having multiple stores at once <civodul>i think it's important to distinguish the PR stuff from the actual technical stuff that might be relevant to Guix <civodul>"multiple types" sounds like something we already have for instance ;-) <bavier[m]1>jonsger: feel free to pick up/expand on that anbox stuff. There's still some work to do before it's usable. I thought with the guix-on-phone work happening that it would be nice to have. <ryanprior>Anybody know what the defaults are for max cores and max build jobs when you `guix pull`? <ryanprior>(`guix help pull` does not say and I'm not familiar enough with the CLI codebase to know where to look for default values) <apteryx>(parallel-build-jobs) from (guix build utils) <apteryx>if you have a 12 physical cores + 12 hyperthreading cores, that gives you 24 cores <ryanprior>So it defaults to using every available logical core? <ryanprior>Okay got it. I've seen some pretty sad slow builds sometimes that only use 1 of my 8 logical cores so I wondered if that was because of a Guix default or what. <ryanprior>Specifically I remember I built alacritty earlier today and it was using 1 core. That's a Rust app and I don't know anything about the Rust toolchain and don't want to spend the energy to learn right now X.X <apteryx>some packages have broken parallel builds and are built using a single process <str1ngs>if (parallel-build-jobs) is logical cores does that mean there are a max of 24 jobs using one core? <str1ngs>or to rephrase that means you can have as many jobs per logical cores. which is not the same as --cores=$(nproc) <str1ngs>ryanprior: try with guix build alacritty --cores=$(nproc) --max-jobs=1 see if that improves things. <str1ngs>ryanprior if that helps you might want to add export GUIX_BUILD_OPTIONS="--cores=$(nproc) --max-jobs=1" to ~/.bashrc <guix-vits>Gooberpatrol66: `info mcron`, 3.2.1: Seems it can -- (system "my-program") <Gooberpatrol66>just wondering if there were any issues with file paths on guix that i needed to be aware of <Gooberpatrol66>so if i make mcron call "list.sh", and list.sh just has a single "ls" command in it, "list.sh" will know where "ls" is located in /gnu/store, just as though i had logged into my user account, opened a shell, and executed list.sh myself <guix-vits>Gooberpatrol66: Guix Manual, 9.8.2: an example of '#:user "charlie"'. <ryanprior>Manually specifying 8 cores and 1 job does indeed peg my CPU at 800% str1ngs :) <ryanprior>Another question that came up the other day: I found a circular dependency in a golang package I'm working on (gohugoio/hugo) It depends on gohugoio/testmodBuilder, which in turn depends on gohugoio/hugo. <ryanprior>Do we have any way of dealing with circular deps? Or do I need to do something clever like create a source-only package for Hugo that the testmodBuilder relies on, which then in turn the main Hugo package can rely on? ***drakonis is now known as drakonis-
<str1ngs>ryanprior: I hope 800% is good thing :thumbsup: <efraim>ryanprior: in that case I'd mark testmodBuilder as source-only with a note it only being used to test hugo, which it does when building hugo <civodul>are we building i586-gnu derivations yet? :-) <mothacehe>but the Cuirass UI should be must faster displaying that nothing was built <civodul>i'm looking at the issues with childhurd, janneke <civodul>there's something weird with qemu port forwarding: you can successfully connect to the guest before there's anything actually listening in the guest <civodul>and somehow qemu seems to buffer what you write there and eventually delivers it <janneke>i tried your patch set on another laptop, tried hurd restart hurd-vm and herd status hurd-vm .. it doesn' work for me :-( <civodul>then maybe there's a difference between bare-bones and my laptop config that has an influence <civodul>for testing i use my laptop config, which has X, so i can run vncviewer <janneke>yeah, i'm also using my laptop config <janneke>so it would be so great if childhurd in a guix vm worked, then we test/run the same thing ***apteryx is now known as Guest40591
***apteryx_ is now known as apteryx
<peanutbutterandc>(while I'm searching elsewhere too) does anybody know if there's a function like (glob "/path/to/asdf*") that would expand to "/path/to/asdf-3.3" in guile? <guix-vits>peanutbutterandc: (system "python-glog.py") with something of (ice-9 popen)? <civodul>in Guix you would use 'find-files', which supports regexps (not glob patterns) <peanutbutterandc>civodul, Hello there! Yes, I think that is what I'll use. I was just wondering if there was something easier (as it's just one binary. Guess I'll just (car) from that list). Thank you <efraim>where is the 3.3 from? could you use (package-version other-package) to get it? *guix-vits giggles "third" <jonsger>mothacehe: is it a known bug that an evaluation on CI doesn't show all jobs, whether they are failed, succeded or scheduled? <mothacehe>jonsger: only jobs that do trigger a build (and which failure is not cached) are shown <peanutbutterandc>efraim, yes, version number (3.3)... with the revision truncated (3.3.1) so yeah.... I can't do that <efraim>peanutbutterandc: (version-major+minor (package-version other-package)) <peanutbutterandc>leoprikler, Hmmm... that seems to work! (I'll have to (car) though) Thanks! <peanutbutterandc>efraim, Ooooh! Cool! (guix utils) seems to have all the gems! I'll go for this one, perhaps! Thank you! <peanutbutterandc>leoprikler, Yes. I remember, in GIMP, if I'm writing a plugin via scheme-fu (tinyscheme) I have to (car) on everything <PurpleSym>civodul: Found the issue with port-ascii-armored?. Fix see #43699. <Brendan[m]2>gimp can use guile, its just noone wanted to do that as a project. they always said sure , just send the patches and you will be the one to maintain it ;) <Brendan[m]2>perhaps one could implement tinyscheme as a language in guile <peanutbutterandc>Brendan[m]2, lol. I still need to go through SICP. But I'll put this on my list of things to do someday when I get competent enough and nobody else has gotten around to doing it. :D <peanutbutterandc>Now, regarding that https://termbin.com/ely1 thing: It seems that that is the way to add further arguments to an inhertied package (guix edit goffice)... so there must be something else going on here. *looking* <guix-vits>-| "Error in evaluating guile expression ..." ? <civodul>i thought it was due to my settings, but maybe not <civodul>janneke submitted a patch to emacs-guix recently and i think we never got an answer <janneke>civodul: it took a while, but they picked it up: d246b2c elisp/misc: Update Emacs path if needed <janneke>..but i think this is unrelated; i wrote a patch for guix-set-emacs-environment <janneke>well, "unrelated" is too black/white: there's the "emacs-guix" relation ;) *civodul .oO it'd be interesting if a guest's shepherd services could somehow be visible to the host <mothacehe>janneke: I added support for compressed qcow2, and added a hurd-barebones.qcow2 image to the CI. <janneke>mothacehe: mental note to tell mihi about qcow2 compression for the hurd <mothacehe>so that it uses qcow2 format to save some space on berlin <mothacehe>in progress means that it is evaluating if new builds are required <janneke>mothacehe: ah, right -- guess we'll be seeing a hurd-vm update some time soon <janneke>mothacehe: okay..could still compute => 0 then? <mothacehe>but as long a 43668 is not fixed it will still be 0 I guess <civodul>janneke: i've pushed wip-childhurd with a fix for unreliable startup <civodul>works for me on bare-bones + hurd-vm-service *janneke goes to try civodul's new fix <civodul>what's annoying is that when you change secret-service.scm, you end up rebuilding the image of the childhurd inside the VM <civodul>that takes quite some time and space <civodul>(and my laptop becomes dog slow for a minute or so as the image is written to disk) <janneke>ah, so the suspect is a qemu port-connect race --- that makes sense <janneke>moving to the end of the service list is also smart <civodul>yeah i was seeing those "generating keys" messages followed by "receving files" <jlicht>civodul: I found a workaround for my spooky "/" permissions in a guix system container yesterday at #43673. <jlicht>What _is_ the default set of permissions for "/" anyway? I went with 755, but I found it hard to find a sane default anywhere <xelxebar>I guess this means that upstream sources and well as build substitutes can use (or fallback to?) IPFS. <nckx>jlicht: 755 sounds pretty sane to me. Or rather: anything else does not. <jlicht>hello nckx! it's good 'ol lucky 777 right now for some reason <OriansJ`>nckx: 750 with the group being users is a good way to prevent system services from accessing certain programs they shouldn't need to access (assuming one doesn't have something like selinux or apparmor running) <jlicht>honestly, I'm happy with anything that makes sshd happy ;-) <OriansJ`>jlicht: most programs complain because their programmers were too lazy to think through what the implications would be if say nginx or apache spawned them because of a carefully crafted POST or GET request. <nckx>OriansJ`: Honestly that sounds like a risky choice that will work until it doesn't, but more due to sloppy programming than a hard need, indeed. I have encountered daemons that barfed when they couldn't open / after I'd restored a back-up badly. <nckx>Is FILE_OFFSET_BITS a temporary thing until (say) a core-updates merge? Or more boilerplate to remember? ***trava9626 is now known as travankor
<jlicht>unrelated, but is there anyone using Emacs 28-to-be native compilation on their guix system? <PurpleSym>Is `guix archive --export` broken? It says “guix archive: error: corrupt input while restoring archive from #<closed: file 7f27c396e150>” on two of my machines. <PurpleSym>You mean a signing key in /etc/guix? Yeah. It worked previously. <str1ngs>does the error happen on --export or --import? the error kinda implies --import <str1ngs>you need more then just a signing key you need to authorize the public key on the importing end. <PurpleSym>No, it’s export. Piping to /dev/null right now. <str1ngs>ahh ok then this would not be a trust issue <str1ngs>PurpleSym: are you using guix system? <str1ngs>have you guix pulled as root lately? <str1ngs>on foreign I like to try and keep my guix describe on par if I can. ie guix describe as user then guix pull --commit=<hash> as root <str1ngs>that should ensure guix daemon is upto date IIRC. <PurpleSym>Yeah, 1 or two commits apart maybe. This was never an issue and the daemon protocol rarely changes, right? <str1ngs>also after guix pull as root do a systemctrl daemon-reload the restart guix-daemon <str1ngs>rarely changes is not quite the same as never changes of course :) <civodul>PurpleSym: there are been changes recently regarding export <civodul>i think you have to make sure root's guix-daemon and guix are in sync <civodul>actually just "guix pull" as root should give you that <str1ngs>thanks civodul that was the reason I mentioned updating the daemon. but I was'nt sure what the exact changes where. <str1ngs>all I know is the changes made things faster! :P <PurpleSym>I restarted guix-daemon and retried with root’s guix, same issue. <civodul>PurpleSym: so "guix archive --export something >/dev/null" is failing, right? <civodul>would be great if you could strace -p $(pidof guix-daemon) -f and try again :-) <PurpleSym>Yup. I can actually see an error in the daemon log: guix-daemon: nix/libutil/serialise.cc:15: virtual nix::BufferedSink::~BufferedSink(): Assertion `!bufPos' failed. <civodul>right, but there must be something before that *civodul knows two debugging tools: strace and pk <PurpleSym>Hm, +++ killed by SIGABRT (core dumped) +++ looks suspicious. <divoplade>Hello guix! I have watched the recent FOSDEM "Universal package & service discovery with Guix A universal functional package manager and operatin..." (I guess it was truncated from operating system), by Pierre Neidhardt and I am glad to see someone talking about data as linked data! I am myself trying to implement the Solid authentication protocol (https://github.com/solid/authentication-panel) in guile with Nettle, and it's not that <str1ngs>divoplade: hello, you message got truncated. <divoplade>So I was saying that there is a recent FOSDEM video by Pierre Neidhardt, and he mentions data as linked data <jlicht>don't click the gnuguix-drive thing, in case it wasn't clear <jlicht>they've been spamming mailing lists for emacs, replicant and possibly more as well :/ <divoplade>And I just wanted to say that I'm trying to implement the solid authentication protocol in guile with nettle <divoplade>This would be a great platform for publishing reviews and stuff I think <divoplade>For the message truncation, is it because of the server or my client? I'm using srain (within guix, of course ;) <str1ngs>divoplade: that solid in guile looks interesting. I'd like to add this to nomad at some point. <divoplade>For now this is mainly me trying to combat undefined behaviour while crossing the scheme / C interface of nettle <divoplade>(I mean, I am writing an interface between nettle and guile, and I have a lot of trouble, but I progress!) <str1ngs>divoplade: would gcrypt work in place of nettle? <divoplade>Maybe, but I've never used it and I could not find documentation for the interface <str1ngs>thing with gcrypt it is has bindings <civodul>divoplade: there's a manual in there, it's incomplete but hopefully a reasonable starting point <divoplade>I just need RSA and ECC signatures with SHA256, SHA384 and SHA512 (with and without PSS for RSA) ***ChanServ sets mode: +o civodul
<divoplade>I'm puzzled that nettle does not seem to find RSA + SHA384 interesting, even if it's an official JWT algorithm for signing <divoplade>Yes, and it does not support RSA or ECC according to its readme <civodul>it's under development though, i think it's very recent <roptat>still waiting for a review for my groovy update :) <civodul>in the meantime, i think you have other issues reviewed and waiting for you :-) ***ChanServ sets mode: +o nckx
<civodul>think of the feeling of relief when applying years-old patches <apteryx>roptat: is your email client configured to filter on the return-path ? <roptat>no, I receive everything in my inbox <civodul>i'm sure we could do something nice with it :-) <roptat>systemd has systemd-resolved, so we could have guile-dns :p <jlicht>I might be wooshing here, but I would think guile-dns would rather be a dns server <apteryx>It puts every list mails in their own folder but leaves things addressed to me explicitly go to my INBOX <apteryx>that makes it less likely that I miss these. *civodul has too many folders <roptat>I remember reading the RFC very carefully to build that dns client <roptat>but that it didn't work in the test environment for some reason <roptat>oh and maybe we should give more priority to the license issue. for the manual, I'm still missing approval from 3 people: one German, two Russian <roptat>and we have to fix that issue with the guix.*.po and guix-package.*.po, that are attributed to you or the FSF <civodul>can you ping the 3 remaining translators? <civodul>po/guix/*.po has "Copyright (C) 2018-2020 the authors of Guix (msgids)" <civodul>pl.po has "Copyright (C) 2016 Free Software Foundation, Inc.", which is quite an innovation <roptat>civodul, I think they should all say "Copyright (C) 2012-2020 the authors of Guix (msgids)" (2012 being the start date of Guix, right?) <roptat>and keep individual translators under that too, of course <roptat>I know we can change the copyright when it says "copyright Ludovic", if you agree, but for the FSF, I'm not sure we can do that. Should we ask them for permission or something? <civodul>roptat: we can definitely change "copyright Ludovic" to "copyright the authors of Guix" <civodul>the same goes for the FSF: none of us assigned copyright to the FSF, AFAIK <civodul>the FSF is not a copyright holder on Guix <civodul>so the "copyright FSF" line is wrong, probably copy/pasted from another project <roptat>some translators have, and may be also contributors to Guix, so I don't know <roptat>also I found where the wrong license comes from, the package name for the manual is "guix", instead of "guix manual", but changing that I get this line: This file is distributed under the same license as the guix manual package. <civodul>oh well, that line is probably good enough <roptat>ok, I just pushed a fix for that :) <roptat>I see our po/guix/Makevars is also wrong <roptat>COPYRIGHT_HOLDER = Ludovic Courtès <roptat>I think that's the reason why I did that too for the manual <civodul>MSGID_BUGS_ADDRESS is also wrong :-) <civodul>hasn't been touched since 2012-06-29 <roptat>need to go, I'll be back in 30 mins <rndd>can i use regex to substitute strings in snippets? <ryanprior>@rndd yes you can use pretty much any Guile in snippets. However, depending on the use case it might be more idiomatic to create a build step to do the substitution. <rndd>ryanprior: what does mean "blob" term? <rndd>i see it from time to time <ryanprior>@rndd a blob is a compiled, obfuscated, or otherwise obscure file for which there is no source provided. <rndd>where i can find partprobe command? <roptat>although it's starting to be a bit old <roptat>oh, and if you feel more confident in French, you can use any language here, so feel free (you'll get less answers, since we don't all speak French) <user_oreloznog>OK , good to know ? Penses-tu que je puisse commencer à m'entaîner avec ce fichier .po ou bien avec un autre ? <roptat>tu peux utiliser ce que tu veux. une fois que tu as une contribution dont tu es fier, tu l'envoie au robot <roptat>ensuite il te répond qu'il a rejeté tes changements et il te dit pourquoi, tu corriges et tu réessayes :p <user_oreloznog>Ah... Je pensais justement utiliser celui que j'ai mentionné plus haut pour me faire la main. Ce n'est pas grave s'il commence à être un peu vieux ? <roptat>non de toute façon on n'a pas plus récente pour le moment <roptat>ah et tu peux utiliser offlate, c'est un petit logiciel que j'ai fait, il permet d'automatiser un peu la récupération et l'envoie des traductions <roptat>il marche pas encore avec weblate par contre :/ <user_oreloznog>Penses-tu que j'arrive à trouver un fichier .po pour me faire la main ? En aurais-tu un à me conseiller ? <roptat>tu peux essayer avec guix-packages, il n'est qu'à 10%, donc toute amélioration est vraiment bienvenue <roptat>ah mais non tu peux pas, il m'est attribué <roptat>je suis sensé travailler dessus ^^' <roptat>bah guix-manual, de toute façon je travaille pas dessus en ce moment, tout ce que tu y feras sera utile pour la suite <roptat>yes, je te laisse la main dessus :) <roptat>ah et sinon tu peux aussi t'inscrire sur la liste de traduc.org et faire un petit coucou <apteryx>our tensorflow is in need of a major update <civodul>apteryx: i vaguely remember rekado saying something about a Tensorflow upgrade along the lines of: "this is hopeless" <roptat>but which kind of hopeless? maven-hopeless or scala-hopeless? :p <apteryx>civodul: yeah I remember it too, I think it had to do with changing their build system to Bazel or something <civodul>nothing's really hopeless to roptat :-) <civodul>apteryx: yeah, Bazel is the only supported build system <civodul>i think we're relying on a CMake-based thing that's no longer available <civodul>as if it could be more difficult than Maven :-) <roptat>yeah but that's only a build system, we can always simulate that (if we know how it's supposed to work) like we do for maven <joshuaBPMan>guix deploy: error: failed to deploy locke-lamora: no matching pattern <civodul>roptat: yeah it's easy, we just need to add a Bazel frontend to Guix and we're done <str1ngs>janneke: hello, emacsy should support multiple minibuffer. but minibuffer is a global binding and hard coded in (emacsy minibuffer). I'm debating making it a fluid or a parameter. let me know what you think would work best. this would be something I change later down the road. First I need to redo all the tests because there are many cases tests pass but they should'nt due to check.scm. <ryanprior>(looking at Bazel's WORKSPACE) yep that's a lot of deps <ryanprior>Speaking of which though, I'm making some progress cutting the gordian knot of javascript build systems. I'm convinced there's a way out but it's gonna be an adventure. <ryanprior>I use javascript for work so I'm much more motivated there than in the java/bazel realm :) <ryanprior>Anyhow I packaged quickjs in guix now, there we've got a fully compliant JavaScript ES2020 runtime with no dependencies other than gnu-build-system. <ryanprior>I've also packaged (but not submitted upstream yet, will do soon) esbuild, which has only go-build-system and golang x/sys dependencies. It bundles javascript and typescript, like webpack. <ryanprior>So between those two I hope to be able to clean up the nodejs bootstrapping story and upgrade our node package. <ryanprior>I also hope to use esbuild to boostrap Rome, a js dev swiss army knife which aims to replace webpack, ESLint, Babel, Prettier, and Jest. <ryanprior>Then that should open up a lot of js packages: we can scrape out their dependencies on things Rome replaces and package them. <ryanprior>I'm hoping to create a rome-build-system to automate that. *leoprikler wonders if rome-build-system will take more than a day for a given package. <ryanprior>I will include an #:in-a-day? keyword argument which guarantees this <ryanprior>Rome only dependencies are node and typescript. Typescript, of course, is written in typescript. But esbuild will hopefully let us short circuit that and get productive. <jlicht>ryanprior: no way, that is amazing news! <janneke>str1ngs: that sounds like a good idea either way; i'm a bigger fan of parameters, although i feel civodul is becoming less and less enthousiastic about dynamic binding in general (the same holds for fluids i guess) <jlicht>once we have esbuild, we might even be able to properly build node versions > 10. <janneke>str1ngs: i'd just take the easiest step for you, first -- and like you say, changing it is probably trivial once you gained some experience with that first choice <ryanprior>jlicht: yes, once I finish my current epic (packaging Hugo, which also depends on esbuild) my next goal is node 13. <ryanprior>err node 12, I guess that's still the latest stable <str1ngs>granular control can happen but it's alot more work and I don't want to replicate emacs ... quite yet. <ryanprior>yeah I'm trying not to look into that too much. still lots of work to do on Hugo X.X <jlicht>ryanprior: is this automatically generated? Either way, "nice" <janneke>str1ngs: yeah that's the thing, a growing dislike for a feature does not always present an easy alternative, so tbh: i don't know ;-) <nly>how do you add global directives to nginx conf? <janneke>good to know about your minibuffer...some time soon nomad will already be a better guixmax than guimax itself :-P <str1ngs>janneke: <widet-entry> turns a GtkEntry int a minibuffer I use it for the browser URI bar. the main minibuffer still uses GtkSourceView. <jlicht>ryanprior: It is civodul who is now proposing a patch to add `cc` with his --with-toolchain patch series though, so you might want to revise your README <ryanprior>Oh dang I been following that, I will definitely update my readme after educating myself on with-toolchain <str1ngs>janneke: but <widet-entry> is much more isolated and refined then how <text-buffer> and the main <minibuffer> are handled. widget synchronization is not easy. <jlicht>ryanprior: omg esbuild seems to work with typescript! It doesn't seem to do any actual typechecking, but who cares :D. ***daviid is now known as Guest14680
***Guest14680 is now known as daviid
<PotentialUser>Hi, im trying to add a printer with lp, i already added and configured cups in my config.scm and installed escpr, but when listing drivers with lpinfo i can only find 2 epson drivers, what should i do? <nckx>PotentialUser: Just in case: ‘installing’ printer drivers with ‘guix install’ doesn't add them to your system; you need to add them to (service cups-service-type (cups-configuration (extensions (list <here>)) ...)) in your system .scm. <nckx>If you did so: disregard. <nckx>Same here: 9-pin and 24-pin series 😳 <rekado>re tensorflow: not everybody uses or even wants to use version 2.x; there’s a more recent version of 1.x, which we could upgrade to. <nckx>Is that a literal serial/parallel D-port... <rekado>it’s just a lot of busy work, made more complicated by the fact that the contributed CMake stuff has been removed. <PotentialUser>i would use the generics to see if they work but i dont know what "kind" of print do i have <rekado>there are third-party projects that provide a CMake build system for tensorflow, and there are experimental converters of Bazel stuff to CMake. <rekado>it doesn’t work on the Tensorflow build system, though <nckx>PotentialUser: How old is this printer? And how is it connected? <nckx>Drivers have been deprecated for a while, although some old/USB printers still need them. <nckx>Hmph, I've never owned an Epson, dunno what ‘ESC/P-R’ is supposed to mean. <nckx>PotentialUser: Despite the USB, try ‘Generic’ → ‘IPP Everywhere’. It's what every single printer should be using according to CUPStream. Drivers are going away, although it's moving slowly. <PotentialUser>if that doesnt work i will see if there is any ppd in the debian package <nckx>PPDs have been deprecated for a long while, but probably won't go away soon. <nckx>They're just text files with printer metadata that point to executables, they're not drivers (also deprecated) in themselves. You'll still need to package the driver if needed. *nckx updates escpr to 1.7.7 in the meantime. <PotentialUser>can you make an issue about the escpr package in the tracker?, i dont really have access to my mail right now <nckx>What's the exact bug? E.g., are there more model names available under ‘Epson’ on other distributions? <PotentialUser>i would assume, i had no problems searching from drivers in artix <nckx>Using the same CUPS manufacturer+model list? <PotentialUser>epson-inkjet-printer-escpr 1.7.7-1epson-inkjet-printer-escpr2 1.1.12-1 <PotentialUser>epson-inkjet-printer-escpr 1.7.7-1 and epson-inkjet-printer-escpr2 1.1.12-1 * <nckx>PotentialUser: It would be helpful if you could say which one is actually needed. And 1.7.7 is currently being a pedantic dork about autotools versions. <PotentialUser>sorry, im looking into the details right now give me a moment <nckx>NP. I just found a Epson-Stylus_Office_TX300F-epson-escpr-en.ppd in escpr-1. <nckx>So no need to package v2, just a bug in our(?) v1. OK. <nckx>Er... well, the CUPS Web UI allows you to manually ‘upload’ a PPD file and it would be copied to /etc/cups, so you could ‘guix build escpr’ to get the store path & do so. That might still break later, dunno. <nckx>I *think* the actual bug is that our escpr package installs PPDs to /share/ppd/epson-inkjet-printer-escpr/<foo>.ppd instead of /share/cups/model/<vendor>/<model>.ppd. <nckx>So they don't show up in the list. <nckx>I'll test whether moving them fixes that, which would be the much safer option. <PotentialUser>That would be so nice, if you get any results tell me i will be connected, if there are no results i will try the guix build thing <nckx>OK. If I don't get them to show up in the UI before I go to bed I'll let you know and open a bug report. <nckx>PotentialUser: Pull and reconfigure and sudo herd restart cups and try again. <nckx>It fixes the problem of models not being listed. Whether it prints you'll have to tell me. <nckx>(The model ‘names’ are horribly long & noisy, but I think that's Epson's choice.) <PotentialUser>you should probably go to bed btw, my internet is not that good so it will take a while until i can actually test the fix <joshuaBP`>man, I'm having a really tough time getting guix deploy to work. <joshuaBP`>Failed to read private key: /home/joshua/.ssh/id_rsa <joshuaBP`>I'm not certain how that is my error message. I am running guix deploy as my regular user, which can read that file. <nckx>PotentialUser: Don't rush. I'll be up for at least another half hour and can always read the backlog tomorrow. If the drivers themselves don't work, I can't do much more than open a bug for you. <PotentialUser>nckx uhhh reconfigure didnt gave any output for a while so i re-ran it with --debug 4 and there is a LOT of "acquiring/downgrading write/read lock on /var/guix/temproots/numbers"