IRC channel logs


back to list of logs

<nckx>Depending on your ‘learning style’ (ralph) it might help just to bust out a REPL and try a few things.
<unmatched-paren>I *think* it might be possible to define (begin ...) in terms of (let () ...)?
<unmatched-paren>(define-syntax-rule (begin expr expr* ...) (let () expr expr* ...))
<nckx>unmatched-paren: Yes.
<nckx>This is all very Scheme.
<kabouik>I think I kind of understand what When serves, but since this is all new and very different to everything I know, and since the little I know I learnt myself in small steps as a simple Linux user (not programmer), I'm just bumping my forehead real hard at the Guile learning curve.
<kabouik>I was quite happy to even be able to get that .scm to build (with a lot of help), but the formatting conventions for the tests phase that I can't read better before or after it's formatted, that's beyond my current level :<
<unmatched-paren>kabouik: Would it help if I explained it with a hypothetical C-like syntax?
<kabouik>Nope, you'd have to make it R. Good luck. :P
<nckx>Scheme is not a complicated language. It helps to remember that. It can be made to look complicated and do things as complex as any language, but you should always be able to see the underlying primitives if you peer hard enough. (Something which I sorely miss in, say, Haskell.)
*nckx no speak R.
<kabouik>I don't think R shares any common ground with common lisp really
<unmatched-paren>kabouik: Scheme invented lexical scoping, I believe.
<unmatched-paren>It probably has more of an influence than you think it does :)
<unmatched-paren>kabouik: Also, Common Lisp is quite different from Scheme.
<kabouik>R is designed to manipulate data, analyze and build graphics, it's not fast and not programmable like common lisp. But it's easy to understand. You have functions, which take arguments. And when you bump into a new function that you might need, you can just type ?thatfunction to show its help, which arguments it takes, and possibly an example. This really helps improving discoverability. I miss that with Lisp, but I know it
<kabouik>actually is superior to R, the latter being a bit trivial and not as potent as lisp. I mean, you wouldn't write complex software with R.
*unmatched-paren bye
<kabouik>Oh, I thought Scheme and Guile were both under the broader group of Common Lisp, misconception probably
<drakonis>guile is a scheme implementation slash dialect
<nckx>s/Common // and basically true. There are part of the Lisp family.
<nckx>‘Common Lisp’ is a leaf on the family tree.
<kabouik>Got it
<nckx>In fact, Common Lisp (maximalist, Stardardised™, enterprisey) is probably the most distant relative of Scheme (minimal, ‘elegant’ in the eyes of its many lovers).
<nckx>(Both are stereotypes of course.)
<nckx>Did you finish your lambda* yet?
<kabouik>Being in #guix and #nyxt channels gives me all sorts of contradicting signs on what Lisp language is the best :p
<nckx>Hey, I said nothing about that :)
<nckx>They are just the two most different, I think.
<kabouik>No group is talking in a bad way about the other language, don't get me wrong, but of course preferences are not the same
<civodul>kabouik: there's only one correct answer though
*kabouik checks if civodul is in #nyxt.
<kabouik>Not yet nckx. I was thinking `(lambda* (#:key tests? #:allow-other-keys) (when tests? (invole "ctest" "--output-on-failure"))`, but I may as well just play Euromillion
<nckx>That looks good?
<kabouik>I just merged what both of you said above, and luckily each one of you took one pair of brackets so that made it easier for me to merge
<kabouik>Seems to build
<kabouik>You all better install nmail and use it
<nckx>It's really just (FUNCTION (ARGUMENTS [oh and ignore arguments you don't recognise]) BODY).
<nckx>And BODY is just ‘when tests, then invoke tests’.
<nckx>It's not as complex as it might look.
<nckx>You wouldn't write it all on one line in a file, which also helps.
<kabouik>No need for aerc anymore unmatched-paren, it was decided nmail is mandatory now.
<kabouik>> (FUNCTION (ARGUMENTS... This actually is one of the major roadblocks for me, and also why I mentioned how ?somefunction in R really helped me learn it. In Scheme, or Lisp in general in fact, I look at words but don't know when they're arguments or functions, and when they're a function, how many arguments they take. I imagine I need to go check in the source code each time, or functions defined above, but it's not the natural
<kabouik>reflex for me yet.
<nckx>kabouik: I don't really understand what you mean by merging, should not need merging?
<nckx>But I didn't read every single line in the convo, it is true.
<kabouik>unmatched-paren said my lambda part was right, and you posted just above the when tests? part. I just concatenated them
<nckx>Soon you'll find this trivial to write and understand.
<nckx>Promise (if you stick with it, at least).
<nckx>It is after all a teaching language.
<kabouik>Hope so. I'm commited and genuinely want to embrace the Guix way, but it's not trivial for non-programmers, I think. I also hope I'm not bothering you too much; the channel has been flooded by my first world issues since a few days (and you all showed a lot of patience, thank you).
<drakonis>it is a fairly trivial affair to learn
<pashencija[m]>It's sad that was not tested on arm before merging
<pashencija[m]>It basically broke building aarch64 images on aarch64 hosts
<kabouik>Speaking of, I just found out about the qemi-binfmt service, and this looks very useful.
<drakonis>pashencija[m]: has it?
<drakonis>to be fair, if it is broken, then it is worth fixing it?
<pashencija[m]>Indeed it has
<drakonis>it doesnt seem like it has anything that could've broken it
<pashencija[m]>How to disable grub-efi32 in the image completely?
<drakonis>it isnt touching any arm bits
<pashencija[m]>Well, in fact my non-grub image began to build grub
<pashencija[m]>And it fails as grub-efi32 cannot build on aarch64
<pashencija[m]>With `checking for options to compile assembly... configure: error: could not compile assembly`
<drakonis>i'm not sure why it is building that?
<nckx>kabouik: It is! It's quite magical to be able to build (and run) foreign-architecture packages with such ease.
<drakonis>hm, i see why
<pashencija[m]>drakonis: No idea!
<kabouik>Does that work the other way around too nckx, i.e., running x64 builds on arm machines?
<pashencija[m]>drakonis: And I also cannot understand how to disable it entirely in my image. Is that possible?
<pashencija[m]>kabouik: It does
<kabouik>That is cool.
<nckx>What's x64? It sounds familiar but I can't place it. There is no direction, so yes, it works any->any as long as QEMU supports it kabouik.
<drakonis>64 bits
<kabouik>short for x86_64
<nckx>64 bits anything?
<drakonis>also known as amd64
<nckx>It's Microsoft for x86_64 isn't it.
<drakonis>so it is
<nckx>I knew it was familiar.
<kabouik>Oh, it's a Microsoft short? I didn't know.
<nckx>I think so?
<nckx>Not that it matters, but x86_64 is a lot more common & familiar here I think.
<drakonis>pashencija[m]: try setting it to #f
<nckx>The whole ‘64-bit x86’ (and even ‘x86’ itself) naming is a mess anyway, so it doesn't really matter.
<kabouik>That's what I usually use, just started using x64 consistently since not more than a couple weeks actually, because I was using it a lot and got tired of the long name. I thought they were exact synonyms.
<drakonis>pashencija[m]: i'm reading that patch wrong
<nckx>They probably are. ‘x64’ just wasn't familiar.
<drakonis>anyways, the patches really werent tested for arm
<nckx>And since you were speaking of ARM, of which I know little, it was possible that it was an ARM thing.
<drakonis>if you could write patches to fix it, it would be quite nice
<pashencija[m]>I just don't understand why is grub built on a non-grub image
<nckx>Is there no CI job that would have caught this if the CI hadn't been on summer holiday?
<drakonis>it'd help if you posted the image config somewhere
<pashencija[m]>No problem, it's public
<drakonis>ah, that's still around, huh.
<pashencija[m]>It's actually must be affecting any aarch64 systems, not just this one
<pashencija[m]>Pine64 products, for example
<drakonis>relevant commits
<drakonis>pashencija[m]: highly suspect that it is the presence
<drakonis>of grub-efi32 in the image root initializer
<pashencija[m]>drakonis: What do you mean?
<pashencija[m]>Is there any way to disable it?(
<drakonis>bisect them in a channel?
<pashencija[m]>I need to test an important patchset we were going to upstream
<pashencija[m]>For arm machines
<pashencija[m]>I feel like the gotta fix this one first
<pashencija[m]>drakonis: Sounds like a good plan for now
<kabouik>Do I understand right that I shouldn't just paste my nmail.scm into gnu/packages/mail.scm, but just the `(define-public …)`, and then just add the missing #:use-module at the top, if any?
<kabouik>And copyrights are just for the core team I assume
<vagrantc>anyone who writes copyrightable content
<vagrantc>(though what is considered copyrightable may not exactly be absolutely clear)
<kabouik>I was thinking that
<vagrantc>e.g. bumping a version number and corresponding hash isn't exactly creative expression :)
<vagrantc>but writing a package descriptiong or synopsis, definitely
<kabouik>You'd consider a package is creative content? I was not even putting packages in that category
<vagrantc>a guix package definition is code ... although a boilerplate package maybe not if it was programatically created
<vagrantc>adding a dependency? probably not.
<kabouik>In my example I think the real work was done by IRC and the dev who wrote the sources (but they're in the License already)
<vagrantc>writing a custom phase, probably!
<vagrantc>a commit message ... maybe probably?
<kabouik>If packagers are in the copyright, I shall add myself; I wouldn't mind at all being wiped from it either.
<vagrantc>comments describing the thing, certainly
<kabouik>Now, checking all modules…
<kabouik>So basically any form of creation deemed relevant by the core team that merges patches.
<vagrantc>anything you write creatively is generally covered by copyright in (many? most?) jurisdictions
<kabouik>If I somehow manage to smuggle a smiley in mail.scm, and claim it's mine, I should get a copyright line? :P
<kabouik>Do you folks have a routine for checking modules, sorting them alphabetically, and removing duplicates? I would expect emacs to do some magic there.
<kabouik>I can do the first two parts with kakoune but I'm not sure about duplicates.
*vagrantc so wishes guix had a convention of sorting package definitions alphabetically
<vagrantc>duplicates probably shouldn't be there
<kabouik>I expect all the modules I needed for the package to be there already
<kabouik>But never know
<kabouik> (guix build-system go) seems to be duplicated (before my commit) already
<kabouik>Same with (guix utils)
<vagrantc>kabouik: good luck and have fun, gotta go
*vagrantc waves
<kabouik>On the other hand the addition of modules there is very error prone
<kabouik>See you
<efraim>I have a fix for grub-efi32 on aarch64
<pashencija[m]>efraim: Really? Could you please submit a patch?
<pashencija[m]>Does it fix the problem with package that's not building or does it allow to build an image without grub?
<efraim>it fixes the problem with building
<pashencija[m]>If you're not willing to submit the patch, could you please at least send it to me so I use it here?
<efraim>I've pushed it to master
<pashencija[m]>Wow. Thank you!
<pashencija[m]>Is there a reason this package is built on non-grub systems? Is this intended?
<drakonis>unlikely to be intended
<drakonis>an uncaught mistake
<kabouik>The git send-email is giving me trouble. I added the smtp and credential (except password) settings in ~/.gitconfig, but send-email doesn't ask for my password after I confirm I want to send the email.
<kabouik>It just hangs.
<gnucode>hey guix!
<pkill9>anyone know why pcsxr package fails to build?
<Guest85>Hi all, I was trying to build llvm on guix with some modifications using `guix build llvm --with-source=./path/to/local/source` but I got a message saying that the `with-source` option has no effect on the llvm package. Anyone know why that would be?
<nckx>Guest85: --with-source=llvm=…
<nckx>pkill9: Apart from the linker error (missing -fcommon?), $something is pulling in pango headers which then try to include a harfbuzz header (#include <hb.h>) which of course fails.
*nckx → 😴💤, good night.
<Guest85>nckx: thanks!
<yewscion>Hello all, I think I did a bad. I just sent a patch series to, but from the email responses it looks like it may have created an individual issue for each patch in the series.
<yewscion>If this is the case, I apologize. I should have sent an informative email first, and then the patch series once the issue was created, and will do so in the future.
<yewscion>Yup, looks like it did indeed create 5 separate issues (56989-56993). Again, my apologies. Should I create a sixth issue in the correct way and trash the rest?
<iyzsong>yewscion: i'd say no need to create another one, but that if you like to, then it's okay too, it's a common thing so don't bother with it so much :)
<yewscion>iyzsong: Okay, I'll wait until it becomes clear it's necessary. Thanks for the reassurance!
<iyzsong>no problem, and in public inbox they are group into one:
<yewscion>Thank for for the link! I somehow hadn't come across that.
<raghavgururajan>Hello Guix!
<yewscion>Weird tangentially-related packaging question: Does anyone know how I might avoid redefining a function used inside of another build system? I am looking to solve the non-determinism in one of the above-submitted packages (dbqn), and per it seems the issue is timestamps in jarfiles, which ant-build-system handles in its strip-jar-timestamps procedure.
<yewscion>Can I use that procedure without using ant-build-system to build the package? Or should I just copy and paste the code into the module with my new package?
<yewscion>Hello raghavgururajan!
<lilyp>yewscion: "...without ant-build-system" not really. What you'd typically do is import the relevant module and then use the phase from there. You can do this regardless of the build-system of the package, though, which is probably what you were asking for
<yewscion>lilyp: But the issue I'm having is that this particular procedure is not public (it's a define*). Is there a similar mechanism to double colon (::) in common lisp in Guile Scheme, that lets You access a module's private symbols?
<lilyp>you probably don't need to, you can access it by %standard-phases
<lilyp>but sure, @@ and module-ref (with the module rather than the interface) do that
<yewscion>lilyp: Thanks! I'll read up on those two mechanisms for Guile. That said, I guess I just wasn't familiar with how %standard-phases is populated within a package. I thought it would be the standard phases for the declared build system, not an amalgam of all of the build system modules listed in use-modules.
<lilyp>Well, I don't think there would be a procedure to set jar timestamps without a phase that uses it.
<yewscion>lilyp: There is, in ant-build-system. But my package uses gnu-build-system.
<yewscion>I must be missing something, sorry. I've added #:use-modules (guix build ant-build-system) to the module declaration, and I've added (write %standard-phases) to a phase in the package in question, and it doesn't seem to be in there.
<lilyp>Because #:use-modules is for the defining module, not the package. Packages have a #:modules and #:imported-modules argument
<yewscion>lilyp: Is there documentation for these arguments anywhere? I've looked at some other packages, but the closest I've come to understanding what I'm looking at is getting my package to ask me to manually add each module gnu-build-system depends on to #:imported-modules.
<lilyp>There should be a variable %gnu-build-system modules that you can simply splice via ,@
<lilyp>similar for other build systems
<lilyp>IIRC every package that does that should ,@ it'd be weird if you found one that doesn't
<lilyp>But for a humorous and simple example, see shakespeare-spl in esolangs.
<yewscion>Copy that, will do! Thank You for all Your help!
<vivien>Dear guix, is it OK if I fix perl for mingw to use cmd.exe instead of bash?
<vivien>I doubt it but maybe
<civodul>Hello Guix!
<civodul>vivien: you'd have to do it in a way that doesn't trigger a world rebuild
<vivien>civodul, I mean, what is bash used for in perl? Spawning processes? In that case maybe cmd.exe is enough. Does it need to handle file redirections? Then cmd.exe is not enough. It depends on how the shell is used by perl at run-time, and I don’t know much about perl.
<vivien>Hey, visual c++ build for perl defines the shell to be "cmd /x /c" by default
<civodul>vivien: dunno, you'd have to check exactly how Perl uses Bash
<civodul>then again, the choice between cmd.exe and bash is maybe something better left to Perl developers?
<vivien>I would like to hear about the issue from a perl point of view
<vivien>But if perl devs thought cmd was good enough when building with visual c++, then maybe it is good enough for us
<civodul>yeah, could be
<kabouik>Any user of dwservice ( on Guix? It's a really convenient alternative to proprietary things like TeamViewer and other remote desktop solutions that work on WAN without a static public IP (machine are agglomerated under an account, so you don't need to know their current IP to contact them); or for one-time connections using throwable credentials.
<kabouik>I'd be interested in getting it packaged but I'm not ready for that kind of complexity yet I'm afraid.
<unmatched-paren>kabouik: It could be a good way to learn to write a service, but yes, it would probably be too complex at this early stage
<unmatched-paren>kabouik: regarding your git send-email problems, here's my gitconfig for reference
<kabouik>I already tried the agent on my Guix machine to use it as host, without installation (the agent can either be installed or run temporarily) and it works, screensharing was not working though but I could still access other applications like shell, file manager, resources, etc. It's under MPLv2 license (
<kabouik>Thanks unmatched-paren. In the end it just worked some time later without changing my settings; I suspect git send-email was keeping in cache some wrong setting I may have tried first from CLI, or a smtp server hiccup.
<unmatched-paren>Ah, okay.
<unmatched-paren>There's also <>, which is not directly relevant but interactive rebasing is cool :)
<kabouik>Oh but you're using disroot too, that makes your config even more interesting because I thought that was my issue last night
<AwesomeAdam54321>if dwservice-agent was packaged, would it go in admin.scm?
<kabouik>Re "I already tried the agent on my Guix machine to use it as host, without installation": the installation itself does not work, presumably mostly because dwagent expects the usual file structure. But I found it intersting that just running it was mostly working, with the exception of screen sharing (again probably just because the required lib is not where it expects it).
<unmatched-paren>AwesomeAdam54321: admin.scm is basically random-stuff.scm :) so probably
<AwesomeAdam54321>I'm currently trying to package GNU Kart, but when the build process tries to #include SDL_image.h, SDL_image.h says it can't find SDL.h:
<AwesomeAdam54321>/gnu/store/k7y6i2v5qfm161zf88ynp5amk92ylpqc-sdl-image-1.2.12/include/SDL/SDL_image.h:27:10: fatal error: SDL.h: No such file or directory
<AwesomeAdam54321>hmm, if I don't pass CFLAGS+=-lm to make it provides the SDL directory as a search path again
<unmatched-paren>AwesomeAdam54321: Could you paste the package?
<AwesomeAdam54321>It builds but for me it segfaults when I try to run it
<AwesomeAdam54321>wait I forgot to include two patch files
<unmatched-paren>I think you need to add an include flag
<unmatched-paren>-I /gnu/store/...-sdl-.../include
<unmatched-paren>Oh, wait
<unmatched-paren>-I /gnu/store/...-sdl-.../include/SDL
<unmatched-paren>That will make the paths correct
<unmatched-paren>Then you can remove those #include substitutions
<unmatched-paren>Also, try using gexps for #:configure-flags, like this:
<unmatched-paren>And the #t at the end of the phase isn't necessary anymoe
<unmatched-paren>AwesomeAdam54321: untested
<unmatched-paren>AwesomeAdam54321: small fix
<unmatched-paren>typo: s/mixor/mixer/
<unmatched-paren>this seems to work
<unmatched-paren>apparently you don't need that phase at all
<unmatched-paren>Hmm, yes, it segfaults for me too
<unmatched-paren>Ah, will the patches fix it?
<AwesomeAdam54321>These patches add missing #includes
<unmatched-paren>I see, but I don't think that will stop the segfaults
<unmatched-paren>If it builds without those includes, it probably doesn't need them
<AwesomeAdam54321>Is guix planned to be used to produce bit-for-bit reproducible tarballs for GNU projects, like GCC?
<nckx>Hi Guix.
<nckx>‘-I’ in CFLAGS is hella sus.
<nckx>civodul: Oh, it happens:
<nckx>The backtrace doesn't look that useful to me, but I'll post it to the bug report if you think it is.
<unmatched-paren>nckx: The last stable release was in 2010, so it's not entirely surprising
<unmatched-paren>It appears to be abandoned since 2017
<unmatched-paren>and that 2017 version is an attempt at a complete rewrite
<unmatched-paren>which doesn't seem to have gotten very far at all :)
<unmatched-paren>Only 62 bzr revisions
<nckx>They honour both LDFLAGS & CPPFLAGS though.
<unmatched-paren>Good for them.
<nckx>Meaning there's no need to clobber CFLAGS.
<unmatched-paren>I thought that was a joke about their makefile being good :)
<nckx>Heh. I didn't… no… let's not.
<unmatched-paren>So should the -l go in LDFLAGS, and the -I in CPPFLAGS?
<unmatched-paren>Seems like a bit of a pointless distinction to me but ok.
<nckx>I just mean the WIP package above clobbers CFLAGS (deleting -O2 -g). Even though it's not to blame for this segfault, it's a bad idea to drop upstream's CFLAGS.
<nckx>They sometimes know what they're doing.
<unmatched-paren>Ahh, right
<nckx>unmatched-paren: Uhm, you're deleting all upstream CFLAGS.
<unmatched-paren>Well, maybe it is to blame! Optimization does strange things sometimes
<nckx>Not doing so is not pointless :)
<nckx>Alas, no, since I tried that.
<nckx>Cleaned-up version that still segfaults:
<unmatched-paren>Maybe we should try the latest non-rewrite bzr rev. Do we have bazaar-fetch stuff?
<nckx>But keeps that sweet -O2 so it segfaults faster, probably.
<unmatched-paren>There's also a CVS mirror if we don't have bzr.
<unmatched-paren>s/don't have/can't use/
<nckx>I don't have debug symbols installed but ew, scanf:
<unmatched-paren>I suppose you do need a *very* good reason to do a complete rewrite :)
<nckx>Oh, we have a bzr fetcher.
<nckx>I think nginx uses bzr, for one.
<nckx>But I should be working and this is not working. I'll pop in later to see progress!
<unmatched-paren>Okay o/
<unmatched-paren>But we shouldn't try to bzr-fetch the latest commit, because that seems to be part of the complete rewrite.
<unmatched-paren>Oh, hmm. Looks like the non-rewrite game isn't that far on in development either:
<unmatched-paren>There are currently three characters that have a (incomplete) 3D model to them: GNU, guile, and icecat.
<unmatched-paren>You have to run it from the command line and it only lets you go through one lap and then quits, but the computer characters will drive around the track nicely.
***civodul` is now known as civodul
<kabouik>Hey unmatched-paren, thanks for the reply! Did you drop libetpan from the list of inputs on purpose, or did it just slip when you ordered them alphabetically?
<unmatched-paren>kabouik: Ah, I must have forgotten it, yeah
***wielaard is now known as mjw
<apteryx>I'm still a bit rusty when it comes to reporting errors in Guix; on the user side, should I raise an error via format-error, or prefere 'leave' when encountering a fatal error?
<apteryx>I'd normally use 'leave', but for what I'm doing it seems perhaps easier to unit test if it's using format-error, as I can catch and match the message to something expected
*apteryx tries stuff
<Cairn>So I was yapping about terminus a couple weeks ago. Turns out the package does build the otb version.
<Cairn>I'm confused though: why can't my system see it? Do I need to configure the package for it to be added?
<Cairn>I've done fc-cache -rv
<unmatched-paren>When I install a font it just appears, though I think guix home does something with fontconfig
<Cairn>Well, the pcf versions of the font appeared with no issue
<nckx>Appeared where?
<Cairn>idk, that's the verbage unmatched-paren used
<Cairn>When I do fc-list I only see the pcf versions
<unmatched-paren>'installed correctly', 'was made available', that's what I meant
<nckx>Cairn: I think you forgot to install the :otb output.
<nckx>I.e. ran ‘guix install font-terminus’ instead of ‘guix install font-terminus:otb’.
<gnucode>unmatched-paren: I don't know if you noticed, but I sent a patch for that debbugs-my-open-bugs to guix-pathches. bug 56987
<gnucode>morning nckx!
<unmatched-paren>gnucode: Yeah, I noticed :)
<Cairn>nckx: That explains it. Thank you
<yuu[m]>sneek: botsnack
<shcv[m]>what's the recommended way for updating a really old guix install that can't complete a `guix pull`?
<unmatched-paren>shcv[m]: I'm not sure whether this will do it, but maybe try `guix time-machine -- pull` if it has time-machine
<shcv[m]>ok, I'll try it
<yuu[m]>shcv: guix system init /mnt/etc/config.scm /mnt?
<unmatched-paren>I've never used time-machine, so I think it's likely it won't work
<unmatched-paren>yuu[m]: How would that update the machine?
<yuu[m]>unmatched-paren: well, you'd completely reinstall it ig maybe with a live iso
<shcv[m]>I was thinking there might be a way to run the reconfigure from a checkout of the guix repo
<shcv[m]>using pre-inst-env or whatever the script was
<unmatched-paren>Oh, that's a good idea
<shcv[m]>but I'll try the time-machine idea first to see how magical the time machine is :P
<unmatched-paren>You might need to explictly specify the latest commit, idk
<shcv[m]>but yeah, my previous pull was ~520 days ago, with 24k new commits :D
<unmatched-paren>But try it without that first
<AwesomeAdam54321>I wonder if people have Guix that are 3 years or older
<rekado_>I’m older than 3 years, and I use Guix.
<shcv[m]>sadly, time-machine was insufficient
<AwesomeAdam54321>lol, what I said was ambiguous
<AwesomeAdam54321>shcv[m]: Can you time machine 6 months into the future from your previous guix pull and guix pull that way?
<unmatched-paren>Or just guix pull 6 months and then guix pull again :)
<shcv[m]>yeah, I need to do something like that; I can't even build guix from source with the current guix I have 😢
<shcv[m]>is there a way to pull a tag or something? maybe I could update to the minor version tags
<unmatched-paren>--commit probably takes tags
<shcv[m]>I just looked up the commit hash for 1.3.0 and the pull for that seems to be working
<shcv[m]>hopefully that one can take me the rest of the way
<Cairn>On, there's a little dropdown on the right that says of each spec that says "Edit" and "Deactivate"
<Cairn>Are people supposed to have access to that?
<efraim>you need to be authenticated to actually use the buttons, so it's not a problem
<Cairn>Ok cool
<yuu[m]><shcv[m]> "yeah, I need to do something..." <- reproducibility at its best. iirc nix/nixos also has such issues
<unwox>hi. do you know if it's possible to use "home-channels-service-type" and import modules from custom channels in one "guix home reconfigure" command? if not then how this service is supposed to be used? currently while installing new system i manually copy channels.scm from dotfiles to ~/.config/guix, but i'd like to automate this step using guix tool
***Dynom_ is now known as Guest7377
***mark_ is now known as mjw
<atka>hi guix, are there any gotchas running non guix software (not nonguix) eg. app images, tarballs etc?
<atka>basically stuff not pulled by the package manager
<vagrantc>it if depends on files in /lib or /usr/lib or such, it just won't work
<vagrantc>if it ..
<atka>ok, gotcha, thanks. how's the honeycomb?
<atka>last I heard you had debian booted but thats all
<unmatched-paren>there's a FHS container option for guix shell in the works
<unmatched-paren>so you could run non-guix software in that
<atka>oh cool, that would be graet
<vagrantc>atka: haven't done too much else with it ... lots of other things going on
<atka>I hear you, I've been busy as hell too
<podiki[m]>atka: for the fhs container patches
<podiki[m]>needs some rewrite/tests, but functionally is set I think
<atka>podiki[m]: thank you!
<podiki[m]>there was also a discussion on guix-devel that I think had some examples of usage
<atka>ok, I'll check the logs
<podiki[m]>or feel free to ask me here (it is my patchset and I do use the fhs container)
<atka>thank you
<PotentialUser-58>Hello, I have a build error installing rust-cargo. In log of the build I have this line:
<PotentialUser-58>failed to run custom build command for `libgit2-sys v0.12.25+1.3.0`
<PotentialUser-58>Anyone else has similar error?
<blake2b>is there a good way to hack guile on checkout, the way we do with guix?
<blake2b>I've fixed a bug and want to do some tests, but running ./libguile/guile won't boot from the repo, and I didn't run "make install" because I don't want to cause a namespec collision
<Cairn>Does anyone know if configuring fontconfig changes the output of fc-list? Like, if I set antialiasing to true in my config, are the fonts that have antialiasing disabled supposed to say true instead?
<Cairn>Or do I have to just rely on knowing that I've changed the setting
<nckx>Cairn: If you are able to edit and deactivate CI things, please let us know 😉
<Cairn>nckx: I'll give it a shot
<nckx>Oh, I didn't mean you had to expend $effort.
<Cairn>No I just get 403s when I try to change anything
<Cairn>So it seems good
<nckx>Good good. Thanks!
<nckx>Cairn: <fc-list> Not as I understand it.
<nckx>Not an expert though.
<Cairn>I can't get the config to work I guess
<blake2b>the error I get is: "Pre-boot error; key: misc-error, args: ("primitive-load-path" "Unable to find file ~S in load path" ("ice-9/boot-9") #f)Aborted"
<blake2b>I don't know if perhaps the libguile directory is not the place to run it from... it seems to be, from poking around
<PotentialUser-58>Could someone try `guix shell rust-cargo`. Are you able to successfully install it?
<blake2b>PotentialUser-58: cargo is installed as a separate output
<blake2b>so you run guix install rust:cargo
<PotentialUser-58>blake2b: Thanks I'll give it a try
<PotentialUser-58>blake2b: Thank you! It worked!
<blake2b>not sure why there is a rust-cargo in there tbh
<nckx>Cairn: What I've noticed (but not investigated) is that fontconfig won't load anything from conf.d (*despite* printing ‘Scanning’ when FC_DEBUG=1024 is set!) but loads a fonts.conf in the same location just fine.
<davidl>nckx: hi, any estimate on when the bash-bcu patch will get merged?
<nckx>I'm waiting for a reply to a question about it.
<nckx>(Not from you.)
<nckx>I was tempted to push the dependencies, which are ready, but they make little sense without the bcu.
<Cairn>nckx: Interesting. I'm using a fonts.conf file though. Probably user error.
<Cairn>I just wish Terminus has larger sizes. I'm gonna make my own version someday I guess.
<davidl>ok! I was just nervous things will be forgotten about, but seems like they aren't :-)
<blake2b>Cairn: I know this is obvious, but just to check, did you source your profile?
<nckx>blake2b: Interesting (not obvious :), could you explain?
<nckx>davidl: I don't think I'll forget about BCU until the day I die. And even then.
<pashencija[m]>Maybe I'm asking a wrong question, but
<pashencija[m]>Do arm substitutes work now? I haven't seen any in a while
<blake2b>yeah sure, maybe "source" isn't the correct terminology
<efraim>bayfront has more aarch64 substitutes than berlin does
<blake2b>but the good ol' GUIX_PROFILE=/home/user/.guix-profile
<blake2b>and then
<blake2b>. "$GUIX_PROFILE/etc/profile"
<pashencija[m]>efraim: I don't understand you. Do I need to enable it in my system?
<efraim>pashencija[m]: you want to make sure you have #7D602902D3A2DBB83F8A0FB98602A754C5493B0B778C8D1DD4E0F41DE14DE34F# in your /etc/guix/acl file
<blake2b>Cairn: if you haven't run that, try it. it sets your environment variables
<pashencija[m]>efraim: I do not think I have /etc/guix/acl at all
<efraim>if you don't have an /etc/guix/acl at all then you won't get any substitutes
<blake2b>(the period is just shorthand for "source", which is why I asked if you "sourced" your profile)
<nckx>blake2b: I'm just curious how that affects fontconfig config… er… uration.
<nckx>(Genuinely, having had less than stellar results with it in the past.)
<nckx>I find it very odd that fonts.conf works fine here but conf.d doesn't. The kind of odd that random environment variables like to explain.
<efraim>from the root of the guix repository you can run `sudo guix archive --authorize < etc/substitutes/` and `sudo guix archive --authorize < etc/substitutes/`
<pashencija[m]>efraim: I can get them for x86 packages...
<davidl>nckx: alright ^^ even though Im not sure I fully understand what u mean by that.
<davidl>(mean to imply* by that)
<blake2b>nckx: I was just scrolling through the earlier conversation, and saw something about "the system not knowing where something is", so I thought this is the obvious first remedy in case missing envars are the issue
<pashencija[m]>I have run that for all files in etc/substitutes/ Let's see
<blake2b>Cairn: if you're using Guix Home it would be "source /home/user/.guix-home/profile/etc/profile"
<nckx>There are duplicate keys under etc/substitutes/ and ‘guix archive’ doesn't deduplicate the ACL, so yours will now contain duplicate entries, which is harmless but now you know.
<nckx>Have fun sleeping.
<pashencija[m]>nckx: Yeah, thank you
<pashencija[m]>How to I refresh data from these? guix pull?
<nckx>There should be nothing to refresh.
<nckx>You can purge the substitute cache with something like ‘sudo rm -rf /var/guix/substitute/cache/* ~/.cache/guix/substitute/*’ but I do not believe that authorisation status is cached. Still, can't hurt.
<pashencija[m]>Well, it's the same now
<pashencija[m]>x86 packages are substituted
<pashencija[m]>arm ones are not
<pashencija[m]>I test on nano and its dependencies
<pashencija[m]>/etc/guix/acl has a lot of entries!
<nckx>Very strange, as I do get substitutes for ‘guix build --system=aarch64-linux nano’.
<nckx>Does an explicit --substitute-urls="" help? Ignore if this has been discussed before.
<nckx>guix build --system=aarch64-linux nano -d → /gnu/store/0phfpqyqszax6rbnan288343mdhxdzfd-nano-6.4.drv by the way.
<Cairn>blake2b: Sorry, just got back. As far as I can tell, fontconfig only needs to know the $XDG_CONFIG_HOME. And I just put my little test config in `~/.config/fontconfig/fonts.conf` which should be the right path
<shcv[m]>why does `guix shell --search-paths` still take ~4s even when it should be using a cached profile?
<Cairn>blake2b: I'm not using Guix Home btw. I'm not doing anything particularly Guixy right yet
<pkill9>has any progress been made on adding KDE desktop environment?
<pashencija[m]>Well, I have packaged some apps and libs in my repo, but there's long way of upstreaming them
<pashencija[m]>I will probably push some after featherpad is merged
<blake2b>Cairn: ah ok, well in case there is a missing environment variable you're unaware of, its worth a try. it certainly wouldn't hurt anything.