<OriansJ`>bavier[m]1: that command results in https://paste.debian.net/1168333/ using guix's guile on debian; but when I tweak it to include -L . when inside of the guix source directory; it unfortunately returns the same error
<helaoban>I'd like to contribute a package definition for a haskell package. This would include adding ~10 haskell dependencies that aren't currently in the source tree, as well as bumping the version of 1 existing package. When sending these changes to the mailing list, what is the preference? One new package definition per commit (and a separate commit for the upgrade) sent as a patch-series, or lumped
<OriansJ`>bavier[m]1: I got the answer from guix repl; thank you for the guile code ^_^ (I usually try to get it from the source and didn't consider that route for some reason)
<bavier[m]1>OriansJ`: glad you got it :) I'm still finding more things the repl can help me with.
<OriansJ`>and a new bug report for guix was found in the process ^_^ as guix's README says to run configure (which doesn't exist on a fresh checkout [use git clean -xdf to verify that yourself]) when it actually appears to be autoconf and automake (which don't work either)
<wleslie>what environment should I be using for direct checkout hacking again? configure is failing again with "Guile-JSON is missing; please install it."
<wleslie>I currently have: guix environment --pure guix --ad-hoc readline guile guile-json coreutils findutils which
<wleslie>have tried without specifying guile and guile-json too
<OriansJ`>well the README says: guix environment guix
***OriansJ` is now known as OriansJ
<wleslie>no luck. I should have saved the working profile I had before I started.
<vagrantc>OriansJ: looks like it's missing mention of ./bootstrap
<vagrantc>OriansJ: probably need to sync corresponding part from the guix manual ...
<apteryx>so, I git cloned my local repo into /tmp to make sure I had something perfectly clean, then 'guix environment --pure guix', './bootstrap', './configure --localstatedir=/var', 'make -j8'
<vagrantc>apteryx: sounds like it ... but it isn't mentioned in the README
<ryanprior>I messed around with running Guix entirely in Docker containers today - one for the daemon, another for the client. Works pretty well up until you want to actually build something, then it says it refuses to run guix-download as UID 0
<apteryx>vagrantc, OriansJ I just pushed commit 503d2bfde0 to clear that up from the README
<ryanprior>Might mess with it more later. The reason is, I'm interested in running my own CI for a few packages in GitHub Actions, and I think having a fully Dockerized workflow would make that easier.
<apteryx>there's also no need to run 'make install'
<apteryx>you should rather run './pre-inst-env guix pull' to guix pull using the resulting (freshly built) guix.
<wleslie>apteryx: no, I started the environment, ran ./bootstrap, and then ./configure --localstate-dir=/var
<bdju>I don't know guile well enough to do those modifications but I like the idea of sticking it in the manifest and avoiding channels. I'll keep it in mind. maybe add some lines commented out in the manifest to remind me
<zzappie>I am getting bunch of warnigs I never seen before during 'guix system reconfigure' like 'cannot determine provenance for current system', 'cannot determine provenance of GNU Guix' and then fails with guix package hash missmatch
<divoplade>demotri, civodul : OK now the daemon uses 1 core by default, but I can override it when I need it. Neat!
<xelxebar>vits-test: Haven't figured it out yet. I have several other OS isos on a usb that are working. With guix, I have grub sucessfully loading the linuz and initrd from the iso, however, booting then fails to find the root partition.
<xelxebar>vits-test: The problem is that the iso device *contains* the root partition... so I need to mount the usb and put the iso at a loop device during the initrd stage.
<maav>civodul: thank you, that's mostly what I added as a comment :)
<xelxebar>Also having trouble simply booting the install image normally on my thinkpad. Kernel just stops somewhere in the middle of booting :/
<jlicht>If I swap out an existing build system with a new one, will the commit message be okay with "Swapped out implementation...", or is the rest of my weekend spent writing out the Changelog 'diff' of two unrelated pieces of code that happend to share the same name?
<civodul>jlicht: you mean you changed the build system of a package?
<jlicht>civodul: No, I changed the node-build-system entirely.
<jlicht>secondary question, do you think a 'binary' importer similar to what janneke and samplet once made could be in guix-proper? The package definitions generated from it still are a good starting point for making 'proper' packages as well, although for most packages they produce something that is unacceptable as-is for inclusino in guix.
<jlicht>so are importers supposed to do 'most' of the work in making a guix package, or simply do some of the repetitive work and offer a running start?
<mfg>what do i do if a package desperately wants sources of another packjage in it's build tree and there already is a patch that unbundles this source because it's a seperate package? Is there a place in the store with the unpacked sources?
<mfg>(talking about google benchmark specifically which wants googletest sources but it's patched out)
<mfg>this package seems to not build since june 2019 :/
<BlackMug>i want to ask does guix devs care about who is contributing like his political views , race , ...etc or you dont care about it and only focus on the technical things?
<mfg>BlackMug: this is a very broad and really general question, so i don't know if it's bait or what you really want to know :| (also: i'm not a dev)
<BlackMug>i want to know the answer according to what im asking
<BlackMug>no imagine a contributor is a pro nazi and other one is pro antifa are they both welcomed despite their backgrounds (since the project is about code and technical things) or someone going to be accepted and the other not or both rejected...etc
<jlicht>BlackMug: you seem to be in luck, the guix CoC (or any CoC I've read, for that matter) doesn't mandate that you change the way you feel or think! Just that you behave like a civilized human being in project spaces :-)
<mfg>vits-test: nope that package explicitly searches for the sources. As i understand the packages they're (name . store-path) pairs, but the store path is what gets generated by the derivation (i think), and the sources are discarded after that, no?
<vits-test>mfg: Hm.. So there should be a package like those for the linux-libre. deblobbing takes the not-built sources as input.
<mfg>either that or it's possible to generate build the derivation of googletest during the build of benchmark and pass the path --- which sshould be in /tmp/guix-build-* or something
<mbakke>mfg: I think there are some packages that have (package-source googletest) in their inputs.
<mfg>That sound interesting mbakke will check it out
<mfg>package-source really helped, cmake now finds everything, even though i had to do add a phase for it (like other packages), because cmake seems to ignore GOOGLETEST_PATH it tells me to set, when it doen't find the source. LOL
<mfg>the build itself still doesn't work though. There are som eundefined references
<mfg>BlackMug: watched that video, now i /really/ understand why you were asking.
<mfg>i disabled the tests of benchmark, because i'm not able to see where those missing references are coming from...
<mfg>ah, there is an updated version available! Let's see if it makes any difference :
<mfg>maav: i wouldn't consider it spam, it's an opinion. With the information that came through that video it's plausible to me. If i really wanted to know if i think the same way i would have to read a lot of references i guess --- I really don't want to...
<maav>mfg: entering a channel, asking directly an upfront delicate questions like that, and posting a video before leaving seems a troll behaviour to me
<maav>I'm open to question that if it's needed, but that's not the way to get a fair debate
<mfg>Ah, i have (setq erc-hide-list '("JOIN" "PART" "QUIT")) otherwise to much annoying emssages :D
<jlicht>I feel like I lost some IQ-points having watched that video.
<maav>jlicht: don't hit your head too hard, you only have one ;)
<jlicht>maav: after two concussions, I don't have a lot of wiggle room left in that department either ;)
<civodul>anyone proposing a Guix/Guile session for LibrePlanet? :-)
<Zambonifofex>I’m not trying to be gratuitously controversial, but I just wanted to be able to say that I feel like maybe that user shared that video and asked those questions because they wanted to know whether GNU developers shared mentalities with the GNOME developers, not because they were trying to troll or bait or anything. Of course, I don’t know for sure, but I generally try to assume good intent on others at first.
<ani_>the description should be 80 chars because we want it to be visible when user says guix search <package name> then he should be able to read the description in 80 char terminal and its usually practice of writing programming since early days of computer? isn't it?
<wleslie>that's the synopsis, right, not the description?
<ani_>description also needs to be 80 characters per line I guess.
<apteryx>mfg: I pushed the revert, we're back at u-boot/u-boot-tools 2020.07, which builds fine.
<wleslie>it's nice not to have randomly long ugly lines, I guess
<apteryx>sneek later tell vagrantc I reverted the update to u-boot, which caused the u-boot-tools to fail to build. The later is indirectly pulled-in by the childhurd service (through genimage).
<ani_>am I suppose to build first and then use linter on on it?
<wleslie>no, you might need to add part of the discovery process
<mfg>how does cmake determine which google test it should use? the library i'm trying to build tries to build it itself if GTEST_FOUND is false, but i don't get the documentation as to what variable needs to be adjusted. :/
<wleslie>for example, if you're inheriting from an existing package, that might be a private package
<wleslie>or maybe you need to export your bindings, or maybe you need to add your .scm file to the makefile
<wleslie>have you added it to gnu/local.mk for example
<zimoun>ani_ wleslie: hum? I am not sure the indentation is correct. “ of base32 should be under b and not a, idem about description, backquote ` of native-inputs should be aligned with n, etc. Well, is it the result of ‘etc/indent-code.el’?
<apteryx>civodul: Should we adapt the README to say './pre-inst-env guix pull --url=$PWD' ?
<apteryx>I'm not too sure of the usefulness of 'installing guix from a guix checkout', rather than just 'building guix from a guix checkout', especially since that part is kind of dependent on having a working Guix in the first place.
<apteryx>cbaines: not a direct reproducer, but here's one oddity that I thought was related to local-file: From Emacs, M-x run-guile, then make sure your Guix checkout is in your %load-path, then ',use (gnu packages linux)'
<apteryx>you should see an error message about "~a: patch not found\n"
<apteryx>this happens the first time... if you re-execute the same command it'll pretend to have worked, but no variables are defined.
<apteryx>I can't reproduce this at plain Guile REPL
<raghavgururajan>rekado_: I see. I use Guix System with full-disk encryption on SSD in X200T with libreboot.
<rekado_>cbaines, apteryx: yes, replacement laptop (broken mainboard with sudden freezes), repairs of the replacement (kill switches not wired up), new Coreboot firmware (to stop extreme vertical flicker, but led to inability to boot from SSD), sent it in a third time after months of emailing back and forth, but now they say fixing it is not a priority
<rekado_>I got it back without the ability to boot
<raghavgururajan>libreboot is close to coreboot (which you are using), so may be I can help you.
<zimoun>speaking about Geiser, how can I “discover“ function? With IPython, I just type funcName? or help(funName) the it shows me docstring and more importantly the signature (arguments). With Guile, I have to do ,a and ,d. What is the trick?
<zimoun>civodul: there is no fallback of channel to SWH, right? Even if it is Git repo?
<civodul>zimoun: no, channels are pulled from the given URL
<civodul>plus there's the "primary URL" mechanism that warns users who try to download from a mirror
<zimoun>in the case of guix-science or guix-past or guix-inria-hpc which are on different forges, they could disappear or shutdwown. So if a paper is refering to this channel, it will be hard to reproduce, even if all the packages are in SWH.
<civodul>right, but that's a different use case: if you're looking for a specific commit, you can take it from anywhere you want
<zimoun>So the channel could be saved in SWH (by any mean, say externally and the author’s channel does it). Then if ‘guix time-machine -C channels.scm’ fails, it tries to fallback to SWH, since the channel is Git repo.
<civodul>right, the user who'd have to explicitly pass the URL of a mirror like SWH