IRC channel logs

2021-01-11.log

back to list of logs

<alextee[m]>how can i get the pwd in a package definition?
<alextee[m]>or the package "work dir"
<alextee[m]>hmmm i should probably write a basic packaging guide (or tips) to save all this info somewhere
<ryanprior>alextee: you shouldn't use any absolute references to the working build directory, because it won't be there on the target machine.
<ryanprior>alextee: you can get the absolute path to the package's output directory using (assoc-ref %outputs "out") or substitute some other string for "out" if you have multiple outputs.
<alextee[m]>ryanprior: im building a weird package where i need to go into a dir in the input's source and invoke something which creates files but it wont let me
<alextee[m]>but i did something else, i made a separate package for the input now
<ryanprior>alextee: here's an example of where I go into the directory of my package source and modify some files for a build https://github.com/ryanprior/guix/blob/master/gnu/packages/vlang.scm#L127-L130
<alextee[m]>(the input was an (origin))
<ryanprior>that linked page also has two inputs that are origins
<alextee[m]>but you are susbtituting files in the main package's sources right?
<alextee[m]>i wanted to do something with the input's sources, not the main package
<alextee[m]>i think that's not supposed to be allowed
<ryanprior>You can copy files from your inputs into your own build tree and make changes to them there.
<ryanprior>Or you can use a gexp that creates a new derivation of the input with the changes that you need.
<alextee[m]>yeah i was thinking to copy files into the build tree, that's why i wanted to get the (absolute ) path to it
<alextee[m]>it was a Makefile and i was trying to change the build dir it was using to the package's build tree
<ryanprior>Here's a section of a package definition where I get the path to an input so that I can generate some files from it: https://github.com/ryanprior/guix/blob/master/gnu/packages/golang.scm#L6479-L6491
<ryanprior>In that case I do not copy it into my own tree but rather modify my source generator script to use the path to the for codegen.
<alextee[m]>ooh unpack-path ? is this it?
<ryanprior>Unpack-path is a thing in the go-build-system, other build systems do not have unpack-path afaik.
<ryanprior>(string-append (assoc-ref inputs "libsass-src") "/src") evaluates to the absolute path of my libsass-src package input
<alextee[m]>ah i already know how to get the input path
<alextee[m]>what about the path of the current package?
<alextee[m]>it's the current dir but idk how to get its path
<ryanprior>notice that I do not need it
<alextee[m]>because you do "../.." ?
<ryanprior>That's some literal text from the codegen config that I replace with the path to my input.
<ryanprior>The original package vendors its own source code for libsass, while for the Guix package we want to use the libsass that's in Guix, not the vendored one.
<ryanprior>So I strip out the reference to the vendored source (../../libsass_src in the upstream package) and substitute it with ours (libsass-src, which I let-bind above)
<alextee[m]>ah yeah that sounds a bit different
<alextee[m]>i actually wanted to build a binary from the input and then use that to "compile" something in the main package
<ryanprior>I'm not sure I'll be able to find an example that's exactly like what you're doing. Just trying to give hints :)
<alextee[m]>yeah i ended up making a separate package for the input so it's fine
<alextee[m]>still curious how to get the package's build dir though
<ryanprior>It really sounds like you made the right choice to create a full separate package.
<lfam>There is a procedure (getcwd)
<alextee[m]>right!! that's it
<alextee[m]>i remember using it before
<ryanprior>Yeah it's used in hundreds of packages. But typically you don't need it, and it's possible to create a broken package by misusing it.
<bdju> https://github.com/mvdan/xurls would love to see this packaged. apparently foot (terminal emulator) needs it to interact with on-screen URLs
<ryanprior>bdju: I'll give it a shot
<bdju>thank you! not sure how hard it will be. it looks like a simple tool but not sure what goes into the packaging process exactly
<ryanprior>I'm not sure either. Are you interested in learning packaging? Want to pair with me on it?
<jgart[m]>I'd love to join. Do you have room for three?
<jgart[m]>It looks like go-internal is already packaged https://github.com/mvdan/xurls/blob/master/go.mod#L5
<ryanprior> https://meet.jit.si/Yg42I0Mr/XurlsPackaging
<jgart[m]>is that the only dep needed?
<jgart[m]>I'll be in now. give me 5 min
<jgart[m]>did you gen that with https://github.com/ryanprior/meet ? ha
<ryanprior>I did indeed =D
<bdju>ryanprior: I want to learn at someday probably, but not now
<bdju>s/at/it
<ryanprior>bdju: packaged at https://github.com/ryanprior/guix-packages/blob/master/testing/xurls.scm#L12-L39
<ryanprior>The package isn't ideal, in that I couldn't figure out how to get the tests to run
<ryanprior>But I checked it with the example from the xurls repo and it appears to work
<raghavgururajan>apteryx: I think we can close the bug (38557) after complete merge of commits from wip-desktop to master.
<raghavgururajan>dannym: Are you available at the moment?
<bdju>ryanprior: thanks, I don't remember what to do with this, but you wrote that blog post I can look at later. although whatever package I was testing last time I couldn't figure out how to use it by just running it normally. I had to supply a long path iirc. going to bed soon but will maybe dig into that tomorrow
***iyzsong-- is now known as iyzsong-w
<joshuaBPMan>hey guix! whoever updated sway to the latest version, thanks!
<joshuaBPMan>It's much smoother.
<raghavgururajan>joshuaBPMan: Seems like it was mbakke (https://git.savannah.gnu.org/cgit/guix.git/commit/?id=7fc378aa7bc1fff5d87ed993205a1e825a7872d9). :-)
<dannym>raghavgururajan: Yeah
<sneek>dannym, you have 1 message!
<sneek>dannym, raghavgururajan says: What shall we do regarding the wip-desktop patches that was reverted in master? I think you were mentioning something about building on a ryzen system. Any luck?
<ryanprior>Speaking of updating to new versions, I sent in a new version of vlang on Dec 1, and a new new version on Jan 1, and neither of them has seen a review or any commentary yet.
<ryanprior>If anybody wants to take a look I'd appreciate! https://issues.guix.gnu.org/45601
<raghavgururajan>dannym: Is core-updates still broken or no?
<dannym>raghavgururajan: I'll know in a week or two
<dannym>Currently waiting on a internal power supply cable from the USA...
<raghavgururajan>Ah okay.
<raghavgururajan>dannym: Btw, would you be able to rebase master into wip-desktop? The latter would be too old by now right?
<raghavgururajan>I meant master --> wip-desktop (not wip-desktop --> master).
<nij>The source of gnu-build-system contains '(lower lower).. what does this meaning? http://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/gnu.scm#n615
<nij>lower as a function is defined in http://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/gnu.scm#n276
<nij>How about the second 'lower?
<ryanprior>nij: each build system defines a "lower" function. The first "lower" is just a symbol (like "name" above), not a function. Then the second "lower" refers to that function defined above.
<dannym>raghavgururajan: I'll have a look at rebasing
<raghavgururajan>dannym: Thanks!
<nij>ryanprior: OH that makes sense. Thanks so much !
<nij>How does "lower" get its name @@
<ryanprior>Don't know on that one, maybe it's inherited from Nix, maybe it's a Scheme thing or a term used in some domain of computer science?
<nij>I see. #'lower returns a bag. "A bag is like a package, but with less ornamentation—in other words, a bag is a lower-level representation of a package, ", hence the name.
<nij>Ref: https://guix.gnu.org/manual/en/html_node/Build-Systems.html#Build-Systems
<nij>------------------
<nij>I really want to understand all the magic under #'define-public. Are there some tricks to see how '(define-public hello...) expand?
<nij>I find it very slow and tricky to read the source through webpage..
<nij>(In particular, the build-system field.)
<iyzsong-w>From 'info guile', (define-public foo ...) equivalent to (begin (define foo ...) (export foo))
<iyzsong-w>then the (package ...) form just make a record
<nij>Tbh I haven't got guile's tooling. Do you recommend me getting that first?
<iyzsong-w>sure! it's all guile scheme..
<apteryx>raghavgururajan: core-updates broken in what regard?
<raghavgururajan>apteryx: I forgot the exact reason mentioned by dannym.
***iyzsong-- is now known as iyzsong-w
<jgart[m]><nij "I find it very slow and tricky t"> I'd recommend cloning the repo and using ripgrep to browse around different parts of guix that you'd like to look into
<nly>issues.guix.org -> solutions.guix.org, more apt
***iyzsong-- is now known as iyzsong-w
<raghavgururajan>The future of libjpeg-turbo: https://groups.google.com/g/libjpeg-turbo-announce/c/_H2BZDmSQWA/m/Fvy9sEByBwAJ?pli=1
<peanutbutterandc>Hey everyone! Long time no see
<raghavgururajan>peanutbutterandc, o/
<peanutbutterandc>raghavgururajan, \o (:
<Aurora_v_kosmose>By the way, cl-cffi v0.21.0 is broken with recent SBCL since it removed LINKAGE-TABLE, and I think it needs some patching because just swapping in v0.23.0 doesn't seem to work.
<Aurora_v_kosmose>It compiles fine, but when one tries to use it, obviously something more is required.
<Aurora_v_kosmose>(The package builds. The output isn't usable.)
<Aurora_v_kosmose>Ah, or it might be other packages which are depending on the disappeared features. My bad.
<Aurora_v_kosmose>Got it to work. I was messing up the package definition part.
<Aurora_v_kosmose> https://paste.debian.net/1180577/ Here's my patch.
***apteryx is now known as Guest60100
***apteryx_ is now known as apteryx
*Aurora_v_kosmose currently lacks an imap-capable email linked with this identity for git-mail
<civodul>Hello Guix!
<civodul>hey mothacehe :-)
<mothacehe>hey civodul!
***iyzsong-- is now known as iyzsong-w
<mroh>good morning guix!
<civodul>o/
<civodul>what's up, comrades?
<mroh>All is good over here. Procrastinating as usual, currently tax authorities stuff as always in a new year. (not sure if that is the correct word for the german "Finanzamt sch*ss" ;)
<civodul>heheh :-)
<efraim>I upgraded my machine from an nvidia 710 to a 730. now my kids can get my old machine
<mroh>yay! ;)
<mroh>How old are they?
<efraim>6 and 9
<efraim>graphics cards are from 2013(?) but new to me :)
<mroh>yeah, should be good enough for most games.
<efraim>computer store owner is a friend, he was amused when I came in and asked for the oldest graphics card they had. my use case for the 710 is probably why they carried them "I broke the VGA port on my motherboard and need something to show graphics"
<efraim>fun discussion of why I needed such an old card and if it was supported by nouveau :) he pretended to help me look online
<civodul>heh
<civodul>a special customer :-)
<civodul>hopefully now they know what's at stake with graphics card and user freedom ;-)
<mothacehe>it looks like guile 3.0.5 build fails for aarch64: https://ci.guix.gnu.org/build/189221/log/raw
<efraim>anyway, anyone have a suggestion for a program like tilda but for wayland? I miss my dropdown terminal and tilda will only launch when I'm hovering over an xwayland window
<efraim>shepherd failed to build for me with guile-3.0.5
<mothacehe>the faulty test (test-stack-overflow), sets an rlimit, I wonder if it works when using transparent emulation
<kmicu>(Most modern games doesn’t work well with those cards but now we can play top entertainment on Guix System* too thanks to remote services. It’s even more pleasant for me.)
<efraim>I'm testing guile-3.0.5 (with qemu emulation) for the ppc32 commencement chain
<raid5atemyhomewo>what can I do to help my ZFS-on-Guix patches get merged in?
<efraim>raid5atemyhomewo: another thing I was thinking of :)
<raid5atemyhomewo>:P
<efraim>I was going to go through and read all the threads. The easiest one looks like the update to 2.x
<raid5atemyhomewo>Is it "okay" that ZFS by default wants to write to a file in /etc/zfs named /etc/zfs/zpool.cache ?
<efraim>although honestly an email saying "I did these things and now it works as expected" would go a long way, especially as someone who doesn't actually use it
<raid5atemyhomewo>well I wrote those too......
<efraim>I assume it writes to them on other distros? I would've expected /var/zfs
<efraim>like I said, I have to go and read them. I'm (always :/) a couple hundred emails behind it seems
<PurpleSym>Is is somehow possible to figure out which expression causes this error? In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f
<raid5atemyhomewo>PurpleSym: what I usually do is lots of (format #t ...)
<raid5atemyhomewo>efraim: Yes, it's written also on other distros.
<PurpleSym>raid5atemyhomewo: What do you mean exactly?
<raid5atemyhomewo>I modify the code and add lots of (format #t ...) expressions in order to get stuff printed so I can narrow down where the error is
<raid5atemyhomewo>i.e. "debug prints"
<PurpleSym>Oh, okay. It’s all declarative data though, i.e. OS description, packages, …
<raid5atemyhomewo>there's a backtrace usually somewhere, so you could try tracing back from where it gets read in etc
<raid5atemyhomewo>because if the source of the error isn't your declaration, then presumably it got inserted somewhere in the actual code, ie you do have to debug it
<PurpleSym>No backtrace, that’s my problem.
<civodul>mothacehe: it must be non-deterministic because it tested on all the architectures before pushing
<civodul>we've already had issues with test-stack-overflow before
<civodul>ah but yes, it could have to do with kvm
<efraim>I can test it on my pine64 after I finish with the current builds
<civodul>(i built on real hardware)
<mothacehe>i tried to run (setrlimit 'as 50 #f), it work on native guile but doesn't have any effect on guile for aarch64 ran through transparent emulation
<civodul>ah, good catch!
<civodul>PurpleSym: in what context does that error happen? while running a guix command?
<PurpleSym>civodul: Yeah, `guix search` for example. Currently narrowing it down by commenting out stuff.
<mothacehe>oh looking at qemu sources the setrlimit call with RLIMIT_AS argument is just discarded, I'll disable this test altogether then.
<civodul>makes sense
<civodul>PurpleSym: is that with extra channels?
<PurpleSym>Yeah, the problem must be originating from my external channel.
<civodul>still surprising that there's no backtrace
<civodul>looks like "guix build emacs-devel --with-branch=master" works
<civodul>i thought there was something that prevented it from building, no?
<PurpleSym>Reasons seems to be a call to current-filename, which returns #f if the channel is “built” using `guix time-machine`, but not when using `-L /path`.
<civodul>hmm
<civodul>current-filename returns #f if the code is read from a non-file-backed port, such as stdin
<civodul>i wonder if that's what's happening
<civodul>ah no, the strip-double-wrap phase fails
<civodul>now i remember discussing it on the list
<civodul>but it seems we have yet to take action :-)
<mroh>civodul: I thought, it was a (xim?) patch in our emacs-next pkg that doesn't apply to (emacs) master/main anymore. But maybe that was temporary and it works again now, idk.
<civodul>looks like it
<civodul>right now it's just the file name of the "emacs-X.Y" binary that's causing troubles
<mroh>ah, yes, there was some discussion on list about that, maybe a patch also.
<leoprikler>the xim patch is something else, that's input methods no longer working in emacs
<leoprikler>This should be resolved in emacs-next-pgtk
<leoprikler>(at least for us GNOME folks)
<leoprikler>the double-wrap issue is specific to some emacs builds, because the chain would otherwise be emacs → emacs-X.Y → .real-emacs-X.Y
<civodul>leoprikler: ah right
<civodul>we should be able to use find-files or scandir instead of constructing the file name
<leoprikler>yep, that's probably a possibility
<civodul>weird, some nars are gzip-only, like this one: https://ci.guix.gnu.org/7pg9gna9vbilz1kwn2vnqh38kjvhxrrj.narinfo
<civodul>even though we run 'guix publish' with both compressions on ci
<mothacehe> nckx: looks like there's an offloading error due to dmitri.tobias.gr not being available: https://ci.guix.gnu.org/eval/22714/log/raw.
<mothacehe>offloading shouldn't fail when one of the nodes timeouts though
<leoprikler>Is someone with commit access to shepherd willing to look at http://issues.guix.gnu.org/45004? I think it would close http://issues.guix.gnu.org/26252.
<aadcg>is emacs crashing for some of you?
<leoprikler>Not currently, but I suppose that depends on your configuration.
<aadcg>leoprikler: it crashes due to glibc-2.31 it seems. I tried to go to previous generations from guix packages, guix pull and the system (at grub). but none of these helped... how can I fix this?
<aadcg>leoprikler: just to be clear, vanilla emacs crashes (i.e. emacs -Q)
<leoprikler>are you by chance using glibc-utf8-locales?
<aadcg>leoprikler: I'm not sure, how can I check it?
<leoprikler>`guix package -I` is a start
<aadcg>it seems I don't have any glibc-*-locales
<aadcg>I'm using the guix system, not only as a package manager
<leoprikler>now check the same for your system (preprend "-p /run/current-system/profile" before -I)
<aadcg>leoprikler: nothing there either
<leoprikler>Hmm, interesting
<aadcg>in my system config I have "(locale "en_US.utf8")"
<aadcg>leoprikler: there should be a locale in the system packages? I never touched anything under /gnu/store
<leoprikler>what was the rationale on .utf8 vs .UTF-8 again?
<leoprikler>I'm always confused as to which of those is the fake
<aadcg>leoprikler: according to the guix info pages it should be "en_US.utf8"
<aadcg>things started to misbehave after I did guix pull & guix system reconfigure
<civodul>leoprikler: i like the shepherd patch! currently it breaks several tests though, could you take a look?
<civodul>aadcg: booting or rolling back to an earlier generation didn't help, right?
<aadcg>civodul: it didn't. I did it at the system level (grub), previous guix generation (from guix pull) and previous package generation (from guix package)...
<leoprikler>Try a generation that's older than five days – that's when UTF-8 locales might have changed.
<aadcg>I'm not the only one facing this it seems - https://issues.guix.info/45758
<aadcg>leoprikler: will give it a try again then, thank you
<leoprikler>Wait, that's emacs-guix, not emacs itself
<leoprikler>glibc has been at 2.31 for ages
<civodul>aadcg: does it crash exclusively when using emacs-guix, or does it happen in other circumstances as well?
<leoprikler>If it was the reason, you'd have discovered the bug sooner
<aadcg>leoprikler: oh... you're right! in my case emacs crashes, regardless of emacs-guix
<aadcg>something strange is happening here then, but I will find out what it is!
<leoprikler>civodul: It's been a while since I last built shepherd, so it may take a while to set up the environment, but I'll have a look
<leoprikler>which tests are failing?
<civodul>leoprikler: basic.sh and a couple of others
<civodul>i didn't investigate
<civodul>aadcg: could you get a backtrace with gdb?
<civodul>for better result, you can do: guix install emacs --with-debug-symbols=emacs
<civodul>BTW, emacs-guix is still broken AFAICS :-/
<leoprikler>hmm... basic.sh passes in my developer environment
<aadcg>civodul: that's a good idea, will give it a try (never used gdb before).
<aadcg>civodul: one thing regarding emacs-guix that is broken quite some time is completion (at least for me). completion used to work in eshell for me. I should take a look at it
<civodul>yeah
<civodul>looks like it not the only issue
<civodul>pity :-/
<civodul>jsoo: do M-x guix & co. work for you in "emacs -Q"?
<jsoo>civodul: mostly yes
<jsoo>Also alex got back to me and said he would like the gitlab version to be a fork. I can go ahead and push to the savannah repo
<civodul>jsoo: nice
<civodul>oh, and hi! :-)
<jsoo>You will have to be patient with me since I don't know savannah much at all
<jsoo>Hi :)
<civodul>ah np
<civodul>there's not much to know about Savannah ;-)
<civodul>it's bare-bones compared to the newfangled forges
<aadcg>so the emacs-guix repo is now moving to savannah?
<jsoo>Yes
<jsoo>Ok cool. Well I'm not sure how I go about it. Do I need to have a login?
<leoprikler>civodul: for me, all tests run fine from a fresh checkout inside `guix environment shepherd --pure --ad-hoc autoconf automake gettext pkg-config texinfo help2man texlive`
<civodul>jsoo: yes, you need a Savannah account, and then we can add you as a "member" of the "guix" project
<civodul>FWIW, if i do: guix environment --ad-hoc --pure emacs emacs-geiser emacs-guix guile --with-debug-info=emacs -- emacs -Q
<civodul>first, i have to explicitly (require 'guix-autoloads)
<civodul>i don't think that was necessary before, but it's not related to emacs-guix
<civodul>second, if i do M-x guix p i (for instance), i get a Geiser error
<leoprikler>For `guix build` one would have to first rebuild the po directory.
<civodul>and then, when i C-x C-c, it segfaults as reported
<jsoo>Oh I see. Well hm.
<jsoo>Yes that happens to me too. First bug fix I suppose!
<jsoo>Do you get the segfault without --with-debug-info=emacs?
<jsoo>I did the same but without debug info and did not get a segfault
<civodul>i don't see the segfault in a container
<civodul>weird
<jsoo>:/ hmm
<jsoo>For me M-x guix and then p n works. Several sub commands are not working correctly but others are
<jsoo>I am registered as jsoo1 on savannah now
<zimoun>mothacehe: hey! I do not remember/find your answer about adding IP, DNS, Gateway instead of the automatic detection by the installer. See bug#37005 for an ause-case. Or machine in my labs. ;-)
<mothacehe>hey zimoun! hehe yes it's on my installer TODO list, together with adding support for extra substitutes server as requested recently.
<zimoun>mothacehe: cool!
<aadcg>civodul: I got this from gdb "Thread 1 ".emacs-27.1-rea" received signal SIGSEGV, Segmentation fault.
<aadcg>0x00000000005cfbe8 in ftcrfont_open ()
<aadcg>". any ideas on how can I go from here?
<leoprikler>up
<civodul>aadcg: ah ha! looks like fontconfig
<civodul>could you run "fc-cache -fv" and try re-running "emacs -Q" after that?
*civodul really happy to see all the issues closed by apteryx lately :-)
<aadcg>civodul: oh, that works for me!!! thank you so much!
<aadcg>will keep this in mind in the future when I play with fonts
<jsoo>civodul: I'll take a look at the sub command options in emacs-guix this week. I don't use most of them so it might take a while
<civodul>jsoo: i've added "jsoo1" as a member on Savannah
<civodul>could you email guix-devel a message signed with the key you'll use to sign commits to Emacs-Guix?
<civodul>(note that technically you can push to all Guix repos, but please commit only to the Emacs-Guix repo for now)
<jsoo>thanks civodul. i will send the email. and i will refrain from pushing anywhere but emacs-guix
<civodul>thank you!
<civodul>it's great you're helping out here
<jsoo>my pleasure! it's the least i can do :)
<jsoo>one minute while i figure out how to sign my email from emacs...
<jsoo>is the keybinding C-c C-m s s in the mail composition mode?
<civodul>i do C-c RET C-s
<civodul>(i think?)
<jsoo>ok thanks
<PotentialUser-54>hey ! Anyone knows how to boot into a guix system that has some of its non essential hard drives (non root) removed ? It boots into a guile shell. How would I go about reconfiguring the system without that hd - or how would I boot it skipping that HD ... I tried chroot from an installation USB and it seems to be downloading the whole world again wh
<PotentialUser-54>en i do a reconfigure from there
<civodul>PotentialUser-54: were these marked as 'needed-for-root?'?
<PotentialUser-54>how would i even do that ... first time i heard about "needed-for-root"
<PotentialUser-54>there is a "needed-for-b(!)oot" mentioned in the manual and it defaults to false
<civodul>yes sorry, that's the one i had in mind
<civodul>then it shouldn't prevent booting hmm
<civodul>could you paste the message or a picture of the screen?
<PotentialUser-54>but it does ... it always does that
<PotentialUser-54>i had the same problem on another machine ... guix will not boot if some arbitrary hard drive is not found
<leoprikler>I never had that for hard drives, that normally aren't connected to my machine (that being the main drive)
<PotentialUser-54>my chroot reconfigure just stopped with "no space left" this explains why it wanted to download everything again .. chroot does not point to the store in the target, it still uses the store from the usb medium
<PotentialUser-54>so a proper guix friendly chroot guide would be really nice at some point
<PotentialUser-54>civodul: the error is bad magic number in super block while trying to open /dev/sdb1 ... File system check failed ... spawning bourne like repl
<PotentialUser-54>that partition is mounted to /transit in my config
<PotentialUser-54>i suppose i just re-install yet again ... what a chore .. this is my biggest gripe with guix, once you cant boot there is no obvious and documented way how to repair it
<jsoo>civodul: am i alright to push to emacs-guix now? i reformatted my commits to something i think resembles changelog format.
<civodul>jsoo: sure! please also check you have commit.gpgSign = true in your Git config
<civodul>you should be all set
<jsoo>sweet! thank you!
<jsoo>do i need to authenticate my ssh key or anything?
<civodul>jsoo: you need to add your SSH public key to your account page on Savannah
<civodul>but that's about it
<jsoo>hm. ok. thanks. i probably am missing something
<mothacehe>There's another error while building guile@3.0.5 on aarch64: https://ci.guix.gnu.org/build/189493/log/raw
<mothacehe>It's in port.test: "ERROR: ports.test: revealed port fdes not closed - arguments: ((system-error "seek" "~A" ("Bad file descriptor") (9)))"
<mothacehe>but this time I cannot reproduce it with an emulated Guile interpretor
<zimoun>civodul: about SWH, it is on the side of Guile-JSON. The default behaviour changed; see https://github.com/aconchillo/guile-json/issues/61#issuecomment-703212590 so any tip for a fix?
<mothacehe>oh looks like it's undeterministic one because this one succeeded: https://ci.guix.gnu.org/build/189480/log/raw
<civodul>uh
<civodul>zimoun: this issue is about the other way round no? that is, from record to JSON
<civodul>whereas our problem is about JSON->record
<civodul>zimoun: at <https://archive.softwareheritage.org/api/1/origin/https://github.com/Genivia/ugrep/visits/>, snapshot_url = null
<zimoun>the json->record also changed; in order to combine them. If I read correctly the comment.
<civodul>but in this case the JSON field is not unspecified, it's null
<zimoun>again, if I read correctly it is unspecified because we are fetching that https://archive.softwareheritage.org/api/1/origin/https://github.com/Genivia/ugrep/get/
<civodul>oh i see
<civodul>it doesn't allow us to use #f as the field value
<zimoun>Yes. I do not know where the fix should be applied. The ugly hack is to replace the #<unspecified> by #f after the json->record. Or tweak the functions to deal with #<unspecified> instead of #f. Or on the Guile-JSON side.
<civodul>zimoun: i've reported this: https://github.com/aconchillo/guile-json/issues/69
<civodul>i can't think of a way to work around it
<mothacehe>there's a fix here for the Guile test issue, I think it should be applied: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43521.
<civodul>oh good
<civodul>rlb (Rob) can apply it
<mothacehe>civodul: nice :)
<mothacehe>always feels nice when someone did the hardwork before! Now, let's see if guix-modular can build for aarch64.
<civodul>it's weird because before pushing i sent the four guile-3.0.5.drv to berlin (via GUIX_DAEMON_SOCKET) and got them built there
<mothacehe>it used the daemon offloading which probably sent them to the overdrive nodes, whereas Cuirass is now using the remote building mechanism that is not yet connected to the overdrive machines
<civodul>oh oh!
<civodul>and it doesn't use the local store either?
<mothacehe>yes it does, then I don't understand :p
<civodul>or maybe they got gc'd right away
<civodul>unlikely but not impossible
<zimoun>civodul: about the tests/swh.scm, you mean create a couple of fake JSON files, and use them for testing, right?
<mothacehe>that's a possibility!
<mothacehe>I gc'ed 10TiB on berlin a week ago, maybe it happened at that time.
<civodul>zimoun: there are examples for directories and origins; we could add one for visits, with a field set to "null", and check that it translates to #f
<civodul>mothacehe: no, that was just a couple of days ago
<zimoun>I see.
<Aurora_v_kosmose>Hello
***sneek_ is now known as sneek
<rndd>hi guix \0/
<rndd>is it possible to make a package that put file in my home directory? i wanna put my .emacs in channel and be able to install it with emacs (i know about (inherit ...) but don't know how to copy files from package sources to user home directory).
<rekado>rndd: you can’t install packages anywhere other than /gnu/store, but you can use “guix package -p /somewhere/else” to link the profile elsewhere.
<Aurora_v_kosmose>Yes and no. You could symlink ~/.emacs to ~/.guix-profile/[...]/emacsrc
<jackhill>rndd: you may also find https://framagit.org/tyreunom/guix-home-manager interesting. However, I was thinking something similar to Aurora_v_kosmose's suggestion
<rndd>rekado Aurora_v_kosmose jackhill: thanks, will try these ways
<mroh>is there a config trick or something to make notifications work in icecat? https://www.bennish.net/web-notifications.html gives "Notifications are not available for your browser." if I try to authorize.
<Aurora_v_kosmose>Some sites only support Chrome. But I'm also not sure if Icecat itself supports notifications.
<apteryx>Aurora_v_kosmose: it does, I'm using it
<apteryx>I think I had to force it in about:config
<apteryx>dom.webnotifications.enabled
<apteryx>I also have dom.webnotifications.serviceworker.enabled set to true
<Aurora_v_kosmose>I wonder why it's disabled. Does lend itself to tracking somehow?
<apteryx>This I have no idea. I think it's just because it was not deemed ready by Mozilla in the ESR version that Icecat is based off.
<apteryx>mroh: ^
<mroh>apteryx: Thank you! That does the trick.
<apteryx>glad it worked!
<Aurora_v_kosmose>Anyone here can send an email/patch on my behalf?
*Aurora_v_kosmose has no working imap account under this name
<Aurora_v_kosmose>* imap/smtp
<helaoban>ls
<helaoban>wooops.
*Aurora_v_kosmose lists ~/
<apteryx>Aurora_v_kosmose: not sure that helps, but note that you can send patches as simple attachments rather than via git-send-email.
<Aurora_v_kosmose>It kinda does. I'd forgotten about that.
<adfeno>Hi there, is anyone working on packaging PeerTube?
<kingcons`>Afternoon folks! I submitted my first package to guix-patches late Saturday. Is there any particular follow-up I should take? Not really sure what the cadence is for those sorts of things being looked at. (Nothing important, just an emacs lib)
<leoprikler>kingcons`: normally it's just waiting for review
<leoprikler>note, that that takes some time (committers need to wait 2 weeks for stuff that hasn't been reviewed as well)
<leoprikler>which bug id did you get btw?
<kingcons`>leoprikler: that makes total sense, Leo. Thanks. Bug ID is 45757
<leoprikler>emacs-consult?
<kingcons`>Yes.
<leoprikler>building it right now
<leoprikler>btw. since you brought up "formatting", normally you'd want to `git send-email`
<kingcons`>Lovely! :) I'm still early on in my guix journey but there's an awful lot to like.
<kingcons`>Fair, I was trying to do everything via magit and some other configuration but I'll be sure to use git send-email in the future.
<leoprikler>how tf is consult-find even supposed to work, lol
<dustyweb>kingcons`: !!!!
<dustyweb>kingcons`: I'm thrilled to see you here.
<dustyweb>welcome to #guix, I hope you have a good time and stick around.
<kingcons`>dustyweb: thanks so much! I'm just finding my sea legs so I imagine it'll be a bit before I'm much help.
<kingcons`>leoprikler: oof, hadn't tested consult-find. mostly been using consult-buffer and consult-line. maybe it expects more up-to-date selectrum? those packages have been a bit bleeding edge lately :-/
<leoprikler>it's fine, but the the interface seems rather unintuitive to me personally
<leoprikler>to the point where I feel as though find-file and rgrep do a better job
<leoprikler>but that's just my personal take, have fun with consult :)
<kingcons`>Understood. Thanks for the patch review! :)
<jeko>Hey Guixters !
<kurisu>Hi, i have several issues with guix : when i do guix pull and then guix package -u it says icedove and mpdris2 don't exist