<nckx>ScaredySquirrel: Even if your CPU has multiple cores, you don't have enough RAM to run multiple large jobs or commands in parallel so keep it at 1 when compiling anything ‘big’ (or that has ‘big’ dependencies that can't be substituted).
<ng0>guix lacks something like doxygen to document itself internally better, but i found the code usually good enough if you study it long enough depending on what you are reading (understanding the store monad etc is probably not what everyone wants)
<Franciman>I can't seem to figure out what I am doing wrong
<nckx>Franciman: The code in ‘arguments’ is run in a different (build) environment. You need to define the remove- procedures there, for example by using ‘let’. However, in this case, I don't see the point of creating 2 named procedures to perform 5 (static) operations in total. Phases are already named procedures: just (add-after 'unpack 'remove-unused-imports (lambda _ (invoke …) (invoke …))) directly.
<g_bor[m]>I guess there was some time when this worked...
<nckx>Not sure about safety; if the package just can't find its own ‘test’ module because it's missing it's own search path in the build environment (just a guess), it might not be a serious thing. Or at least easy to fix.
<nckx>sneek: later tell raghavgururajan: Be sure to always leave the second line (the one between your ‘gnu: foo: Do this.’ summary and the ‘* gnu/packages/…:’ rest) blank. Emacs should warn you, nano will not.
<nckx>sneek: later tell raghavgururajan: str1ngs' point is important, since sometimes you might happen to start a line with something like ‘#:configure-flags’. That won't work. You'll have to reformat your text.
<sneek>raghavgururajan, str1ngs says: anything prefix with a # will be considered a comment and will not be included in the commit message.
<sneek>raghavgururajan, nckx says: Be sure to always leave the second line (the one between your ‘gnu: foo: Do this.’ summary and the ‘* gnu/packages/…:’ rest) blank. Emacs should warn you, nano will not.
<sneek>raghavgururajan, nckx says: str1ngs' point is important, since sometimes you might happen to start a line with something like ‘#:configure-flags’. That won't work. You'll have to reformat your text.
*raghavgururajan pushed their first patch (#38347). Yay!
<nckx>smithras: Tarballs, unless there's a reason not to 😉 (This can be the most popular ‘the release ‘‘‘‘‘‘tarball’’’’’’ is just a crappy github /archive/ link with no QA that changes in place’-reason).
<leoprikler>but wouldn't in that case a patch against the CVE be preferrable?
<smithras>nckx atw thanks for the clarifying info!
<nckx>leoprikler: Depends. If the release was an official tarball, plz. If it was a git commit to begin with? Eh, pushing just that one patch to the Guix repo feels a bit weird to me, but it's not wrong.
<raghavgururajan>Intresting thing is. After doing `guix package --install-from-file=gnome-contacts.scm` followed by `guix gc`. The gnome-contacts still runs.
<nckx>If glib:bin were referred to, it would be suspicious and probably unintentional.
<nckx>raghavgururajan: That's because you installed it, and your profile is a GC root. If you'd simply ‘guix build gnome-contacts’ and then ran it with /gnu/store/…/bin/gnome-contacts, then ran ‘guix gc’, it would probably be gone.
*nckx is waiting for gnome-contacts to build again because they had done just that 🙂
<nckx>raghavgururajan: Same for gettext, vala, pkg-config (another one of those should-always-be-native classics), gobject-introspection, and libxslt. gst-plugins-base is suspicious: does it need to be propagated? native doesn't make much sense to me.
<nckx>raghavgururajan: So ‘all the packages I mentioned under native-inputs are referenced by guix gc’ is quite false. How did you check? I did ‘guix gc --references `guix build gnome-contacts`’ and grepped it for each native-input (modulo false negatives caused by :outputs).
<nckx>raghavgururajan: gst-plugins-base *isn't* propagated, though. And it usually is, when it's needed. Also, the error message you get when you remove it is ‘cheese not found’ which smells like a missing .pc Requirement on cheese's end.
<nckx>Hence: ‘gst-plugins-base is suspicious: does it need to be propagated? native doesn't make much sense to me.’ 😛
<raghavgururajan>It ran fine on my end without needing to put it as propagated. Could you please try on your end?
<lispmacs>hi, I installed evolution email client (am using Gnome desktop) but when I try to create an email account I get error "The name org.gnome.evolution.dataserver.Sources5 was not provided by any .service files"
<nckx>raghavgururajan: Your V2 patch first removes the V1 patch, then adds the V2 package. That's not really how it's done. Also, I see you're still using NAME in the URI. And the ‘dockbook’ typo is still there. And docbook-* should not be propagated as I noted above.
<nckx>raghavgururajan: This is not about running fine.
<raghavgururajan>lispmacs You need to separately install 'evolution-data-server' either in user or system profile.
<smithras>lispmacs: I've gotten the same error using gnome to-do
<nckx>Please read everything I wrote above (I know I write a lot; sorry). Your V2 patch has quite a few inputs that should be native inputs, which is why I wonder if you made a mistake running ‘guix gc --references’, and does not address all points from my e-mail.
<smithras>raghavgururajan: shouldn't it be a propagated input then?
<nckx>raghavgururajan: Then maybe the patch you sent isn't the patch you meant to send.
<raghavgururajan>nckx Oh what I did was ` guix gc --references /gnu/store/*gome-contacts*`
<nckx>raghavgururajan: That command (with *) lists the references of .drv files, which is all inputs off any kind. You should only run it on one specific /gnu/store/ item, returned by ‘guix build gnome-contacts’.
<nckx>raghavgururajan: That's why ever input is in that list: .drv files are build recipes, so they include native inputs that won't be referred to by the final output.
<raghavgururajan>nckx Did you mean to renove the whole (name ..) block? Because edited uri is like this
<nckx>raghavgururajan: Sorry for being grumpy above. These were the 2 most trivial points of my mail, but seeing them unadressed gives me the impression that I'm not being listened to and I am putting quite a bit of work into grepping inputs & double checking your answers &c.
<nckx>raghavgururajan: You're right that adding ‘gst-plugins-base’ to native-inputs makes the gnome-contacts build succeed, *and* that ‘gst-plugins-base’ is not a run-time reference of gnome-contacts. I'm not disputing that: I'm saying that it's fishy and there might be a ‘more correct’ solution.
<raghavgururajan>nckx I still facing trouble with guix lint and guix build. I am use to doing --install-from-file=package.scm. But how to do I execute lint and build for a file? ./pre.. did not work.
<nckx>raghavgururajan: Don't worry about gst-plugins for now, I'll take a look.
<raghavgururajan>For example, I have the package definitions for the package gnome-contacts as gnome-contacts.scm. But being in that directory and executing 'guix build gnome-contacts.scm' does not work.
<raghavgururajan>I think I am missing something about how guix build works or takes input.
<nckx>raghavgururajan: I've addressed this before, but it probably got lost in the mess 🙂 You should *not* run guix lint on gnome-contacts.scm, then copy & paste gnome-contacts into gnome.scm and then send a patch.
<nckx>You *should* move gnome-contacts to gnome.scm, run ‘./pre-inst-env guix lint gnome-contacts’ (it will find it), then send a patch.
<nckx>This is why the V1 patch you sent was broken: it referred to (license gpl2), which worked in your gnome-contacts.scm but not in gnome.scm. But you didn't run ‘guix lint’ on gnome.scm.
<raghavgururajan>nckx You meant the gnome.scm inside the cloned git right? I did move contents of gnome-contacts.scm to gnome.scm and tried ‘./pre-inst-env guix lint gnome-contacts’ by being in the dirctory that contains the gnome.scm. But still did not work.
<nckx>raghavgururajan: You need to run it in the top level directory.
<raghavgururajan>nckx I understand the importance of that, thats why I keep reclarifying things.
<nckx>raghavgururajan: For me, that's ~/guix, and my packages are in ~/guix/gnu/packages.
<nckx>raghavgururajan: Clarifying is good, thanks!
<raghavgururajan>nckx I see. For me, ~/git/guix/guix/gnu/packages/gnome.scm ; so I have to run the command inside ~/git/guix/guix correct ??
<eloyesp>oriansj: substitutes? I didn't touch any substitutes option (I've used the graphical install)
<nckx>eloyesp: I think there are a small handful of people who do (used to anyway), but I don't know if they're on IRC. Posting in Spanish to firstname.lastname@example.org is completely supported, but you'll be limiting your audience. I recommend including an English translation for that reason.
<nckx>The graphical install should enable substitutes by default.
<oriansj>eloyesp: substitutes are what guix calls binary packages; otherwise you will be downloading and building all programs
<oriansj>nckx: but will fall back if the substitute is not available
<nckx>Sure, sure. But you said ‘don't enable’ so that's how I read it.
<nckx>eloyesp: It's completely normal, as is lots of downloads, so it sounds like your Guix is configured correctly and your VM is just slow.
<eloyesp>I don't know that verb, what does that means?
<nckx>Grafting (injer…) is 100% disc & memory reading & writing, maybe that's slow on your VM.
<nckx>eloyesp: It's quite technical and specific to Guix's functional model. Read it as ‘applying security updates by reading and writing to disc a lot’ 🙂
<nckx>Actually, I guess the string scanning code could be slow on very slow CPUs but I've never seen that be the bottleneck.
<eloyesp>ok, it is a virtual machine on an old notebook, so it makes sense that could be slow if try to use a lot of CPU..
<nckx>eloyesp: And a rotating HDD, which I still suspect is the bottleneck.
<nckx>eloyesp: The good news is that grafting is always the last step, so chances are high that you're almost finished.
<eloyesp>nckx: Ok, then I think it was an interesting test, my main computer doesn't have a SSD eighter, so it might be a painful point (I were testing before I do the switch from trisquel on my home PC)