<dftxbs3e>cbaines, by the way, sourcehut has that thing where it can send emails through the web interface for you intuitively <dftxbs3e>cbaines, powerpc64le-linux agent started! :D <dftxbs3e>anyone knows about the Nix importer works? Never could make it work. <ngz>dftxbs3e: the truth is it doesn't. <ngz>I think it will be ditched at some point. <lfam>We should remove it before the next release. It's been broken for longer than things should stay broken in Guix <ngz>There's a "~1.2" in a Cargo.toml <ngz>That does not bode well <ngz>I just need to fix that ~1.2 thing, and I'm good to go. <dannym>How do I set how many builds are done in parallel? <dannym>I have 16 cpus and guix build seems to use two of them at most to build stuff... <lfam>dannym: The guix-daemon takes this option as well, to set a default <ngz>error: failed to run custom build command for `libgit2-sys v0.12.17+1.1.0` <ngz>Bah, I give up for today. <lfam>Sounds like you've done enough for one day <dftxbs3e>Somehow it seems that the "nobody" account cannot access /gnu/store <lfam>dftxbs3e: That's surprising. /gnu should be world-readable <dftxbs3e>how would I provide coreutils & co at runtime to a package that invokes various shell scripts? <lfam>The coreutils should be found in $PATH, right? <dftxbs3e>lfam, well yes, but will it always? For testing I'm using a --pure environment <lfam>I guess it depends on what kind of system you want to use the scripts on <lfam>The --pure environment is not similar to a real operating system <dftxbs3e>lfam, so it's OK if it doesnt work there? Should I use propagated-inputs then? <lfam>You could do `guix environment --pure foo --ad-hoc coreutils <dftxbs3e>lfam, yes but I'm writing a package so I want to make it robust <lfam>Right, but what kind of operating system doesn't have coreutils? <dftxbs3e>GNU Guix typically it doesnt always have coreutils in PATH in all scenarios, does it? In shepherd services? <dftxbs3e>Isnt the goal to have self-contained packages? <lfam>Yeah, but it sort of falls apart with shell scripts <dftxbs3e>Do you think propagated-inputs is good to use here? <lfam>I would grep for ",coreutils" in gnu/packages and look at the existing examples <lfam>By propagating coreutils, your package's coreutils dependency will "override" the system coreutils when users install your package <dftxbs3e>I'm not going to rewrite their shell scripts <lfam>Oh, my bad. I thought it was your own program <dftxbs3e>Would a wrapper with wrap-program be more appropriate you think? <lfam>If it were me, I would ignore the issue :) I assume that coreutils are there <lfam>You might also look in gnu/services to see if other packages / services have to do special things regarding coretuils <dftxbs3e>Some packages like sct explicitly replace all references to individual programs with absolute paths in /gnu/store <lfam>Yeah, I've thought about it some. Sometimes it's really hard to do programatically, since the names of these commands are very generic <lfam>It's not easy to pick out what is a command and what is not in every case <lfam>If you give an example of one of these scripts we might have better advice <lfam>If I were reviewing a package that is like sct, I wouldn't ask the author to remove that 'fix-sctd-paths' phase. But it seems unnecessary to me <lfam>I wouldn't expect the functionality of these commands to change <lfam>It looks like it is conservative in what it expects to use. find, grep, sed, that kind of thing <lfam>It I was doing the work, I would try to avoid statically binding these dependencies, and instead find them at runtime <dftxbs3e>lfam, to give an example, gnome-keyring depends on gcr at runtime for prompts, it's not in propagated-inputs of gnome-keyring, result I was stuck with a non-working gnome-keyring and has to debug obscure errors until finding out. <lfam>Yeah, things like that, that are not part of a standard GNU / Linux, you have to do something about them <lfam>If it's easy to patch the full store path to gcr with a regex, I'd do that using substitute* <lfam>Propagation would be fine too <lfam>You'll probably have to do something about dmidecode, for the script you linked to <lfam>They don't make it easy to patch: dmidecode="$(command -v dmidecode)" <lfam>It's almost always preferable to wrap <lfam>The way that propagation affects profiles is kind of limiting <dftxbs3e>Would be nice having an easier way to wrap <lfam>If you don't know Scheme, it's a big step up from a standard package definition <lfam>So, even though propagation isn't the first choice, the most important thing is to get your code working <lfam>It can be polished later <lfam>It's not productive to spend too much time struggling with some obscure syntax *raghavgururajan peeps in <pkill9>is there a lightweight launcher packaged similar to synapse that is extensible with plugins? <pkill9>oh synapse isn't packaged, that's something else <pkill9>what i want really is to have apreview of actions i can take on a given launcher item <dongcarl>Getting this error: guix time-machine: error: Git error: cannot locate local branch 'origin/keyring' <dongcarl>However, the git-url specified has a keyring branch... <dongcarl>Ah it's the libgit2 bug vagrantc ran into <nalaginrut>hi folks, I've installed guile3 with guix and it works. However, the pkg-config always complain it can't find guile. How should I tweak it? <nalaginrut>oh, it's fixed after I install pkg-config. Well, it looks a little weird since I saw a pkg-config in guix path, hmm... <nalaginrut>I'm going to release Artanis these days, and it only support guile3. And I wonder if guile-dbi related packages have guile3 support. ***pocketroid_ is now known as pocketroid
<efraim>dftxbs3e: still building toward cmake-minimal, up to automake test suite now <efraim>at some point I'm going to need to bisect guile and see what makes newer versions fail <dftxbs3e>efraim, okay! it's minor versions but actually many things were added <brendyyn>anyone got guix running with a radeon 6800 xt or similar (newer amd graphics card)? <sneek>Welcome back brendyyn, you have 1 message! <sneek>brendyyn, bdju says: yep my obs has icons <brendyyn>i just installed, selecting GNOME. and it boots to setting up setuid progams in ... and then hangs. nothgin works except for ctrl-alt-backspace which reboots. maybe gdm is failing to load? <pkill9>there was a recent security fix for sudo due to a setuid thing, maybe it has something to do with that <sundbry>I am usuing the nongnu kernel for the amd firmware <sundbry>look at yor dmesg its proabably full of linux refusing to load gpu firmware <brendyyn>there was i think. cant it work with linux libre? <sundbry>no i tried i evenhave a system76 no luck <sundbry>mine would just freeze the whole display as soon as X started <brendyyn>system76 is not libre friendly at all. its just a company that uses linux with all the proprietary stuff for nvidia etc.. <sundbry>yes I was disappointed I was hoping the whole stack would be linux-libre friendly. <sundbry>I also needed to access the intel wifi firmware on the nongnu linux <brendyyn>i bought a system76 laptop but i took the wifi card out to replace with a thinkpenguin on so it all works. for the desktop i got some random wifi card from the shop and it worked somehow <sundbry>one fun thing about my config up there is I mount /gnu on a separate spinning hard disk so it doesnt fill up my ssd <brendyyn>id be happy if it could work with linux-libre even if it has poor perfomance. since i have an amd cpu too there is no integrated graphics to fall back to either <sundbry>if i were you i would get a baseline working with nongnu linux so you can at least get your desktop running, then experiment with libre configs with a fallback to the nongnu system <brendyyn>raghavgururajan: no just setting up setuid <raghavgururajan>brendyyn: Ah, then I don't think the freeze is related to gdm or x or graphics. <sundbry>you can probably get into your machine with SSH <brendyyn>any other magic buttons i can press? currently i can't do anything besides reboot <sundbry>Thats how I was able to diagnose my system to get it booted <sundbry>it sjust the display stack that's FUBAR <brendyyn>sundbry: that would happen after setuid programs are set? <raghavgururajan>brendyyn: Before installing Guix, did you guix pull on the live media? <sundbry>in all likelihoold your system is finished booting just gdm crashed <sundbry>Look on your router or nmap your subnet <raghavgururajan>brendyyn: Ah okay, the 1.2.0 installer was released before changes to setuid programs. <brendyyn>does the graphical installer do a guix pull? <sundbry>command line install is actually easier once you partition your disk and write a config.scm just mount /boot/efi and /mnt then `guix system init /mnt /etc/config.scm` <sundbry>with some steps in between you can guix pull if you follow the guides <brendyyn>so its easier after you do the hard bits ;) <sundbry>well its easier than gentoo lol as far as I remember <sundbry>I had to run thru the graphical config over a dozen times before I gave up and wrote config.scm <sundbry>if the ssh is up though you should be good to guix pull on the live system and reconfigure with the compatible kernel without screwing with the installer further <sundbry>i dont know how to boot into a non graphical system if there is a such a grub boot parameter it would be useful <brendyyn>i tried one of those from ~last month but it errored updating substitutes. maybe ill try again with the lastest <sundbry>at this point I would reboot with the live cd and mount the file system to inspect /var/log <brendyyn>sundbry: sounds good. although its all encrypted @_@ <sundbry>you can cryptsetup luksOpen /dev/sdaX <brendyyn>error"Could not find the request build product." <raghavgururajan>brendyyn: Do one thing. Boot into liveusb of stable image (which you already have) and do guix pull. Then do the installation. <brendyyn>raghavgururajan: can i still use the graphical installer? <brendyyn>actually, itd be nice if i could just chroot in and guix pull, reconfigure <raghavgururajan>brendyyn: If you gonna do guix pull on stable image, then you can't use TUI. You have to go into manual mode. <sundbry>chroot *should* work fine as long as you are on a guix host os, you would want to kill the host guixbuild process and respawn it in the chroot <sundbry>it needs the guixbuild users in /etc/passwd /etc/group, you would have to copy /etc/passwd /etc/group from the host into the chroot since there will be no /etc/ files. <sundbry>also /etc/services /etc/hosts are necessary for guix daemon to run in the chroot (I am going off some notes I have here) <sundbry>then run `guix-daemon --build-users-group=guixbuild &` to spawn the daemon and you can run all the `guix` commands from there <sundbry>it is also a pain in the ass to run anything in the chroot without your profile loaded for $PATH so I recommend putting a static busybox binary in your chroot at /busybox so you can spawn a shell <sundbry>you also have to mount /boot/efi in the chroot dont forget that. <sundbry>really the best thing is if you can find the IP address in /var/log/messages then yo dont have to worry about any of that. <Epholys>I'm not sure where to post this, but I just wanted to report a 404 link on the guix website <sundbry>brendyyn: if you take a picture of /var/log/messages or put it on a flash drive /paste bin i coul dhelp you better <brendyyn>the possible bios error thing is concerning <brendyyn>i get some graphical glitches in bios and grub/cli. the top of the screen is cut off and flickering :/ <sundbry>ssh started and you got 10.1.1.170 via dhcp? <brendyyn>yeah but nmap couldnt find it. it finds it when its on the installer tho. ill try boot back in and test it <sundbry>Feb 11 18:08:57 localhost vmunix: [ 22.363358] 0000:0d:00.0: Missing Free firmware (non-Free firmware loading is disabled) <sundbry>Feb 11 18:08:57 localhost vmunix: [ 22.363374] amdgpu 0000:0d:00.0: amdgpu: failed to init sos firmware <sundbry>Feb 11 18:08:57 localhost vmunix: [ 22.363410] [drm:psp_sw_init [amdgpu]] *ERROR* Failed to load psp firmware! <sundbry>Feb 11 18:08:57 localhost shepherd[1]: Service host-name has been started. <sundbry>Feb 11 18:08:57 localhost vmunix: [ 22.363443] [drm:amdgpu_device_init [amdgpu]] *ERROR* sw_init of IP block <psp> failed -2 <sundbry>Feb 11 18:08:57 localhost vmunix: [ 22.363445] amdgpu 0000:0d:00.0: amdgpu: amdgpu_device_ip_init failed <sundbry>Feb 11 18:08:57 localhost vmunix: [ 22.363446] amdgpu 0000:0d:00.0: amdgpu: Fatal error during GPU init <brendyyn>sucks i have to type my luks password in twice in two different keyboard layouts <sundbry>yes its annoying for that reason i only put my home on an encrypted partition <sundbry>The swat team can have my /gnu/store <brendyyn>i might need a second older graphics card <sundbry>just use the normal kernel on your desktop it is wihat it is -_- stick to libre on servers <sundbry>i think the amdgpu driver is open source that runs on your CPU, its just the firmware thats needed inside the gpu <sundbry>and the linux-libre prevents the firmware from loading so you cant just for example load the nongnu firmware package only unfortunately <brendyyn>i want amd to release libre software, not use their proprietary crap <dftxbs3e>brendyyn, I hope that will happen, it does not look close to that though. <iyzsong>dftxbs3e: glad to help, thank you too :) <dftxbs3e>iyzsong, are you looking for other rather trivial patches to review? I have a few pending :-D <raghavgururajan>iyzsong: Holy! Thanks so much for your contribution on xorg-server-service-type. High time! <dftxbs3e>o.o cool! long time seeing this being a bit weird around my system config ***Server sets mode: +cntz
<iyzsong>raghavgururajan: I almost forgot it, as I switched to wayland this year :) <iyzsong>no, I start 'cagebreak' from tty. So no need for 'sx' and 'xorg-server-service-type' now. <jlicht>is there anyone with 'modern' (AVX/AVX2 supporting) hardware able to have a look at patch 46376? I feel that I'm sending Andy on all kinds of arbitrary errands, with no end in sight. <dftxbs3e>iyzsong, cagebreak interesting! What's so nice you like about it? <iyzsong>dftxbs3e: I have been used to the ratpoison keybindings, so it's 'out of box' for me <dftxbs3e>jlicht, how can I help there? Just test the latest version of the patch? <jlicht>dftxbs3e: yeah, but preferably with tests still enabled; the issue with this package seems that running its tests is a bit difficult, so if the tests don't work anyway, it might make more sense to disable them (and provisions to run them) entirely <jlicht>dftxbs3e: tldr: please apply the latest patch, but remove the line that says `(delete 'check)` <dftxbs3e>jlicht, the latest patch seems to run tests but ignore return value <PurpleSym>jlicht: I’ve tried fixing overlapping define’s from NPM’s importer by hand, but this is just not feasible with multiple packages like kind-of, which is pulled in in three different versions by ~20 packages :( <jlicht>dftxbs3e: I derped, my email-refresh-cronjob broke, so I only read up to the one from yesterday <jlicht>dftxbs3e: so never mind, on the entire thing. Thanks anway <jlicht>PurpleSym: sorry to hear that. Just for later testing purposes, which command did you run? <PurpleSym>jlicht: Same as yesterday, `./pre-inst-env guix import npm-binary -r fuse-box` and then I did some `curl -s registry.npmjs.org/is-descriptor | jq '.versions.["0.1.6"].dependencies'` to find out which is the correct version of the dependency. <dftxbs3e>jlicht, I got: Intel(R) Core(TM) i7-1065G7 - it supports AVX-512 <dftxbs3e>Instruction Set Extensions: Intel® SSE4.1, Intel® SSE4.2, Intel® AVX2, Intel® AVX-512 <efraim>../config/test-driver: line 107: 15010 Segmentation fault "$@" > $log_file 2>&1 <efraim>I got a couple illegal instructions also <iyzsong>raghavgururajan: re #46437, sure, what the change to 'qt-build-system' bring? cvassistant built with 'gnu-build-system' seem works for me.. <raghavgururajan>iyzsong: It just noticed that the source uses qt and qt-build-system is relevant built-system. I think when it was packaged, qt-build-system wasn't available. <raghavgururajan>Also, qt-build-system has qt related phases like qt-wrap etc. This would clear the QStandardPaths warning during run-time. <dftxbs3e>iyzsong, lz4 could've been a core-updates thing, it's 310 packages, but may be fine <iyzsong>raghavgururajan: okay, it invoke 'qmake' now, could you try if we could get rid of that too? <raghavgururajan>iyzsong: We still need to invoke 'qmake' manually as the source doesn't provide CMakeLists.txt. <dftxbs3e>iyzsong, docker, wireshark, qemu rebuild due to it I think <efraim>dftxbs3e: i'm good, up to texinfo on powerpc32 <iyzsong>I checked 'emacs' don't need rebuild, so.. do we have a to-go 'core-updates' check list? <efraim>also testing rust on core-updates on aarch64, almost 30 hours into compiling towards it <efraim>it might be after cmake-bootstrap, but i'm specifically building to cmake-minimal, so I haven't gotten there yet <dftxbs3e>iyzsong, don't think so, just 300+ dependents is the usual rule, guix refresh -l <pkg_name> tells you <dftxbs3e>efraim, I am thinking GNU Guix packages so much stuff we can never keep up maintaining each and every of them <dftxbs3e>I am thinking maybe it would be great separating well maintained packages vs best-effort maintained packages, so one user can choose to say "I only want well maintained packages on my system" <dftxbs3e>cbaines, It would be great to have inside Guix Data Service information on when a package was last updated, or how often it is being updated, so one can go over the list of packages from oldest to newest and find the forgotten ones and update them. <dftxbs3e>I believe it would require computing derivations for each and every revision of GNU Guix, which is expensive <apteryx>if you want I could merge a patch that reduces it a further 30%. <efraim>apteryx: building from findutils-boot0 to mrustc is about 30 hours <apteryx>I haven't yet because I was trying to fix something else on top of it, but that's unrelated and already broken on core-updates, I believe. <apteryx>efraim: are you already far into building rust? <efraim>not quite yet, still at python-3.9 <efraim>the test suite gets longer each version <PurpleSym>jlicht: Can I send patches for wip-node-14 to your fsfe.org address? <apteryx>I think you'll have to do some change to rust because currently IIRC it's marked to only supported x86_64 <apteryx>but there's no fundamental reason it should be so, so it should be fixable I think <apteryx>Danny would probably know the reason <efraim>IIRC it was taking a long time to build on the CI and we didn't want to spend all our time rebuilding the same package <pkill9>I wonder how expensive it would actually be to build every single derivation of guix <apteryx>I see. It still take a long time, but it's twice as fast as it used to be. <apteryx>(8 hours instead of 16 on a Ryzen 3900X) <apteryx>anyway, let me know if you hit some bumps <pkill9>I think it wouldn't be so bad if after computing which packages have been updated in a guix revision, you keep the results and delete the derivation, it would just take a while starting form the beginning <pkill9>but once you got that information it's not going to change <pkill9>plus you could just parse the git logs <pkill9>all updated packages have the same style of git message <pkill9>now a more interesting problem to solve would be finding out how often the upstream package gets released, versus the rate the package definition gets updated in guix <pkill9>that would show which packages are more regularly maintained <pineapples>o/ Yes or no — can the latest installation ISO be verified? <pineapples>Well. Anyway, don't I need to trust the official instance of Cuirass to build tamper-free substitutes? From my understanding, the development images are built by it as well, right? <pineapples>Again, I mean the development image of the ISO installer ***pocketroid_ is now known as pocketroid
<jlicht>PurpleSym: are you okay with me upstreaming (some version of) these patches at some point as well, using your name? <PurpleSym>jlicht: Yes, sure, that’s what they are for :) I hope we can get all of this into Guix proper one day. <jlicht>such polite drive-by packaging requests :-) ***ChanServ sets mode: -o apteryx
<brendyyn>for the project founder of all people ;) <bqv>To be fair, even if a request was crazy polite, would anyone here consider doing it? <roptat>to me it depends on the kind of software. If you ask for an update to some ocaml package, I think I'd do it <roptat>at least I'd try, but won't give more than 10 minutes effort if it resists updating <roptat>I'd put much more effort helping that person get the package updated / packaged though <dissoc>has anyone got the guile-emacs package to build and install? i tried it after people here were talking about it and it has been building for a few days now <roptat>that was not exactly the fsf wiki <bqv>dissoc: aiui it's not worth trying <dissoc>yeah. that's fine. it's not like i need it or anything. i was just going to test it out <ngz>bqv: I don't think packaging requests are frowned upon here. But indeed, it is better to learn how to package. <rekado_>bqv: we’ve packaged quite a few things together with the requesters <ngz>I want to skip tests for TeXmacs on i686. Is, e.g., `ghc-bsb-http-chunked' doing it right for that matter? <dannym>I'm merging master into core-updates again since it fixes xorriso. <ngz>I have this package <https://paste.debian.net/1185115/> but when I try to run it, with, e.g., "wob 10", I get an error "Wayland compositor doesn't support all required protocols". Could anyone with a Wayland environment test it to check if it works properly? <pineapples>wob? I was going to package it myself at some point <ngz>I also have gammastep packaged, but I guess that's for another test ;) <dongcarl>Hi all, let's say I'm on an offline computer, is there a way to manually seed a source tarball I need? <pineapples>ngz: That's awesome! I'm looking forward to both of those <dongcarl>E.g. I'm building gzip, and it needs /home/dev/guix/root/gnu/store/vgrx621h8750zm0ijlpdfnd9s4igsakp-gzip-1.10.tar.xz, and I have the file, but I'm offline. <ngz>pineapples: do you want a link for the package definition too? <pineapples>ngz: Do you have a list of modules that both the package definitions need? <ngz>pineapples: not really. I stuffed them into an "incubator.scm" with a lot of #:use-module headers. However, this should not be difficult to list them, at least for wob. Let me see. <luke-jr>on that note, is there a way to get Guix to tell me what files it wants rather than it timing out and me reviewing its log? ;) <ngz>pineapples: (guix packages man) (guix packages linux) (guix packages freedesktop) and (guix packages pkg-config) for wob. <ngz>gammastep is more involved, but I think Guix gives you clues when you try to build it. <ngz>You also need (guix build-system meson) <ngz>and ((guix licenses) #:prefix license:) <ngz>Well, I think you get the idea :) <pineapples>I do. Thank you. I'll first compile and test wob <dongcarl>Given a manifest, is there a command to _just_ download all missing sources for that manifest and not build? <avalenn>Would listing Guix there be a good idea ? <pineapples>ngz: I did 'echo 43 > /tmp/wobpipe && tail -f /tmp/wobpipe | wob <pineapples>Let me incorporate it into my sway config to see if I can have it display the current system volume <ngz>You have a couple examples for Sway in the repository. <luke-jr>can `guix download` just make symlinks instead of copying all the data? <dongcarl>luke-jr: I believe the general thinking is that the "store" should not reference the outside environment <dongcarl>luke-jr: Symlink it the other way around! :-) <luke-jr>dongcarl: especially if we throw away the store after the build <luke-jr>dongcarl: the source could be read-only ;) <luke-jr>I'm thinking of the gitian VM just linking to the read-only network cache <dongcarl>Yeah don't think it's possible right now :-/ *pineapples will be right back <pineapples>ngz: It's working perfectly fine. I really, really needed this on Guix <vagrantc>dongcarl: it's an ugly hack, the tests still fail <vagrantc>dongcarl: so i still have to disable many of the tests ... but without that, it still attempts to download the binaries <vagrantc>dongcarl: the debian/patches directory is somewhat of a nightmare :/ <dongcarl>vagrantc: I see... But all the hacks are in debian/patches? <vagrantc>dongcarl: it's mostly just disabling ~20% of tests through one way or another ... either because of network access or bootstrap binary use <vagrantc>hopefully i'll be able to propose some improvements for the next guix release to avoid most of that <dongcarl>Hmm... So it's the tests that are downloading the binaries? <vagrantc>yes, the tests will download the bootstrap binaries from the network if they are not present <vagrantc>partly due to my request to not ship the bootstrap binaries in the tarball, as this is a violation of debian policy ... so the patch now dynamically downloads them ... through guix, of course, so if they're already in /gnu/store it won't <dongcarl>vagrantc: Okay, so with all your patches applied, the bootstrap binaries are never downloaded, and only the tools you copied in are used? *dongcarl looking through the patch series <vagrantc>dongcarl: i think i still have to disable some of the tests that try to use the bootstrap binaries, as they're not the right hashes <vagrantc>the patches aren't well commented or anything :/ <ngz>pineapples: OK. Thanks for testing! I'll push this in the repository as soon as I find an appropriate place for them. <dongcarl>vagrantc: Okay, let me study your patches! <vagrantc>dongcarl: it's mostly just (test-skip 1) in various permutations :) <dongcarl>vagrantc: Question: if we _don't_ run `make check`, and want the bootstrap binaries we copied in to not get clobbered, do we have to do anything? <vagrantc>dongcarl: my turn to ask a question ... what are you building? the .deb package, or some other non-guix package? <vagrantc>dongcarl: i don't think you need the bootstrap binaries except to run the tests when building from source <dongcarl>vagrantc: We're mostly trying to install Guix on Gentoo in an offline and non-bootstrap binary way. Perhaps make a Gentoo package out of that process. <dongcarl>vagrantc: You're the preeminent expert in this :-) <warren>dongcarl: I didn't join this channel until now. Could you please pastebin what I missed? <vagrantc>dongcarl: i think arch and opensuse had packages before i did :) <warren>Is offline operation already an upstream guix supported option? Download stuff and put it in a directory instead of requiring the network. *dongcarl brain overloading <dongcarl>vagrantc: Yeah, but I'm not sure they have the offline+no-bootstrap-bin policies <narispo>hello! do you guys know of a package with incompatible configure feature switches? As in, they can't be enabled together in any meaningful way? <dongcarl>vagrantc: I'm very happy you took the effort to patch out all those tests though, this is immensely useful. You have my gratitude! <vagrantc>dongcarl: to be honest, i pretty much just built the package, ran the tests, and incrementally disabled test suites until it built <dongcarl>vagrantc: Hey, as long as it works I count that as a win! :-) <vagrantc>attempting to figure out why it failed in the best of scenarios ... and the bootstrap binary thing was basically a network access issue in disguise ... and harder to disable <vagrantc>most of the network tests attempt DNS access and if it fails, it assumes it cannot run the test ... so there's that hack to get glibc to not resolve dns <vagrantc>so the RES_OPTIONS=attempts:0 environment variable hack helps with most of those <vagrantc>but the checks requiring bootstrap binaries aren't guarded with those checks ... <vagrantc>it probably needs a separate variable ... it works in guix because guix-daemon is able to download the bootstrap binaries before the build <vagrantc>or even having guix installed at all, you probably have the bootstrap binaries available <dongcarl>vagrantc: Btw, my colleague is saying that when he tries to `guix install glibc-utf8-locales`, Guix tries to download the bootstrap tarballs, is that expected? <efraim>does he have substitutes enabled? <efraim>otherwise there's a fair amount of building to bootstrap the distro <dongcarl>efraim: Not sure, but he turned off networking entirely <luke-jr>efraim: I won't allow Guix to execute any binary it doesn't compile itself <luke-jr>(and I do fully expect a long build) <efraim>I haven't used gentoo, but my understanding is the bootstrap process is similar to an automated stage1 install. it has to build up to the base level and then it can start compiling everything "for real" <vagrantc>luke-jr: other than the bootstrap binaries? as you can't build anything without them... <luke-jr>efraim: I started without stage1 - but that's another topic ;) <vagrantc>dongcarl: if you use different bootstrap binaries, you won't be able to use the substitute servers as you'll have different hashes for everything <vagrantc>dongcarl: so simply copying the system binaries into the bootsrtap binary locations won't work in the long-run <efraim>dftxbs3e: up to cmake-bootstrap on powerpc32, shouldn't be much longer until cmake-minimal <dongcarl>vagrantc: Hmmm, but I'm guessing that it's possible to do so if one were comfortable with no substitutes forever? <luke-jr>dongcarl: would that also break the determinism of guix-produced bitcoin builds? <vagrantc>dongcarl: i guess coming from gentoo, the idea of rebuilding everything all the time might be comfortable :) <luke-jr>vagrantc: if I don't want 3rd-party bootstrap bins, why would I want 3rd-party anything else? :P <dongcarl>Haha true. Thank you for your time vagrantc efraim, you have been very helpful! <luke-jr>also I'm pretty sure not using /gnu/store for my store path breaks subs anyway <vagrantc>you're unlikely to get deterministic builds if you're building with a different bootstrap lineage ... though you might get lucky <luke-jr>vagrantc: well, we have deterministic builds without guix right now.. <.< <vagrantc>luke-jr: it's getting pretty close to guix having a full source bootstrap, so ... the issue may become moot :) <vagrantc>luke-jr: if you bootstrap everything from source and get the same results as anybody, there will effectively be no bootstrap binary blobs ... there's just bootstrap source <rekado_>it’s good to see all build nodes being busy <pkill9>then it can be fully audited, woo <luke-jr>I need to figure out how to replace the bootstrap bins for a subsequent step anyway >.> <vagrantc>luke-jr: are the deterministic bitcoin builds still done with a very controlled build environment? <luke-jr>(installing on my main machine which isn't x86-64) <pkill9>maybe it will become the first true conceptual virus <pkill9>how long until guix is fully bootstrapped? <vagrantc>pkill9: janneke made a post on it recently to guix-devel <pkill9>when it's fully bootstrapped, guix will ascend to more than software, but an idea expressed in code *raghavgururajan peeps in *dongcarl goes to look at wip-full-source-bootstrap ***rekado_ is now known as rekado
<narispo>efraim: hey, so I will try patching cargo to disable mtime checking for .rlib, maybe that's the issue, since incremental compilation (what .rlib is in part for AIUI) relies on mtime <narispo>And since we reset mtime in the store.. <narispo>efraim: there was quite fruitful discussion with them I could have <narispo>efraim: someone just suggested we could get rid of cargo and use rustc directly, reimplementing parts of cargo within GNU Guix to fit our needs, we could even dynamically link stuff this way. What is missing is build script handling when doing that, so maybe we can rewrite build scripts in Scheme or reimplement that part as well. <narispo>efraim: do you know where the other guy we had spoken conversation with is? <ngz>hmmm. Silly question: how can I tell an executable to look into its own $out/lib directory when looking for a .so? <lfam>Grep in the packages for "-rpath" <lfam>(string-append "LDFLAGS=-Wl,-rpath=" (assoc-ref %outputs "out") "/lib") <efraim>narispo: I think it's in the backlog <narispo>They showed up willing to work it seemed but I've never seen them around here <efraim>they idle in chat, mostly working on getting guix on powerpc64 <narispo>I had their nick given to me but never got an answer from them on it <efraim>well i'm actually off to bed, I'll try to remember who else was there. Using rustc directly is an interesting way of getting around a bunch of the cargo problems <narispo>efraim: Good night sleep well ferris :-D <lfam>PotentialUser-10: Update it to what? From what I can see, it is already at the latest version, 1.14.0 <lfam>I guess the "number" of the potential user indicates their patience <ngz>Ah well. I'm too dumb to package gamemode, it seems =/ <lfam>It's time to crowdsource it, ngz ;) <lfam>Send your work in progress to the mailing list <ngz>:) To which ML, guix-devel? or guix-user? <lfam>To whichever ML you like, really <lfam>"Bug: I can't figure it out" <lfam>"Announce: It still doesn't work" <lfam>"Help: I'm not sure which mailing list to use" <argylelabcoat>is there a way to troubleshoot a "guix copy" to a remote host? <luke-jr>building /home/dev/guix/root/gnu/store/k1z4m06rl4l0mv8gvdykr2slhxjl250h-bash.drv… <luke-jr>so how do I change the hash it expects? <narispo>luke-jr: what are you running? you are getting unexpected hash error? <narispo>luke-jr: you can clone a gnu guix checkout, compile it without installing (see manual), then run ./pre-inst-env guix edit <package> - and you will see the hash there you can replace it and run your command again! <luke-jr>trying to build bootstrap-tarballs now <narispo>luke-jr: what are you attempting exactly? is it powerpc64le related? <luke-jr>just trying to get guix usable on x86-64 without third-party binaries <lfam>A whole screen of bioinformatics jobs in progress :) <narispo>rekado: :-D - seeing machines work is satisfying <luke-jr>I don't see the hash in the source code.. <rekado>luke-jr: the only hashes we keep in the source code are source file hashes <rekado>we cannot know the hashes of derivations in advance <narispo>okay maybe we misunderstood each other, in that case the hash is only used for fetching substitutes and realizing something has already been built <narispo>luke-jr: also what is that /home/dev/guix/root/gnu thing? <rekado>luke-jr: not sure if that’s on purpose, but do note that using a store directory other than /gnu/store means that you cannot use any of the binaries that ci.guix.gnu.org (or anyone else) builds. <dongcarl>rekado: He intentionally doesn't want it :-) <dongcarl>luke-jr: Okay gnu/packages/bootstrap.scm is what you want <luke-jr>dongcarl: but the hash isn't in there..? <rekado>also note that the store prefix should not be too long <dongcarl>luke-jr: I'll talk to you in another channel <pkill9>the nice thing about guix is i can drop in and out of doing stuff with it and it's very stable and I can update whenever without breaking things <narispo>I never used a rolling release distro before so I guess I don't even know how the instability is like 