<PotentialUser-39>Just to check if i did everything right: i made a 1gb partition in cfdisk with EFI system as its type, then i marked it with esp in parted, then i mounted it in /mnt/boot/efi and proceded with the installation <raghavgururajan>PotentialUser-39: Please consider asking in the help-guix@gnu.org mail-list. You are likely to get help there. <alextee[m]>is there a way to find the store path of something installed as a propagated input? <leoprikler>alextee[m]: Not directly, but what about parsing the profile manifest? <PotentialUser-39>That will be a problem since it is in the computer, i will try to get a photo <alextee[m]>leoprikler: that's hacky, should probably be a way to do it with guix package <leoprikler>maybe there's a weird incantation of guix graph I'm missing <stikonas>mekeor: well, you'll need to do some manual setup first, raspberry pi needs non-free software to boot <mekeor>stikonas: do you know which non-free software-packages i'll need and if there are existing guix-package-declaration for those? and if so, could you share them with me, i guess privately? :) <stikonas>I don't know if there are any guix-package-declarations for that videocore bootloader stuff. Probalby search engine would know more... <morgansmith>So my school wants me to use virtual box and I was quite surprised to see that it's not packaged. Is there a specific reason it's not packaged or is it just that no one has done it? <OriansJ`>morgansmith: well kinda both ways. No one had a reason to do it yet (just like no one has yet packaged open-vm-tools) and virtualbox depends upon the non-free "Guest Additions" <morgansmith>cool. I'll see if it's hard to package. If not I'll package it and send it in for review. If there's no way to get it in, I'll give it to nonguix. <roptat>finally managed to build antlr4 with its tests <roptat>(I was planning on updating groovy, and the new 3.0 versions require antlr4) <raghavgururajan>guix system: warning: cannot determine provenance for current system <roptat>\o/ sent! now I can go to bed, although pretty early ^^' *apteryx pushes an update to QEMU 5.1.0 <apteryx>enjoy the full QEMU documentation as 'info qemu' :-) <raghavgururajan>During make, I get "ld: libstore.a(libstore_a-local-store.o)(.text+0x10000000749): reloc against `_Znwm@@GLIBCXX_3.4': error 4" <apteryx>raghavgururajan: perhaps run 'make distclean', start the bootstrap over <apteryx>are you in a 'guix environment guix' ? <raghavgururajan> /bin/sh: line 7: 26757 Segmentation fault XDG_CACHE_HOME=/nowhere host=x86_64-pc-linux-gnu srcdir="." <apteryx>I can bootstrap & configure in 'guix environment guix --pure' here <apteryx>using guix master 0996fcc657593955845c2761d7eb0f656149fe11 as the main guix command (the one that spawned the guix --pure env) <raghavgururajan>I added `(extra-special-file "/usr/bin/env" (file-append coreutils "/bin/env"))` to service list of my system config.scm recently, would that affect anything? <apteryx>nope, but that's unnecesseray because it's already part of %base-services <raghavgururajan>apteryx: I don;t it is. only (special-file is part ot base-services, not extra-special-file? *raghavgururajan did `guix pull --roll-back` and retrying bootstrap <mroh>segfaults from g++ are often ram or other hardware problems. Can you compile other things? *raghavgururajan restarts the system <raghavgururajan>In my previous boot, I booted with iomem=relaxed, as I was flashing my ROM. <bdju>seems like there's no man page for awk <apteryx>janneke: do you think bumping the version of xz in the bootstrap-binaries would be feasable? How would I go around this? <raghavgururajan>Now, I just keep getting "/bin/sh: line 7: 28836 Segmentation fault XDG_CACHE_HOME=/nowhere host=x86_64-pc-linux-gnu srcdir="."" <janneke>apteryx: yeah, don't do that for too long unless you're having fun with it ;) <sneek>Welcome back peanutbutterandc, you have 1 message! <sneek>peanutbutterandc, guix-vits says: maybe it's a "zip-bomb"? re: "Hey there, what does it mean when a build fails at 'unpack phase? ... error 127". <janneke>apteryx: you could...but usually we don't want to update bootstrap binaries unless there's a pressing need? <peanutbutterandc>guix-vits, Yes! It was a zip-bomb! How do I deal with those? Do I invoke something myself? (invoke "gzip" "that thing" "name")? Or something? <janneke>apteryx: have a look at gnu/packages/make-bootstrap.scm; in %static-inputs there's xz <peanutbutterandc>Okay... so crossguid is lib/libcrossguid.a and include/guid.h, perhpas that has something to do with this <raghavgururajan>mroh: You were right. It was indeed my RAM. I took one module out and make is working fine now. <Brendan[m]2>I'm trying to package something that requires an -alpha2 rust package. it errors with "prerelease package needs to be specified explicitly". Any idea how to make them behave? <Brendan[m]2>Actually, turns out I'm a big dummy. there is a lower major version release i think works <mfg>is there a place in guix where files are stored which are just copied into a build? <peanutbutterandc>Question: I've been seeing a lot of guix.scm in quite a few repos. Like this one: https://termbin.com/vgbp and I know that it's supposed to be used with `guix environment -l guix.scm` to start up a build/dev environment. But this particular guix.scm file does not work. Am I missing something? <peanutbutterandc>wait... neither does the guix.scm in the guix repo works for me with `guix environment -l guix.scm`. Educate me please. <mfg>peanutbutterandc: -l evaluates that file, i think this is not what you want <mfg>or --manifest i guess <peanutbutterandc>mfg, I see. It works for the first one (it seems to be working) but not for the guix.scm in the guix repo.... <peanutbutterandc>Am I correct in assuming guix.scm files are used to generate a build/dev environment conveniently, and are supposed to be used with `guix environment`? Or is there some other purpose? o.O <mfg>If you look into such files and see *->manifest i would assume it's a manifest. In the guix repo i don't see anything like it, so i guess it has another purpose <mfg>But: ig you want a dev environment for guix just use guix environment guix <peanutbutterandc>Yes, precisely. Which is why I'm a bit confused as to the use of guix.scm file <mfg>the manual says: guix environment guix --pure <mfg>i always name those files `manifest.scm` <peanutbutterandc>mfg, This is strange.... I just did `guix environment -m guix.scm`, and the manifest does contain guile-syntax-highlight, but running `haunt build` fails because it can't find it.... <mfg>i'm trying it out currently <mfg>Got it: either you change to guile3 or you have to use the guile2.2-syntax-highlight package in the manifest :) <mfg>built successfully with the latter here <mfg>otherwise it's installing the guiile3 version and guile2.2 obviously doesn't find it <peanutbutterandc>I'm surprised how often the errors I encounter are such minor issues (and how I can't see them staring me right in the face). Thank you very much! <peanutbutterandc>Oh... it seems that the Makefiles and friends refer to guix.scm. So, perhaps not really for `guix environment` (?) <mfg>The comment says it's a composite module that re exports every publicly defined modules, so i guess it's a shortcut of importing all publicly defined guix modules? But i'm not sure i don't know the source that good... <peanutbutterandc>I see... That comment line: it's all greek to me. Anyways, thank you very much! <peanutbutterandc>I have learned something new today: if guix.scm has (manifest) then I go for -m, else, I go for -l. <peanutbutterandc>It seems that manifest is used for --ad-hoc packages, whereas -l for spinning up a build environment for the packages specified. <mfg>i just recently started to use those features of guix and they are really to nice to not be using them :D <mfg>even though guix doesn't have all the packages it makes so much fun to use it! <peanutbutterandc>Yes, guix is super fun. I have been loving guix ever since I actually figured out how to use it. (: <Brendan[m]2>I'm taking on a new challenge. To write a Guix service for a greeter: greetd. <Yasu>Is there any video meeting of Guix users? <marusich>peanutbutterandc, some guix commands can load files as input. For example, as you know, "guix environment -l foo.scm" will drop you into an enviornment in which the inputs of the package defined in foo.scm are available. <marusich>This fact is documented in the manual in section "Invoking guix environment": "Create an environment for the package or list of packages that the code within FILE evaluates to." <marusich>The file can be named anything. By convention, some people choose to use the name "guix.scm". <marusich>Other commands expect the file to contain different stuff. For example, although "guix environment -l foo.scm" expects foo.scm to be Guile code which evaluates to a package, the command "guix package -m foo.scm" expects foo.scm to evaluate to a manifest, which is not the same as a package. <marusich>So in general, the name of the file doesn't matter, and the expected contents of the file depend upon what command you are using. <peanutbutterandc>marusich, I see. I was wondering what the use of guix.scm in the guix repo is.... <marusich>Do you mean the guix.scm that appears in the root of the Git repository? There are 4 guix.scm files in various locations in the repository. The one at the root exists as a convenience, so you can import the (guix) module and get a lot of common modules easily in Guile. <marusich>For example, if you're in a Guile repl with access to the Guix libraries (e.g., by running "guix repl"), you can just run ",use (guix)" and you'll have access to all the usual things. For example, the %current-system procedure. Normally you would have to know that %current-system is exported by the (guix utils) module, and then you would have to run something like ,use (guix utils) to make it available. <marusich>Sure thing. Sorry for misinterpreting your question earlier! <peanutbutterandc>So, the way to figure out what guix.scm files are --- beyond knowing that files containing (manifet are to be -m-ed with `guix environment` and files just listing a package are to be -l-ed --- is to be familiar with guile and stuff, too. <peanutbutterandc>But in general, guix.scm-s are to be used with guix environment. And are either to be --manifest-ed or --load-ed. <marusich>That's probably true in most cases, yeah. <peanutbutterandc>Hmmm.... I think I'll try to create a guix.scm for a few of my own repositories, then, now. :D <marusich>My goodness, I have tried about 5 times to "guix pull" from fresh installs of the last couple Guix releases on fresh Debian and Fedora machines, and I have to say it has been quite rough. <marusich>I cannot get "guix pull" to succeed even once. <marusich>The 1.1.0 release cannot "guix pull" without substitutes because tcc-boot0 fails to build. <marusich>The 1.0.1 and 0.16.0 releases both cannot "guix pull" without substitutes because python-minimal fails to build. <marusich>Does any release actually build successfully without substitutes? <marusich>I've tried a machine with 4 cpus and 8 GB of ram, and another machine with 4 CPUs and 32 GB of RAM, so I'm fairly confident it isn't a problem with too few resources. <cbaines>I think some things fail to build reproducibily with multiple cores, so that could be an issue <cbaines>do you happen to have the derivation names to hand for those failing builds? <peanutbutterandc>I remember someone suggested that for me once for a package that wasn't building. <peanutbutterandc>Also, a 'foreigner' here, too. But for my 4 core machine, `guix pull` did succeed. For the latest release. <marusich>0.16.0 release cannot guix pull without substitutes due to failing build: /gnu/store/f98gcg2vl9jga7a97r2rqlz3mzbqhzpl-python-minimal-3.7.0.drv <marusich>similarly, 1.0.1 release cannot guix pull without substitutes due to failing build: /gnu/store/6hpqhrgrmgh9ra4fh6nv2myh59c9c8mr-python-minimal-3.7.0.drv <peanutbutterandc>Ah! "cannot pull WITHOUT substitutes". I missed that part. Sorry I misunderstood. I haven't tried pulling without substitutes yet. <marusich>similarly (but due to a different derivation), 1.1.0 release cannot guix pull without substitutes due to failing build: /gnu/store/ssj7xx3q05l4b84iyzrc90rdw79c90b3-tcc-boot0-0.9.26-6.c004e9a.drv <marusich>I wonder to what extent the binaries provided by the build farm are carried over incrementally from commit to commit between releases. I wonder if anybody is actually testing whether we can guix pull without substitutes from the release. <cbaines>I wouldn't quite frame the problem like that, but with Cuirass, it just builds each output once <cbaines>that's OK for providing substitutes, but not great for doing continuous testing <cbaines>for testing purposes, you actually want to build each derivation multiple times, across a range of hardware, and check you get consistent results <rekado>if it’s the same derivation why would it make sense to build it again? <marusich>Yeah, it feels like maybe some derivations that got built successfully in the past are carried forward even if they become unable to be built in the future. <rekado>if it’s the same derivation, why would they become impossible to be built later? <cbaines>Say you've got a single core x86_64-linux machine, and one with 32 cores. If you build the same derivation twice on each machine, you might notice that it fails consistently on one machine, and not the other <cbaines>I've encountered and fixed/worked around those kind of issues with Guix packages, often when it fails to build with multiple cores, but definately one odd case when it only could be built with multiple cores (the more the better) <cbaines>if all derivations are perfect, build with bit for bit reproducibility across a range of hardware meeting some minimum requirements, then you don't need to build them more than once. <marusich>The derivation in that bug report is even "the same", except for its hash. <cbaines>but the only way to find out if that's the case is to test, and that does require building derivations again, even if they built the first time <marusich>Again, same derivation, except for the hash <marusich>I thought perhaps my machine was too weak to build it somehow, so I increased its memory from 8 to 32 GB, but i still got the failure when i tried again. <rekado>what does “same derivation, different hash” mean? Doesn’t this imply that different tools are used? <marusich>I mean that the name of the derivation is the same, down to the version numbers, which implies that probably the inputs changed but the package didn't. All I mean is, it's very similar. <marusich>What are the specs of the build farm machine that usually builds these substitutes? <marusich>how many cpus and how much memory does it have? <marusich>regarding the python-minimal failure, i'll try building with --cores=1, since I haven't tried that yet. <cbaines>for python-minimal, I managed to build the first of the derivations you mentioned with multiple cores <cbaines>I think I've definately encountered issues with python-minimal though <marusich>i'll just try more cores, i guess. we shall see if that helps. <marusich>this is for derivation /gnu/store/f98gcg2vl9jga7a97r2rqlz3mzbqhzpl-python-minimal-3.7.0.drv btw <cbaines>although that mentions >= 3.10, and I'm running 5.2.21 <cbaines>but that's something that might cause different behavior <cbaines>Given you're building on Debian and Fedora, it might be good to pick some other distros and continuously test building all packages on them, to see if there are any weird issues that just crop up on other distros <marusich>Is that a ppc specific bug though? I'm building on x86_64-linux <mfg>How do i create and populate a file in a build-phase? i tried (call-with-output-file "file" (lambda (port) (display "text" port))) but the file doesn;t get created. Is there anything special i have to pay attention to? <cbaines>that's probably what the reports about, the issue looks similar though <mfg>or is there a guix helper function for such a thing? <marusich>crossing my fingers that building with 16 cores helps. i doubt it will, but at this point i'll take what i can get! <cbaines>marusich, is this /gnu/store/f98gcg2vl9jga7a97r2rqlz3mzbqhzpl-python-minimal-3.7.0.drv ? <peanutbutterandc>Am I wrong to expect `guix environment --ad-hoc emacs-dumb-jump` to extend EMACSLOADPATH just like it extends PATH normally? <cbaines>I'm not sure python-minimal respects the --cores= argument for the test phase <cbaines>when I pass in --cores=1, it still seems to run with all cores <cbaines>peanutbutterandc, you'll need emacs in there as well, since that's the package which actually describes the search path, see: guix environment --search-paths --ad-hoc emacs emacs-dumb-jump <peanutbutterandc>cbaines, I see. That makes sense. (I didn't think of adding emacs there as I already had emacs) Thank you <guix-vits>peanutbutterandc: I'd seen a few of '(method url-fetch/tarbomb)' and '(method url-fetch/zipbomb)', when grepped gnu/packages/*. IDK how to deal with it myself. <marusich>cbaines, what about /gnu/store/ssj7xx3q05l4b84iyzrc90rdw79c90b3-tcc-boot0-0.9.26-6.c004e9a.drv ? do you know anything about that derivation...? it is the one i could not build on debian when guix pulling without substitutes from the binary guix 1.1.0 release <marusich>it also failed on fedora, as i recall, following the same steps. <cbaines>I'll try again, I think it builds for me <peanutbutterandc>guix-vits, Ooooh. That is cool! I got through that particular error. Thank you very much! <guix-vits>peanutbutterandc: Thank U for master Foo stories. <marusich>my goal here, by the way, is just to build enough stuff, without substitutes, to be able to compile guix from source. <marusich>i already tried running 'guix environment guix' from the releases, and it fails in similarly frustrating ways. <marusich>hence the reason why i tried to do guix pull <marusich>i am trying to verify that %gcc-static cross-builds for powerpc64-linux reproducibly with some changes i've made. that's why i'm being particular about not using substitutes. <marusich>cbaines, rekado python-minimal failed on intel but succeeded on amd cpus. <marusich>Specifically, /gnu/store/f98gcg2vl9jga7a97r2rqlz3mzbqhzpl-python-minimal-3.7.0.drv (involved in doing 'guix pull' from guix's binary 0.16.0 release) fails to build on an EC2 c5.xlarge, but it succeeds on a c5a.xlarge. The former is intel, the latter is AMD. <marusich>Guess I'll switch my instance back to intel and hope nothing else funky happens while I finish "guix pull"ing. <marusich>it's possible i got lucky somehow and it wasn't because the cpu was amd vs. intel, but i suppose i will find out when i try again on fedora. ***terpri_ is now known as terpri
<marusich>anyway, hopefully it'll work. i'm going to sleep because it's super late. <peanutbutterandc>Okay.... for a package that uses gnu-make-system but a completely different compiler, where do I add the compiler? (native-inputs)? or (inputs)? <leoprikler>If used during build (e.g. during 'make check') they also need to go to native-inputs <mekeor>hello. i ran `guix package -i glibc-locales`, added `export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"` to my .bash_profile, and i re-logged into bash, and i checked `echo $GUIX_LOCPATH` and `guix package -I`, but when i run `guix pull`, i still get the "guile: warning: failed to install locale. hint: Consider installing the `glibc-utf8-locales` …" warning. why? <peanutbutterandc>mekeor, It is because the guix-daemon, that runs as root, does not yet have GUIX_LOCPATH set (or glibc-locales installed) <peanutbutterandc>mekeor, To fix this, log in as root `sudo guix ...` seems to be a bad idea to me: the last time I did that, I ran into trouble. Install glibc-locales. And then export the variable. <peanutbutterandc>Maybe I didn't write that clearly enough. The "warnings" are from the guix-daemon. Which is running as root. The 'root' user's guix profile does not yet have glibc-locales installed. Neither is the GUIX_LOCPATH set in the environment where guix-daemon is currently running. Hence the warning. <mekeor>peanutbutterandc: ah, thank you! :) <peanutbutterandc>mekeor, You're most welcome, fellow 'foreigner' (those of us using guix on top of other distros, as opposed to using guixSD)! (: <mekeor>but nice to meet you anyway, peanutbutterandc :D <mekeor>peanutbutterandc: i installed glibc-utf8-locales as root and added the variable export to ~root/.profile but it didn't help to get rid of the warning :/ <mekeor>peanutbutterandc: i also did reboot <peanutbutterandc>glibc-utf8-locales is a small subset of glibc-locales, and perhaps you are on a locale other than the one contained in the small subset? <peanutbutterandc>My battery is dying (power outage here). I'll have to go. All the very best with your work. <mekeor>mfg: comparing it to other similar code snippets in the guix-repository, i can't find thing suspicious. LGTM <mfg>i don't understand it :D if i use "glversion.txt" as the filename it gets correctly created in the top dir chdir write chdir also results in a non existetent file <mfg>with-output-to-file doesn't support relative paths i guess ***dddddd_ is now known as dddddd
***deesix_ is now known as deesix
<mfg>okay i'm giving up on it, i don't understand the error, and i don't know how to debug it :| <Yasu>Has anyone tried compiling NVIdia proprietary video card driver for use with Guix? I wonder how easy it would be when I get around to do so ***testfff is now known as test3f
<roptat>hi Yasu :) even if people had done that, it would be off-topic for the official communication channels of guix ;) <Yasu>Great I have fathered information - thank you @roptat and eveybpdy! <Yasu>But its insane that we cannot discuss - can't we simply agree yo call it guix-inferior or something or postfix with something like -obscene and be done with it? 😅 <mfg>Yasu: how does renaming change the contents? <Yasu>@mfg no it won't 😅 - I think it could be counter-effective if I am forced to use Windows just because of the video driver issues... <Yasu>But I do appreciate FSF philosophy - I even put DeleteFacebook disclaimers all over the place including my homepage 😄 <roptat>Yasu, btw guix inferior is an actual concept <roptat>an inferior is a guix from the past (or the future) you can talk to through your current guix <mfg>Yasu: you are not forced to use guix as your distro you can also just decide to use it as a package manager on a foreign distro... <roptat>and pushing our users towards non free software is against our principles, so we don't want to talk about any specific non free software <roptat>we could talk about non free software in general though <roptat>I mean, we can say that in our view, non free software are bad and such things .) *roptat is half-blind apparently .p <Yasu>Yes, it seems having a separate channel is a good compromise and I really appreciate the fact this community seems very principled 😄 <mfg>Yasu: i see, i know that issue. <Yasu>Besides, I cannot go back to non-declarative OS (that would be as painful as dealing with poor video performance) 😅 <mfg>Yasu: i feel you. What is your use-case for the graphics card anyway? <mfg>rendering? machine-learning? <Yasu>and video-chat and pair programming <mfg>doesn't some integrated intel chip do the trick? <mfg>at least it has good open driver support... <Yasu>Well I have just bought a new AMD motherboard and CPU 😅 <Yasu>The IceCat rejection of all the bad JavaScripts makes me feel delighted 😄 <Yasu>I am really starting to like Guix <mfg>it also makes every site i use faster without missing functionality :D <Yasu>I checked the Japanese govt web site a few hours ago and IceCat pointed out some facebook javascripts embedded?? isn't this a conflict of interest? <civodul>mbakke: did you or anyone tried switching to GCC 8 or 9 before? <mfg>so as i see it plain-file is defined in (guix gexp), right? so i need to #:use-module it? i tried it and i still get unbound variable: plain-file errors, is there a restriction on where it can be used? ***ChanServ sets mode: +o civodul
<mfg>lel i could visit the guy listed on the dismail site as responsible... same city maybe 20 minutes by bike... <civodul>i'm still not sure whether/how to ban the whole domain, help welcome! <civodul>raghavgururajan: this is from disroot.org again, any suggestions? <raghavgururajan>civodul: The sys-admin is already working on blocking public-access. <roptat>they host the image, but they don't really control how it's used, do they? <mfg>guix-vits: ".. du hast mich gekuesst" ? i guess that's the next line isn't it? <civodul>mfg: no, you can use plain-file anywhere a "file-like object" is expected <civodul>roptat: the IRC client went through disroot.org apparently <mfg>guix-vits: you did cite the rammstein song didn't you? i instantly remembered the melody... <civodul>mfg: but you need to #:use-module (guix gexp) like you wrote <raghavgururajan>> civodul: roptat: the IRC client went through disroot.org apparently <raghavgururajan>Its an IRC gateway for XMPP. That is how I am connected here as well. <mfg>civodul: i included the use-module but still get the error that's what confuses me... i also don't know to much guile, so that might make things more difficult for me <civodul>could you paste the code snippet and full error message? <guix-vits>mfg: Yes, the bike, 20 mins road, and that melody. Isn't fun? Anyway, i've nothing to add, though. <mfg>guix-vits: it does :D <mfg> https://dpaste.org/wvwv i noticed though that copy-file isn't the right function there, because it doesn't expect a file-like object but a string. I just want to create the file with static contents, everything i tried didn't work and gave no errors... <mfg>that's why i'm trying out as much as possible :D <raghavgururajan>civodul: Can you see the hash on the line shell/disroot.org ? If so, create a block rule with that hash. It is an identd hash. No matter what nick the spammer, if the connection to the gatway is from same xmpp account, the hash will remain same. <raghavgururajan>Don't include that shell/disroot.org part, else I will also get kicked. 😅 <mfg>in the repo i have seen that this is used rather often: <mfg>(with-output-to-file "file" <mfg>but file doesn't get created if i use it <mfg>so the build system of the package i'm trying to package automatically deletes the just injected file and doesn't recreate it, that's why it seemed like the file doesn't get created ... D'oh <roptat>so groovy actually needs a fork of antlr4, which depends on itself... I tried to break the loop, but couldn't, so I'll have to use older versions to build the newer versions of that fork <roptat>I tried using antlr4 to generate a file in the fork's source tree. that worked, but that file won't build without the proper runtime library from the fork it belongs to <roptat>then I tried to build only a subset of the runtime library that's required to build the fork of antlr4, so I can use it to generate the sources for the full runtime library, but the minimal set of runtime library includes the generated file <roptat>antlr4 itself contains a runtime library, so I tried to use it, plus an even more minimal subset of the runtime library of the fork, but that failed because the two are actually incompatible, despite being the same version <roptat>so I'll have to follow the pom.xml files that use older version of the fork, and build ~6 years of historical versions of that fork <roptat>the usual story with Java packages :) <cbaines>that sounds quite awkward! Hopefully there aren't too many versions in that 6 year period <stikonas>roptat: groovy can be bootstrapped, but it's complicated... <stikonas>oh, wrong channel :), this is already guix <guix-vits>roptat: next 1 April "joke": 'Java banned in Guix. Because.' <Nemin>Heya, I'd like to dual-boot GuixSD with my Arch install, with the Arch managing the bootloader. How can I instruct Guix to not install one? I've tried passing --no-bootloader to guix system, but it's still <user_oreloznog>Nemin: I don't know if I can help, maybe have a look to my own config, (on line N°40 of the file) where dual boot with Debian and Guix System is configured... <Nemin>Thanks, this isn't really what I'm trying to do, but I suppose it's simply not part of the distro (yet). <user_oreloznog>I suppose it's simply too... But my level knowledge isn't sufficiant ;-) <Nemin>I've found one article on a mailing list that seems to be trying to do the same thing, there it was recommended to create a "dummy bootloader" that doesn't do anything <roptat>stikonas, yes I know, I added groovy a while back, but I'm trying to update it now. It went through a phase where it was not boostrappable, but the 3.0 series seems to be bootstrsappable again <roptat>but it added more dependencies, including antlr, so I have to package this first, before I can actually bootstrap groovy <roptat>I might propose a talk to the java devroom at fosdem this year "The Java nightmare, a packager perspective" or something like that :) <stikonas>hmm, on gentoo antrl 4 depends on antrl 3... ***ChanServ sets mode: +o nckx
***nckx sets mode: -b *!*@gateway/web/irccloud.com/x-vpbdwiyyybtxdvys
***ChanServ sets mode: -o nckx
<roptat>and there's a path from antlr2 to antlr3 actually <nckx>raghavgururajan: If disroot decide to die on the hill of being a freezepeach spam-cannon we'll be forced to ban them. I hope it doesn't come to that. <apteryx>janneke: thanks. I'm trying to enable xz multi-threading in a reproducible fashion (it seems to be possible, but I need --memlimit=50%, and the current version in the bootstrap binaries doesn't know about '%'). <apteryx>janneke: oh, that's nice, it inherits from the current packages. So if I can just regenerate the bootstrap binaries it should just work. <nckx>Nice. Weird that an amount that varies across machines makes it reproducible. <apteryx>it's rather convoluted, but the trick is to have the xz code stay into the 'multi-thread' code path <apteryx>so you enforce at least --threads=2 (not 1), but need a way to scale down its thread counts from N (parralel-jobs) to 2 because it can use a lot of memory. <apteryx>that's where --memlimit=50% comes into play <apteryx>You are welcome to try to break it :-) <cbaines>I tried to enable parallel decompression a while back, as I noticed some builds would spend many minutes just starting <janneke>apteryx: yeah...however i can also imagine xz to be removed altogether from the bootstrap binaries in favor of a guile based xz-decompress <apteryx>janneke: that's even better, as long as at least ignores the --threads and --memlimit args <apteryx>janneke: so basically, I'd just rebuild the %bootstrap-tarballs from say, master? <apteryx>cbaines: xz doesn't know to use threads for decompression, only for compression <apteryx>so it only speeds compression (useful when repacking tarballs following applying patches) <apteryx>xz decompression is blazing fast anyways, from my experience <apteryx>you can see it in action with webkitgtk for example <janneke>apteryx: yes, but like i said, i'm not sure whether we want to update the bootstrap xz <janneke>in the current bootstrap i don't believe we use bootstrap-xz for compression <janneke>patches are applied "by hand" until after xz-mesboot has been built, unless i'm mistaken <nckx>apteryx: I'd actually like to change patch-and-repack to use zstd, xz is hardly cheap (even decompression is expensive compared to zstd). I have an (I think) finished patch to do so at home. <apteryx>nckx: that'd be even better... thanks for making me realize that we do not need to care preserving the original tarball compression type <nckx>Well, I didn't realise it affected the bootstrap chain(?). <nckx>That would probably be deal breaker. <janneke>nckx: i don't think it will/should, that's why i'm a bit puzzled about apteryx efforts <janneke>apteryx: oh my -- looking at your paste -- that's unexpected!? <apteryx>janneke: I can workaround xz-bootstrap erroring when receiving the '--memlimit=50%' argument (which I presume is because it a bit dated, as the current xz doesn't suffer from that). <janneke>the bootstrap binaries are actually used to created patched sources -- yuck! <janneke>iwbn to change that, if it's at all possible <apteryx>but if I don't need workarounds (as in, simply bump the xz-boostrap version), that's even nicer in my opinion. <apteryx>about boostrap binaries being used to create patched sources; isn't that inevitable? <janneke>i don't know -- i realise that i haven't looked at that at all... <marusich>rekado, cbaines it occurs to me that to avoid using substitutes when building stuff using my custom guix, i can just configure guix to use a different store path. then i can use substitutes all i want in order to build the custom guix, without worrying about my custom guix re-using those substitutes later. i feel silly for not thinking of that sooner... but it was an interesting adventure in seeing how the same derivation can succeed in one ***raingloom_ is now known as raingloom
<apteryx>janneke: is it possible to partially regenerate the bootstrap tarballs (such as just refreshing the %bootstrap-binaries-tarball, which includes xz). I guess that's too dirty, in the sense that you now need two guix commits to regenerate the same tarballs collection. <marusich>It sounds lke you are saying you are trying to modify the bootstrap xz. Why would the performance of that, in practice, matter much? <marusich>It isn't used for building packages generally. <apteryx>it doesn't matter, but it shouldn't break when being passed the usual options used (guix packages). <mfg>what kind of characters do i need to escape in a substitute* statement? do i need to escape $? <marusich>I see. The thing about the bootstrap binaries is that they are rarely updated; it's kind of a security feature to avoid updating them, so that nobody can sneak in something hidden in the root binaries of our bootstrap tree. <apteryx>mfg: substitutes use the ERE regexp flavor, as described in the sed info manual <marusich>So even if you could make it faster, I am not sure we would want to replace the ones we have? <ryanprior>I'm packaging a bunch of Go deps building towards Hugo. Gonna be a long road. Right now I'm stuck on an error in the "unpack" stage where it says "In procedure copy-file: Permission denied" <ryanprior>Anybody dealt with similar before where Guix couldn't unpack? <marusich>ryanprior, without more context, the first thing I would suggest is to figure out why permission is denied. e.g., find out what command it's running which returns that error, check for more verbose errors, run with "guix build --keep-failed" and try to manually reproduce the error, and if necessary strace the failing process to see what it's doing at the syscall level. <apteryx>marusich: makes sense (to touch them only rarely, and have a couple people verify them well). <marusich>However, a likely cause is that something in the build logic is trying to modify a file in the store, which is immutable. <apteryx>I guess my case is not strong enough to warrant touching them, so I'll implement a workaround. <ryanprior>I'm working on pushing this work out into my repo so I can provide some more context :) thanks for your thoughts marusich <marusich>apteryx, yeah, but i am not sure how extensively they have been "verified" beyond when they were initially added. I looked into this a little bit, and I could not find evidence in the email list archive that, for example, any of the prior binaries were actually reproduced bit-for-bit, without using substitutes, on separate machines/OSes. But people did on occasion verify that they could produce the same bits (perhaps using substitutes - <marusich>sometimes that wasn't clear in the emails) <apteryx>marusich: If I recall mhw looked into reproducing them carefully <marusich>I am currently working on this bug to try to make the powerpc64-linux bootstrap binaries bit-for-bit reproducible, and it's really time consuming. I am honestly not sure if it is better than just accepting the set of binaries we build 2 months ago, and just using them. <marusich>Personally, I would be pleasantly surprised if I found out that any of the existing bootstrap binaries were actually verified by building two times from source with no substitutes on two different machines. <marusich>I know that some of them were verified by building two times on two different machines because some emails said as much. However, the emails I saw didn't clarify whether substitutes were used. <efraim>xelxebar: just getting back to my computer after off for a few days, last I saw I was way too many hours into qemu-minimal's test suite and now I can't connect to the board. I'll probably adjust qemu to skip the test suite on the board if it's not done <ryanprior>Here's the package I'm working on, aws-sdk-go. Its dependencies all build, but when I try to build this package it fails in the "unpack" step with "In procedure copy-file: Permission denied" <efraim>ah, yeah, the "can we just delete it and pretend it isn't there" idea <marusich>Turns out, if you re-use the exact same inputs (e.g., by manually copying them allll over onto the other machine), then simply adding the --disable-libstdcxx configure option to %gcc-static's package definition succcessfully eliminates the non-reproducibility. Now I'm testing whether it remains reproducible on debian vs. fedora if i build everything from source, including all inputs. <marusich>I don't know if libstdcxx is required to build the next thing(s) in the bootstrap path on powerpc64-linux, but i'm all about easy fixes, so if this works that would be nice. <marusich>ryanprior, use --keep-failed and find out what files it's trying to copy when it fails. <marusich>you can "enter" the build environment if you use --keep-failed, so you can poke around and see what it's doing. <marusich>it mentions the files in the stack trace, but it's truncated so it's hard to tell what files it's failing to copy exactly. <ryanprior>I did go ahead and run it with keep-failed and I'm in the build directory now poking around. What am I looking for? <ryanprior>The build directory has a big bunch of symlinks into the store, which I'd expect, but the're pointing towards paths like: <ryanprior>/gnu/store/926vdjm5b5a8nayc4nb0fgv8g86bdc1i-go-github-com-go-sql-driver-mysql-1.5.0/src/github.com/aws/aws-sdk-go/auth.go <ryanprior>Which I would not expect- why is it trying to symlink to something inside the go-sql-driver-mysql package? <ryanprior>It doesn't try to link into any of the other dependencies <ryanprior>What else is weird is that those paths do exist - why? How is that happening? <marusich>ryanprior, maybe it's one of the files mentioned in the unpack section of the logs? <marusich>stat /gnu/store/76h7rl047h1b7by8nwm9by1j44w1snnk-go-github-com-aws-sdk-1.34.27-checkout/README.md <marusich>stat /gnu/store/76h7rl047h1b7by8nwm9by1j44w1snnk-go-github-com-aws-sdk-1.34.27-checkout/.godoc_config <ryanprior>It says those are "regular files" with uid and gid of 0 <marusich>When you're in the failed build directory, /tmp/whatever, you can source the environment-variables file via ". environment-variables" and then manually walk through the steps taken to build the package. to know what steps are taken, you either have to see what it says it did in the build log, or read the package definition. <marusich>cp /gnu/store/76h7rl047h1b7by8nwm9by1j44w1snnk-go-github-com-aws-sdk-1.34.27-checkout/.godoc_config /tmp/guix-build-go-github-com-aws-sdk-1.34.27.drv-0/src/github.com/aws/aws-sdk-go/.godoc_config <marusich>cp /gnu/store/76h7rl047h1b7by8nwm9by1j44w1snnk-go-github-com-aws-sdk-1.34.27-checkout/README.md /tmp/guix-build-go-github-com-aws-sdk-1.34.27.drv-0/src/github.com/aws/aws-sdk-go/README.md <ryanprior>That package built fine, but it was actually misbegotten X.X <ryanprior>Now my aws-sdk-go builds successfully =D thank you again marusich that was helpful advice. <rekado>pfff… I know why the search on issues.guix.gnu.org isn’t working right <rekado>the worker is updating a different database <rekado>that other database, though, … really up-to-date <rekado>and the reason why it failed in the first place: database corruption, probably when we last ran out of space. <rekado>I’m doing a full re-index now, should be done in a few minutes <rekado>amazing what can be achieved in a lucid minute <ryanprior>It would be nice to let people know when I'm making progress on a package people are wishing for <luis-felipe>Hi, I found a segfault in Glade 3.36.0 and reported it to the Glade project. They are asking me for a stack trace, they provide some instructions, but I'm not sure how to map them to the Guix System. <rekado>ryanprior: we don’t but I suppose you could just comment right there on the wishlist <rekado>in my experience the wishlist is not really closely integrated in many people’s workflows <mfg>what would be guix's alternative to: ${stdenv.lib.concatStringsSep "\n" (map (f: "-L${f}/lib") buildInputs)} in nix, or what expression do i need to grep for? <luis-felipe>I know I can install debug packages like gtk+:debug, glade:debug, etc. <rekado>mfg: you can iterate over the inputs in a build phase <luis-felipe>But then I don't know if "coredumpctl gdb" and then "bt full" works on Guix... <rekado>mfg: (add-after 'that 'this (lambda* (#:key inputs #:allow-other-keys) …)) <rekado>mfg: now inside that lambda you can use the variable inputs, map over it, etc <ryanprior>rekado: that may be true, but I don't know of any other similarly public-accessible way to request a package. Editing a wiki is already a fairly high bar, using the guix-devel mailing list even moreso. <mfg>rekado: hm ok, i did something else wrong then... <luis-felipe>civodul: Yeah I read that page. But I'd like to know what would be the equivalent commands in Guix to "coredumpctl gdb" and "bt full". <luis-felipe>Which I'm supposed to run once I have installed the debug packages. *luis-felipe has never used gdb before. <cbaines>ryanprior, I think having a bug against guix-patches can be useful <cbaines>you could always then get the wiki to link to that bug <rekado>mfg: feel free to share what you have <civodul>luis-felipe: you can run gdb like so: "gdb $(which xyz) core", where "xyz" is the program and "core" is the core file that was dumped (in $PWD) <civodul>presumably that's what coredumpctl does <rekado>this keeps coming up, but I’m genuinely curious: in what way is sending an email to guix-devel@gnu.org a high bar? <ryanprior>cbaines: are you suggesting I should file a wip bug to guix-patches to track my progress towards the target? <rekado>(I don’t think requesting packages on the mailing list is a good idea, but I do wonder about the impression of a mailing list as an obstacle) <cbaines>ryanprior, yeah, you can even mark them as "More information needed" to set them apart from the other patches <ryanprior>rekado: sending an email to a list feels like shouting into a void. I think people are less hesitant to open an issue on a wiki or a git-forge like GitLab because they can see other people doing the same and getting responses <rekado>I wonder if thihs means that we need more visible and more attractive archives. <rekado>pineapples: would a more visible (and perhaps more attractive) web archive of messages sent to the mailing list make this any better? <rekado>it has a very “web forum” feel to me <ryanprior>That interface does feel like a step in the right direction. I like that it has a "Start a new thread" button but I dislike that it's disabled for me with no explanation. <rekado>this is a demo server; I don’t know what this means in terms of available features <civodul>hyperkitty is trying to bridge this gap <civodul>mumi & woof! too, but with a more specific focus <mfg>rekado: it seems i have to learn regex a more :D <rekado>I would love to kick out stringy regexes from the Guix sources <rekado>and use something like irregex where needed <mbakke>civodul: I think NieDzejkob has a patch to make GCC 9 the default, but I might have sent him down a rabbit hole. IIRC it was largely okay. :-) <civodul>well and perhaps debug remaining issues :-) <mbakke>NieDzejkob: do you remember where it got stuck? cross-compilation issues? <NieDzejkob>yeah, some usecase like cross-compiling to Hurd started failing. It looked like some substitute* started failing silently so I started working on #42146, and that *is* a rabbit hole <pineapples>rekado: I should've elaborated a little more: I'm hesitant to open an issue by sending an email to a list because I feel uncomfortable revealing my personal email address, and dislike the idea of having to set another email address up. All it'd take to convince me to contribute to the project would be an ability to hide it from other participants <rekado>pineapples: with issues.guix.gnu.org you can already comment on an existing issue without having an email address. (You won’t receive notification on updates, though, because the system would need to know your email address.) <rekado>pineapples: we don’t have this yet for submitting new issues. <pineapples>rekado: The last time I tried to send a comment through the web interface, it didn't go through for some reason. Submitting new issues via issues.guix.gnu.org would be a huge deal-maker to me if you ask me <mbakke>NieDzejkob: can you submit the patch and mention the failing use case? maybe other hackers already know what the problem is. <luis-felipe>pineapples: That has happened to me before. I sent a message, and it seems it never goes through. <rekado>pineapples, luis-felipe There used to be a problem with the gateway (it needed some more environment variables) <rekado>the problem still remains, but in the meantime I’m running it in a screen session where the variables are set. <rekado>someone needs to fix this some day <luis-felipe>I'm trying to get a stack trace of Glade. I run this: gdb -q glade. But I get this: <luis-felipe>"/home/yo/.guix-profile/bin/glade": not in executable format: file format not recognize <civodul>you may need ".glade-real" instead of "glade" <luis-felipe>Oh, but wait, isn't the application suppossed to start so that I can follow the steps to make it segfault, and then get the backtrace? *luis-felipe doesn't know what he's doing... <luis-felipe>Another thing is that Glade people say I will probably need a debug package for Gtk, but Guix's gtk+ doesn't seem to have a "debug" output. <peanutbutterandc>For the moment I'm trying to work with just this: (display (string-append "asdf" "jkl")) nothing fancy. <peanutbutterandc>the way I understand it, I should be seeing the help text of string-append <peanutbutterandc>However, if I go to the geiser-repl (running guile) and go (help string-append) it is there. <luis-felipe>Are you using the GNU system from Guix or Guix on a foreign distro? <peanutbutterandc>Foreign distro. Using guix to install both emacs, guile, and emacs-geiser <luis-felipe>Well I don't see why it does not work if you installed everything with Guix... <luis-felipe>I use the GNU system, and I have use Geiser in that way, yes. <peanutbutterandc>luis-felipe, Please do check my .emacs, too. I'm loading geiser using (load "geiser.el") and nothing else. Am I missing something? <mfg>andreas-e: perl-opengl now successfully builds! <luis-felipe>peanutbutterandc: Things work as expected here, I get the documentation of that procedure. Let me check my .config/emacs/init.el and yours <luis-felipe>peanutbutterandc: My Emacs init file doesn't have anything related to geiser. Did you install geiser using Guix? <luis-felipe>peanutbutterandc: Wait, I do have this line in my Emacs init file: (setq geiser-active-implementations '(guile)) <luis-felipe>Tells Geiser to use Guile as the default implementation. <peanutbutterandc>and it doesn't make sense to my brain.... why that one line would cause this trouble <peanutbutterandc>You're the best. I've been asking for help from #guile and #emacs and everywhere. Finally someone! (: <peanutbutterandc>luis-felipe, Thank you very much. Now, perhaps the first thing to do is `guix environment -m guix.scm` ? <peanutbutterandc>Now, in that environment (equipped with haunt, and everything) I've opened up the file haunt.scm <peanutbutterandc>So, what I want geiser to help me with is this: I want to know where these procedures are defined, which modules they come from <peanutbutterandc>And then there's sxml->html in line 223. I know it comes from (haunt html), but geiser does not tell me that <luis-felipe>peanutbutterandc: But static-page in haunt.scm is a procedure definition itself not a call to that procedure. <peanutbutterandc>luis-felipe, I meant the call to the procedure (with-layout) in line 222 within the (static-page) procedure <peanutbutterandc>Yes, and then there's the sxml->html function in line 223 that comes from (haunt html) --- I figured that out by brute force. <mroh>If I have a pkg that has source of libs like zip or lz4 or lua in a folder of the tarball/checkout, but I ./configure --usesystemlua=true it to use our library/input, do I still have to mention the license of that library in the license field of the pkg? <peanutbutterandc>mroh, I would think not. As the license of that library will already be in the package definition of that library that is already in the gnu system. <luis-felipe>peanutbutterandc: geiser should be able to give you information about things defined in the haunt library too. <luis-felipe>peanutbutterandc: Since haunt is installed in the environment you created, your Emacs and geiser installation (which I assume is in your Guix user profile) cannot see it. <luis-felipe>So, Emacs, geiser and haunt should be in the same environment for geiser to be able to find haunt definitions. <peanutbutterandc>They are in the same environment... since it's not --pure, they are all there.... <peanutbutterandc>luis-felipe, I have no idea what just happened, but for some strange reason it decided to work. lol. Thank you very much. You have been awfully helpful! <mfg>is there an option like -K which also keeps successful builds? <peanutbutterandc>mfg, I was also thinking of the same thing the other day. But it seems that there's only --keep-failed for now <mfg>hm okay, time for workarounds then :) ***KE0VVT_ is now known as KE0VVT