<vagrantc>lechner: it will certainly prevent you from building with the wrong commit, because you also have to specify the guix hash, too <vagrantc>oh nice, the staging merge appeared to fix as many or more reproducibility issues as it introduced :) <vagrantc>oh, maybe it hasn't yet tested it ... i misread the commit number <sleepydog>env -i /usr/bin/env 0=foo x=bar ./gawk 'BEGIN { print ENVIRON["x"] }' -> fatal: floating point exception <fnstudio>hi! if i reconfigure to a system definition that inherits from another one, how will that be reflected into /run/current-system/config.scm? will i end up losing any "provenance" information, e.g. anything related to the base definition? <jorge[m]>guix pull: error: Error git: '/home/jorge/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq' exists and is not an empty directory <fnstudio>i see there's a build failing on cuirass - certbot on x86, i think because of a problem with python-acme - what does one do in cases like this as a quick fix? time-machine? <blake2b>i just noticed that someone appears to have installed guix on a classic Nintendo NES, I'm not trying to do anything like that but any chance this was documented for the curious? <tpefreedom>The guix website says that shotcut is in the repos but it doesn't come up when I use guix search and I get an error with guix install. <podiki[m]>I see shotcut locally just fine, by any chance on a new install and haven't guix pull-ed yet? <podiki[m]>it was only added a year ago, so if you installed and didn't do a guix pull, that would explain it <tpefreedom>This is a fresh install (maybe an hour or two ago) <podiki[m]>tpefreedom: then yes, do a guix pull as currently you'll have the guix package definitions from the installer I believe <podiki[m]>(and if you used the 1.3.0 installer, it is quite dated until 1.4.0 comes out "real soon now") <tpefreedom>I pulled right after I installed but I'm trying again. <podiki[m]>on Guix System I don't (seems fine) though to be safe go ahead, especially after just installing <podiki[m]>the brief explanation is that "guix" is the guix binary and also all the package definitions, so "guix pull" will update that to the latest (but not upgrade your packages) <podiki[m]>"guix system describe" will tell you what commit you are on as well, for future reference <justkdng>is there a way to programatically obtain the latest kernel bzImage and initrd? <podiki[m]>kdbusaddons seems to be at the root of the kde-related failures I see, built fine (and the CI log looks fine too...) <cc0a3hr>honestly speaking, how hard is guix? im artix user but wants to try new distros, GNU/Linux respecting ones <macroperson[m]>unless you are dedicated to learning scheme. parabola would be a good fit for you <lechner>Hi, how can I set GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH to the source's top directory in a package declaration, please? ***wielaard is now known as mjw
<PurpleSym>podiki: As expected rocm 5.1.3 does not support my gfx803-based GPU any more ☹️ Keeping only rocclr-4 is not sufficient, I think. We’d need a full stack of rocm 4.5 (which is the last version to support that GPU). I’ll see if I can simply `inherit` everything without too much hassle. <tex_milan>hello folks, any idea why mount is unable to mount sshfs? <tex_milan>root@t14s /home/milan# mount -t fuse -o defaults,user,exec,uid=1000,rw,noatime,allow_other,max_read=65536,port=2222,IdentityFile=/home/milan/.ssh/id_rsa_moto_e7 sshfs#milan@192.168.1.236:/mnt/sdcard/ /sshfs/moto-e7 <tex_milan>mount: /sshfs/moto-e7: wrong fs type, bad option, bad superblock on sshfs#milan@192.168.1.236:/mnt/sdcard/, missing codepage or helper program, or other error. <jpoiret>i'd suggest using the sshfs command directly if that's possible for you <jpoiret>my guess is that you'd need to install sshfs/fuse userspace helpers in the system profile <tex_milan>sshfs directly works. but i want automount, this is what automount executes and fails. <jpoiret>you'd need to add fuse and sshfs to your operating-system's packages <mothacehe>jpoiret: hey! regarding your 1.4 email, switching to wayland on gnome by default seems like a good idea. <mothacehe>wayland works fine here, except for screensharing on chromium but that looks like a chromium issue <tex_milan>I put sshfs, autofs to system config, but unfortunately it did not help, <tex_milan>root@t14s /home/milan/guix-config# mount -t fuse -o defaults,user,exec,uid=1000,rw,noatime,allow_other,max_read=65536,port=2222,IdentityFile=/home/milan/.ssh/id_rsa_moto_e7 sshfs#milan@192.168.1.236:/mnt/sdcard/ /sshfs/moto-e7 <tex_milan>mount: /sshfs/moto-e7: wrong fs type, bad option, bad superblock on sshfs#milan@192.168.1.236:/mnt/sdcard/, missing codepage or helper program, or other error. <fnstudio>hi, what does one do when hitting a "cannot build derivation ... guix system: error: build of ... failed" on a guix reconfigure operation? <jpoiret>fnstudio: there should be a mention of a build log, you should inspect it/paste it here with paste.debian.net <jpoiret>tex_milan: can you try with -t fuse3 instead? <jpoiret>arf, that gives 'unknown filesystem' <fnstudio>jpoiret: in theory there shouldn't be anything sensitive to parse out of the log file, am i right? <tex_milan>root@t14s /home/milan# mount -v -t fuse3 -o defaults,user,exec,uid=1000,rw,noatime,allow_other,max_read=65536,port=2222,IdentityFile=/home/milan/.ssh/id_rsa_moto_e7 sshfs#milan@192.168.1.236:/mnt/sdcard/ /sshfs/moto-e7 <tex_milan>/gnu/store/chfwin3a4qp1znnpsjbmydr2jbzk0d6y-bash-minimal-5.1.8/bin/sh: line 1: sshfs: command not found <tex_milan>root@t14s /home/milan# mount -v -t fuse3 -o defaults,user,exec,uid=1000,rw,noatime,allow_other,max_read=65536,port=2222,IdentityFile=/home/milan/.ssh/id_rsa_moto_e7 /run/current-system/profile/bin/sshfs#milan@192.168.1.236:/mnt/sdcard/ /sshfs/moto-e7 <tex_milan>the last message is from sshfs itself. thanks jpoiret! <jpoiret>fnstudio: no, since they're from the isolated build (unless you're building something that should be kept a secret) <jpoiret>you can still inspect it just in case <fnstudio>and python-acme the failing dependency, if i understand it correctly <jpoiret>you just guix pull'd? let me try building it on my end <jpoiret>staging was merged into master yesterday i think, so there might be some breakage <fnstudio>yeah i think i pulled before trying guix system reconfig, yes <jpoiret>i'm getting the same, it worked fine before the staging merge, let me see what the issue is <tex_milan>root@t14s /home/milan# mount -v -t fuse3 -o defaults,user,exec,uid=1000,rw,noatime,allow_other,max_read=65536,port=2222,IdentityFile=/home/milan/.ssh/id_rsa_moto_e7,debug /run/current-system/profile/bin/sshfs#milan@192.168.1.236:/mnt/sdcard/ /sshfs/moto-e7 <tex_milan>failed to execute 'ssh': No such file or directory <tex_milan>usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] <jpoiret>i think mount doesn't preserve PATH, rightfully because it is setuid <tex_milan>maybe, should I try run autofs form home manager under my user instead of system one? can it work this way? <jpoiret>i have no idea, i've always manually ran sshfs <jpoiret>a committer will need to have a look at it <fnstudio>jpoiret: hey wow, that was quick, thanks for filing the BR for me! <jpoiret>it built fine with this patch for me <fnstudio>in the meanwhile, anything one could do as a temp workaround? e.g. using an older version of guix? <jpoiret>you could use the commit before the staging merge, ie d4482e9a9ebe61197a0756ce9048fcb895e6f552 <fnstudio>adding python-chardet... i see, yeah i see it in your bug report <jpoiret>(if that's what broke it, although i don't understand why it broke) <jpoiret>maybe an update to python-requests which apparently used to propagate chardet but doesn't anymore <tex_milan>this works! root@t14s /home/milan# mount -v -t fuse3 -o defaults,user,exec,uid=1000,rw,noatime,allow_other,max_read=65536,port=2222,IdentityFile=/home/milan/.ssh/id_rsa_moto_e7,debug,ssh_command=/run/current-system/profile/bin/ssh /run/current-system/profile/bin/sshfs#milan@192.168.1.236:/mnt/sdcard/ /sshfs/moto-e7 <jpoiret>i wonder if jumping through all these hoops should be required <daviwil>Hey folks! Simple patch to bump the version on herbtsluftwm, any maintainers free to take a look? If I hadn't let my commit access lapse I could have pushed it myself ;) https://issues.guix.gnu.org/55924 <fps>i screwed up by calling sudo -E guix pull. now running that as regular user complains about the symlink already existing (sorry, can't copy and paste from that vm) <fps>is there a quick way to fix the ownership/link structure in /var/guix/profiles? <fps>i think i got it figured out.. <fnstudio>it seems that the certificate creation has to happen as a separate step, using a separate system definition <ekaitz>hi guix! is there any recursive alternative to `install-file`? <nckx>Close: copy-recursively. <nckx>It is analogous to copy-file, not install-. <nckx>Thank you for reminding me to fix install-file. <nckx>Doens't it create an empty file when called on a directory, instead of either erroring out (meh) or copying recursively (win)? <nckx>I guess that's inherited from copy-file but same diff. <nckx>If that no longer happens, that's good. <ekaitz>another random question: why if my package generates a /include output that is not added to the $GUIX_ENVIRONMENT when I use the package from a manifest? what did I miss? <fnstudio>ok, the certbot+nginx thing ended up requiring a bit more tinkering than expected: i understand one has to first deploy a certbot-only system config; at that point i had to run the renew-certificate script manually, which was unexpected; then i reconfigured to a certbot+nginx system, but also in that case i had to manually herd restart nginx for it to come to life <fnstudio>(i may very well be missing something of course) <nckx>ekaitz: I'm not sure, but something. So $(guix build P)/include definitely exists? Which command do you run to enter the shell/environment? <ekaitz>nckx: the /include dir exists in the build and the command to enter the shell is just `guix shell -m manifest` and the manifest includes the package <jonsger[m]>nckx I do usually `sudo -E guix pull`, but I can't do anymore. It says "guix pull: Fehler: directory ‘/home/jonathan/.cache/guix’ is not owned by user jonathan" but that directory is owned by jonathan:users <nckx>jonsger[m]: It just calls (stat:uid (stat …)) on the directory… no? Now I'm missing something. It's catching. <ekaitz>nckx: so I'm doing something superwrong <nckx>I'm not saying that, but I don't understand why you're seeing what you're seeing. <ekaitz>nckx: I said it! It's basically that i don't see the .h files around there <nckx>jonsger[m]: It's just a typo in my patch. Stupid, but a relief. <nckx>Is this breaking a crucial workflow for you? Because it will still be broken when I fix it; it's just a bug in the error message. <nckx>The pull will still be disallowed because it checks the owner, not group, of the cache directory. <nckx>This is the exact kind of ‘who in their right mind would do something like this’ that I couldn't imagine anyone would do. Explain your use case, sir! <nckx>ekaitz: Can you share the package & manifest? <jonsger[m]>nckx I have no idea what will be the difference when using `sudo -i` instead of `sudo -E` in terms of Guix... <nckx>jonsger[m]: With ‘sudo -E’ (the default for ‘sudo’ on Guix System), you are root but keep almost all of your regular user's environment. This was a problem, because ‘sudo guix pull’ would happily create root-owned files in ~user/.cache/guix, and the next ‘guix pull’ without sudo would be unable to update them → fatal. ‘sudo -i’ is the moral equivalent of logging is as root; ‘sudo -i guix pull’ with update root's guix using root's ~/.cache, <nckx>The question is, why are you using sudo? <nckx>s/with update/will update/ <nckx>Getting a substitute for glibc-cross-riscv64-linux-gnu-2.33 in seconds felt very good, this is what Guix is supposed to be. <jonsger[m]>I have only single user (biological) systems, so I do not wanna have split the environments, caches, profiles etc between my user and root <nckx>ekaitz: Finding a tcc package/repo that actually compiles is a greater challenge than expected. <jonsger[m]>I don't have an use case to run guix pull without root priveleges <nckx>jonsger[m]: But you are? Or is there a symlink involved? <nckx>*you are splitting them? <jonsger[m]>because I run guix system reconfigure as next step <nckx>You're putting root's files in /home/jonsger. <nckx>I can follow up to not needing 2 guixes (most people don't). Why do you need to pull as root at all. <nckx>For example, I've never pulled as root, my root user doesn't have a guix. <nckx>sudo guix system reconfigure <attila_lendvai>nckx, and don't you need to regularly chown files in your ~/.cache when you want to pull with your user after a sudo guix pull? <nckx>Yes, because it's confuses Guix. <jonsger[m]>dont know when and how I started to use `sudo -E` but I guess it was to avoid the two guixes thing... <jonsger[m]>its maybe from the time I used Guix only on foreign distros... <nckx>jonsger[m]: I think you've always been doing it wrong and assumed it was necessary but it isn't. At least that's my guess. <nckx>Maybe you never tried ‘guix pull && sudo guix system stuff’, it works fine. If not, bug time! <nckx>This isn't unique to Guix: if you always run ‘sudo emacs ~/…’, your ~ will end up full of files you can't edit yourself. <nckx>Hence a bad idea, hence why it's now an error. <nckx>jonsger[m]: Seems like it. Not a workflow I use either. <nckx>-bash-5.1# is definitely an indication. <jonsger[m]>so you need to manually source the profile of your normal, unprivileged user then? <nckx>I can't speak to your needs. That would load your regular user's Guix environment, but as root. <nckx>It could still lead to problems if you forget that. <nckx>I have only single user (biological) systems → then why do so much as root? <jonsger[m]>because with root stuff just works(TM), at least on traditional distros :P <nckx>It's a very bad idea, even there, but it seems Guix exposed a particularly sharp edge. <nckx>jonsger[m]: You're very much not alone, I added that commit because of the number of people running ‘sudo guix pull’ because Debian taught them it means ‘please’. <fnstudio>anyone knows of a how-to or blog post or something for provisioning a matrix synapse server via guix? <ekaitz>nckx: I know but this one does actually compile! Also it's my job now... <nckx>ekaitz: (C{ursed ,}ongrats?) Thing is I don't have access to a ‘this one‘ that compiles, so I can't help reproduce. <nckx>jorge[m]: If you haven't yet, just ‘sudo rm -rf /home/jorge/.cache/guix/checkouts’ and try again. <ekaitz>nckx: what I'm wondering is I missed anything to make the /include directory available or something like that <nckx>If it's present in the build output (and it looks like it is) you shouldn't need to do anything. <nckx>Hmm, with that fork & branch I still get a missing tcc.1 throwing an exception during the install phase. <nckx>Easy to comment out, but not reassuring. <nckx>That's what other random git forks threw, I thought it was related, guess not. <ekaitz>probably not, my package is compiling properly <nckx>…it's not somehow built only for riscv64, is it? I mean, that would be weird bordering on buggy, but not impossible. <nckx>Because I'm testing without --system <nckx>because --system=riscv64-linux throws other errors not related to tcc :-/ <nckx>I'm missing the bootstrap xz and alpha.gnu.org doesn't have it. <ekaitz>you just need to `guix build -f guix.scm` <nckx>Then no, I have no idea why tcc.1 wasn't built. <ekaitz>i don't know what changed but something worked <nckx>I'm very glad to hear that and not continue investigating completely unrelated errors on my end :) <ekaitz>anyway, in my computer started to work I don't know how <nckx>Clearly, your computer is magic, and this is why reproducible builds are a mistake — they leak the precious developer laptop magic. <ekaitz>exactly haha now I need to make this thing find the glibc, but hey! that's another story <jorge[m]><nckx> "jorge: If you haven't yet, just..." <- Thank you very much <nckx>So we know: did it help? <lechner>Hi, in my package the Guile Autoconf macro GUILE_SITE_DIR resolves $(GUILE_SITE_CCACHE) to /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/lib/guile/3.0/site-c <maximed>turns out the (stable?) Rust compiler in Guix can compile unstable rust just fine <maximed>All that has to be done is setting RUSTC_BOOTSTRAP=1. <lechner>cache, but the system folder in unsuitable as an install location. Would it be better if GUILE_SITE_DIR worked off of $prefix to produce $(libdir)/guile/$(GUILE_EFFECTIVE_VERSION)/site-ccache ? <maximed>lechner: For classical non-Nix-like distribution, installing to Guile's site-ccache makes more sense (if in another location, it wouldn't be found <maximed>Though maybe nowadays $(libdir) makes more snese? <lechner>maximed: isn't the location the same for classical distros? <maximed>lechner: No. On classical distros, it's /usr/lib/guile/3.0/site-ccache. <maximed>Which _is_ writable by dependencies during installation. <maximed>Maybe 'guile' should come with a configuration flag to regulate the behaviour of GUILE_SITE_DIR? <lechner>that looks like $(libdir)/guile/$(GUILE_EFFECTIVE_VERSION)/site-ccache to me <maximed>lechner: it isn't, because $(libdir) is variable. <maximed>GUILE_SITE_DIR looks in wherever Guile is installed. <lechner>Who uses GUILE_SITE_DIR to find object files? <maximed>Whereas $(libdir) is wherever the dependency is installed. <maximed>(on the configuration) E.g. put a flag in .pc or something and let GUILE_SITE_DIR go for $(guile's site-ccache) when set to ‘classical’ and $(libdir)/guile/3.0/site-ccache when set to ‘nixy’. <maximed>anyway, seems more a question for #guile to me. <maximed>ENOSPC on ci.guix.gnu.org strikes again: <civodul>i've started a cleanup process that should help... until next time <civodul>i have to go afk for a couple of hours <podiki[m]>PurpleSym: ah, that is annoying. luckily the changes were nearly all in patches and hashes, just a minor build tweak in rocm-opencl-runtime if I remember <podiki[m]>PurpleSym: might need to downgrade llvm-for-rocm too? <apteryx>When running 'guix deploy', Shepherd is not updated, right? (that wouldn't be possible -- being PID 1 I guess) <PurpleSym>podiki: Yeah, just wasted some time trying 4.5 and it also does not work, which means 4.3 was the last version to support my GPU. I guess the easiest path would be to just bump to 5.1 and I’ll just use a Guix inferior with 4.3. <podiki[m]>any idea where the support dropped that we could patch back in or just keep a limited package set around? <podiki[m]>very annoying for them to drop support, though I guess they never really list anywhere what is supported too <lechner>Hi, in view of the 'staging' rebuilds, is there a local strategy for the sharing, mirroring or other reuse of official substitutes? <maximed>lechner: You can set up a publish server and set up guix-daemon with --discover to share things on the local network <maximed>but I'm not seeing the relation to staging. <maximed>Also, the substitute server is ‘just’ a HTTP server, so you a generic caching proxy should work if you want something mirror-like. ***jesopo is now known as jess
<ekaitz>hey all, what's the best way to create a text file during the phases of a package? is there a simple command to do something like `echo "whatever" > file` <cbaines>ekaitz, (call-with-output-file "foo" (lambda (port) (display "bar" port))) should work I think <ekaitz>okay no helper function then, scheme ftw <podiki[m]>PurpleSym: as perhaps the main (only?) user of rocm v4, probably up to you how to handle the older version. Though if this is a habit of rocm, might be worthwhile to keep older versions going forward? <lechner>Hi, is an inferior a way to amend the symbol definitions in xkeyboard-config with a custom layout (likely a patch)? <PurpleSym>podiki: I’m always conflicted about that tbh. I mean: We have a the time-machine to go back, but guix-past also exists. Not sure where to put rocm in this spectrum and when time-machine would fail us here. Does it work after a libc upgrade, for example? <podiki[m]>PurpleSym: yeah, not sure the best course of action. we do have several options in guix and at least rocm is pretty standalone, other than the llvm part (but we keep a few versions of llvm anyway) <ggoes>hmm, i seem to have lost spell check in chromium <ggoes>on guix system; looking into it <justkdng>but I'm having issues adding a dependency for nss-util.pc ***038AATU1M is now known as mjw
<justkdng>even though I'm including nss as part of the inputs, the compilation still can't find it's libraries for linking for some reason <maximed>, nss-util appearrs to be distro-specific <maximed>justkdng: are you using the output of TARGET-pkg-config --libs? <justkdng>not sure how to use what you are saying maximed <maximed>justkdng: The makefile Make.defaults is broken. <maximed>To determine the arch it's compiling for, it uses uname. <maximed>Which won't work when cross-compiling. <maximed>So HOSTARCH and CROSS_COMPILE needs to be set explicitly in #:make-flags <maximed>(though maybe not broken and more like: if you want to cross-compile, please set those flags) <maximed>(probably not related to the nss-util problem, but will be needed eventually). <maximed>justkdng: make sure that 'pkg-config' is in the native-input <maximed>Also, I don't think any of the inputs need propagation. <maximed>justkdng: Maybe check if .../lib/nss ends up in the -L arguments of the invocation to gcc? <maximed>justkdng: Looks like pkg-config-ldlibs is used, but pkg-config-ldflags isn't. <maximed>(Only the latter contains the -L flags) <justkdng>oh, so I could append an $(exec pkg-config-ldflags) to the Makefile? <maximed_>Writing constant-time crypto code turns out to be insufficient to make the crypto code constant-time (at least, for all Intel processors and some (all? a few?) AMD processors): <efraim>thats it, I'm going back to my 32-bit ppc <maximed_>efraim: according to Intel, _all_ Intel processors are affected (effected?) <efraim>maximed_: my iBook G4 should be safe! <justkdng>how can I add a patch that is a local file? ***gmodena_ is now known as gmodena
<maximed_>justkdng: (list (local-file "the-patch.patch")) ***jfb4_ is now known as jfb4
<tricon>University of Illinois represent! <maximed_>And the hertzbleed is based on frequency scaling ***stryan_ is now known as stryan
<maximed_>so possibly that computer is also unsafe! <efraim>it has a 7447A, but now I need to reread it to see if it needs a second thread <justkdng>does the patch need to have a special format? <maximed_>justkdng: Multiple formats are supported. <efraim>looks like I should check if the A53 cores have frequency scaling, they already don't have OoO processing <justkdng>oh, I'm using git diff to generate the patches <efraim>`git diff -p > the-patch-file.patch` should be fine <maximed_>Curious there doesn't seem to be any reference to crypto libraries. <maximed_>(Like, ‘this new version has mitigations against Hertbleed’ <tricon>the site claims they have yet to determine specifically which crypto libs are affected. <maximed_>tricon: SHouldn't this have been done during the embargo period? <tricon>maximed_: Yeah, I'm wondering why at least major libs weren't audited during that time. <maximed_>Even if it's only telling crypto lib people: ‘here's a vulnerability, we don't have the resources yet to look into it ourselves yet if it applies to you, but quite likely it does, so prepare!!!’ <justkdng>ok, somehow managed to build it, still don't know why the patching didn't work <justkdng>how can I install this pult package now? <maximed_>juskdng: you could give "guix install -f the-package-definition-file.scm" a try if you're a user of "guix install" <maximed_>Though a later "guix package -u" won't understand the package definition. <maximed_>Long-term, I recommend submitting it for inclusion in Guix itself. <maximed_>(Time required for including it in Guix itself varies) ***rgherdt_ is now known as rgherdt
<justkdng>and what is the process for including it? <elb[m]>(To follow up on my Emacs troubles earlier; I removed the distro Emacs packages, which were there to be able to build Emacs debian packages, updated Guix and cleaned some things up, and now guix-about works, so I have no idea. The distro Emacs stuff wasn't in the load-path, but I wonder if it wasn't interfering.) <podiki[m]>basically removing the -Ddri-drivers flag we currently have <podiki[m]>there is a separate branch to have these older drivers.... thoughts? <kaelyn>Hi guix, how would I select the gcc:lib output (with libstdc++.so in it) when calling "guix shell"? I would have expected "guix shell gcc@10:lib" to work, except it gives an error because "gcc@10" is being shunted to "gcc-toolchain@10". <kaelyn>forgot to add: and "gcc-toolchain" doesn't have a "lib" output, nor does it include libstdc++.so <jpoiret>gcc itself is hidden iirc, only gcc-toolchain is usable from the CLI <justkdng>what is the recommended way to package a binary that has it's socket and pidfile hardcoded? <justkdng>for example: #define SOCKPATH "/var/run/pesign/socket" <nckx>justkdng: Fix it to use /run, but what else would you do? <nckx>kaelyn, jpoiret: Should it be added to gcc-toolchain? It's not the first time someone needs it, and I'm not sure how I'd write it using -e (which doesn't accept gexps, although I'm not surprised). <justkdng>nckx: don't package have a hash prefix or something? <nckx>Hold up. Are you saying this package installs a PID file or socket? <justkdng>I'm trying to use Arch's pkgbuild as an example <justkdng>it has some systemd files, services, tmpfiles <justkdng>don't know how to translate that to guix <nckx>The ‘hash prefix’ applies only to the store directory, which is where the package is installed after it's built. It's similar to the contents of ‘a package’ (.deb, .whateverarchuses) on other distros. At run time, packages may go nuts, and write whatever they want to /var. <nckx>Although as previously stated we use /run, not /var/run. <nckx>podiki[m]: Our current mesa package builds some dusty DRI drivers to the detriment of their shiny Gallium versions (there can only be one provider), which is weird. <justkdng>ok, it also has a service that executes after it is installed <justkdng>/usr/bin/certutil -N -d sql:/etc/pki/pesign --empty-password <justkdng>should that be run during the build stage? <nckx><it also has a service that executes after it is installed> But that seems to be provided by Arch packagers, not upstream? <nckx>If so, you can happily ignore it. <nckx>justkdng: No, builds can't write outside of the temporary build directory (/tmp/…) or their own /gnu/store/hash-pesign-xxx output directory. <nckx>Guix packages can't create databases in /etc. <nckx>It doesn't look important either. <nckx>Then it should create them, or ask the user/admin to. <nckx>Not leave it to distro packagers. <nckx>The Guix equivalent to the .service file would be a ‘system service’, but those are a (little) bit harder to write than packages, I recommend getting the package down pat first. <nckx>Maybe not harder, just less common & even less well documented. *nckx AFK whilst their X230T heats the room rebuilding mesa & friends. <justkdng>though, they are related to the service files <podiki[m]>nckx: I saw Arch had the same drivers we do (i915, etc) for that flag, so we weren't alone; if I remember correctly now mesa will refuse to build if you specify that as that code is removed <podiki[m]>nckx: I'm not up on all the different drivers and names to know if we are losing actual hardware support or just the older drivers that have been superseded (seems like at least some old hardware is unsupported now?) <podiki[m]>we could also have a mesa variant that uses the alternative branch with those drivers still, but that's only useful for someone to specify a transformation to build all the mesa dependents with it <podiki[m]>justkdng: from what I know that is all towards setting up systemd services, or mostly I think (or e.g. a user meant to run something)...for services look into shepherd if you need to make a service <podiki[m]>nckx: I see core-updates has the libdrm and wayland-protocols version needed for latest mesa, other than that I had to remove the old driver flag and it built successfully last time I tried <nckx>justkdng: Yes, those would also be handled by Guix system services, if they are handled at all. <mitchell>Hello guix, I need to get my hands on an arm-linux-gnueabihf cross compiler. How can I tell guix to build such a thing for me? <maximed_>mitchell: Do you want the cross-compiler, or the cross-compiled software? <nckx>Just for reference, I'm building Mesa-not-22 with "-Ddri-drivers= -Dgallium-drivers=[long list of crap],i915". I don't expect it to break my 2013 ThinkPad at all, since it should be 10+ years newer than the kind of hardware targeted by the deprecation, but I'd prefer to be certain. <maximed_>For the latter, I think you can do "guix build hello --target=arm-linux-gnueabihf" to cross-compile hello. <nckx>Since i915 is what old ThinkPads use, a disproportionate number of Guix laptops will be unaffected if it works 😉 <maximed_>There are methods for just getting just the cross-compiler itself but I don't know how <mitchell>maximed: but say i wanted the xgcc for purposes of guix pack <maximed_>getting just the cross-compiler: has been asked on IRC before, so maybe the logs have some hints <podiki[m]>I think i915 is also on my laptop (a Dell)...which has not run into any problems on Arch <maximed_>Was something about using the cross-gcc procedure and a manifest I think <podiki[m]>I never followed the ups and downs of intel drivers, but I did have to switch at some point away from old buggy ones <maximed_>Going by a comment I vaguely remember from the source code, there used to be convenient TARGET-gcc packages but they were removed because of being unused by GUix. <maximed_>Though given people occassionally ask for something equivalent, maybe they can be reintroduced? <justkdng>hmmm, it seems make install is installing binaries in /usr/bin <nckx>justkdng: Because it honours the ‘prefix=’ make variable. Use #:configure-flags (list (string-append "prefix=" #$output)) and you will be happy. <nckx>Don't worry, it has a silly number of Makefiles to make up for that. <maximed_>#:make-flags (list (string-append "PREFIX=" #$output)) <nckx>Very Red Hat in many ways, this package. <nckx>maximed_: prefix, lowercase. <podiki[m]>nckx: I don't see i915 in e.g. arch's mesa flags, maybe it is built by default? <maximed_>nckx: sometimes makefiles use uppercase PREFIX <nckx>And this one doesn't, so… <maximed_>I don't remember what this package makefile uses. <justkdng> (let ((out (assoc-ref %outputs "out"))) <nckx>maximed_: I did write ‘prefix’ above, you know. <nckx>justkdng: prefix, not PREFIX, nor DESTDIR. <justkdng>without destdir makeinstall tries to write outside of the chroot <nckx>DESTDIR is always a bug, either in the Guix package or to work around an upstream one. <nckx>maximed_: My apologies then. <nckx>justkdng: Then the Makefile is buggy. I did say it was a RH product. <maximed_>I think I actually read that, but somehow dunno. <maximed_>(arguments (list #:make-flags #~(list stuff ...) #:phases #~(modify-phases stuff ...))) <nckx>justkdng: You need (use-modules (guix gexp)) and (arguments (list … #:make-flags #~(list …))) <nckx>Which is probably what maximed_ wrote but with a typo thrown it to keep you on your toes, I dunno. <nckx>podiki[m]: I'm far from an expert, but what exactly is confusing, apart from the length? Maybe I can help. <nckx>justkdng: Just to confuse you further, G-exps are a proprietary Guix® innovation, not found in other Schemes (or even Guile). <mitchell>maximed_: How do I refer to the package created by `cross-gcc` from the `specifications->manifest` form <podiki[m]>nckx: I mean confusing what is included by default or not. Looking at the Arch wiki, i915 page just says plain old mesa, so I want to say that in current mesa i915 is in the default gallium driver set <maximed_>mitchell: You don't. specifications->packages only accepts, well, specifications. Use packages->manifest instead. <maximed_>mitchell: also, for the non-cross-gcc packages, you can use specification->package, to do a mix of specifications and other things <nckx>podiki[m]: …wait, I get what you meant, never mind. <nckx>podiki[m]: Just check? Rather than trust iffy docs. <nckx>maximed_: Then I'm disappointed in myself. <nckx>‘with a typo thrown it’ was not intentional, so I say it counts. <maximed_>I misread that sentence again, I thought you meant _I_ wrote a typo. <justkdng>#:make-flags #~(list (string-append "DESTDIR=" #$output) <nckx>For the third time, it's prefix, not PREFIX. <maximed_>* that -> the sentence ‘Which is probably what maximed_ wrote ....’ <nckx>justkdng: And once that's fixed, share the full error output at paste.debian.net, it helps helping you. <justkdng> 217:50 19 (lp (#<procedure 7ffff29ea9e0 at ice-9/eval.scm:282:?> ?)) <justkdng> 217:50 18 (lp (#<procedure 7ffff29ea9c0 at ice-9/eval.scm:282:?> ?)) <justkdng> 217:50 17 (lp (#<procedure 7ffff29ea960 at ice-9/eval.scm:649:?> ?)) ***ChanServ sets mode: +o nckx
<justkdng> 217:50 16 (lp (#<procedure 7ffff29ea940 at ice-9/eval.scm:282:?> ?)) <justkdng> 217:50 15 (lp (#<procedure 7ffff29ea8e0 at ice-9/eval.scm:649:?> ?)) <justkdng> 217:50 14 (lp (#<procedure 7ffff29ea8c0 at ice-9/eval.scm:282:?> ?)) <justkdng> 217:50 13 (lp (#<procedure 7ffff29ea8a0 at ice-9/eval.scm:282:?> ?)) <justkdng> 217:50 12 (lp (#<procedure 7ffff29ea880 at ice-9/eval.scm:282:?> ?)) <justkdng> 217:50 11 (lp (#<procedure 7ffff29ea700 at ice-9/eval.scm:649:?> ?)) <justkdng> 217:50 10 (lp (#<procedure 7ffff29ea6e0 at ice-9/eval.scm:282:?> ?)) <justkdng> 217:50 9 (lp (#<procedure 7ffff29ea6c0 at ice-9/eval.scm:282:?> ?)) <justkdng> 217:50 8 (lp (#<procedure 7ffff29ea6a0 at ice-9/eval.scm:282:?> ?)) <justkdng> 217:50 7 (lp (#<procedure 7ffff29ea640 at ice-9/eval.scm:649:?> ?)) <justkdng> 217:50 6 (lp (#<procedure 7ffff29ea620 at ice-9/eval.scm:282:?> ?)) <justkdng> 217:50 5 (lp (#<procedure 7ffff29ea600 at ice-9/eval.scm:282:?> ?)) <justkdng> 217:50 4 (lp (#<procedure 7ffff29ea5e0 at ice-9/eval.scm:282:?> ?)) ***justkdng was kicked by nckx (justkdng)
<nckx>Great lag tonight. I typed that at #16. <maximed_>no multi-line backtraces on IRC, use a paste service for that <podiki[m]>nckx: oh, is i915 in the iris driver? I can never keep track of all these weird names <podiki[m]>""i915" is the name of the kernel module - "iris" is mesa's Intel driver (i915/i965 drivers have been removed from mesa >=22..." (from the internet) <nckx>Mmmkay. Yes, this is confusing. <nckx>The ‘Iris’ name is *great*, because having 2 drivers named ‘i915’ would be silly and confusing… but then I had to type ‘i915’ to select it so whut. ***ChanServ sets mode: -o nckx
<podiki[m]>searching back this discussion goes back like 10 years, as the gallium drivers were being developed but the previous i915 was the main one <nckx>They just aren't consistently used? Or is ‘i915[g]’ not quite a synonym for ‘Iris’? Or…? <nckx>I'm beginning to fear justkdng didn't take the kick as purely technical. <podiki[m]>mesa 22 no longer has any i915, so that wouldn't work for mesa 22; prior to that is more confusing <nckx>sneek: later tell justkdng: Welcome back, sorry for the kick, nothing personal. *Please* use the paste service in the topic for posting more than ~3 lines. IRC isn't Matrix; posting walls of text is considered bad form to say the least. <nckx>You mean -Dgallium-drivers=i915 wouldn't work? <nckx>‘mesa 22 no longer has any i915’ was not how I read it. <nckx>I thought only the ancient DRI cruft was being ripped out. <podiki[m]>been a while since I tried, but I believe it won't build specifying the removed drivers (unless you use that other branch they have that still includes that cruft) <podiki[m]>maybe I'm misremembering? but I don't think I modified the configure flags without prompting <nckx>But that's assuming that i915g was removed? <nckx>> having 2 drivers named ‘i915’ would be silly and confusing… <sneek>justkdng, you have 1 message! <sneek>justkdng, nckx says: Welcome back, sorry for the kick, nothing personal. *Please* use the paste service in the topic for posting more than ~3 lines. IRC isn't Matrix; posting walls of text is considered bad form to say the least. <nckx>I do assume the entire flag was removed. 