IRC channel logs

2021-07-12.log

back to list of logs

***xgqtd is now known as xgqt
<leoprikler>brettgilio: tbf I don't do much with vnc, so I can't really help you there
<brettgilio>I am having an issue with the cookbook page shell command on setting up a pure environment
<brettgilio>when it tries to eval the profile envvars it gives permission denied
<brettgilio>not sure why
<brettgilio>its a local profile
<brettgilio>the command in general also just doesnt work as it is written
<brettgilio>`. path/to/etc/profile` doesnt establish the profile, and neither does `source path/to/etc/profile`
<drakonis>brettgilio: foreign system right now?
<brettgilio>nope
<brettgilio>guix system
<drakonis>ah ok
***apteryx_ is now known as apteryx
<char>My patch email was ignored for 2 weeks. What do?
<lfam>What number is it char?
<char>49242
<lfam>I'm wondering how this change affects the minify-build-system
<lfam>The nice thing about the current uglify-js package is that the dependency graph seems to not depend on Javascript. I'm not familiar with how Javascript works in Guix but, in general, I'd guess that quality was seen as important
<lfam>I recommend contacting the people that have worked on the minify-build-system and the uglify-js package to see what they think
<lfam>I'm sure this new uglify implementation can at least be added to Guix
<lfam>char ^
<char>I see why javascript dependencies would be avoided, but the current system will not work for most modern code.
<lfam>Yeah, could be
<lfam>I would discuss it with those people identified by `git log` or `git blame`
<lfam>Or, invite them to the patch ticket
<lfam>Sometimes they are in this channel too
<char>I think you mean M-x vc-annotate 😉
<char>how do I invite them to patch ticket, just CC?
<lfam>Yeah
<lfam>I think it's mainly Ricardo and Pierre N. Let me know if you need help finding their email addresses in the Git history
<lfam>I just got your Emacs joke :)
<char>I got it, thanks.
<char>how do I sign up for patches mailing list?
<lfam>You could subscribe here: https://lists.gnu.org/mailman/listinfo/guix-patches
<lfam>Hopefully people will "reply all", though, so you'll get any replies even without subscribing
<derivedbags>hi, what are the correct steps for making a bootable custom guix system iso?
<derivedbags>I'd like to make a custom iso with emacs and some major modes pre-installed
<jackhill>derivedbags: This is the part of the manual that mentions it, but it looks like it makes some assumptions of the reader: https://guix.gnu.org/en/manual/en/html_node/Building-the-Installation-Image.html#Building-the-Installation-Image perhpas we should add a cookbook entry. In the meantime…
<jackhill>the install.scm that it mentions can be found in the source tree. You can download it and add your custom packages here: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/install.scm#n511
<podiki[m]>derivedbags: actually I think you want guix system image: https://guix.gnu.org/en/manual/en/html_node/Invoking-guix-system.html#Invoking-guix-system
<podiki[m]>where you give it a system configuration (just like a running guix system would have) and it makes an e.g. ufi-raw image you can copy to a usb drive
<podiki[m]>(I've done exactly that to test guix and should iron out the details to add it to the cookbook)
<podiki[m]>and example systems exist in the source (or start with someone's you find online): https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/examples
<podiki[m]>(similar to mentioned above but without installation-services I believe)
<derivedbags>thanks! yes, what i'm interested in is creating a pre-configured image with no guided installer
<derivedbags>podiki[m]: have you tested this command? `dd if=$(guix system image my-os.scm) of=/dev/sdc status=progress`
<podiki[m]>I didn't do it in a one-liner, but basically. I did something like `guix system image --image-type=efi-raw system-def.scm` and then looked at the output at the end for the path to the disk image
<podiki[m]>then `dd` to a usb drive, yes
<podiki[m]>worked great, but haven't had a chance to customize it nor write up a little guide. but that's it really
<derivedbags>podiki[m]: wdyt is missing from the cookbook?
<podiki[m]>and then once it is running you can use it as a system and I guess get it the way you want like that (haven't tried out the details yet)
<podiki[m]>the ingredients are there, but I think this is something we can add to show a cool and useful thing you can do with guix
<podiki[m]>also: you don't have to worry about the filesystem stuff in the system config, `guix system image` will overwrite that as appropriate
<derivedbags>one thing I'd like to do with it is have a pre-configured mumble server that I can just run on vultr straight from the custom iso
<podiki[m]>you can also have the image immediately run things, like for a kiosk (or server), saw that somewhere....
<derivedbags>haven't seen the kiosk yet
<derivedbags>I have seen a kiosk config setup with NixOS but not yet with Guix System
<podiki[m]>found it: https://rendaw.gitlab.io/blog/55daefcf49e2.html#how-to-guix-for-those-who-don-t/creating-a-read-only-bootable-kiosk-usb-image
<derivedbags>can a guix system iso be created from a foreign distro?
<podiki[m]>basically just setting up a custom service to include in the system config
<derivedbags>thanks for linking
<podiki[m]>derivedbags: yes! that's exactly what I did
<podiki[m]>once you have guix installed on a foreign distro (like a package manager) you can that
<derivedbags>can a 64 bit guix system iso be created from a 32 bit foreign distro?
<podiki[m]>my plan is to work a bit on a starting config so when I install guix it'll already be set up
<derivedbags>cool!
<podiki[m]>I haven't tried that, but there is cross compiling support in general
<derivedbags>podiki[m]: have you tried guix home?
<podiki[m]>not yet, but would like to. I already have most of my config as literate org files (and then use stow), but curious how guix home would be
<podiki[m]>`guix system` can take `--system=` to specify what to build for rather than host system type, so that should be what you want
<derivedbags>podiki[m] thanks, I'll give it a try
<podiki[m]>welcome! let us know how it goes or if anything comes up. I think it would be helpful to have in the cookbook with some useful examples of what you can do
<derivedbags>exec /gnu/store/58c67fc6adbjw824zd1ryc00n0fhpw6d-guix-f0eb053da/bin/guix-daemon --build-users-group=guixbuild
<AmyMalik>.. without the exec on the front
<AmyMalik>because that'd replace your login shell
<derivedbags>the above is currently what I have for a runit service
<derivedbags>the issue at the moment besides exec (thanks AmyMalik) is that the store hash changes if I update the guix-daemon
<derivedbags>AmyMalik: although it looks like other runit services are using exec
<derivedbags>what should I use instead of /gnu/store/...hash for my runit service
<derivedbags>some sort of symlink or environment variable?
<derivedbags>that is constant
<AmyMalik>hm
<derivedbags>at the moment I am just manually editing the runit service everytime the hash changes
<derivedbags>which is whenever I upgrade the guix-daemon
<derivedbags>jackhill: what are the assumptions the manual makes of the reader?
<torm84>How to translate guix-manual? I'm translate version.texi, conrtibuting.texi, Top as Top, but my translation does not work.
<MysteriousSilver>Hello, what does the X in (let ((commit ...) (revision X)) ...) mean?
<leoprikler>MysteriousSilver: it's an integer that gets incremented when the package changes
<derivedbags>MysteriousSilver: I've heard it said that it means the x revision since the package entered guix upstream but I might be wrong on that.
<leoprikler>because commit ids can't get compared easily, you need the revision to not accidentally mark a package as downgrade
<leoprikler>s/package/commit/ in my first line
<derivedbags>leoprikler: so the first revision is the first time the package is added to upstream guix?
<MysteriousSilver>leoprikler: ah, now that makes sense
<leoprikler>that depends
<leoprikler>sometimes the package uses whatever notion upstream has of revisions
<leoprikler>g-golf is organised that way and counts commits
<leoprikler>other times it's just how long the (let ((commit ...) (revision X)) ...) line has been kept around
<derivedbags>leoprikler: so the revision number is something determined by the package's upstream not by guix maintainers?
<leoprikler>note that you'd typically reset revision to 0 if a major release was between then and now
<leoprikler>e.g. ("0.7.1" "7" "abcdef") → ("0.7.2" "0" "123456")
<MysteriousSilver>leoprikler: so everytime i change the commit and checksum, the revision is incremented?
<derivedbags>leoprikler: have you packaged anything yet with renpy-build-system?
<leoprikler>yup, everytime you switch to another commit you bump revision
<leoprikler>derivedbags: there is a formulation of the-question, that uses renpy-build-system, in the ML, but since the-question is already an output of the renpy package, none is upstream
<derivedbags>revisions are needed because upstream is not making tagged releases?
<derivedbags>or because the packager wants to package a specific commit?
<leoprikler>I tried packaging some naughty VN for the naughty channel, but that VN was borked in that it probably relied on 6.x and didn't build
<AmyMalik>:)
<leoprikler>derivedbags: it's when you use commits instead of fixed-point releases, but there are also cases when upstream doesn't even tag anything
<derivedbags>I didn't realize there was a naughty channel?
<derivedbags>ohh you mean ***guix?
<leoprikler>well, yeah, there are sadly few free VNs written with Ren'py and most of what exists anyways is gated behind itch.io
<leoprikler>It's part of why I'm writing my own VN engine in Guile.
<derivedbags>cool!
<derivedbags>leoprikler: I want to create a custom iso image that is pre-configured to load a mumble server. I want something that can be uploaded to vultr. What are the steps I should take?
<derivedbags>that is, a custom guix system iso image with mumble pre-configured
<leoprikler>hum, I'd add a mumble-service-type configuration to some bare-bones template and then `guix system image` it
<leoprikler>(or is it murmur-service-type?)
<derivedbags>yup it's murmur
<derivedbags>what image type would I need to choose if I wanted to boot from my laptop?
<derivedbags>iso9660?
<derivedbags>are there any other options I would need to pass for a basic bootable laptop image?
<leoprikler>I think they understood me wrong…
<leoprikler>(context: they /noticed me about the naughty channel and I asked them not to)
<leoprikler>(further context: it's somewhat inevitable that people bring those up, so we usually don't kick those who do unless they do it excessively)
<tissevert>hello guix !
<KittyOwO[m]>hi
***rt is now known as robin
<munksgaard>Good morning!
<soheilkhanalipur>"Activation of network connection failed"
<soheilkhanalipur>😕
<rgr>Hi, I need some help getting started. I need to setuid a guix package. I found here: https://guix.gnu.org/manual/en/html_node/Setuid-Programs.html . But I cant actually find *any* docs on what to edit and where. Pathetic of me I know. It seems you need to know it all before you can get on the ladder to learn it. XY if you will. Im using guix as a package manager and all I want to do is do the guix setuid equivalent for swaylock. Any
<rgr>pointers?
<irfus>rgr: the documentation you linked to applies only to guix system
<irfus>afaik, this isn't possible to do with guix on a foreign distro
<irfus>rgr: if you were using guix system, then that snippet would go into your operating-system config. Read the rest of section 10 for more information.
<rgr>yeah I couldt even find where the operating-system config was. Really, the docs are shocking. Thanks for the help. If I cant setuid the foreign system then its pretty useless. Better to know now than later at any rate. Cheers.
<maximed>sneek: later tell rgr: Too find the documentation of 'operating-system', open the manual with "info guix", and type 'i' and then type 'operating-system'
<sneek>Will do.
<maximed>sneek: later tell rgr: Or type 's' and 'operating-system'
<sneek>Okay.
<maximed>sneek: later tell rgr: If you want to setuid a random binary, you can copy the binary to somewhere and make the copy setuid
<sneek>Okay.
<maximed>sneek: later tell torm84: translation happens at https://translate.fedoraproject.org/projects/guix/
<sneek>Will do.
<maximed>sneek: later tell torm84: Alternatively, you could modify the .po in po/doc/ directly
<sneek>Okay.
<mothacehe>hey maximed! i'm testing the meson serie on core-updates. It applies correctly but i'm hitting a build failure on python-minimal when building openssl or glib
<mothacehe>(natively or cross-compiled)
<maximed>mothacehe: Could you paste the build error?
<maximed>Also, which architecture are you using? I tested this on 'x86_64-linux'
<mothacehe> https://paste.debian.net/1204154/
<mothacehe>yup, tested it on the same arch
<mothacehe>i reverted this one: "python: Fix reference to input when cross-compiling" to see if it helps
<maximed>I haven't seen that error before
<maximed>Odd that the ‘compress-documentation’ phase fails
<mothacehe>yeah that's strange
<maximed>I'll rebuild "python-minimal" with --rounds=LARGE-NUMBER --keep-failed, maybe that will reproduce it
<maximed>Maybe check "dmesg" if there has been an OOM?
<mothacehe>dmesg output looks fine
<maximed>It's rebuilding now with --keep-failed
<mothacehe>maximed: the revert I mentionned above fixes python-minimal build for me
<maximed>mothacehe: Just to be clear: do you mean reverting <https://paste.debian.net/1204155>?
<maximed>I don't see how that would have any effect when compiling natively
<mothacehe>yes, me neither that's so strange
<maximed>mothacehe: If you undo the revert, does it still compile?
<maximed>maybe there is some non-determinism somewhere
<mothacehe>let me try
<mothacehe>i reverted the revert: it fails with the same error
<maximed>I'm stumped
<mothacehe>there's also this warning before the failure which seems abnormal:
<mothacehe>strip: supported targets: elf32-i386 a.out-i386-linux pei-i386 elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex trad-core
<mothacehe>warning: /gnu/store/bkjg8mfncnws4hfzsb5cg4kyf19q2mnc-python-minimal-3.5.9/bin/python3.5m: program "strip" exited with non-zero exit status 1
<mothacehe>
<maximed>Weren't you on a x86-64 system?
<mothacehe>yes I am
<maximed>The warning suggests that "strip" is for i686
<mothacehe>yes indeed: mathieu@meije ~/guix-core-updates [env]$ file /gnu/store/9kjj64nz2ac2gz39r1byyrlp6h4v4ccn-binutils-mesboot-2.20.1a/bin/strip
<mothacehe>/gnu/store/9kjj64nz2ac2gz39r1byyrlp6h4v4ccn-binutils-mesboot-2.20.1a/bin/strip: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.0.0, with debug_info, not stripped, too many notes (256)
<mothacehe>
<mothacehe>even though my %current-system is "x86_64-linux"
<maximed>mothacehe: What commit did you apply the patch series to?
<maximed>in my case, it is ‘gnu: kmod: Add zstd support.’
<mothacehe>on top of 12c2648f4e (doc: cookbook: Adjust example ...)
<maximed>mothatcehe: "guix build --keep-failed" has completed. It didn't reproduce the error you've seen, but apparently python-minimal is not bit-for-bit reproducible
<mothacehe>mmh the python patch triggers the build of python-boot0 which is done for i686 I guess
<maximed>FWIW, do you have the same store path (without the revert): /gnu/store/3la7jyl6nkxlk811ahqml651q0mn8ih3-python-minimal-3.9.5
<efraim>the mesboot bits are 32-bit
<mothacehe>you can trigger it with: ./pre-inst-env guix build -e '(@@ (gnu packages commencement) python-boot0)'
<mothacehe>without the revert my output path is: /gnu/store/3mfc198s8xbdd61vjjdj0zx6xbmcz6n8-python-minimal-3.9.5
<maximed>Actually this is ot unexpected as I haven't ‘gnu: coreutils: Patch broken Gnulib tests’. I suppose I should rebase on current core-updates
<mothacehe>oh no
<mothacehe>it's getting worse
<maximed>mothacehe: Not sure what's happening, but 'guix gc --verify=contents' won't hurt and it could perhaps detect a problem
<mothacehe>gzip is failing because of this syscall: lstat("/gnu/store/bkjg8mfncnws4hfzsb5cg4kyf19q2mnc-python-minimal-3.5.9/share/man/man1/python3.5.1", 0x80ad428) = -1 EOVERFLOW (Value too large for defined data type)
<maximed>Is that directory > 2GiB or something?
<maximed>that's bad and weird
<mothacehe>No that a mesboot error I already hit in the past
<mothacehe>Let me find the bug report
<mothacehe>Happening only on NVME drive IIRC
<maximed>I'm on a spinning disk
<mothacehe>that would be why
<mothacehe>maximed: here it is: https://lists.gnu.org/archive/html/bug-guix/2020-05/msg00335.html
***apteryx_ is now known as apteryx
<maximed>does the patch for "mes" already exist?
<mothacehe>i don't think i went further on that one
<mothacehe>but I can always manage to have python-boot0 built on another machine without NVME to test your series
<fnstudio_>hallo! i just did a guix pull + guix package --upgrade which completed successfully; a few seconds after that i run "guix install an-already-installed-package"
<fnstudio_>i'd have expected that to just terminate saying "already on the most recent version" or something along these lines
<fnstudio_>instead, it told me "The following package will be upgraded: ... (dependencies or package changed)"
<fnstudio_>which was unexpected considering that i'd just done a pull+upgrade
<fnstudio_>is there anything i'm missing either on the pull+upgrade side or on the "guix install" output?
<maximed>"bash" caches the location of binaries that are not called by their full name. Did you do "guix pull && guix package -u"? Then you might need to do "guix pull && hash && guix package -u" instead
<maximed>Otherwise, the package definitions from the old guix are used (IIUC, I don't encounter this situation often)
<fnstudio_>maximed: oh i see, this is new to me, good point
<MysteriousSilver>is it possible to set a different branch for defining packages with git-fetch?
<maximed>MysteriousSilver: set 'commit'
<roptat>hi guix!
<maximed>as described in the manual, it can be a commit id or a tag
<maximed>dunno if branch names are supported
<MysteriousSilver>ah, didn't know it was this simple
<maximed>I would advide against choosing a branch anyway. What if a new commit is pushed to the branch? Then the hash becomes invalid and you need to change the reference
<maximed>or, less technically, branch names aren't good from a reproducibility pov
<maximed>the same argument could be made about tags, as tags can be replaced with tags pointing to new commits, though this happens far less often in practice
<ebubekir-siddik>Hi guix. I'm using the tp-link UB400 bluetooth adapter and I have added "bluetooh-service [#:bluez bluez] [#:auto-enable? #t]" to my system.scm. But am not able to use bluetooth. What is the problem? The tp-link UB400 works fine on Trisquel with linux-libre kernel.
<maximed>ebubekir-siddik: What precisely is not working?
<maximed>‘I am not able to use bluetooth’ is rather vague
<maximed>In any case, don't forget to "guix system reconfigure system.scm" after modifying system.scm
<maximed>And maybe reboot. Not all modifications require a reboot to take effect, but some do, and maybe adding 'bluetooth-service' is one of them
<jlicht>ebubekir-siddik: do you happen to use gnome? The bluetooth settings in gnome have never worked for me
<jlicht>(on Guix System, that is)
<Noisytoot>GNOME's bluetooth settings haven't worked for me either on Guix
<jlicht>This did not prevent bluetooth from actually working for me, but of course YMMV
<roptat>I remember having bluetooth issues in the past, and this was simply because it was disabled, I had to use bluetoothctl (or a similar command name) for that
<fnstudio_>hi, i seem to be having problems with a utility called passmenu (from password-store); if i launch it from the command line, i receive an error about passmenu not being able to find a few dependencies (e.g. dmenu and xdotool) at the expected location in the guix store
<fnstudio_>i get that even after an pull+upgrade
<fnstudio_>anyone has experienced something similar? does it sound as a potential issue with password-store or something i might have misconfigured at my end?
<lfam>I don't use password-store but that definitely sounds weird
<fnstudio_>right, i can try and downgrade to a prev version
<lfam>How could it know the store paths if they don't exist?
<lfam>Can you check if they exist?
<fnstudio_>lfam: sure, let me see
<lfam>`guix gc --references $(guix build --no-grafts password-store)`
<lfam>That will print the "references" to the "store items" that Guix registered for password-store
<lfam>It does keep references to dmenu and xdotool
<fnstudio_>lfam: yeah the path does exist, but... the way this shows up in the passmenu scripts seems to be misinterpreted by my shell (possibly because it contains a = sign?)
<fnstudio_>let me see if i find a relevant link to the source code
<lfam>Okay. Are you using a weird shell?
<lfam>fnstudio_: I see the code here
<fnstudio_> https://git.zx2c4.com/password-store/tree/contrib/dmenu/passmenu#n15
<lfam>It looks like a variable assignment?
<lfam>But... weird
<fnstudio_>lfam: nah, just an ordinary bash
<lfam>Oh, I mean it's weird after Guix "builds" it
<fnstudio_>*if* i understand what might have happened, is that dmenu gets replaced twice
<lfam>The build phase 'patch-passmenu-path' does the wrong thing
<fnstudio_>as the way that piece of code becomes visible at my end is long-dmenu-path=long-dmenu-path
<lfam>Maybe it used to work, and the upstream code changed? It's a problem with Guix code substitutions is that they fail silently
<lfam>Anyways, the substitution should probably match something like "=dmenu-wl", not "dmenu"
<lfam>Similar for the xdotool thing
<fnstudio_>exciting, i stumbled into a small glitch, ok, so i'll try and open a bug request later, if you think that could be the way to go?
<lfam>Yeah
<lfam>It looks like a simple fix
<fnstudio_>brilliant, thanks lfam
<lfam>I have to go afk for a bit or I'd "just do it"
<lfam>Thanks for poking at this :)
<fnstudio_>oh ok, that's also an option... maybe i could re-mention it here later if you or somebody is around and we could try and do that together (people's time permitting)
<lfam>I think it's good to file the bug
<fnstudio_>lfam: ty of course!
<lfam>Bonus points if it includes a patch :)
<lfam>Or maybe somebody else here will pipe up
<fnstudio_>deal!
<fnstudio_>with regard to my issue with passmenu maybe something like this: https://paste.debian.net/1204177/ ?
<fnstudio_>but i'd need to see what the process is to have that tested and then submitted, i'll try and pick somebody's brain here later
<maxwell_TGAP>I have a strange problem and im not sure if its guix or not
<maxwell_TGAP>I have a file that is marked as exacutabel
<maxwell_TGAP>but when i try it complains that "No such file or directory"
<maxwell_TGAP>even though I use the same path to ls it
<maxwell_TGAP>ive never seen anything like that
<maximed>maxwell_TGAP: probably the program is trying to opening a file that doesn't exist before it can really start running
<maximed>is this program built with guix?
<maximed>Does the file start with "#!/bin/SOMETHING" or the like?
<maximed>If so, you could verify /bin/SOMETHING exists
<maximed>you could also try "strace ./the-program" and use the output to determine what's going wrong
<maximed>If the program comes from guix ("guix package -i", "guix build ...", or the like), then you shouldn't see such an error
<maxwell_TGAP>It is from a python package that i installed with pip because it wasnt in guix
<maxwell_TGAP>and its a binary
*maximed afk
<roptat>maxwell_TGAP, you can't execute arbitrary binary files in guix, because they won't find a linker
<roptat>like, if it's an elf executable file, it won't find /lib/ld.so, because it doesn't exist
<roptat>which results in "no such file or directory"
<roptat>(and that is very confusing!)
<maxwell_TGAP>hummm
<maxwell_TGAP>sym link?
<dstolfa>maxwell_TGAP: you can expose it as a special file in your system configuration
<maxwell_TGAP>the executabel?
<maxwell_TGAP>or ld.so
<dstolfa> https://guix.gnu.org/manual/en/html_node/Base-Services.html
<dstolfa>the linker
<dstolfa>see special-files-service-type
*maxwell_TGAP reading
<maxwell_TGAP>so i need to add `("/lib/ld.so" ,(file-append ld '/lib/ld.so))
<maxwell_TGAP>to the serveces bit in my configeration.scm
<roptat>the exact name depends on the architecture, you can find that with "ldd <the-binary>" for instance
<roptat>(ldd is part of glibc)
<roptat>I think "file <the-binary>" will work too
<roptat>and then, you might have issues with shared libraries that are not in /lib either...
<maxwell_TGAP>I dont realy know how to interpret that output
<maxwell_TGAP>it seems to fine a load of things but then stats failing
<maxwell_TGAP>first failed thing is libX11.so.6 => not found
<maxwell_TGAP>then its => not found for alot of most of the rest of the file
<maximed>maxwell_TGAP: "guix import pypi THE-PACKAGE" might be simpler
<maxwell_TGAP>oh hummm
<maximed>is "pip" source-code on ‘binary’-based?
<maxwell_TGAP>the python library downloads a binary the first time you run it "its not nice but i need it for work"
<maxwell_TGAP>so im not sure if pip is even awear whats going on with it
<maximed>the library code downloads a binary from somewhere? That's unusual
<roptat>it's not that unusual, it happens with libenchant, pyqt, ...
<roptat>they download a precompiled enchant or qt
<roptat>it's not part of the package though, it's just pip downloading a binary as a depenedncy
<roptat>so guix import works mostly as expected, except you have to add the dependency to the package providing the library yourself
<maxwell_TGAP>so I run guix import pipy <package> and pipe the output into a .scm file in my $GUIX_PACKAGE_PATH
<maxwell_TGAP>then add lines to the head of that package to get the right dependencies
<roptat>sounds right
<Noisytoot>pypi, not pipy
<maxwell_TGAP>I did that and i added some basic dependencies, now when I do a guix search i recive an error pointed at the new package file
<maxwell_TGAP>warning: source expression failed to match any pattern
<maximed>that probably means there is a syntax error
<maxwell_TGAP>is there a package.scm debugger?
<maximed>No, and not sure what such a debugger could do
<maximed>when you do "guix build -f package.scm", does it succeed?
<maximed>If not, what's the error?
<maximed>The error message + backtrace might be more informative than the warning
<maxwell_TGAP>it fials with a source expression failed to match any pattern
<maximed>and there should be line number information, and it should they you _which_ source expression failed to match any pattern
<maxwell_TGAP>it prints out a line whish is the whole define-public form
<maximed>probably a missing parenthese --- (define-public NAME VALUE) is valid, but (define-public NAME ANOTHER-VALUE) isn't
<maxwell_TGAP>ohhh i thought it wrapped the package form
<roptat>(define-public package-name (package ...))
<roptat>it's a guile syntax to declare a variable, like (define-public variable-name variable-value)
<maximed>‘Someone’ should make the syntax error messages in Guile more informative for these relatively frequent mistakes
<maxwell_TGAP>great i think its nearly working
<maxwell_TGAP>its failing to find the license
<maxwell_TGAP>license:expat
<maxwell_TGAP>I have in the passed just wraped the licence value in "" but thats not a good solution, is there a way to look up/add licenes to guild
<maxwell_TGAP>guile*
<maximed>'expat' can be found in (guix licenses) or asomething like that (not sure about the module name)
<maximed>You'll need to import the module, possibly using #:prefix license: (if you want to write license:expat instead of expat)
<maximed>*asomething->something
<apteryx>sanity check: fontconfig provided by Guix does *not* lookup host fonts, correct?
<apteryx>(e.g., on a foreign distribution)
<maximed>I'd think fontconfig provided by Guix looks at some kind of environment variable
<maximed>so if the host sets that environment variable, then fontconfig would look there
<apteryx>it used to be hard-coded to lookup only in ~/.guix-profile and /run/current-system/share, I think
<maximed>but I'm not familiar with fontconfig
<maxwell_TGAP>how do you use #:prefix?
<apteryx>on core-updates, if we use the latest version, it should know to use XDG_DATA_DIRS
<maximed>maxwell_TGAP: see Guile documentation on the module system
<apteryx>perhaps also ~/.fonts
*maxwell_TGAP is reading the documentation
<maximed>maxwell_TGAP: from a terminal: info '(guile)Using Guile Modules'
<maximed>(to read the documentation)
<roptat>maxwell_TGAP, (use-modules ((guix licenses) #:prefix license:))
<podiki[m]>for those of you running a custom guix channel (as in channel 'guix), how do you handle the authentication? or do you disable? I've mirrored the repository and made a separate branch so far
<sneek>Welcome back podiki[m], you have 1 message!
<sneek>podiki[m], irfus says: Thanks for going ahead and updating the patch, and also putting the email on guix-devel!
<roptat>or, for a module declarition (define-module #:use-module ((guix licenses) #:prefix license:) ...)
<podiki[m]>sneek later tell irfus welcome! I figured separating out changes from the version update would make it easier to get merged, but still waiting to see what happens
<sneek>Got it.
<podiki[m]>sneek snack
<Noisytoot>sneek: botsnack
<sneek>:)
<maxwell_TGAP>I have both the pdf docs and the info docs but there seems to be more in info then in the pdf
<maxwell_TGAP>when I guix build -f the package i get an error error: Could not find suitable distribution for Requirement.parse('websockets<9.0,>=8.1')
<maxwell_TGAP>does this mean I repeat the prossess for websockets
<podiki[m]>python-websockets exists (v8.1)
<podiki[m]>may need to specify it as an input then, with that name
<podiki[m]>hmm, does `guix pull --disable-authentication` does that for all channels huh? what does one do to authenticate custom guix (diverge from keyring branch to add your own while keeping others?)
<lfam>Did you read this yet, podiki[m]? <https://guix.gnu.org/manual/devel/en/html_node/Channel-Authentication.html>
<lfam>The followup section is <Specifying Channel Authorizations>
<lfam>Err, <https://guix.gnu.org/manual/devel/en/html_node/Specifying-Channel-Authorizations.html>
<podiki[m]>yes. but I'm setting the channel as 'guix (custom branch)
<podiki[m]>so presumably i'll need to keep all the original keyring stuff when I want to pull new updates from upstream
<podiki[m]>but I guess I can just add myself to the keyring branch, diverging from upstream and needing to manage manually
<podiki[m]>? does that make sense?
<lfam>I'll let somebody else answer... I'm actually not using channels yet (aside from the primary Guix channel, I suppose)
<roptat>I don't think that would work
<roptat>the commit that adds your key to the keyring branch must be signed by a key that was in the keyring branch before that
<roptat>(we also authenticate the keyring branch :p)
<roptat>so, I'd say avoid authentication entirely by not adding an introduction to the channel specification
<roptat>I don't have this issue, I use the official guix repository, so maybe there's some other way
<dstolfa>has anyone managed to build gcc from source on guix?
<dstolfa>it keeps asking for /usr/include, which i could set manually, but there has to be a better way
<podiki[m]>roptat: gotcha, did seem tricky
<podiki[m]>roptat: hmm, but i don't have an introduction in the channel.scm .... maybe cause the .guix-channel file specifies a keyring?
<roptat>it's part of the %default-channels I think
<podiki[m]>(it fails with channel 'guix' lacks introduction...)
<roptat>ah
<podiki[m]>i specified channels as a list explicitly
<roptat>yeah, maybe the .guix-channel is an issue here
<podiki[m]>because you should be able to mix channels that have authentication with those that don't presumably? or maybe 'guix channel is special (will investigate...)
<podiki[m]>hmmm..."guix" channel indeed treated separately
<podiki[m]>yeah so I think you can't have an unauthenticated guix channel, which means can't have a custom "guix" channel with authentication without altering guix?
<cybersyn>when I try to run guix pull I get error: bind: permission denied, is anyone else experiencing this?
<roptat>podiki[m], maybe you could set the introduction to the latest commit?
<podiki[m]>i would still need my key in the keyring, but I guess then it won't matter since i'll just be introing after setting up the key?
<podiki[m]>roptat: ah, that worked! just added the introduction to current commit with the key I used to sign it (didn't add the key to keystore)
<mekeor[m]><dstolfa "has anyone managed to build gcc "> maybe someone from the bootstrappable project can help you