***terpri_ is now known as terpri
<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 ***daniel is now known as Guest54518
<lfam>helaoban: We prefer one commit per change. So, that would be about 12 commits <lfam>Let us know if you need any assistance with the Git stuff <helaoban>lfam: Got it. I'll see how far I get and come back for help if I need it. <helaoban>Also, on running guix lint over my package definitions, I'm warned that I need two spaces after periods in the description. Is this just a style decision? <bavier[m]1>OriansJ`: hmm, does it work if you use `pre-inst-env` from the source tree? <lfam>helaoban: It might be a texinfo thing (our documentation is written in texinfo and the descriptions are processed as texinfo), but I'm not really sure <lfam>There are a few nit-picky things like that but `guix lint` will catch them all <terpri>indeed, it's a style decision as you guessed, from 'check-description-style' in '(guix lint)' <helaoban>that is a *highly* opiniated decision :) <alphazino[m]>noob here, is there a preferred way to handle user i3-wm config on Guix System? <alphazino[m]>Should I just modify the config files directly in ~/.config/i3 or is there a way to do it from a manifest file in scheme? <alphazino[m]>If I want declarative user config, should I just make some sort of wrapper? <OriansJ`>and doing guix environment guix didn't help either <alphazino[m]> * noob here, is there a preferred way to handle user i3-wm config on Guix System? <alphazino[m]>Should I just directly modify the config files directly in ~/.config/i3 or is there a way to do it from a manifest file in scheme? <alphazino[m]>If I want declarative user config, should I just make some sort of wrapper? <alphazino[m]> * noob here, is there a preferred way to handle user i3-wm config on Guix System? <alphazino[m]>Should I just modify the config files directly in ~/.config/i3 or is there a way to do it from a manifest file in scheme? <alphazino[m]>If I want declarative user config, should I just make some sort of wrapper? <OriansJ`>alphazino[m]: prefeered way for noobs would be just copy and paste your i3 config into ~/.config <alphazino[m]>would it be reasonable to configure from scheme in the future? <OriansJ`>alphazino[m]: if you wish to do the extra work to enable guix to do the setup, it is possible to leverage it as a package definition. <OriansJ`>So following the steps in the README doesn't actually work <apteryx>OriansJ`: seems like it's picking stuff (/usr/share/automake-1.16) from your Debian: try with 'guix environment --pure guix' <OriansJ`>full process to replicate from zero can be provided if desired <apteryx>what guix are you on? (guix describe) <OriansJ`>commit: e97be4a3c750fceec1d4d691484de36c60f7c42 <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' <apteryx>Were you missing the ./bootstrap part? <apteryx>it's mentionned in "info '(guix) Buliding from Git'" <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 <wleslie>every time I get errors about guile-json <wleslie>I updated git yesterday, and guix pull today <wleslie>the other thing I did yesterday was remove old automake from my environment just to make sure it wasn't messing anything up <apteryx>note that it's --localstatedir=/var (without hyphen) <apteryx>that'd just fail right away (just tried) ***iyzsong-- is now known as iyzsong-w
<apteryx>also, you can test that guile-json is present and in the Guile load path by testing with: guile -c '(use-modules (json))' <apteryx>you should have a /gnu/store...-profile/share/guile/site/3.0 entry in your GUILE_LOAD_PATH that contains a json.scm file <wleslie>/gnu/store/fxryl7gdzx8rwsx1dagjdibj23higwsf-profile/share/guile/site/3.0/json.scm <wleslie>my GUILE_LOAD_PATH only includes site/2.2s <apteryx>not sure why 'guix environment --pure guix' leaves you with this <apteryx>it should be on guile (GNU Guile) 3.0.4 <apteryx>unlessy ou were using a very old Guix to start with <wleslie>guix describe: error: failed to determine origin <wleslie>hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version <wleslie>how do I update it, if not with guix pull && hash guix ? <wleslie>guix pull works fine, I did just yesterday <apteryx>ryanprior: you could also pester their CI provider for native Guix support ;-) <wleslie>guix is so nice, I put it in my path twice <apteryx>yeah, you have guix installed in your user profile <apteryx>also your PATH seems to be missing an entry to $HOME/.config/guix/current/bin, which is where the latest pulled guix lives <apteryx>it should appear pretty near the beginning of your PATH to prevent issues (such as picking an old Guix from your user profile, if it was installed there) <wleslie>so it'd be `guix remove guix` to remove it from my profile, and then just add that path to my search path? <apteryx>you can try to run it at first to make sure it works well <apteryx>$HOME/.config/guix/current/bin/guix describe *nalaginrut thinks that it's better to have yarn ... <wleslie>O_O successfully built /gnu/store/8q4xrms6ax1mq7irw4hyn1v22nla3gpp-capos-capros-gcc-10.2.0.drv <wleslie>still missing a few pieces required to build capros/coyotos but this feels like a big milestone <xelxebar>Where is the --root=<uuid> kernel cmdline coming from in the official iso? <nalaginrut>but my current webapp is using yarn, and I'm going to stick with it <xelxebar>I am trying to configure grub to boot directly from the iso instead of having to nuke an entire usb stick just for guix. <nalaginrut>anyway, it's just a feature request, it doesn't affect me currrently <xelxebar>The iso boots just fine normally but not when loop-mounting the iso in grub... <xelxebar>The kernel fails to find the root filesystem. <xelxebar>But why? It's the same kernel loading the same initrd <xelxebar>Oh, wait... The iso fs itself needs to be seen? <bdju>looks like our alacritty package is a few major versions behind <vits-test>xelxebar: Was U able to boot entering the options directly in the GRUB prompt? <bdju>I suspect a bug I'm getting with pasting text in alacritty is fixed in 0.5.0 after reading the changelog, so if anyone took the time to update the package, I would really appreciate it! <bdju>sometimes when I paste, there's a big delay and then it pastes many times from one press. pretty annoying <bdju>sounds like this bug may be fixed on master but not 0.5.0 after all <bdju>one of these days I'll have to figure out how to get my own channel going for running newer versions of some packages maybe ***apteryx_ is now known as apteryx
<zzappie>bdju: It is preety easy. I't can even be local repository in your home dir <bdju>I had one once on another machine but only for one package and I later got rid of it. just can't remember how it works anymore <vits-test>bdju: Aren't it a overhead? Why not just inline the package defs. in manifest? <vits-test>then guix package -m. No load-paths, no channel stuff. <bdju>vits-test: I'm not sure how I would do that <bdju>I do use a manifest but it's just a plain list of packages currently <zzappie>vits-test: did not think of this option :) <bdju>like paste the contents of the package in the file? but change it a little? <vits-test>just the last thing should evaluate to manifest <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>vits-test: Love the hacking spelling :) <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 <civodul>the 1st warning means there's no /run/current-system/provenance file on your system (perhaps because you haven't reconfigured in a while; it was introduced ~8 months ago) <civodul>the 2nd one means 'guix' doesn't come from 'guix pull' <zzappie>hm this is strange because /run/current-sytesm/provenance is in place. And I already did few guix pulls already on this machine <zzappie>guix describe: hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version string is 1.1.0-23.2f458ad. <zzappie>which guix: /run/current-system/profile/bin/guix <wleslie>oh. maybe that's different on guix system? apparently you shouldn't have guix in your profile <wleslie>for me now `which guix` => /home/wleslie/.config/guix/current/bin/guix <zzappie>maybe I've spoiled something cause it is a digital oceand debian droplet coverted to guix with famous script <civodul>normally you should be using ~/.config/guix/current/bin/guix, unless you've never run "guix pull" <zzappie>wleslie: /root/.guix-profile/bin:/root/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin:/bin yada yada <wleslie>is /run/current-system a symlink? not sure what that is supposed to be <wleslie>not sure if there's any value to that <wleslie>anyway apteryx told me earlier that adding "$HOME/.config/guix/current/bin" to the front of your path is best <wleslie>that way guix is always the latest pulled version <divoplade>Hello! Is there a way to have unattended upgrades using only one core when running guix system? <zzappie>civodul: you said hash missmatch is a bug. Is it worth submitting? <divoplade>I don't really care how much time an unattended upgrade takes, it just needs to not overload the system <civodul>zzappie: i think it's a bug that's been fixed a few weeks ago :-) <demotri>divoplade: You can use "--cores=1" for the guix-service. <civodul>so normally you just pull and you're done with it <demotri>divoplade: Though I don't know how to do it "fully unattended". <divoplade>demotri, is it possible to override the value when I need to run guix build or other commands from user-space? <civodul>divoplade: good point, the unattended-upgrade service doesn't allow you to specify --cores=1 or similar <divoplade>civodul, the goal would be the opposite: by default, run with 1 core, and when I can monitor it (and kill it in case it starts filling in the memory) use more cores. <zzappie>wleslie and civodul: Thanks! reconfigure worked with modified PATH :) <civodul>divoplade: oh, then what demotri suggests is the right thing for you <divoplade>civodul, yes, I'm reconfiguring right now, but there's a gnunet input change so I'll know if it works in some time :) <vits-test>zzappie: the spelling came out when i'd found out the System's `guile` and the `guile` that used by `guix` are byte-incompatible, so anything in geiser need a lot of compiling. <zzappie>vits-test: oh and you would't get whats going on just plain silence. Like geiser is saying "i'm ok" <mothacehe>just tested the new Git progress bar, nice addition civodul! <mfg>vits-test: ah that's why geiser completely stalls when I'm trying to interactively work with packages ... Is there a solution or workaround for it? <civodul>i wonder how many people gave up because they thought "guix pull" wasn't doing anything :-) <wleslie>apologies for site requiring javascript <wleslie>refcfar: there are a few packages that depend on opengl; notably blender. I'd try it myself and tell you, but I'm running on a foreign host. <wleslie>civodul: I'm so excited I nearly have all the tools working! <vits-test>mfg: yes, install guile-3.0-latest, then start geiser from that environment. <refcfar><wleslie "sudoreboot: there are a few pack"> I'm on NixOS and there's no straight forward to install and use Guix here, so I cannot test whether it's an issue or not. <civodul>i was under the impression Coyotos had been abandoned before going anywhere <wleslie>civodul: well yes, it's a long story, and I feel a bit daft for going off and doing other things rather than hammering on coyotos and hurd, but I was in a different place back then <wleslie>civodul: but now we have guix and it makes it all so much easier (: <civodul>i think it can definitely help OS development <wleslie>Jan and Mathieu's work has been a bit of an inspiration <civodul>mbakke: interesting, didn't know about it! <mbakke>indeed, weird choice in this day and age ;-) <mbakke>yes, they are rolling it out at work currently ... having worked with both Gentoo, easybuild, and Nixpkgs, I know what I would choose (neither!) :P <mbakke>the combination is just horrifying <civodul>so did you offer your colleagues to add bits of Guix as extra topping? <civodul>and pip, but maybe that one is implicit? <mfg>vits-test: thank you :) <mbakke>civodul: I'm fairly disconnected from the HPC people still, but I'll get there ;-) <mbakke>they didn't bite when I posted the Nature reproducibility article in a discussion about building an ancient Fortran.. :P <maav>ça va, civodul? i was busy translating... and i found something that may be an error <maav>but you conversation was more interesting, what about Coyotos? Is it back? <maav>the possible "error", the values returned by package-with-c-toolchain are different depending on the name of the input you provide, but it's nowhere specified (at least in current version) <maav>i'm adding a comment in the example code, but maybe it's worth to specify it in the manual too <civodul>maav: package-with-c-toolchain returns just one value no <civodul>ah you mean the labels in the input list have an impact, right? <maav>(package->bag (package-with-c...`(("cadena" ,toolchain)))) doesn't return the same as (package->bag (package-with-c... `(("toolchain" ,toolchain)))) :) <maav>the first adds an input "cadena" and removes the other, the second returns gcc, glibc, and so on, on the inputs <maav>but i cannot find where does that happen :( <maav>(I'm guix repl-ing the examples too :)) <civodul>maav: ah yes, in general labels are part of the API <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>and now having working llhttp and node 14, incidentally :D <civodul>if the file doesn't share anything with what it previously contain, you can just write "foo.scm: Rewrite." in the commit log <civodul>anyway it sounds like a big achievement <civodul>now i understand the need for a wip branch :-) <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? <janneke>jlicht: the node-build-system is an interesting case, especially the idea of a 'binary' importer <janneke>it can be a great help for creating a free package; but i guess it cloud also be seen as a big help (encouragement?) to create and use non-free packages <jlicht>exactly my point: in that sense, it would be less of an importer and more of a... meta-data generator? <jlicht>I could even adapt it so it always outputs `(source #f)' ;-) <jlicht>It's mostly the inputs and textual stuff (e.g. home-page, synopsis) that is annoying to figure out for ~50 packages <xelxebar>Oh. It's my graphics card. Had to put nomodeset in the kernel params <xelxebar>At least I can use the iso relatively normally now <mfg>ffmpeg is in gnu/packages/video.scm, maybe there <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 <mfg>okay, for me it's bait then. <BlackMug>its not a bait, i want to know how the devs group think before jumping into helping them very simple <BlackMug>i dont like crazy political,religious judgments which are unrelated to technology <mfg>ah, yes. No i understand you :) As long as you are not against free software i haven't read anything in that direction :D <jlicht>Developing (free) software is by definition a social endeavor, so you seem to be entangled in 'politics' whether you want to or not ;-) <jlicht>BlackMug: There is a CoC for the guix-project and related (online) spaces that folks are expected to know and follow (See 'CODE-OF-CONDUCT' in the git repo) <jlicht>does that (practically) answer your question, or did I misunderstand it? <BlackMug>im pro free software, But doesnt mean i agree on the politics or religion or ..etc of the devs or so <mfg>you mean in what they are personally into? <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 :-) *vits-test wow we've a CoC. <mfg>most of the time i skip CoCs because imho, it's 99% common sense... 🤔 <BlackMug>mfg not really, there are crazy projects and devs has crazy mindset like sjw and others <mfg>BlackMug: i see what you mean, i have never encountered such persons (luckily, i guess) <BlackMug>true you are, you want bad example check out gnome devs <mfg>at least their CoC doesn't read suspicious... <vits-test>mfg: are U sure there isn't any env. variable like WHERE_TO_GET_SOURCES_OF_ANOTHER_PACKAGE? <mfg>vits-test i'm certainly unsure about this! benchmark has a variable which i can set to the sources of googletest, but i can't find those, i thought they have to be somewhere in the store <vits-test>Then chances are it's just some configure flag, or something like (setenv VAR package). <mfg>so the thing is: where are the sources of googletest actually? <mfg>i successfully built googletest, but the resulting store item of course only contains the resulting binaries <vits-test>mfg: IDK, but the pairs from package's inputs should bear the filenames/paths with them. Aren't they.. <mfg>i'm testing that now <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 : <maav>mfg: i discovered today what erc-fools variable was for... <ss2``>how does offloading work? I'm trying it with two machines, but the second machine (that is waiting for input), won't be used. <ss2``>which results that the client is waiting, until the other build machine is finished. <mfg>maav: haven't heard about it before, but i can guess what you mean ;-) -- TBH i don't care too much <maav>mfg: you can "highlight" messages that contain some text to the background colour, it helps your stomach sometimes, mainly for future references of the same thing <maav>you know, like that spam-video <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? :-) <apteryx>Is anyone else having issues building u-boot-tools? I think it's required by the childhurd service that's in my operating system definition. <apteryx>seems it broke due to a change to openssl <apteryx>../include/image.h:1427:12: fatal error: openssl/evp.h: No such file or directory <ani_>is git rebase -i is for commit messages only or it can be used for changing the content in that commit? <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. <Zambonifofex>Not that I think the GNOME developers really have any kind of ill intent and “should be cancelled” or anything. <Zambonifofex>I’d have to investigate further to form an opinion regarding that. ***jetomit_ is now known as jetomit
<mfg>apteryx: i have the same issue <apteryx>I think the update of u-boot broke u-boot-tools (the later inherits from the former, so it's easy to miss). *apteryx tests the revert "fix" <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_> ./pre-inst-env guix lint r-deconv <ani_>when I type this command I get error saying <ani_>r-deconv unknown package. <wleslie>can you share your package declaration? <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 <wleslie>nice, is this in a package or just bare? <ani_>I am including it in file <ani_>where usually cran are saved <mfg>apteryx: interesting, so how do influence it? is it possible to just -D all the variables that otherwise get set by this module? <wleslie>hmm, looks like everything you need is in here <apteryx>if their CMakeLists.txt makes use of FindGTest, it should "just work". <apteryx>(provided you added googletest as a native input). <mfg>They don't ... they enable_testing() and at some point if(NOT GTEST_FOUND) <ani_>wleslie: do you mean that the module indentation is correct? <wleslie>fields, everything looks good to me here <wleslie>I take it you've already run `./bootstrap` and configure? <wleslie>honestly I find `make` gives better errors than lint, at least if you have real errors <maav>one question: between a git commit tagged as a version and a release tarball not storaged in Software Heritage, which one should we choose? <apteryx>mfg: you could open a bug for it, and patch it in Guix <apteryx>well, submit a patch upstream and apply it to Guix in the meantime ;-) <mfg>i'm looking into inkscape <apteryx>seems they use "find_package(GTest)" <mfg>btw: icecat doesn't load gitlab.com properly, but every other gitlab instance i tried with it works just fine. What's wrong here? <mfg>apteryx: i also always don't know which characters in substitute* need to be escaped? (and how often?) <mfg>someone pointed me to documentation a few weeks ago, but it didn't help :| <apteryx>you need to know which are the special characters of the extended regexp "standard" (ERE), which is what is used by the libc/Guile. <mfg>okay and how often do they need to be escaped? sometimes it needs \\ and i don't get why <apteryx>yeah, it can be confusing, you have to escape at the Guile level (\\ will give you one backslash in the resulting string) <mfg>ah, that's what i was missing, i guess <apteryx>so you don't have to escape the ? + {} and | to make them special (this is what extended regexp has on top of basic regexp). <apteryx>alse parentheses are special (see info '(sed) ERE syntax') <mfg>yes, that means ( -> \\( ? <apteryx>so if you want a literal parens you'll need to enter \\( (the first escape is for Guile, the second for the ERE engine). <mfg>how does guix handle \n in strings? does that also need multiple backslashes? <mfg>or more specifically guile, :D <mfg>it seems \n is enough <apteryx>\n is a understood by Guile as a newline character <apteryx>so again if you want a literal \n you'll need to escape it. <divoplade>I mean you can totally break a line in a literal string, but you don't need to put a '\' at the end of the line. <mfg>thx for your explanation :-) <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’? <ani_>zimoun: Just looking at it. <vits-test>sneek: later tell raghavgururajan my ip is still 95.181.110.196, and i'm real guix-vits. <abcdw>Is it possible to pass amount of memory for qemu to use, when I use guix system disk-image? <vits-test>"Build a virtual machine ..., and return a script to run that virtual machine (VM)." <vits-test>should be like `$(guix system vm) -m 1024 `, as per 9.14 of manual <abcdw>vits-test: Nope, I need to build an iso. guix system disk-image uses qemu to build an iso, but it passes -m 512 to the qemu and building iso take a lot of time. <mfg>why do scripts that runduring build have no permission to write into /dev/stderr? <mfg>shouldn't this be possible? <mfg>or is the /dev tree not available inside that environment? <vits-test>mfg: add to build something like (invoke "ls /dev"). U'll get a doctor degree in printf debugging one day :) <mfg>vits-test: Bah -- i hate printf debugging :'D but i have no chance i guess <mfg>but i see the directory exists and it's a symlink to /proc/self/fd/2 this is owned by nixbld, is it possible that this shouldn't be nixbld, but guixbuild? <lfam>sneek: later ask jsoo: Can you take a look at patch #44119 (linux-libre 5.9 update) and decide what to do with linux-libre-with-bpf? Should it use 5.9? Does it need to be versioned? <jsoo>lfam: I suppose it could be versioned. Also we discussed making the standard linux-libre have bpf <sneek>jsoo, lfam says: Can you take a look at patch #44119 (linux-libre 5.9 update) and decide what to do with linux-libre-with-bpf? Should it use 5.9? Does it need to be versioned? <lfam>What I meant by "versioned" was, should it use e.g. 'linux-libre-5.8-version', or can it use 'linux-libre-version'? <lfam>We could also make the standard linux-libre support bpf, as you said <lfam>I'm looking for some guidance :) <jsoo>I think it depends on the configuration changes require <jsoo>When I bumped linux-libre to 5.8 it wasn't as simple as changing the kernel iirc <jsoo>That said, it wasn't a lot of work either <lfam>The 5.8 kernel is going to stop being supported upstream, probably in a few days, so we need to upgrade anything that depends on it <lfam>I can try building the bpf kernel based on 5.9 <jsoo>Ah actually, I just looked at the patch to upgrade the bpf kernel and it was as simple as changing the kernel and source <lfam>But, I don't have a test case for it, so it's better if you can do it :) <lfam>I can test the build, but can you test that it actually works? I'll send an updated patch to the #44119 ticket now <jsoo>I haven't really used it too much but there are some example programs in the bpftrace package <civodul>apteryx: re README, "./pre-inst-env guix pull" should have the same effect as just "guix pull" <jsoo>I won't have a chance to for another hour or so, if that's ok <civodul>that is, it takes the latest upstream commit <mfg>i have had this problem before: adding ice-9 ftw to the use-module list of a module but guile says scandir unbound variable. Is it not enough to include it at the module definition? <lfam>jsoo: I'll also update the 'kernel-updates' branch on Savannah, so we should get some help from the build farm <mbakke>mfg: if you use it in a build expression, you need to import it on the 'build side' instead of the 'guix front-end' <mbakke>mfg: for gnu-build-system and friends you do that by passing #:modules in (arguments ...). <mfg>Ahh, that's what #:modules is for! <mfg>(guix build-system gnu) <mfg>there might be a better approach to go recursively through the configuration directory and replace every /bin/* invocation of commands <mbakke>mfg: you need to cons (ice-9 ftw) onto the default modules, e.g.: #:modules ((ice-9 ftw) ,@%gnu-build-system-modules) <mfg>okay, why is this needed? i mean how do i know that i have to add it besides getting unbound variable errors? <mbakke>mfg: although in this case I think you can use 'find-files' <mfg>let me check the manual about it <mfg>mbakke: you're right find-files is better :) <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. <civodul>but yeah, i don't think it's useful advice <apteryx>and there's already HACKING that points to the Contributing node <apteryx>I suggest to just take the part touching building from Git out of the README altogether. <civodul>or just remove the paragraph at "Following building Guix from ..." <civodul>many users will always start by taking a look at README, so it should at least contain the pointers *civodul goes afk for a bit ***capnick is now known as cap
***nlofaro_ is now known as nlofaro
<apteryx>Would anyone have an idea of how local-file could be made to work at the REPL? <apteryx>hmm, let me try to find a reproducer <mfg>is it possible to define procedures inside a package definition? If so how would it look like? <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 <cbaines>Hmm, I can't seem to reproduce that, it seems to work and I don't see errors about patches *apteryx retries in a pristine Emacs env <apteryx>wow, I coudn't reproduce so far. Thanks! I'll investigate what went wrong. <divoplade>I'm building icecat with 1 core, but rust does not care and starts threads on all of my cores :( <mfg>divoplade: i feel you <ss2``>would anyone fancy to paste their fontconfig with crisp fonts for me? <lfam>Can you file a bug report about that? <divoplade>But at least rust compilation does not fill all my memory. <sneek>raghavgururajan, you have 2 messages! <sneek>raghavgururajan, vits-test says: my ip is still 95.181.110.196, and i'm real guix-vits. <apteryx>(and sorry about that spam in your sneek mail box) <cbaines>Does sneek have a way to forget messages? It's not mentioned in the help output, and this isn't the first time that sneek has sent abuse to people. <apteryx>Not that I know of, but I'm no sneek expert by any mean. <lfam>cbaines: There is a "forget it" command, but I'm not sure how to tell it exactly what to forget <lfam>sneek: The sun is shining <lfam>I know how to teach things to sneek but I don't know how to recall them or how to tell sneek to forget <rekado_>I’m trying to debug a booting problem with my repaired Librem 13 laptop, so I’m trying PureOS… and the installer keeps crashing. <rekado_>I think Guix is doing pretty well, considering that the installer is not just an existing installer with a different theme. <rekado_>on the other hand: the state of software in 2020 is not very encouraging *raghavgururajan should focus on merging gnome stuff <apteryx>any idea of what could cause Guile to think it needs to recompile the whole Guix tree that I've got already compiled for the very same version of Guile? <rekado_>in related news: the failure to boot from encrypted SSD is *not* specific to Guix System. Even the installed PureOS won’t boot. <civodul>rekado_: re the installer, that's "good news" for Guix i guess? :-) <civodul>apteryx: usually Guile is very talkative about why it's recompiling things (or not recompiling things, even) <apteryx>I'm trying this: guix environment --pure --ad-hoc emacs emacs-geiser guile guile-gcrypt guile-git guile-readline -- emacs -q, then M-x run-guile, then (add-to-load-path "/path/to/my/guix"), then ,m (gnu packages inkscape) and it goes on recompiling everything <civodul>ah well that's expected: /path/to/my/guix/*.scm is necessarily newer than the .go files on GUILE_LOAD_COMPILED_PATH <civodul>so you get the "file is newer" warning and it compiles things <apteryx>but there are .go files in /path/to/my/guix/*.scm (it's my already built git checkout) <cbaines>What does (getenv "GUILE_LOAD_COMPILED_PATH") say in Geiser? <civodul>apteryx: ah, it doesn't say, but that's simply because there's no matching .go file in the load path <civodul>because there's no "guix" on your "guix environment --ad-hoc" line <rekado_>I think the fact that even PureOS cannot be booted on this Purism Librem laptop is in fact good news for Guix: it means that it isn’t our fault. <apteryx>ah, so I need to set the compiled-load-path as well as the load-path to my git checkout <rekado_>it’s bad news for me, but I’ve had a whole year of bad news when it came to this laptop. *rekado_ tries not to let the frustration take over <cbaines>apteryx, I would guess so, civodul can probably confirm <civodul>there's GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH <raghavgururajan>By encrypted SSD do you mean full-disk LUKS encryption or full-disk SSD firmare encryption? <cbaines>rekado_, I'm sad to hear you're having laptop troubles again! What's the issue with PureOS? <apteryx>rekado_: you got the laptop "repaired", but it won't boot with their OS? :-( <apteryx>cbaines, civodul: Confirmed the issue was the GUILE_LOAD_COMPILED_PATH, it works fine when starting Emacs with ./pre-inst-env <cbaines>apteryx, in some cases I use direnv, combined with emacs-direnv to manage things like the GUILE_LOAD_PATH <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. <rekado_>older versions of Coreboot do in fact work, but with this particular laptop the graphics chip goes crazy when it goes into power saving mode for the first time <cbaines>rekado_, hmm, are you trying to boot from the M.2 SSD or the SATA SSD? <rekado_>raghavgururajan: used to be GRUB on my X200S, but I think here it’s SeaBIOS (that’s what I see stuck when attempting to boot PureOS) <rekado_>I even bought a new SSD from a different manufacturer (WD instead of Samsung) to see if it might be my disk <rekado_>(or a combination of disk and Coreboot) <rekado_>all other machines that I have access to boot just fine <rekado_>it’s clearly a problem with this version of Coreboot <rekado_>but I can’t convince them that they should fix it. <cbaines>rekado_, I think mine boots from the M.2 SSD. In what way does it fail to boot? <raghavgururajan>rekado_: Okay, in that case, you can soft-flash the BIOS with coreboot-grub image, instead of coreboot-seabios image. <rekado_>I still have the extended warranty, but they seem to want to run out the clock <rekado_>with Guix System I see GRUB come up, but the moment I select an OS to boot the screen goes black and it just sits there. <rekado_>with PureOS I just see a message that it will boot from Hard Disk, blinking cursor. Nothing more. <raghavgururajan>rekado_: If you would like to, boot any GNU/Linux via USB and soft-flash the BIOS with Coreboot-GRUB image. Then you can do many stuff on GRUB command-line. <rekado_>raghavgururajan: I’m a bit worried I might break things. <rekado_>I flashed different versions of the purism fork of coreboot using their scripts <apteryx>rekado_: does it work with non-SSD drives at least? <rekado_>apteryx: it boots the installer media from USB just fine <rekado_>and with an older version of Purism Coreboot I can boot from SSD just fine. <apteryx>weird. Have you tried asking in #coreboot? <raghavgururajan>rekado_: I think the problem is with SeaBIOS part of coreboot, not the coreboot itself. From what you say, seems like newer code of SeaBIOS is not loading GURB-on-disk correctly. <rekado_>I gotta to another room now, and since I can’t use my Librem laptop with Wifi now that means I’ll be offline now :-/ <rekado_>really bothers me that this expensive laptop and the expensive warranty still requires of me to do all the debugging work by myself <rekado_>I’m so happy I didn’t have to pay for it myself :-/ <apteryx>does Geiser have a variable for the guile-load-compiled-path? I can't seem to find it. <apteryx>ah, geiser-guile-load-path acts as both <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>thanks. And I can list in the REPL all the exported functions of one modules? <apteryx>One thing which is nice is C-c C-d which shows the docstring or manual of the procedure/symbol at point. <zimoun>apteryx: cool! That’s what I was looking for ***card.freenode.net sets mode: +o ChanServ
<civodul>the topic of LP is "empowering users" <zimoun>civodul: do you mean call or session? <cbaines>mroh, no, but we might need to update the package defintion <cbaines>civodul, looks like project sprint is one of the things, so that could definately be a thing <civodul>all we need is someone to lead that! <cbaines>I haven't read much yet, but it's unclear if it's going to be an in person event... <cbaines>"we ask everyone submitting a session to tell us if they can be physically present in Boston" <civodul>in-person events are a thing of the past <civodul>maybe they're hopeful because they heard the US will have a vaccine by next week <cbaines>Hmm, I remain sceptical about if/when things will return to be like the before times <cbaines>and I never ventured across the pond to Libreplanet in those times either! <civodul>me neither, but that's the point: it's the year to "be there" :-) <civodul>mroh: YouTube serves videos, and youtube-dl fetches those bits just like Firefox does <civodul>it's interesting that this can be presented as "circumvention" <cbaines>there's a couple more weeks until the close of the call for sessions at least <zimoun>I have not understood what a session is and what a proposal is. <zimoun>for sure, we have to synchronise and propose something about Guix. :-) <civodul>zimoun: the page above lists differents kinds of "sessions" <cbaines>In other news, I succeeded today at starting to try and build packages affected by patches. <cbaines>There's 10,000 builds in the queue though, so it has some catching up to do. <cbaines>In hindsight, I should probably have only tried to build recent patches <civodul>cbaines: roughly the equivalent of "guix build $(guix refresh -l foo)"? <zimoun>yeah I have read them. :-) In my conf’s world, session means different presentations gathered together by topic. And here, I miss if session is similar or only one talk. <cbaines>civodul, I'm using the Guix Data Service, so roughly, but it also catches things that guix refresh doesn't <civodul>zimoun: "update" could be a single talk i guess, but "workshops" and "sprints" would be more hands-on sessions by groups of people <cbaines>guix refresh says: No dependents other than itself: rust-serde@1.0.116 <civodul>cbaines: oh because it can compare the sets of derivations <cbaines>and then building all the derivations associated with the target revision <cbaines>so it should even work with patches for build systems, and things like that <zimoun>civodul: thanks! So the most motivated who reads that and drops an email ti guix-devel to synchronize LibrePlanet will win a beer next time we meet. ;-) <civodul>that's something one could compute locally as well, but it's expensive <cbaines>civodul, this is kind of where I'm going with trying to automate aspects of patch review <cbaines>trying to do lots of expensive things up front, so that actually reviewing and merging patches is easier <civodul>yes, that's the right thing, it's great that you've reached this point! <cbaines>haha, well, it's been literally ~2 years now <cbaines>I'll send an email about this to guix-devel at some point as well <civodul>i always keep an eye on what it would take to do something similar locally <cbaines>yeah, well it might be good to look to get guix refresh to understand the weird packaging for rust things <cbaines>I can see something going wrong if someone doesn't question why something has no dependents... <civodul>more generally, "guix pull" for instance computes the list of packages when you run it <civodul>such that "guix log" or whever could use local data to determine, say, when a package was upgraded <zimoun>cbaines: yeah I remember you were presenting this patch merging stuff in Dec. 2018 just before Reproducible Builds in Paris :-) <civodul>we could also cache the package -> derivation mapping <civodul>so we'd cache: channel instances -> packages -> derivations <civodul>but anyway, these are more ideas for the longer term, not something that would necessarily help patch review <civodul>whereas what you're showing here suggests you've nearly achieved your goals <cbaines>well, I'm optimistic about having a working prototype again :) <cbaines>so much so I've actually attempted to review some patches! <cbaines>there's no shortage of things to do and improvements to make though <cbaines>somewhere towards the start of that list is stop the Guix Build Coordinator segfaulting frequently... <cbaines>Some guile stuff, then some sqlite stuff <cbaines>but I haven't been able to work out where in my code the problem is occuring <civodul>you're using guile-squee and guile-sqlite3, right? <cbaines>I haven't spent much time on this though, it's hopefully just something simple I'm doing wrong <cbaines>civodul, yeah, the coordinator just uses guile-sqlite3 <civodul>guile-sqlite3 seems to be rather solid <civodul>you're not binding to C apart from that? <cbaines>I think the bindings are probably fine, although it's low level enough that I think it's possible to still get things wrong <civodul>in the sense that bindings shouldn't allow you to crash the process <cbaines>anyway, I'll investigate again soon and hopefully figure it out <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 <civodul>maybe we can open an issue to keep track of it <zimoun>yes, I am going to do that. I was just to be sure that I have not missed something :-)