<kmicu>rvgn: GPA code wasn’t changed since 2017 :/ The latest version is gpa-0.10.0.tar.bz2. <quiliro>except when i reboot with the old installation <rvgn>kmicu So, is my problem actually a bug or something else? <kmicu>rvgn: I saw two issues: first about missing GPA in GNOME Dash and second about GPA which looks not maintained in Guix. Both are bugs. <kmicu>I guess you are the first real user of GPA in Guix. <kmicu>quiliro: that could be anything. Did you use i3-wm in 0.16? <rvgn>kmicu I am looking for creating and managing GPG keys with GUI. Is there any alternative? <kmicu>rvgn: It looks like Seahorse (GNOME) is in Guix. <quiliro>it is a driver problem, not a desktop problem <rvgn>kmicu Out of curiosity, how you and others do that thingy, where it displays what you are doing. <kmicu>quiliro: the problem could be with i3-wm misconfiguraton and not video cards. Did you test GNOME with 1.0.1? <rvgn>kmicu tried that already. No luck. Generate key option is greyed out. <kmicu>rvgn: sorry about that. We should fix GPA for sure but I cannot recommend any alternative for now :( <nckx>rvgn: /me is doing this. <vagrantc>dongcarl: it just crossed my mind now that i've got debootstrap working, and there's the qemu-binfmt service support for foreign architectures, if i couldn't get a working riscv64 chroot on guix :) <rvgn>kmicu I'll file a bug report for GPA. <dongcarl>vagrantc: Wait what how I thought chroots needed to be same architecture?? <kmicu>rvgn: that would be great. Thank you. *rvgn is filing bug report for GPA <vagrantc>dongcarl: there's a binfmt service to use qemu to emulate the native calls *kmicu went 😴 cuz sleep is as pleasant as using Guix 😺 <dongcarl>vagrantc: Confused... So that's not cross-compilation right? That's emulating `arm` and running a native compiler for `arm` on emulated `arm`? <vagrantc>dongcarl: pretty much, but with native calls for things like accessing the filesystem *dongcarl has his mind blown <vagrantc>binfmt is basically a way for the kernel to have a registered bit of "oh, you're *that* kind of executable, i'll use this handler to run you ..." <vagrantc>i think it's the same thing it uses to run java binaries, if i'm not mistaken <vagrantc>would be good to teach qemu-lookup-platform how to recognize riscv64 <vagrantc>you can dig up the file magic from the qemu packages in debian... <ngz>So, no idea about my "fatal error: glib.h: No such file or directory" at build time, even though "glib" is an input of the package? *dongcarl adds another thing to list of things to do after making Guix cross-compile bitcoin for OSX and Mac <zch>Hello, I'm installing GuixSD for the first time. I'm in the initial phases of installation, as in just sitting in a shell (root@gnu). Would it be possible to install emacs right away so I don't have to use nano or vi? <nckx>ngz: That depends entirely on how glib is (not…) found, i.e. include paths, (non-standard) environment variables, missing pkg-config, … Could be many a thing. <vagrantc>dongcarl: actually, this looks pretty easy to add the basic support, at least <dongcarl>vagrantc: Yeah but we don't even have basic `--target=riscv64-linux-gnu` support yet on core-updates, as I think even `--target=aarch64-linux-gnu` is broken <zch>I would also use zile but it doesn't come with paren matching, which is mostly what im wanting <ngz>nckx: Ok. Do you know where glib.h is supposed to be located? <nckx>zch: ‘guix install emacs’ should just work, although I'd start cow-store before doing so (otherwise you're installing to RAM, which will work fine, just use… RAM…) <nckx>ngz: /gnu/store/…-glib-2.x.y/include/glib-2.0/glib.h <vagrantc>dongcarl: yeah, but i can at least debootstrap a debian chroot with it :) <nckx>zch: Installing packages (does stock emacs match brackets? I don't even know) is also up to you. <nckx>s/packages/extra emacs &/ <zch>ill just manage without i suppose :P <dongcarl>vagrantc: This might actually make my cross compiles so much easier... <nckx>Okay? I wasn't trying to make it sound hard, quite the opposite. <nckx>zch: ☝ Have fun either way! *nckx ‘guix install’s stuff into the installer's ‘live’ environment all the time. <vagrantc>i'm not sure if the guix service has all the right flags for it to work out of the box ... it might need to copy the binfmt handler into the chroot <dongcarl>vagrantc: What I mean is... Can I create a debian chroot inside a guix environment? <quiliro>is there anything i can do so diagnose my video problem? <quiliro>it is a recent problem on both my machines <quiliro>what is the easiest way to paste to a public pastebin from a bare-bones installation? <quiliro>i want to past my lightweight-desktop.scm <vagrantc>dongcarl: i don't see any reason why not <ngz>nckx: Thank you. I got further and now fail with "fatal error: glibconfig.h: No such file or directory". Let's call it a day. <nckx>quiliro: I use http://ix.io/ but that still requires a client like curl or wget… Dunno if emacs could be made to do the job. ‘Probably.’ <vagrantc>dongcarl: you'll need to specify the PATH= variable when entering the chroot, of course <nckx>quiliro: Sure, but you asked specifically. ‘guix install icecat’ is ‘easy’ too 😛 <nckx>ngz: That file is in a very… interesting location: /gnu/store/…-glib-2.x.y/include/glib-2.0/glib.h <nckx>Not too surprising that it fails to be found. <quiliro>nckx: 'echo Hello world. | curl -F 'f:1=<-' ix.io'? <nckx>→ /gnu/store/…-glib-2.x.y/lib/glib-2.0/include/glibconfig.h <nckx>I honestly don't know if that's the expected location (weird…) or a packaging bug on our end. <quiliro>nckx: 'cat lightweight-desktop.scm | curl -F 'f:1=<-' ix.io'? <nckx>quiliro: Superfluous use of cat, but sure, should work? Try it? <nckx>curl … < lightweight-desktop.scm to save precious electrons. <nckx>quiliro: I probably can't help you with your problem, so I can at least help you paste it. <zch>How would I install ath9k_htc for my wifi adapter: TPE-N150USB - wpa_supplicant is giving output: Successfully initialized wpa_supplicant...rfkill: WLAN soft blocked <zch>"ip a" shows the interface, so its being detected? <zch>but idk if i need to install some additional things? <nckx>zch: rfkill unblock <device> <quiliro>is there any other thing i should report? <nckx>zch: rfkill will list them all <nckx>quiliro: Again, you may have explained earlier/elswhere, but all I've seen tonight is ‘video errors’, basically. A more detailed description would be nice. Black screen? Messages (which)? Something else (what)? <zch>Thank you so much nckx! <nckx>quiliro: Plonk as much as you can in the bug report. A camera screenshot if you have to. <quiliro>oh....black screen which flashes with something that is not possible to have time to read <nckx>(Well, unless it's a black screen, we know what they look like.) <nckx>quiliro: This is *purely* a guess, but sounds like something is failing/crashing/otherwise exiting and being respawned over & over. <quiliro>also blinking numlock led...but it is not kernel panic becaause C+M+Del will restart <nckx>Check /var/log/Xorg.0.log, messages, slim.log or whatever your DM is… <nckx>Very generic instructions, I know, but there's not much a stranger without video troubles can do at this distance ☺ <ItsMarlin>it always returns that it can't access /var/guix <nckx>ItsMarlin: Sounds like it needs patching to store stuff in ~, or whever pip likes to store stuff. <nckx>Yeah, if /gnu/store, that's definitely it. <nckx>That is all I can say for I use not pip. <nckx>ItsMarlin: In lieu of the (needed) patch, does pip accept an --install-to= option (it could be called anything but you get the gist). <recj>hi all, i am trying to create a package... if it's from git what should i run checksum on? <nckx>recj: ‘guix hash -rx .’ in a *clean* checkout (no left-over files &c). <nckx>See ‘Invoking guix hash’ in the Guix manual for more deets. <nckx>recj: To be honest, you can also just fill in a bogus (if valid) hash and have guix tell you the correct one when you try to build the package. <recj>well that's an approach that works too lol but thanks for telling me <recj>i have to say the guix manual is written exceptionally well. sometimes docs can be quite confusing <recj>anyway, i will clone and do that <nckx>The latter is not great practice (especially on release tarballs with a signature — *please* download them manually and verify the signature) but eh, if ‘guix hash -rx .’ wouldn't work for some reason… <nckx>recj: That is the good way! Yay! <vagrantc>dongcarl: it's going to take a bit more to get the qemu-binfmt-service stuff working so that you can easily use debootstrap ... it's not setting some flags that it ought to <dongcarl>vagrantc: yeah I’m trying native in a guix environment right now and fakerooted debootstrap works but it doesn’t want to chroot in even with fakeroot <zch>The manual says: "If you have opted for /boot/efi as an EFI mount point for example, mount it at /mnt/boot/efi now so it is found by guix system init afterwards." - I'm just following along, so do I mkdir -p /mnt/boot/efi? since it doesn't exist and then mount the efi partition? <zch>got it, thanks buenouanq <vagrantc>dongcarl: working on patches to add support that might make it easier <dongcarl>vagrantc: <3 would packaging fakechroot for Guix make it work? <nckx>(zch: If you have the weird-looking path /mnt/boot/efi/efi (or ‘EFI’), this is *correct*.) <vagrantc>dongcarl: well, as a user you might need something like that ... i generally just am willing to chroot as root <vagrantc>dongcarl: but the problem is the qemu interpreter isn't in the chroot, and the flags aren't set to use the interpreter outside the chroot <vagrantc>although... the guix way would probably be to copy all the right things into the chroot ... but this gets a little weird for cross-distro chroots. <bluekeys>I'm trying to build a package for trigger-rally. The makefile is not named makefile, its GNUMakefile. How can I tell guix? <vagrantc>i guess a quick and dirty hack would be to bind-mount /gnu/store into the chroot ... <nckx>bluekeys: That's an unusual name. GNUmakefile (small m) would have just worked. <vagrantc>dongcarl: hrm. the binfmt flags that work on debian aren't working on guix. :( <bluekeys>nckx: I'm not managing to get my -f solution to work either. <nckx>bluekeys: It should Just, although I've never tried ‘-f’ specifically. Are you using the standard phases? <nckx>(I.e. not modify-ing them.) <bluekeys>make: ./src/GNUMakefile: No such file or directory <bluekeys>I've removed the configure phase but thats it <nckx>bluekeys: OK, otherwise you would've needed to (apply invoke make … make-flags) but that's not the problem then. <nckx>bluekeys: What does ./src contain, makefile-wise? <nckx>[s/make/"make"/ for correctness' sake even though irrelevant.] <bluekeys>nckx: Is there a way to check what guix has extracted when it followed my package instructions? That way I can be sure the file does exist as I think it should. <nckx>bluekeys: You can make guix preserve the build directory of a failed build with the ‘--keep-failed’ or ‘-K’ flag. <bluekeys>Where is the build directory then found? <nckx>It will print a ‘note: keeping build directory /tmp/…’ near the end. <nckx>(You can also run ‘guix build foo --source’ to get the unpacked sources, with patches and snippets applied, if any, but without any attempt to build the thing. Sometimes more helpful, sometimes less.) <bluekeys>nice. First error, it's trigger-rally-0.6.6/src/GNUmakefile <nckx>bluekeys: Hmm, so ./GNUMakefile and ./src/GNUmakefile? Great. <nckx>At this point I'd be tempted to write a phase that renames all ‘GNUMakefile’s to ‘GNUmakefile’s 😒 That will require 0 hacking of make-flags, which compensates for the ickyness, I guess. <bluekeys>nckx: No. Let me clarify. GNUMakefile was a misread on my part, which I wrongly relayed to this chat window. <nckx>But… GNU make automatically handles GNUmakefiles…? <nckx>(Several packages in Guix use that name, gnu-build-system happily builds them.) <nckx>What is your original error, with the build system defaults? <nckx>(No time-wasting typos this time, please, it's too late for those here ;-) <bluekeys>*** erudition (~erudition@24.115.66.174.res-cmts.sesp.ptd.net) has joined <bluekeys>*** erudition (~erudition@24.115.66.174.res-cmts.sesp.ptd.net) has joined ***ChanServ sets mode: +o nckx
<nckx>Always just when I'm AFK… <bluekeys>make: *** No targets specified and no makefile found. Stop. <str1ngs>sounds like you might need make -C ./sub <nckx>Blerp. And yes, what str1ngs typed. <str1ngs>I don't know if you need the full path. is pwd the build directory? I kinda made an assumption there. <nckx>Hard to tell without more info. I've resorted to (invoke "ls") before, but that's pretty desperate. <nckx>str1ngs: Needs moar hack. <nckx>(invoke "bash" "-c" "guile" …) <str1ngs>I just want to use arbitrary scheme anywhere. damn it! :P <nckx>guix build --on-failure=repl ♥ <str1ngs>you know what would be really nice. continuing phases <str1ngs>the finally build would not be eligible for the store. but you could debug phase atleast <bluekeys>-C isn't quite doing it for me either. I'm still getting a No such file or directory <str1ngs>I might be better just to change the build directory <str1ngs>I'm not sure the guix way to do that though. <nckx>bluekeys: You can paste your package (er, hm) if you don't immediately require a response. <bluekeys>nckx: no problem, i'd love any help. Where is good to paste it? <nckx>str1ngs: Just chdir, generally, if it's supposed to span phases. <nckx>‘with-directory-excursion’ is the Guixy ‘functional’ equivalent but of course chdirs back at the end of the block. <nckx>bluekeys: paste.debian.net is the house pastebin. <nckx>Others are fine as long as they are libre- and Tor-friendly. *nckx will get back to you between innings. <bluekeys>ty I'm going to take a break. Catch you later *nckx .oO Blue keys… Thinkpads? Symbolics keyboards? <zch>how do i get networking post-installation? wpa_supplicant isn't available as root. <nckx>bluekeys: You did try just ‘./src’, rite? <str1ngs>bluekeys: list "-C ./trigger-rally-0.6.6/src" maybe should be (list "-C" "./triger.....") <str1ngs>"-C ./trigger..." could be treated as on arguement <nckx>str1ngs, bluekeys: Close, try "-C" "src" first. <nckx>str1ngs: I always say that, too. Works like a charm. <str1ngs>but yes, it would make sense that src is the subdirectory <bluekeys>I have new error messages, which in this case is good, I just don't understand why <nckx>bluekeys: If you're planning on donating your work to Guix (and I hope you do, looks rad!), switch to mirror://sourceforge/… But that's for later. <nckx>bluekeys: What's the error? I haven't looked inside yet, but packages without configure scripts often need help to find their inputs. <bluekeys>./include/pengine.h:24:22: fatal error: SDL2/SDL.h: No such file or directory *nckx AFK for a while; leaves you in the care of str1ngs. <str1ngs>okay hopefully, that just works. but you might have to manually tell it where the sdl2 input headers are <bluekeys>OK. I included sdl as input. There is no sdl2 package? <bluekeys>SDL errors are gone. I now have ./include/pengine.h:28:20: fatal error: physfs.h: No such file or directory <nckx>bluekeys: There is an sdl2 package. <bluekeys>#:use-module (gnu packages sdl) gives me no code for module (gnu packages sdl2) <nckx>There is an sdl2 *package* in the (gnu packages sdl) *module*. <nckx>Modules are like categories. <nckx>You'll also need (at least) glew, openal, and freealut. <nckx>str1ngs: Dunno. If you say so. <nckx>I've also replaced sdl2 with a union: ("sdl2" ,(sdl-union (list sdl2 sdl2-image))) <nckx>make: *** No rule to make target 'check'. Stop. \o/ <nckx>It successfully builds and crashes for me ☺ <nckx>Failed to load /textures/splash/loading.png: /textures/splash/loading.png, PhysFS: 11 - not found at PEngine/texture.cpp:76 <recj>ok so with the software i'm trying to package, it requires docker to build.... <nckx>If you'd rather debug & learn yourself, more power to you. *nckx has encountered that before. It's a smell of general quality. <vagrantc>ok, i've confirmed that the way debian supports qemu+binfmt_misc and foreign-architecture chroots requires static builds of the qemu-ARCH binaries ... but i'm failing to pass the right arguments to configure in my attempt at a qemu-static package... <str1ngs>vagrantc: you may need to add -static to CLFAGS <vagrantc>str1ngs: in addition to passing --static to configure? <str1ngs>also this might require static glibc ligcc files. aka .a files <str1ngs>my guess is Guix is nice and keeps .a files <recj>do you think i would get banned from github for repeatedly posting pull requests that replace instances of "Linux" that refer to the operating system and not the kernel as GNU/Linux or GNU+Linux <str1ngs>vagrantc: think you will need glibc:static as well <str1ngs>vagrantc: --static usually means build static libraries for this package not build this package as a static binary. <vagrantc>str1ngs: pretty sure qemu's ./configure --static is for what i want to pass <str1ngs>that maybe the case. just from my experience --static is not enough and does not imply build this statically <str1ngs>but --help should tell you either way *vagrantc enabled this feature in debian several years ago <str1ngs>but lets say --static does all the right things. then you might need glibc:static input etc <str1ngs>also sometimes gets tricky because if one static library does not exist. :( <nckx>bluekeys: When you accidentally flooded the channel earlier, were you addressed by a bot? Just curious. <nckx>We should have an ‘anti-spam’ bot but I've never seen it in action. <nckx>All right. I guess she needs more spam ☺ <bluekeys>I'm as far as I can get with this game packaging now. (Same error as you). <nckx>bluekeys: I'm taking a look because I want to play it now. 😛 <bluekeys>Uh oh, sounds like this could become addictive. Where do I start? I've got guile installed, emacs and geiser. Am I missing anything? <bluekeys>Do i connect to an external guile server (does guix provide one) or just run with a fresh one? *nckx is playing Trigger Rally. <nckx>Also: It's even in Guix: guix install sicp (although you'll want the videos too, of course). *nckx was thinking of recommending that but it's not a ‘how to Guile’ tutorial per se. Still awesome. <buenouanq>I didn't even know about this package though - This is great. <nckx>buenouanq: Is that a serious question? <nckx>I think it's great that it's available in Guix as-is, and I don't think it's a failure to not ship video files which pose some obvious technical challenges, let alone possible legal ones. <nckx>(No idea what the licence is, but that's a *lot* of bits to mirror and move…) *nckx back to irresponsible driving. <nckx>bluekeys: …so trigger-rally 0.6.6 works fine, but 0.6.6.1 needs a (much) newer tinyxml2 than what Guix currently provides. <nckx>But that's for tomorrow. It's getting light; time for bed. <recj>i'm honestly not sure how to package this because of the docker build system <runejuhl>Hi all. I've got an old installation of Guix 0.15.0-2 -- how would I go about upgrading to 1.0? <runejuhl>jonsger: ah, that all? Stumbled over unanswered questions about upgrading on Reddit and Stackoverflow, so I figured there was something I'd have to do in order to make it work :) <runejuhl>I'll just plow ahead then and see what happens <runejuhl>cccccchcejhthlndcbbeibebtdegfdjlggvlncevgcdl <jonsger>It could be possible that you need some commits between where you run "guix pull" on, so doing some hops <runejuhl>guix pull: error: You found a bug: the program '/gnu/store/9hzdmj33baw0bg2r1am3vrf2vbm9fbhp-compute-guix-derivation' failed to compute the derivation for Guix (version: "8758086d2d25f2e58354febc3f01af586d0ee416"; system: "x86_64-linux"; host version: "0.15.0-2.8bbb79c"; pull-version: 1). <jonsger>hi civodul, the virtio_pci initrd error is now gone at Hetzner Cloud but somehow it fails with the installing due to an error during building binutils <civodul>jonsger: "building" binutils? sounds fishy <jonsger>civodul: it's strange. I tried it again to reproduce the error and the error is just gone. Maybe something with substitutes not available... <roptat>weird, I get tests failures in ocaml-odoc when I check it, but a build farm was able to build the package <roptat>"Files ... make inconsistent assumptions over implementation Cmdliner" <cap>Greetings. I tried to install guixsd on my laptop. I flashed the usb device and tried to boot from it, but I keep getting a error message from grub, saying "error: unknown filesystem". Does anyone has a hint for me? <roptat>I wonder if that's a timestamp-related issue... but the build seems to be reproducible <roptat>cap how did you flash your usb device? <cap>roptat: via dd. I followed the install manual. <cap>I also tried to reflash the image but it didn't help. <roptat>is it the official image or did you build an image yourself? <xavierm02>Hey. Yesterday, I messed with the .scm config file and ended up forgetting to put network-manager (and a few other network-related stuff) in there. The result was that I lost my internet connection. I got things back to normal by rolling back and rebooting but I'd like to know how I could've avoided rebooting. <cap>it is the official one and I also verified it <cap>bootmode is uefi only with cms disabled <xavierm02>The problem was that: When I rolled back, the network still didn't work until reboot. I tried to use sheperd / herd but neither seemed to know a network-manager service, even after I rolled back. <roptat>xavierm02, with "herd status" you can see a list of services <xavierm02>roptat: yeah, I did that and there was nothing about the network listed <roptat>but since you didn't have a network service before reconfiguring, maybe the Shepherd couldn't know about it even after reconfiguring... <xavierm02>I had %desktop-services when I booted. Then I removed it and added some parts of it but forgot network and reconfigured <xavierm02>(I now know how to modify the configuration of things in %desktop-services, but at the time I thought I had to add all services myself if I wanted to customize the configuration) <xavierm02>And then I rolled back and herd still didn't see anything network-related <cap>roptat: I also tried bios only but it didn't help. <roptat>xavierm02, I don't really know how herd is notified on reconfigure / roll-back (is it even notified on roll backs?) <roptat>I found a non deterministic package <roptat>I asked a colleague about it, because it's not trivial to understand why these 2*16 bytes differ in the files <roptat>there's only a difference between what my machine produces and what the build farm produced back then, but no difference between two runs on my machine <rekado>roptat: could be an embedded month or day timestamp <roptat>nope, I'v just checked with ocamlobjinfo, one of the dependencies have a different hash between the two runs <roptat>but the dependency in question is reproducible <rekado>… but could that hash difference be due to an embedded timestamp that changes only every month or so? <roptat>so it's weird that it was given two different hashes <roptat>I understand the reasonning, but then there would be a difference in that dependency between a --check on my computer now and what was compiled on the build farm <roptat>oh, I think I need to challenge the build farms to be sure <roptat>bingo! I might have built that locally already <roptat>so the build farm has a different version of ocaml-cmdliner <roptat>how do I download its version to compare with my build result again? <roptat>there's a constant name that differs in cmdliner_trie.cmx, and other cmx differ, but haven't checked yet <sammich>Where does guix store .so files that are used in an environment? <rekado>sammich: everything is stored in /gnu/store <rekado>sammich: binaries are built so that they retain explicit references to .so files in /gnu/store <rekado>independent of whether they are used in an environment or not. <rekado>(if you want to read about the mechanism that’s used to accomplish this search for “RUNPATH”) <sammich>right, thanks rekado, Is there a way for me to list the paths that guile is checking for .so files when using dynamic-link? the .so file exists but guile isnt finding it <jonsger>If this trained data is release under an acceptable license, I don't oppose against. It's kind of a .png which is shipped with a package. We don't have a recipe and a source to build the PNG, we just take it... *kmicu wanted to link to discussions about that on Debian ML but finding those theards is not trivial ;) <civodul>jonsger: though PNGs such as photographs or drawings don't have "corresponding source", unlike these <kmicu>PNG is static though. Nerual network data is like putting magic numbers in crypto. 🤷 <civodul>also PNG is typically ornamental parts of software <civodul>whereas weights basically drive the software <rekado>a game without data files would be just a game engine. <kmicu>Games data files are trivial. Nothing like magic box. <rekado>I wouldn’t call them trivial in general, but in the computing sense this is probably true. <rekado>admittedly, I have a hard time seeing network weights as code requiring sources, because the path to the specific values might not even be deterministic. <roptat>but if a software is not deterministic, it doesn't mean it's not a software ;) <cap>Meanwhile I tried to use another usb stick but I still getting the grub error "error:unknown filesystem". <rekado>roptat: true. It’s just that there’s a really large set of numbers that could be used; the exact numbers might not even matter much. <rekado>or maybe: “usually don’t matter much” <cap>roptat: do you have any ideas? can we try to reproduce it? <rekado>civodul: I’d like to note that we have a package for kaldi, a speech recognition framework, that does not come with model files. <rekado>does anyone know what copyright has to say about models and derived outputs? *kmicu is not for or against only want to state all pros and cons. The topic is gray area in general. <kmicu>Darn stale X clipboard cache. <civodul>rekado: good question, i don't know, maybe the Debian thread has something about it <civodul>rekado: network weights are the result of a computation, so our natural approach would be to build them from source <civodul>but that is usually not feasible in practice <civodul>apparently it's even more CPU-intensive than building a chain of Rust ;-) <roptat>rekado, so the issue with cmdliner was a different contant name, and that was caused by a file ordering issue during the compilation <roptat>I added an Array.sort to the build.ml file and I think that will help eliminate the issue <rekado>roptat: related to listing directory contents or something else? <roptat>I don't know if there are other issues and how to test for ordering issues like that <roptat>yes, I added that sort around a Sys.readir <rekado>we had to patch a few things (including ghc-pkg) because of this. <roptat>is there a way to check for this kind of issues in guix? <roptat>like mounting a disorderfs on /tmp might help? <rekado>civodul: for retraining networks I’d love there to be a true free culture project that goes beyond distro packaging efforts. <bgardner>str1ngs: Following up on our exchange yesterday, after a reboot the exim configuration is still being ignored. Not sure what else to do. <roptat>so I mounted disorderfs on /tmp2, set TMPDIR=/tmp2 in guix-daemon's environment, checked that cmdliner is not reproducible with current guix, and is reproducible with my patch \o/ <str1ngs>bgardner: that is odd, could you paste your exim snippet? <bgardner>str1ngs: (service exim-service-type (exim-configuration (config-file (local-file "./exim-atlas.conf")))) <bgardner>str1ngs: And 'system reconfigure atlas-config.scm' emits a comment that it picked it up, and if you check the emitted name, it has a proper configuration in it that includes the indicated file (in the store) <bgardner>So guix seems all lined up properly, but asking exim what the live config is always results in the stock package version in the store. <roptat>oh, now there's a build failure in opam when I try to --check it... <roptat>this time "configure: error: C compiler cannot create executables" <roptat>ha, it might be caused by disorderfs, forgot to umount it ^^' <str1ngs>bgardner: I'm curious if the process has the config in it's command line. can you check with pgrep -a exim ? <roptat>cap, sorry I don't know what's going on... <roptat>cap, you might get better luck by writting to help-guix@gnu.org thoug <str1ngs>roptat: build with -K . and check config.log <str1ngs>sorry unless I had the wrong context for that last comment :( <roptat>I unmounted the disorderfs, and it worked better :) <roptat>actually, there were errors like cat: -: no such file or directory <str1ngs>yeah, I thought you were referring to your error. my bad <str1ngs>you can never find a cat when you need one :P <roptat>well, cat was found, but cat couldn't find - apparently <str1ngs>that's my unix man joke for the day :P <bgardner>str1ngs: 308 /gnu/store/mir1rb9l5w84iar811pgk6dd6j2gn513-exim-4.92/bin/exim -bd -v -C /gnu/store/0ay0fi6xzg0k8j59z4gmfksipqirszqr-exim.conf <bgardner>exim -bV replies: "Configuration file is /gnu/store/mir1rb9l5w84iar811pgk6dd6j2gn513-exim-4.92/etc/exim.conf" <bgardner>When I run exim -bV I need to call it the same as guix does, I get it. <cap>roptat: Just this moment I realized, that I flashed the image into a partitition and not on the device itselve. Thank you for your time and effort. <str1ngs>bgardner: I was wondering if the user call might be wrong. <bgardner>That's a bit unclear from the docs, but thinking it through it does make sense. <bgardner>I guess I alias it. Not sure what the best approach is. <str1ngs>I'm wondering if a shepherd target could be created to test config <bgardner>str1ngs: Thanks very much for the help, this at least frees my hand to get it working <str1ngs>does shepherd even have a way to make targets? something like herd config exim? <str1ngs>Im kinda ignorant when it comes to shepherd :( <str1ngs>bgarner: also the issue here might be that exim has a default config path. but it can be overridden with -C . such that when you normally do exim -bV it would not require -C <str1ngs>bgardner: if that is the case it's possible the exwim build could be tweaked to hardcode the store path. based on the config-file store path. just a thought I guess <bgardner>str1ngs: Good point, it was looking in the store rather than /etc so it must already have a reference that can be tweaked. <str1ngs>if it's a gnu project it might use --sysconf but that might fix this either. <str1ngs>it's kinda an edge cause . how often would someone use -bV ? <str1ngs>I guess since this is a MTA quite often <jonsger>cap: you are not the first who achived this :P *jonsger looks at himself :P <str1ngs>bgardner: yeah, modifying the build won't help. the config-file is not know at build time :( <str1ngs>I guess the way to do this is to make a shepherd action <bgardner>str1ngs: I someday want to get more familiar with shepherd, but I can't currently - I'll handle this case manually for now. <lsl88>hi Guix! I am updating my gpg key. Could you help me with the servers where I have to upload it? <lsl88>(sorry, I am updating the expiration date) <civodul>lsl88: you can send to pool.sks-keyservers.net <lsl88>civodul: bonjour! (it is the moring for me <lsl88>yes, I am sending it there, but I get the message: gpg: keyserver receive failed: No keyserver available <civodul>bah, maybe try eu.pool.sks-keyservers.net? <civodul>all this seems to be quite unreliable <lsl88>I ended up submitting it to the site <civodul>i don't know if the problem is with gpg (dirmngr) or with key servers themselves <lsl88>I guess it is with dirmngr because I copy pasted it on the site and I got a successful answer <civodul>yeah, i'm afraid that's what's happening :-/ <civodul>wingo: you certificate at wingolog.org has expired :-) <roptat>ho, turns out the reproducibility issue was already fixed in master, but not on the latest release of cmdliner yet <roptat>how can I list every ocaml package to challenge the build farms just on them? *jonsger wonders why he always uses `| awk '{print $1}'`... <roptat>what does that mean: "guix challenge: avertissement : impossible de mettre « /gnu/store/yqi231fddnwhdf1jm2lgsiqahcagcbq4-ocaml-4.07.1 » au défi : aucune construction locale"? <roptat>I do have that store path locally <bavier>roptat: it means the store path was substituted, so a challenge is meaningless <roptat>mh... but I want to compare two build farms <roptat>I don't care about local builds actually <roptat>mh... there are other reproducibility issues with a few ocaml packages that I'll try to fix :) <nckx>jonsger: Maybe [never used awk] because it handles whitespace, not only single tabs? <bgardner>Ack. After all my back and forth on here to get exim working it turns out only root can send mail. Let's back up: what mail server do all you guixers use for your Guix System setups? <nckx>bgardner: opensmtpd[-next, at the mo'] rocks. <nckx>-next is 6.4, which has an improved configuration syntax that the Guix service doesn't know about yet. If you're using a ‘native’ configuration file, use that. <nckx>bgardner: Oh, and OpenSMTPd doesn't do anything fancy like PTR filtering (coming soonish) or DKIM signing (it works fine with dkim-proxy though). It's minimalist compared to the other behemoths, but production-ready. <bgardner>nckx: That's okay by me, I'm trying to set up simple "help, I have an issue" style alerting until a proper monitoring tool makes it into guix (ala monit or similar) <nckx>It'll definitely do that thing and do it well. ***ChanServ sets mode: -o nckx
<_tibbe>Hi, I just discovered that there are hidden packages in Guix now. Is there any way to build these conveniently from the command line without building them from the Guix REPL by hande? <bavier>_tibbe: you can use 'guix build -e "(@@ (gnu package foo) bar)"' <nckx>(…so, ‘no’, not conveniently, but it's possible.) <_tibbe>`(@ (gnu packages) find-packages-by-name)` doesn't find them either... Do you really need to specify the defining file every time? <nckx>_tibbe: You might be able to stuff a (specification->package) in there, but I've not tried it. <_tibbe>I want to get into an environment with GCCs lib output installed (for libstdc++). Do I have any chance to do so on the command line? guix environment doesn't take paths of store items either. <bluekeys>nckx: Can you pastebin the solution? I'm itching to see what else was needed. <nckx>_tibbe: guix build -e '((@ (gnu packages) specification->package+output) "gcc-toolchain:out")' works, but not with hidden packages >_< <nckx>bluekeys: Oh, wait, that's the WIP version that doesn't work yet. 0.6.6 does, without the tinyxml2 input. <nckx>This one complains about missing definitions in Guix's tinyxml2, which isn't surprising as it's 3 major versions out of date. <bluekeys>I saw you mentioned that. I take it you looked at bringing it up to date and it wasn't trivial? I'd take a look, but I'll just end up asking you to spoon feed me anyhow! <_tibbe>nckx: I also see the profile cache thing in (gnu packages) for the first time. It looks like you have no chance of refering to the package apart from the direct scheme variable. <nckx>bluekeys: It was 6am and I was tired. I haven't looked at tinyxml2 at all yet. <bluekeys>Oh, cool. I'm going to take a look in a minute then. <nckx>_tibbe: I was not pro hiding gcc, and I think your ‘I just discovered that there are hidden packages in Guix now’ (we've had them for a long time) proves that some kind of line was crossed. 🤷 <nckx>Which isn't to say there might be a trivial solution to your problem that I don't know about. *nckx adds a not in there somewhere, or not. <nckx>bluekeys: Cool! TBH I was going to send it to guix-patches (with a request for your copyright name), but then discovered the .1 release and would like to hammer on the description a bit too. <nckx>bluekeys: If upgrading tinyxml2 breaks dependents (guix refresh -l tinyxml2) as I suspect it will, we can keep a separate ‘tinyxml2-4’ package around for now, no worries. <_tibbe>nckx: For now I can get things working for me by defining a package that has these packages as dependencies and dropping into a non ad-hoc environment for it. <bluekeys>You mean my 900 description, copy pasted from sourceforge with no formatting isn't good enough?! <nckx>😛 I arrogantly presumed I could do better. <nckx>_tibbe: That's… just not great. But glad you can make it work for now. <nckx>bluekeys: Oh, sorry, missed your quesh: did you use ‘guix build’? <bluekeys>sort of. It was ./pre-inst-env guix build trigger-rally --keep-failed <nckx>That will print a /gnu/store/… directory. The executable is in $that_dir/bin/trigger-rally. <nckx>You can also ‘guix install’ it if you like. <bluekeys>How do i do that. The same as above less pre-inst and keep-failed? <nckx>Replace ‘build’ with ‘install’. ‘--keep-failed’ is a valid option for both, but since nothing fails, does nothing, so you can drop it. <nckx>Keep ./pre-inst-env to keep using the git guix. <bluekeys>Failed to add PhysFS search directory "../data" <nckx>I had to leave that error in, see the 2nd commend in arguments. <bluekeys>Yup. I see no game. Could window manager affect it? <nckx>Without it the game won't start, and we can't set it to /gnu/store/… because it can go stale in ~. <nckx>bluekeys: I use i3. Let me remove my ~/.local/share/triggerthingy and retry. <roptat>how can I set TMPDIR for the daemon in guix system (at runtime if possible)? <nckx>bluekeys: Could you paste the console output while I build it? <nckx>You changed only the version number, hash, & dropped tinyxml2, right? <bluekeys>Actually, i updated the code I already had from yesterday <nckx>Gives me /gnu/store/svsbvabh4a7d9zkh6vc30yn00kqcr6ad-trigger-rally-0.6.6. <nckx>Hm, bluekeys, try editing the version I pasted (not because it's made of superior bytes but so we're definitely running the same thing). <nckx>The hash is very sensitive to changes (good thing), it will change if you call things in a different order etc. even if the net effect is the same. *nckx is wasting time racing again. <nckx>vagrantc: Eh, yes, one very fun commit, sure. <bluekeys>nckx: I'm just about to rerun it, but in the meantime, can I leave the room with this... *nckx ponders a suitable punishment for that. <nckx>Commit 10 new games by Monday. <bluekeys>guix build: warning: failed to load '(gnu packages trigger-rally)': <nckx>bluekeys: Ah, I added it to games.scm since that's where it would end up. Hence differences like my license: prefix and such. <nckx>(Keeping it in a separate module is fine but I'm lazy and don't like adding module imports to a file I'll never use.) <nckx>Sorry for the added confusion, I did totes forgot. <nckx>bluekeys: What, ‘nckx is an absent-minded fellow’? Best learn that early, yes. <nckx>bluekeys: Adding it in alphabetical order makes time-wasting merge conflicts less likely, but most people (unfortunately) just stick stuff on the end. <nckx>Adding it in ‘alphabetical’ order (i.e. somewhere after the first ‘define public t…’) will earn you bonus nckx-points™ which you can exchange for bad jokes & free support later. <nckx>rvgn: New bridge/bouncer? <bluekeys>Unless I'm mistaken, games.scm needs a major realphabetizing... project-starfighter, chromium-bsu, tuxpaint. <rvgn>nckx Using XMPP-IRC Gateway provided at irc.disroot.org <nckx>bluekeys: Well, that's not going to happen. <bavier>bluekeys: I'm personally not fond of such things as re-alphabetizing, they don't add much, but make the git history difficult <nckx>bluekeys: No, I mean that a reordering megapatch won't be accepted. There are a few modules that are more or less in order, and we should keep them that way for easier merging, but the rest is a lost cause. <nckx>Still, plonking new packages anywhere else but at the end can save some headaches, sometimes. <nckx>Maybe that's because I'm a chronic rebaser, dunno. <rvgn>nckx What did it show on your screen when I joined the room? <bluekeys>I've put it before tuxpaint. I changed the version, removed libxml2 and got another error. <nckx>rvgn: I'd not seen you with that cloak before but I don't often pay attention. <bluekeys>guix build: warning: failed to load '(gnu packages trigger-rally)': <bluekeys>/gnu/store/a3azp15rjii8ssn5fm59fd1ggid30fig-trigger-rally-0.6.6 <nckx>Hmm? How does that /gnu/store line relate to the previous one? <rvgn>Damn why the hell did I tag myself xD <rvgn>nckx Yeah I just started using the gateway recently. One less client on my system. <nckx>‘Unbound variable: package /gnu/store/a3azp15rjii8ssn5fm59fd1ggid30fig-trigger-rally-0.6.6’? <nckx>Could you paste the new package (whole games.scm is fine, even)? Looks like a syntax error. <bluekeys>Length of code is not allowed to exceed 150kB. <nckx>Hrmph. Just the package then. <nckx>(My paste was copied directly from a working games.scm, so weird.) <nckx>bluekeys: You still have a trigger-rally.scm, that's where the error is coming from. <nckx>Move it out of the way for now. <bluekeys>I mean when you say it out loud like that I feel so sheepish ;) <nckx>(The ‘wtf’ wasn't meant like that.) <bluekeys>Oh, I meant the obvious error message and dual package definition oversight. Ok, so I've moved the file out the way. The rebuild was super quick and the hash is the same as mine was before. Not like yours. The game also doesn't run any further than before (not at all). <bluekeys>Is there like a make clean I can do to the guix checkout to get rid of any old packages and force a full rebuild? <nckx>bluekeys: Could you paste the full error log? <nckx>bluekeys: You can ‘make clean-go‘ and rebuild from scratch (including ./bootstrap, in a guix environment guix) but it really shouldn't be necessary. <nckx>bluekeys: Thanks. Run ‘rm -rf ~/.local/share/trigger-rally’ and try again. You might be running the correct package with an old configuration file, although I think that should still work. If it still fails, with the same 4 bogus paths, we know that you're not running ‘my’ version of the package. <bluekeys>Ok, I found a bug... I ran the app once, saw the menu screen, clicked quit and then made a "funny" here (brb driving). I then went to run the game and received the same error as before, which was then fixed by rm -rf again. <nckx>bluekeys: Nope, got it in the mean time, too. I was running it in a clean environment every time. It breaks successfully for me if I keep the config file around >_< <nckx>‘if (!PHYSFS_exists(cfgfilename.c_str())) {’ in src/Trigger/main.cpp is the problem. It's a bit weird: if there's no ~/.local config file yet, set some (sane) defaults, copy the skeleton config file from /bin to ~/.local, then load it, augmenting the sane defaults. That works. But if there is a ~/.local config file, it's loaded directly, *not* merged with sane defaults, so the same file behaves differently depending on where it was loaded from… <nckx>Where's that table-throwing fellow when you need it. <nckx>So all this could have been avoided if I'd just bit the bullet and updated tinyxml2 instead. Hint taken, universe. <nckx>‘Update more packages, nckx’. <bluekeys>Now what is he throwing? My font is showing missing chars? <nckx>‘bump’ upside down. Unicode still a problem on Guix, I see. <bluekeys>hehe my font is fira code, will that make a difference? I'm using erc <nckx>bluekeys: I have perfect Unicode support on all of Guix System… except emacs. I just gave up. <nckx>Whenever I need to edit a file with emojos (e.g. my i3status config), I must run ‘emacs -nw’ in termite instead. <nckx>bluekeys: I'm still getting the same yes-then-no behaviour on .1. Where did you read that it was fixed? <bluekeys>Sorry, no I didn't read it. It was a question. Is it fixed. I assumed you had the code already, so would check! <nckx>But at least updating tinyxml2 was trivial so I'm back where I started with the latest version. <nckx>bluekeys: Maybe. It was certainly ‘suprising’. I'm going to write a patch anyway (this is beyond substitute*), I'll go ahead & submit it upstream. <bluekeys>This has been fun. I learnt about guile packages and modules and have a working guix dev env configured now and a better feel for the flow of things here thx guix <nckx>bluekeys: That's wonderful to hear. <bluekeys>nckx: You have all the working code for the latest version, I'm going to jump back to planet-libre and find something else to try and break. Did you say I should do a guix clean-go to reset my environment? Or can I git checkout -- HEAD and then pull again? <nckx>OK, with a patch to move those lines to an (IMO) more logical place, *and* the substitute* to change /usr to /gnu/store… (because we can't do that in a patch), the game works every time. <nckx>bluekeys: I wanted to explain how you'd do a full clean if necessary, but it's hardly ever necessary. Just git reset --hard to guix upstream && guix environment guix -- make should suffice here. <bluekeys>OK, I'll forget the full clean for now and work with the git reset. <nckx>bluekeys: Re-building everything should only be necessary when the guix package ABI changes. This does not happen frequently, and you won't be doing so yourself just yet. <nckx>bluekeys: https://en.wikipedia.org/wiki/Application_binary_interface. In this case, the convention of which byte in the package record (like a struct in C) corresponds to which field. If the number or nature of package fields (like name, version, build-system, …) change, code that still uses the old convention will read from the wrong memory address. <nckx>(There's a bit more to it than that, but there's the gist.) <bluekeys>In future, is it worth using local branches? <bluekeys>I'm a fan of gitflow, would that approach help or hinder here? <nckx>bluekeys: I can't say; I'm not familiar with gitflow. git checkout my-WIP-foo-branch && guix environment guix -- make should work fine, though. *nckx uses git worktrees for heavily divergent stuff to avoid the speed penalty of recompilation when switching. <nckx>Like branches with more state, and all the precious Guile object files preserved. <efraim>I normally keep a worktree for staging and core-updates <nckx>‘Interesting idea but how about first imma rebuild qtwebkit okay??’ — guix, today, on everything :-/ <nckx>How about maybe let's not. <davexunit>there should be a git hook on savannah that prevents pushing to master when the commit causes any webkit package to rebuild ;) *nckx rebuilds all dependents of anything they push, promise. <nckx>(Not that I explicitly check for *webkit, but the burn marks on my lap would be a helpful red flag.) <nckx>Why not? It messes with me. <str1ngs>I just got away from having to rebuiding one browser component every other day! :P <nckx>Wish the world would follow that advice. <str1ngs>that's funny. sadly its webkit or qtwebengine. believe me I have tried to find alternatives :( <nckx>It's like a parody but less funny. <str1ngs>unless you are a masochist and want to use XUL lol <str1ngs>you can choose this crappy browser component. or this crappy browser component. what's your choice sir? <str1ngs>though I might play with firefox's servo but then that's rust so... <nckx>‘Which one has substitutes.’ <nckx>I'll have what she's having. *nckx iz built webkit \o/ <ngz>Hello. Does the graphical installer generates the system declaration in "/etc/config.scm"?