<podiki[m]>it is for an opencl include directory, probably makes some assumption of where things are in the non-guix world? <nckx>To have more of an opinion I'd have to spend time reading the package(s) and I really don't wanna. <podiki[m]>I make no claims to understanding the AMD mind <nckx>Nothing, I meant a mere origin. <nckx>Not wearing a (package …) fig leaf. ***meena1 is now known as meena
<nckx>That netsplit happened at the *exact* instant I unplugged my laptop. This is not good for my solipsism. <podiki[m]>(my goal is really just to update rocm, the only use I have for it is darktable so I'll err on the side of making that all smooth) <podiki[m]>well that works easily, will go with that (a plain rocclr-src definition) and see what people think in review <elb>Hello friends! I have been using Emacs through Guix on a foreign system (debian) for a long time now, and it works fine, but I had never installed an Emacs package through guix, so I hadn't noticed that the Guix site packages weren't installed. I can't tell why they're not, and they're not there in `emacs -Q`, either. I noticed because I installed emacs-guix, but don't have any guix- commands; I checked my <elb>load path, and my guix profile isn't there. <elb>I'm under the impression that this should be automatic; am I wrong? If I am not wrong, any ideas why it's not happening, or how to find out? <elb>(Background is that I'm wanting to move from using `guix package -i` ad-hoc on a number of machines to distributing a known-good manifest and installing that, and that's causing me to try to learn a bit more about Guix; I was prompted by listening to Foss & Crafts' Guix 10th anniversary podcast while mowing the lawn yesterday!) <maximed>Question: if I have a patch for addressing a publicly-known possible privilege escalation in Guix, how many years do I have to wait for it to be applied? <nckx>This is not to blame you, but have you pinged them since? <nckx>If so, maybe we should ‘consider’ shipping a patched Guile in Guix to get attention. <maximed>(TBC, not all 13 are actually needed for Guix) <nckx>No need to enumerate them all. <nckx>I'd remind civodul personally, again. Everything he says in #54485 is true but it does imply action. <nckx>'d → 'll if you want, but feels a bit escalate-y. <maximed>I don't think I'm in a frame for that to do that myself. <maximed>Rather frustrated with the lack of any progress whatsoever, couln't slee <nckx>I don't really know what to respond, I'll just send a friendly ping & see what happens. <maximed>anyway, the Zzz situation should be better now. <lechner>Hi, what does 'd → 'll mean, please? <nckx>They are both valid suffixes to ‘I’. <nckx>But one is a whole lot easier to promise than the other. <podiki[m]>nckx: so I made a variable rocclr-src for the needed source origin, and it is only needed to set a configure-flag (path to this source); is it okay to just refer to it as #$rocclr-src not putting it in inputs <podiki[m]>nckx: that is to say it works of course, but stylistically, if it should be in the inputs also <vagrantc>ok, i've catalogued most of the reproducible builds issues for guix. <vagrantc>i'm sure as soon as staging is merged, there will be fun surprises *vagrantc writes up a summary for guix-devel ***daviwil_ is now known as daviwil
<unmatched-paren>phodina[m]: maybe something like (arguments (list #:install-plan `(,@(match ... (... '(...)) (... '(...))))))? <unmatched-paren>that's strange... i don't have permission to write to a file in the build environment. <unmatched-paren>system-error "open-file" "~A: ~S" ("Permission denied" "ztypes_amd64.go") (13) <PurpleSym>podiki: Thanks for taking care of rocm! I haven’t gotten around to update it since I added it some time ago. Feel free to CC me on the patches. <avalenn>I think it is a step in the right direction. But will wait to see how it will be used. <civodul>avalenn: it's interesting, but to me it also looks like a band-aid <civodul>for one thing, it's pretty individualistic, despite the last section on "sharing audits" <civodul>i can see how it can be useful to Mozilla <civodul>i don't quite see how it helps the community as a whole <civodul>there's also the design defect of referring to packages by name + dependency <avalenn>The naming problem is common to everything. Go made the decision to bypass it by reusing git and URLs but for all other package managers we still use ambiguous names. <rekado>civodul: congrats on getting ’staging’ merged! <avalenn>I am not sure how to avoid this naming problem. <civodul>rekado: we didn't even run out of inodes overnight, twas easy :-) <civodul>the way we represent packages in Guix is unambiguous <civodul>let's say we add an 'audited?' property on a package: it's entirely clear what has been "audited" <civodul>conversely, "cargo vet" just says that example@1.0 has been audited <civodul>i'm skeptical; to me it's more about building a reputation system, as in p2p systems <civodul>that's far from trivial, there are limitations, etc. <rekado>civodul: clearly, we’re playing on easy mode! <civodul>rekado: that's for sure! none of us at to get up at 3AM to hot-swap hard-disks and whatnot <avalenn>cidovul: As I see it, the core of the problem is reputation. Too much trust is put on what is brought by packaging systems (cargo, npm, pip, etc.) but there is no easy alternative of establishing trust. <avalenn>The thing is that "historical" package managers (aka. Distributions, like Debian, Slackware or Guix) were more trustable (thanks to being a bit more centralized and with known processes) but also considered too slow to bring latest versions and to difficult to use by modern programmers. <rekado>I want to let mumi handle (some?) incoming email directly. I wonder if we should move issues.* off to a separate server. <avalenn>cidovul: I am struggling to express myself on the subject. Not yet to the point of "ce qui ce conçoit clairement s'énonce clairement". I must still think about it. Thanks for the food for thought anyway. <avalenn>Would like to hear about what you think the "social issues" are, at some point. But probably another day. <civodul>avalenn: traditional distros, Guix included, only include packages after review; pip, npm, cargo take everything <civodul>review != audit, but still, we're talking about package repos that grow without oversight <civodul>rekado: i think it would make sense in general to distribute services on more machines <civodul>and to make it easy to move them around ***wielaard is now known as mjw
<rekado>not sure what to do with our limited public IPs, though. <rekado>I guess I should apply for some more. <avalenn>cidovul: The additional gatekeeping of traditional distros seemed to be too much of a burden for the modern speeding world of "fail fast and break things". :-( <avp>The author basically glued bunch of third party libraries under the name of "cbang". <avp>I managed to package "cbang" on my private branch but I hesitate to even to send a patch to "guix-patches" (and rightly so I think.) <avp>The licensing status of the "cbang" is quite ambitious too. <avp>s/ambitious/ambiguous/ <jpoiret>civodul: what did you think about the deprecations/defaults i mentioned in my email about 1.4? <rekado>jpoiret: I think it’s too early to remove deprecated stuff in 1.4, because there has not been a release since the deprecations. <jpoiret>right. what about wayland by default in GDM? <rekado>I don’t oppose it, but I should say that I had enough difficulties with wayland that I’m now back to X :( <rekado>I use GDM+Gnome, so that should totally work. But there were a bunch of problems with it, e.g. a weird flickering when switching between applications, screen blanking when using mpv, etc. <strange>i want to contribute to python pkg management in guix someday, how hard would it be to get a detailed grasp of it ? no experience of guile or python package management but i know some lisp <strange> i mean i want to have python (global) pkgs managed by guix straight off, don t even want to bang my head with pyenv/virtualenvwrapper, only enough for guix abstraction <reza[m]>s/i/with python packaging is that the importer does a really great job. most often the test call has to be adjusted but otherwise there isn't too much manual fiddling when importing/ <strange>just git+hash and wrapper for pip -r requirements ? <rekado>jpoiret: I still think it’s a good idea to make it the default, though. We could get more reports and more fixes this way. <civodul>avp: hi! so the problem is that cbang bundles lots of code coming from other libs? <rekado>avp: according to the author’s comments you should be able to ignore most of it and use zlib, bz2, etc directly. <maximed>civodul: Maybe: use the delabelified package-names->package-inputs for most importers, and use the old one for crate / cargo-build-system? <maximed>the old one could be removed after antioxidant <nckx>bovid-19: Patch looks good, but I can't build it now. Nit pix: there should be a comment after (delete 'configure), usually 'no configure script' say it all, and descriptions should contain only full sentences. Not usually worth a v3 but if you're looking for an excuse to bump... :-) <nckx>Maybe prefix the synopsis with 'Terminal' if that's its only UI. <PotentialUser-75>how does guix know that it should use my fork of guix when using pre-inst-env for things like system reconfigure ? <avp>civodul: Thanks for merging 'python-langcodes'! <maximed>PotentialUser: by doing ./pre-inst-env, $PATH is adjusted to point at your local fork of guix <maximed>That way, when doing "./pre-inst-env guix system reconfigure", you are asking your local fork to reconfigure your system <PotentialUser-75>ok makes sense, the issue i have is derviation are being built but not used <maximed>I'd need more information than that to determine the issue <maximed>Though I'll have to pass, don't really have time for going in detail <elb[m]>Good morning all. I asked a long question (above) about Emacs init on Guix, and I was hoping to get some eyeballs on it. The short is that I have installed Emacs via Guix and been using it for a long time, but recently discovered that it is not loading guix site-local packages (even with -Q). I am under the impression (from manual section 2.6.5) that it should. What might I be doing wrong? <maximed>elb: Can you test whether "guix shell --pure emacs emacs-guix -- emacs" works, where emacs-guix is the relevant Guix package? <maximed>Also, what is "echo $EMACSLOADPATH"? <elb[m]>The `guix shell ... -Q` exhibits the same behavior I see in my "regular" emacs: guix-emacs does not show up in list-packages, and cannot be required. $EMACSLOADPATH lists a directory that contains that file. <elb[m]>(it lists /home/elb/.guix-profioe/share/emacs/site-lisp, specifically) <elb[m]>in the guix pure shell guix does _not_ show up in the packages list, but `(require 'guix-emacs)` _does_ load <elb[m]>hmmmm that require now also works with -Q in my regular profile, I've clearly broken something <elb[m]>(was getting notifications in two places, moved to Matrix) <maximed>elb[m]: Is it important for it to end up in the package list? <elb[m]>no, but I would like to be able to load it :-) <maximed>In case of emacs-magit, I can just do "M-x magit-status" do do magit things, without having to do any (reuire ...) or list-packages things <elb[m]>(the package list thing was just that it turns out I was observing the wrong signal; it was there, it just wasn't declaring itself where I was looking) <elb[m]>well, in this case, I do have to `(require 'guix-emacs)` before anything works <maximed>elb: FWIW I don't have to do the (require ...) do do "guix-about" <elb[m]>`M-x guix-about` does not work, even after `M-: (require 'guix)` and `M-: (require 'guix-emacs)` <maximed>"emacs --help" says: -Q: equivalent to [...] --no-site-lisp <elb[m]>in m ypersonal config, I can't even `(require 'guix-emacs)` <maximed>as such, by passing -Q to emacs, you are asking Emacs to not load site-lisp, where the emacs packages reside <elb[m]>and my config's load-path does not have site-lisp <elb[m]>let me blow away my desktop file <elb[m]>and the only occurrences of manipulations of `load-path` in my config are `add-to-list` <elb[m]>OK, well, I'm fairly certain this is an Emacs problem, not a Guix problem, so I'll go chew on it, thanks <scisssssssors21>hi. does anyone know if it's practical at all to put guix on a thinkpad t420 machine? i tried to do `guix pull && guix system reconfigure` and it's taking ages to build kernel. do i have to wait a couple of days after guix pull for substitutes to be built on ci.guix.gnu.org? <podiki[m]>PurpleSym: I got a new camera so that inspired me to dig into darktable again, hence the dive into opencl. but looks like mesa might be able to handle more opencl directly in the near future which will be great <podiki[m]>scisssssssors21: take a look at the guix weather command to check for subs, or yes, wait a little after a pull if there was a lot for the build farm to build <podiki[m]>scisssssssors21: or if guix tells you it will build rather than download a lot, just ctrl-c to quit, nothing will have changed by design (atomic/transactional updates yay) <podiki[m]>Image support being key for darktable as I understand <scisssssssors21>podiki[m]: by the way it was your article that got me excited to try guix out :) <podiki[m]>PurpleSym: not sure if you saw the earlier discussion yesterday, but any thoughts on rocclr? it no longer has an "install" in the makefile, meant to be included in other packages, so I was just made it a plain origin (to use in the opencl-runtime) <PurpleSym>podiki: Yeah, I tried to upgrade rocm earlier, but got distracted. I also made rocclr an origin, because I couldn’t think of a better solution. <PurpleSym>Weird design decision by AMD, but they must have their reasons. <scisssssssors21>the only thing i'm missing in guix is signal messenger. does anyone know if there is a way to install it? i do not mind using unofficial client as i see electron apps are absent from guix repositories <podiki[m]>though maybe we should see if something like signald is easy to package; personally I bridge signal to matrix, but via my arch server <PurpleSym>I’m slightly worried by old old GPU won’t be supported any more after the upgrade. <scisssssssors21>i do not really like the idea of using flatpak/snap and etc. especially in guix which has an awesome package manager <podiki[m]>maybe there are other client possibilities using signald in the backend <scisssssssors21>i might try packaging signal then, i've written a couple of package definitions for myself <podiki[m]>PurpleSym: I had the opposite where I needed the new version so it would work for me :) <podiki[m]>PurpleSym: on a stylistic front with a bare origin for rocclr, I only needed in a configure-flag (pointing to source location) for rocm-opencl-runtime; should that be included in the inputs then? even though I refer to it directly with #$rocclr-src? <podiki[m]>it doesn't get used as a regular input, but wondering if that makes the dependency clearer <PurpleSym>I don’t see any value adding it to inputs. It’s not a proper package. <podiki[m]>and just checked old version of rocclr does just build, so we could keep it for now <podiki[m]>I see Arch and Gentoo build rocclr within rocm-opencl-runtime, but it doesn't seem to do anything <podiki[m]>maybe in my patch email I'll just include the few lines that do that for future reference, but it seems rocm's build instructions aren't fully up to date or clear on this <podiki[m]>(it is an explicit cmake call with some configure flags, then make, but just pointing to the source of rocclr works for me) <podiki[m]>any other tests I can run? I just have everything building successfully and darktable-cltest works, as does darktable itself with opencl <PurpleSym>But if darktable works that’s usually good enough. <podiki[m]>great, I think I just need to do a quick cleanup and write the commit message (bit long for all of rocm probably) <podiki[m]>llvm-for-rocm I updated too, unfortunately that means for testing one needs to build llvm <PurpleSym>Not sure if there’s any other users of rocm beyond you and me. I’m fine building LLVM. <podiki[m]>great, I'll let you know when I submit the patches <podiki[m]>welcome, but it was purely selfish of course! <Guest11>I'm somewhat puzzled. I was here last week because i was unable to `guix pull`. The problem was some variable still referenced in ~/.cache/guix/checkouts. Now i've run in the same (?) problem again. I'm now on a different machine (guix system, 2 additional channels). Last time i simply deleted the checkouts cache which made `guix pull` run <Guest11>successfully again - this time that trick doesn't work. The package (that is not part of Guix source anymore) is now libpng-1.2. <Guest11>Any ideas on how to make my machine (or profile) `pull` again? I now suspect that the problems stems from me not pull-ing too regularly (last pull was ~23days ago). <unmatched-paren>Guest11: that's because one of your channels seems to use the removed libpng <unmatched-paren>apparently one of the nonfree channels still does (not the one with the blobby kernel) <Guest11>unmatched-paren: ah yes, i see! thanks for the hint! <PotentialUser-75>when one of my packages builds it touches /etc/SharedConfDir to put some share common data there, but i'm getting a permission denied, any tips on how to deal with similar situation? <unmatched-paren>PotentialUser-75: you'd probably have to patch it to use $out/etc/SharedConfDir instead <sneek>katco, podiki[m] says: if it was you that wrote about opencl on guix, I hope the rocm update I will submit soon will help, let me know if it does or if you need the bug number (once I submit) <PotentialUser-75>unmatched-paren what is the recommended "$out" permission model ? rw for all ? is it a common case ? <unmatched-paren>PotentialUser-75: $out is short for the "out" output, which is somewhere in /gnu/store :) you can get $out with (assoc-ref outputs "out"), if you have it listed in the phase lambda: (lambda* (#:key outputs #:allow-other-keys) ...) <maximed>n/quitPotentialUser-75: everything in the store is read-only <maximed>except for the store items of the package that is being built, that's read+write <podiki[m]>katco: what card do you have? I went down the rabbit hole of trying to find what was supported or not, but it is really not documented <podiki[m]>katco: I decided to just try: I'm on a 6700xt and the newer rocm works for me <katco>podiki: sorry, i don't really have time to discuss right now, but 5700xt <podiki[m]>katco: no worries; I'll let you know when the patch lands (about to send), but I feel like you will have a chance in it working since mine does. hopefully <katco>fingers crossed that it just works for my card too :) but i don't know when i'll next have a free moment to try. things are kind of crazy for me right now. <katco>tysm for the ping on this. very thoughtful! :) <podiki[m]>welcome! once that patch is merged (unless you want to build llvm locally) you can give it a shot, at least with rocminfo or darktable-cltest to see that you get something opencl working <podiki[m]>your blog post helped me get to the right direction, so thank you too :) <katco>:D team work makes the dream work :p <podiki[m]>and let's hope Mesa gets full opencl in the near future, make everything much easier ***mark_ is now known as mjw
<PurpleSym>podiki: I’ll have a look tomorrow and see whether 5.0 still works on my GPU, thanks again. <podiki[m]>PurpleSym: no problem! if it did remove support for your gpu, guess we'll start keeping older versions... <char[m]>What does an `failed to produce output path' with an empty build log mean? <podiki[m]>I think that there was nothing built/made in the output path <kaelyn>char[m]: a bit more detail would be helpful to diagnose the specific problem, but I believe I've seen that error when nothing was installed to the package's output path (in my case, from a broken custom install phase) <podiki[m]>nothing ended up in what should be /gnu/store/<hash>-packge-version/ directory <attila_lendvai>so, i have a HP printer on USB, and hplip-minimal installed. in gnome settings the printer is detected, but installing it fails. this is in the cups error log: [cups-driverd] Unable to open driver directory \"/gnu/store/rwrmqxklbdq85lwjgjl56r9zh54066ra-cups-server-bin/lib/cups/driver\": No such file or directory. what am i missing? *the_tubular Thinks we are getting closer to a 1.4 release! <unmatched-paren>the only change i made to that file was to add go-target to the #:export list <unmatched-paren>oh, that paste is missing (srfi srfi-1) in #:modules, but my local copy isn't, so that isn't causing the problem <jpoiret>unmatched-paren: isn't your first let bound variable missing a closing parenthesis? *attila_lendvai has managed to add his printer using the cups web interface. it's only the gnome settings that is broken. <PotentialUser-75>unmatched-paren actually its a system package so its okay for it to put things in /etc i want all the user to have access to this folder <jpoiret>do you have the build log somewhere? <unmatched-paren>i see that go-cross-build uses (first (go-target ...)) to get the architecture, so i'm not sure why it's not working.... <jpoiret>unmatched-paren: for some reason, the phases list ends up having ('regenerate-types "amd64") in it <unmatched-paren>jpoiret: um, this is cursed... i moved the ungexp to #$(first (go-target ...)) and it worked O_o <justkdng>hello everyone, I'm trying to do a guix pull before installing guix <justkdng>but when switching to a tty and writing guix pull I get this error <justkdng>In procedure struct-vtable Wrong type argument in position 1 (expecting struct): #f <nckx>justkdng: Assuming you can copy & paste, can you share the full 'trace at paste.debian.net? <nckx>Cursed is a bit much: ungexp does not return a list. <nckx>justkdng: Is this reproducible? Not making excuses but often these *horribly* reported errors are 'transient'. ***Noisytoot_ is now known as Noisytoot
<nckx>unmatched-paren: 'Unintuitive' unquestionably. <justkdng>well, every time I do a guix pull I get this error <justkdng>could it be a recent guix commit or something? <unmatched-paren>justkdng: can you please `guix describe`? btw, is this the latest or stable image? <justkdng> commit: 598f7289db9955584457ffc11c8504f3938a1618 *unmatched-paren guix pulling <jpoiret>we had a lot of similar issues due to the platform changes <jonsger[m]>attila_lendvai ah that experience about gnome-printer-settings I could have told you :P *jonsger[m] already signed up for Paris meeting :) <attila_lendvai>jonsger[m], you mean it has a solution, or that it has never worked? :) <jonsger[m]>that gnome-printer-settings had some issues, I didn't fixed them... <flugo>hello folks! I have some software that I'm trying to package which only be built if the `.git` folder is present (the build script uses it for some version checking shenanigans) <flugo>but when packaging and using `git-fetch`, that `.git` folder isn't present so the build fails <flugo>this sounds like a problem with a known solution :) <flugo7>it could be an X/Y problem and I'm misunderstanding something, but I can build the thing myself in a guix shell with the `.git` folder present, and that folder is absent from the checkout folder in the gnu store ***flugo7 is now known as flugo
<nckx>flugo: Instead, we tend to override such shenanigans to return the proper Guix package VERSION, for example with something like (substitute* "naughty-script" (("\"git --sniff-my-own-.*\"") (string-append "\"echo " #$version "\""))) <flugo>nckx : thanks! sorry I got disconnected, I don't have a proper IRC client yet on this machine so I'm using the browser thing <nckx>No problem, and now you know about the logs :) <flugo>in this case such shenanigans are ingrained a bit deep into the script, so I was sort of afraid that was going to be the answer. oh well! <nckx>There is usually a simple substitution, but yes, upstreams can make it a fun adventure to find it. *vagrantc wanders off into the mountains <jorge[m]>Hola, How to repair or reinstall the Guix package administrator? <vagrantc>wow, i typoed the name of the package in the commit description ... thankfully did the right thing in the actual code <lechner>Hi, when git-downloading sources from a non-standard branch, should one rely on the commit hash alone to get the right version?