<rekado>this is the first time that I see understandable instructions on how to prepare the SD card and set up the u-boot boot script <rekado>I’ll try to adapt this for Guix. <vagrantc>rekado: looks like it relies on using just one "special" partition to install u-boot too, and then an offset for the other partition? <vagrantc>rekado: seems like a simple workaround for partitioning tools not liking some of the partitions to begin too early ***the-porcupirate is now known as porcupirate
<vagrantc>rekado: though that uses a boot script, which honestly seems more complicated than the extlinux.conf generation already present in guix <vagrantc>rekado: you still having issues using guix to write to the device offsets? ***the-porcupirate is now known as porcupirate
<atka>oof 61 dollars to ship honeycomb lx2 ***rekado_ is now known as rekado
***Noisytoot_ is now known as Noisytoot
<xelxebar>Turned out to be really simple. Just needed to include an extra native input. <anadon>Who here has moderate experience with scheme so I can fix up a package as requested? Me and my dumb brain needs a little help. <anadon>Guile, not scheme. It has been a long day with not enough sleep. <xelxebar>anadon: FWIW, there's also the #guile channel. <mbkamble>Guix noob here. I am trying to use guix home to configure my user env. How do I configure gnupg? Do I need to use rde channel to get module (gnu home-services gnupg) ? Or is it already part of guix? <xelxebar>mbkamble: It looks like that module isn't in the main repo. <xelxebar>Module paths mirror their names, e.g. (gnu home-services gnupg) would be under gnu/home-services/gnupg.scm <xelxebar>There are a few files called gnupg.scm under different paths, but these might not be what you're looking for? <mbkamble>Keeping aside my previous help request related to module (gnu home-services gnupg) .... I am facing a grub update error when I did a "guix pull" followed by "sudo -E guix system reconfigure ~/.config/guix/system.scm". I have not changed any of the expressions realated to (bootloader ...), (mapped-devices ...), (swap-devices ...) and (file-systems <mbkamble>...). The only changes were the addition of a %xorg-libinput-config and corresponding change to (xorg-onfiguration...) and addtion of rde, flat and guix-emacs channels. <mbkamble>mbkamble@kamble9343guix ~> sudo -E guix system reconfigure ~/.config/guix/system.scm <mbkamble> /gnu/store/z2ra4p5ds0k15jcbq5mqr0pcsfs7fwgp-grub.cfg.drv <mbkamble>building /gnu/store/z2ra4p5ds0k15jcbq5mqr0pcsfs7fwgp-grub.cfg.drv... <mbkamble>making '/gnu/store/ccccppsc70nmx3pgm0fjy442mrm9r1q7-system' the current system... <mbkamble>setting up setuid programs in '/run/setuid-programs'... <mbkamble>populating /etc from /gnu/store/rz04avv1j4lgk2araqfix9vl2ayqhn91-etc... <mbkamble> /gnu/store/dwdc27c2nal3prnax14r7qkb21pij3xb-install-bootloader.scm.drv <mbkamble>building /gnu/store/dwdc27c2nal3prnax14r7qkb21pij3xb-install-bootloader.scm.drv... <mbkamble>guix system: error: '/gnu/store/82c6j55hmj8zlr4586m3xc6jisa16cvi-grub-efi-2.06/sbin/grub-install --boot-directory //boot --bootloader-id=Guix --efi-directory //boot/efi' exited with status 1; output follows: <mbkamble> Could not delete variable: Invalid argument <mbkamble> /gnu/store/82c6j55hmj8zlr4586m3xc6jisa16cvi-grub-efi-2.06/sbin/grub-install: error: efibootmgr failed to register the boot entry: Block device required. <jpoiret>it looks like the boot directory has a doubled slash <jpoiret>we'd need to see your config to diagnose further i think <rekado>atka: not only shipping is expensive; I also had to pay a lot for customs and tax. <atka>rekado: I wonder what our import duties are <rekado>apteryx: downtime for berlin has been averted. The SAN extension is complete. We’re now waiting for RAID rebalancing. We’ll extend the SAN share for berlin after Easter (which I’m told is some time soon). *attila_lendvai appreciates the quick response ***bjc` is now known as bjc
<reza[m]>I try to package apache jackrabbit and stumbled upon this error: `Throw to key `no-such-input' with args `("javax.jcr" "jcr")'.` has anyone an idea what the issue is? <jpoiret>reza[m] looks like you're passing an input like this ("javax.jcr" "jcr") whereas it should be something like ("javax.jcr" jcr) <jpoiret>it would help though if you could paste.debian.net your package definition <reza[m]>the problem is in `find-deps` function of the `maven-build-system` <reza[m]>do I have to patch the pom.xml file manually? <jpoiret>i'm not familiar with the maven build system, although from a quick glance i can't find the `find-deps` procedure you're talking about, any idea where that is? <jpoiret>it might be that you have to edit the pom.xml file manually, yes <reza[m]>it is in the guix/build/maven/pom.scm file <reza[m]>jpoiret: sorry it is called *fix-deps* <reza[m]>I'm also not familiar with the build system and there seems to be only one package in guix using this build system <jpoiret>hmmm, it looks like something else rather, is there something under lib/m2/javax.jcr/jcr? <reza[m]>there is a line ("java.jcr" "jcr") listed as dependecy in a pom.xml file which causes the error <jpoiret>that's where the build system tries to look for the dependency <reza[m]>jpoiret: you mean in the build output of java-javax-jcr? <reza[m]>jpoiret: no there's only `share/java/javax-jcr.jar` <reza[m]><jpoiret> "that's where `find-packaged-..." <- I don't understand this code <jpoiret>basically, it looks for groupname/artifact under lib/m2/ of the package inputs <jpoiret>disregard that, ant-build-system generates it itself <jpoiret>well, my knowledge of java build systems doesn't seem to be enough, maybe someone else will know the answer to this <jpoiret>to me, it seems that ant-build-system produces a .jar file, but maven-build-system expects dependencies to be in maven repository form (whatever that is) <reza[m]><jpoiret> "to me, it seems that ant-build-..." <- ok will investigate a little more, thanks for your help! <jpoiret>maybe roptat will be able to help you when he comes online, he's the author of the guix maven build system <yewscion>I've recently switched to using a large number of smaller texlive packages from the large monolithic one, and in the process have created 21 new packages (all parts of texlive I needed for my personal workflow, or programs that that workflow depends on tangentially). If I want to contribute them the Guix, do I open up a single patch for all of them <yewscion>(as they would all be modifying the same file in the Guix repo)? Or is there a limit to the number of packages one can submit in a single patch? <apteryx>rekado: OK, great! thanks for the update <reza[m]><jpoiret> "maybe roptat will be able to..." <- good to know, will try to catch him <attila_lendvai>any ideas? a golang module doesn't register a required dependency, and the module using it is supposed to record the right version as a dependency. what shall i do? i guess something like crate's #:skip-build? is needed here, no? <attila_lendvai>if i record the dependency, and thus pick a specific version of it, then i'm changing the semantics... <jpoiret>sneek, later tell yewscion: one package per patch is the norm <attila_lendvai>err, scratch that! the dependency is present, but not in a go.mod, but in a Gopkg.toml, i.e. something ancient that the importer ignores without any warnings <tribals>To where guix unpacks package source? I've about ~30G of free space on filesystem where /gnu/store is located but tried to build ungoogled-chrome, and it fails when unpacking soruces <tribals>Is chromium sources bigger than 30G? <zimoun>rekado: I think your recent update from 5 to 6 of python-pyyaml breaks a lot of packages. See #54866. <zimoun>such update is for core-updates I guess. Do we revert? <jpoiret>tribals: to a tmpfs in a mount namespace, so you can't really see it <jpoiret>but yes, browser sources are usually very big <attila_lendvai>does the go-build-system reuse build artifacts, or does it include dependencies as source? <jpoiret>attila_lendvai: same as rust, it does not <jpoiret>at least, i think that was the case last time i checked <attila_lendvai>jpoiret, but it does build the dependencies, and then throws away the result... it should support a #:skip-build? also, right? <tribals>jpoiret: So if it is tmpfs, I definitely don't have enough RAM to unpack whole chromium sources )) Is there a way to change unpack location? <jpoiret>in any case, golang only supports static linking iirc <jpoiret>tribals: i think tmpfs is also supported by empty space in regular drives, but i might be wrong on that <jpoiret>and no, there won't be any easy way to change unpack location, since that's mostly guix daemon internals <jpoiret>i'll actually check the sources so that we have a definitive answer tribals *attila_lendvai is adding #:skip-build? to go-build-system <zimoun>tribals: thanks for the pointer. *attila_lendvai continues happily using the new #:skip-build? <tribals>Just fall in the same trap couple days ago <jpoiret>okay, rather, the chroot dir should be created in the store <attila_lendvai>i'm wasting so much time because guile backtraces are hiding too much information by default... <attila_lendvai>it happens in an invocation of guix build, and i have no idea how to convince guile to give me more info <attila_lendvai>there should be a switch to enter the guile debugger to begin with... <attila_lendvai>the guix codebase in general is not very principled about error handling, and it's eating up a lot of programmer efficiency <mekeor[m]>in the "simple-scan" program (from equally named package), icons aren't shown to me at all. how to fix this? <lispmacs[work]>mekeor[m]: I'm just guessing, but I was wondering if simple-scan uses icons from your DE, and also if your "guix package" install and "guix system" are in sync (i.e., from the same guix commit) <lispmacs[work]>like, if you had an older Gnome DE, but a newer simple-scan package, if that might be an issue <lispmacs[work]>I just install ran simple-scan from guix shell but icons all seem to be present <apteryx>tribals: chromium sources are more like 4 GiB IIRC <tribals>> You can influence the directory where the daemon stores build trees via the TMPDIR environment variable. <tribals>But can't figure out how to set this variable for guix builder <mekeor[m]><lispmacs[work]> "I just install ran simple-scan..." <- thanks for checking. i use xmonad... also, i launch X manually with "xinit", including many cli args. maybe i miss some args for icons... ***yewscion is now known as Guest477
***yewscion19 is now known as yewscion
***iyzsong- is now known as iyzsong
<attila_lendvai>this breaks the guix codebase with: warning: failed to delete .git/refs/tags/v??.2.0: No such file or directory <vagrantc>this is 2022 and you're complaining about using unicode? :) <attila_lendvai>vagrantc, i wouldn't even mention if guix handled it without a glitch... installing glibc-locales now to root, hoping that it will fix it <vagrantc>well, yeah, i was more saying that sounds like a bug in guix <attila_lendvai>i'm still getting "guile: warning: failed to install locale" from the daemon. installed glibc-locales, reconfigured, and restarted guix-daemon ***robin_ is now known as robin
<attila_lendvai>vagrantc, doing a guix build on a golang package that i have just imported (with local fixes to the go importer) <attila_lendvai>vagrantc, but it's some git operations. cleaning up .git/ failes, and then the hash mismatches <attila_lendvai>vagrantc, i think the issue is that the guix daemon is running with the wrong locale, at least on my computer <vagrantc>so ... a guix build somepackage is failing to checkout the source? <vagrantc>yeah daemon's locale != user's locale != root's locale <attila_lendvai>vagrantc, it checks it out, but then fails to delete the .git repo before calculating the hash <vagrantc>yeah... sounds worth filing a bug in guix about it ... <attila_lendvai>the guix-daemon is not guile code, but is spawns guile when building, and i think that guile is printing the warning <vagrantc>especially since that might break builds that previously worked by upstream adding a new tag triggering this issue <attila_lendvai>debbugs is so unleasant, that i'll spend a few minutes trying to fix it first... :) <vagrantc>ugly workaround would be to fork the repository, delete the tag, and use the fork ... but that's ... awful <vagrantc>although, for filing a bug, it's literally just sending an email to bug-guix@gnu.org ... <attila_lendvai>vagrantc, it's not just debbugs, but also collecting enough information that the report gets some attention <ekaitz>hi guix! how am I supposed to run `guix shell --export-manifest` to make something show up? <ekaitz>if i do something like `guix shell --export-manifest guile guile-sdl2` the manifest it generates is basically nothing <ekaitz>it's a comment and a (concatenate-manifests) <djeis>Is it normal for guix pull to error when you've added channels but your commit on the main guix channel is already up to date? <djeis>The rollback safety logic is blocking the pull, if I've interpreted the output correctly, but it's complaining about an update from a commit hash to that same hash. <djeis>If that's expected behavior then I'll happily add --allow-downgrades and be on my way, I just want to make sure I haven't accidentally broken something somehow. <yewscion>Hello All, I'm trying to cross compile Guix 'core' (native x86_64, target aarch64) on my home server's Cuirass, and a specific package (coreutils-boot0) keeps failing. The log says `/gnu/store/x5rmkdv5zkl2nxg5ahai10drpm2gc5cz-glibc-bootstrap-0/include/sys/prctl.h:22:66: fatal error: linux/prctl.h: No such file or directory`. Am I overlooking <sneek>Welcome back yewscion, you have 1 message! <sneek>yewscion, jpoiret says: one package per patch is the norm <atka>rekado: do the sfp+ cages on the honeycomb work with the linux-libre arm kernel? do you know of any functionality that doesn't work when using guix on the honeycomb? <atka>cbaines: would you care to share your experience with guix on the honeycomb? pros/cons? <daviid>rekado: intentionally not in #guile? wanted toask is thecode for gix/guile loggers available somewhere, public repo imean <rekado>daviid: I left most IRC channels and mailing lists because I can’t keep up <rekado>sneek: later tell zimoun I built everything out on wip-pyyaml and fixed problems as I saw them. It’s hard to compare failures across branches with cuirass. Those failures I checked were present on the master branch as well. <rekado>atka: I haven’t tested any of the cool networking hardware on the honeycombs <rekado>we’re using them almost only for their CPUs. <rekado>atka: is there something you’d like me to test? I could share some output with you.