***xgqtd is now known as xgqt
***Xenguy_ is now known as Xenguy
<iskarian>sneek, later tell jpoiret: re: finding guile bindings, I'll often just search the guile manual, the guile source code, and/or the guix source code. Geiser seems to think about half of everything is "define"... <iskarian>sneek, later tell apteryx: you may also want to take a look at the lld-wrapper in chromium.scm for reference <excalamus>hey, iskarian. I'm still planning on trying to formalize the Plover thing we worked on. Been trying to do a write up in between life. <singpolyma>Is there anyone here who could help me figure out an issue with `guix copy`? I'm only able to get errors from it so far... <iskarian>excalamus, good to hear it! Sometimes it feels like the documentation and process stuff takes much longer than the actual work :) <apteryx>iskarian: ah, I modified make-ld-wrapper to accept a LINKER argument (e.g., "ld" or "ld.gold") <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, iskarian says: you may also want to take a look at the lld-wrapper in chromium.scm for reference <iskarian>oh, cool! Do you think it'll work with lld? (though, in my testing with zig, it seems lld does fine on its own; I'm not sure why the wrapper was necessary for chromium) <roptat>\o/ /gnu/store/2s8kl297mh4bq9ib55j5v02yrf2ri4qx-kotlin-0.6.786 is built! <roptat>and it let me build kotlin-0.6.1364 \o/ <roptat>so, 30 compilers remaining in the chain until I reach the last I know I can build with this method, which is from 2015 <iskarian>Does anything need the older ones to build? <roptat>0.6.786 is the most recent one that doesn't need kotlin to build <roptat>and then it's a chain of compilers, because the commit after 0.6.1364 can't be built with 0.6.786, I have to build 0.6.1364 and make it the bootstrap compiler <roptat>I'm following Emmanuel Bourg's makefile, so I know which ones I need for now, but after 0.12, I'll be by myself <iskarian>Anyone have an idea how I would run a bash script in a snippet? (It copies certain source files to another dir, and these are the only ones needed to build the package) <iskarian>Overriding patch-inputs didn't seem to work <roptat>you can bring in more modules, but the snippet is not a gexp, so I'm not sure you can bring in inputs <iskarian>Hmm, I could write a builder for it, then, but that's a lot of work. Meh <apteryx>iskarian: yes, it should work with lld, provided you replaced the 'binutils' package argument with lld. <apteryx>(and also specify the linker argument as 'lld') <apteryx>roptat: snippet can actually be a gexp, although that's not much useful right now because it typically introduce cycles <apteryx>we'd need the snippet field to be thunked/delayed <iskarian>Also, not to spark another debate, but was there ever a resolution on whether CDDL kernel modules are FSDG-compatible? ***muradm` is now known as muradm
<PurpleSym>zimoun: I agree wrt ‘-next’, but I don’t see any good solution right now. I thought about a property like “preferred-version”, but inheritance makes this quite useless. <zimoun>PurpleSym, yeah. I do not know either. <PurpleSym>Simply hiding non-default packages would be another option. <zimoun>yes but personally, I like to be able to run “guix install ghc@8.10” and try some stuff. <lilyp>Perhaps we need a property like experimental?, which means you can still ask for a given package, but it won't be "the latest version" unless you explicitly ask for it <muradm>is there glibc docs only derivation? <bdju>is there a guide for what I have to change now that "target" is deprecated in the system config? I tried just adding an s, but of course it's not that simple... <bdju>alright I'll try something based on that <bricewge>bdju: "targets" should be a list isn't it? <bdju>okay, I believe I got it working <bdju>dstolfa: thanks for the help <PurpleSym>Do we have a way to automate changed inputs like version updates? I know rekado_’s cran updater displays changes, but it does not actually change the source unfortunately. <yoctocell>PurpleSym: I don't think we have; it would be nice to have that though. <yoctocell>PurpleSym: btw, any plans for what to do with the `wip-haskell' branch? <PurpleSym>yoctocell: Not quite sure. Locally I rebased it on top of master and added a few changes switching to GHC 8.10 and the latest Stackage. <yoctocell>I guess you could run `./pre-inst-env guix refresh -u -t stackage' and see if anything breaks <yoctocell>Other than that, I don't really know what else we could do <PurpleSym>Yeah, that was my idea too. Then I patched the stackage updater to show changed inputs and there are quite alot I think. I’ll try it anyway. <PurpleSym>Wrt your patch: I’ve seen it and if it passes build and tests locally I’ll apply it to master. <PurpleSym>Any other patches that need to go to wip-haskell? <efraim>Packagingcon decision was pushed back by a week, got an email today *dstolfa still wants to know what will be used <PurpleSym>yoctocell: Ah yeah, for 49326 we could probably build something similar to package-with-explicit-python. If that’s needed. <PurpleSym>48999 has another patch of your waiting, as far as I see. <yoctocell>48999 is related to the imported, so I think it would to master <stfnbms>LibreOffice gives me the error message “Missing hyphenation data. Please install the hyphenation package for locale “de”.” I would like to, but cannot figure out which Guix package provides those patterns to LibreOffice. <yoctocell>PurpleSym: re `package-with-explicit-python', that would be nice, then someone could easily build a group of haskell packages with another version of GHC. <muradm>previously i was mentioning problem with running make check-system for any test on core-updates-frozen, for instance "make check-system TESTS="basic"", works, tests pass ok, but in the end of the day guix reports "build failed". <muradm>just if any one could confirm that they have same problem, or is it only me <civodul>pushing the boundaries of Java bootstrapping today? :-) <roptat>yay, I managed to get one more kotlin this morning <roptat>it's surprisingly easy now that I know which versions I need to use in the bootstrap <roptat>it will be more work after kotlin 0.12.470 (from 2015), because then I'll have to test which versions can be built or not <roptat>I noticed a "prodecures" in a package description (not sure which) while translating. I don't have access to the repo, can someone fix it? <pkill9>latest guix builds qemu-minimal, my 4 day old guix failed to, i wonder what fixed it <civodul>roptat: re kotlin, all this seemed out of reach, so it's really nice <civodul>also great that there's a growing interest in addressing these issues! <roptat>yeah, for a long time I tried to get started on this, but it ends up I wasn't looking for the correct dependency version <roptat>I wanted to try that for some time now, since the message on the bootstrappable ML in April <civodul>i'll email the bug tracker later on, have to go now <sneek>mothacehe was in #guix 14 days ago, saying: bsturmfels: ok, we slowly progress :) If you can find the sources of their resizing tool we can maybe understand why it doesn't work on our image.. <vivien>Hi guix! I’m trying to use guile-gi. However, when I run: echo '(use-modules (gi)) (use-typelibs ("Gtk" "3.0"))' | guix environment --ad-hoc guile guile-gi -- guile there are a bunch of warnings but nothing happens. Is it the same for you? <PurpleSym>civodul: Excellent! I’ll see if it fixes the issue for me tomorrow. <vivien>(I notice that with --pure, it works, so maybe there’s an environment issue somewhere?) <maximed>vivien: Maybe ‘nothing happens’ is good? <maximed>I don't expect importing a module to open some windows for example <vivien>The process blocks and I don’t have a prompt <vivien>I have to kill it by closing the terminal (C-c does not work) <maximed>so guile only has the output of that echo as standard input <vivien>If I run with --pure, the command exits <vivien>If I don’t, the command does not <maximed>Guile reads commands from standard input. In your example, the standard input of Guile is the standard output of 'echo'. 'echo' only outputs two commands to standard output, so guile will only read (and run) the two commands *maximed tries without 'echo' <vivien>Yes, but it should exit after that <maximed>vivien: maybe run ,trace (eval (current-module) '(use-typelibs ("Gtk "3.0"))) to figure out where it is hanging? <maximed>('eval' because 'use-typelibs' appears to be a macro) <muradm>civodul: bug#50604 acknowledged.. make check-system on core-updates-frozen related.. :) <vivien>maximed, if I run ,trace (eval '(use-typelibs ("Gtk" "3.0")) (current-module)) the trace stops at "In procedure procedure-name: Wrong type argument in position 1: #f" <vivien>But If I run (eval '(use-typelibs ("Gtk" "3.0")) (current-module)) (in another session), I don’t get a prompt and I can’t kill the evaluation <vivien>If I run ,trace (eval '(use-typelibs ("Gtk" "3.0")) (current-module)) in a pure environment, I get the same output: the trace runs for a while and stops at In procedure procedure-name: Wrong type argument in position 1: #f <vivien>And if I run (eval '(use-typelibs ("Gtk" "3.0")) (current-module)), the evaluation succeeds and I get a prompt. <vivien>OK, so if I run it in a pure environment containing all the packages I installed, it works as expected, so I don’t think I will be able to debug it. ***CaptainDrewBoy is now known as captaindrewALT
<maximed>vivien: I think I figured out the ,trace bug <captaindrewALT>Hello! Whenever I try to install software I get the error "build of `/gnu/store/[this changes package to package and looks like nonsense]-profile.drv' failed" <maximed>captaindrewAlt: Normally there is a line like "build log is at /var/logs/..../...bz2" <maximed>the build log is required for debugging <lilyp>vivien to avoid problems with pipes, try running your code in a guile repl spawned with guile+guile-gi <lilyp>i.e. guix evironment --ad-hoc guile guile-gi -- guile <vivien>lilyp, it’s the same situation without the pipes. *muradm updated #49969 greetd-service-type seatd-service-type <lilyp>for the record, it's been a while since I've last written guile-gi code, so I might have forgotten some of the details around its quirks <lilyp>do you get a bunch of GObject signal stuff? <muradm>#49969 patchset is tested on both master and core-updates-frozen ***CaptainDrewBoy is now known as CaptainDrewALT
<CaptainDrewALT>maximed: I found the build log. It's very long and (at least for me) pretty undecipherable <roptat>CaptainDrewALT, do you think you could paste the last, say, 100 lines on paste.debian.net and send us the link? <CaptainDrewALT>Okay, will do! Looks like the majority of it is package collisions, mostly with python 2 and python 3. <roptat>the last few lines should contain the error message that explains the build failure <roptat>yeah, the very last line is the actual issue <roptat>apparently, xfce4-terminal, gimp and gnome-screenshot all define share/locale/ast, but some are a file and others a directory <roptat>dunno, all three are directories here... <roptat>maybe it's been some time since you last pulled? I'll try to run "guix pull" too, see if I can reproduce on latest master <CaptainDrewALT>I'll run it again, maybe something went wrong and a bit was skipped or something <roptat>mine is older by two weeks actually, so something happened in between <roptat>mh, I don't get the same hash as you, even though I just pulled, that's weird <roptat>what does "guix describe" tell you? <roptat>did you apply any package transformation option? <roptat>what does "guix build xfce4-terminal" and "guix build xfce4-terminal --no-grafts" tell you? <roptat>it should be a path in the store, and they should be different <vivien>lilyp, I have 3 warnings in the working case, and a few CRITICAL for the non-working case, including a suspicious cannot register existing type 'GdkPixbuf' <CaptainDrewALT>So I did that guix pull from earlier (my cpu isn't great it took a moment) then did a guix package -u. All of a sudden installs work again??? Whatever it needed to resolve has obviously been resolved. <CaptainDrewALT>Thanks for all your help and advice though - I have learnt how to read the build logs and I would never have thought to update without you <muradm>any one did "./pre-inst-env guix system reconfigure" from core-updates-frozen for local host after master merged by civodul?.. :) does it work? <katco>iskarian: caught me on my lunch break! what's up? <katco>ah cool. i hope i provided enough information. <iskarian>I can't reproduce it; I just did 'guix install go' and 'go env' and GOTOOLDIR is the proper /gnu/store/path, and I can use 'go tool doc', 'go tool pprof', etc. <muradm>is it too late to update wayland-protocols on core-updates-frozen to 1.21 ? <muradm>Building the following 1423 packages would ensure 2594 dependent packages are rebuilt <iskarian>Yeah, I can get what you're seeing by setting "GOROOT=~/.guix-profile", so I think that might be what's going on <katco>iskarian: ah! that appears to be what's going on. i am in the middle of redoing my config files, and i have `GOROOT` set to $GUIX_PROFILE/share/go. i forget why i did that, but i think i can unset it. <katco>iskarian: ok, sorry for the false alarm. i'll close the bug with notes. and thank you for all your work on guix! <iskarian>katco, no worries, I'm glad we found the issue :) let me know if anything else breaks! there were a lot of changes in our 1.17 release, and I don't actually use Go <katco>so far this is the only thing i've run into <awb99>Is there a package for vscodium on guix now? <lilyp>vivien: Oh, that's a nasty one. Try loading GdkPixbuf before Gtk <lilyp>IIRC there's a pull request that loads those dependencies first, but idk if it solves the issue at hand <vivien>lilyp, it works! That’s fantastic. <maximed>PotentialUser-92: ‘device not found’ != ‘file not found’ (at least in glibc, I don't know about grub) <maximed>I wonder if you specified file system devices with strings like "/dev/sda1" and connected an additional storage device? <maximed>or maybe grub doesn't care about all that <PotentialUser-92>ls in grub leads me to believe that the file system itself might be damaged <PotentialUser-92>I have grub on one partition and the image I'm trying to boot on another <maximed>There were some issues in the past with /run/current-system/... things not being registered as gc roots, though they should be fixed by now AFAIK <maximed>can you see anything in / and /gnu/store? <maximed>If they are empty, then it's probably not a GC issue <maximed>(the GC always preserves a few store items due to reasons) <maximed>Seems like grub failed to read the root file system for whatever reason? <maximed>grub doesn't support all file system configurations <maximed>for example, I've heard it doesn't support LUKS2, though it does support LUKS1 <maximed>So ‘I tuned it to have large dirs’ seems a plausible explanation for grub to fail <maximed>(don't know if the explanation is correct though) <geex3>how does /gnu/store get mounted ro ? <iskarian>sneek, later tell yoctocell: idea for further updater improvement: detect when a package inherits its source from another, and don't bother checking (unless it was specifically specified on the commandline I suppose) <apteryx>civodul: any experience running 'perf' in a guix container? I did 'guix environment -C --expose=/gnu/store --share=/sys/kernel/debug ldc --ad-hoc less strace zile perf', but getting 'Error: No permissions to read /sys/kernel/debug/tracing/events/raw_syscalls/sys_(enter|exit)' <iskarian>Oooh, I managed to segfault 'guix refresh' <roptat>geex3, on a foreign distro, there's a gnu-store.mount systemd service <geex3>roptat: thank you sir, is it similar in our distro? (the contents of that unit file, looking into it now) <roptat>in the guix distro, I'm not sure, it's probably one of the default file-systems in the os declaration? <geex3>the output of 'mount' for / and /gnu/store as the same drive but one is read-only is neat <podiki[m]>PotentialUser-92: oh no, i did this recently too! <podiki[m]>you can get it to boot by putting kernel and initrd in grub partition (and making changes so it sees it, i forget the details but common enough) <podiki[m]>maybe we should have a warning about this, since guix makes a lot of files in some places (/gnu/store/.links I think is the main one), and you can hit the limit on ext4 <iskarian>apteryx: `guix refresh intelmetool me-cleaner' <iskarian>this might actually be in the generic-git updater I'm testing <iskarian>the odd thing is it doesn't segfault if I do just one or the other <iskarian>But why does it only happen when at least one other package is specified? (even if it doesn't use the generic-git updater) <apteryx>civodul: I ran the guix environment command with sudo; seems to do it <iskarian>Ah, I'm sure it's because the intelmetool repo has 274,957 tags. <civodul>apteryx: yeah, "perf" gives hints about /sys permissions, but sometimes it seems to not be enough <apteryx>they have a bot tagging each commit or what? <iskarian>yeah, there's a lot of tags like "refs/users/82/1001282/edit-21685/11" <iskarian>I should rephrase, there's a lot of *refs* but only a few tags <podiki[m]>haskell guix folks, ghc-8.10 is now live (8.10.7 even, newer than on my arch system) <iskarian>but I think (guile git) isn't releasing the memory of any of the refs until we're done with all of them <podiki[m]>the haskell (ghc-) packages will still need to be updated to newer stackage release <apteryx>civodul: is perf supposed to be as verbose as strace? I'm trying to see 'write' syscall output, and it doesn't seem to be there, with 'perf trace --syscalls --verbose' at least <apteryx>I can't use strace because the process I want to follow is GDB, with which strace seems to clash. <PotentialUser-92>so do you want to strace gdb or do you want to strace the thing gdb is running? <apteryx>I want to strace gdb, hopefully getting clues as to where/when it execs '/bin/sh' <apteryx>there's like just one instance in the code where it could have happened if my grepping was accurate, since patched <civodul>apteryx: ah dunno, i haven't used "perf trace" <apteryx>PotentialUser-92: hmm, let me see if this could work <apteryx>ah, it runs through another process; that process probably clears SHELL somehow, which GDB depends on <apteryx>perhaps I could patch the default SHELL value in the gdb source to prevent such potential issue <apteryx>and avoid the need to set SHELL in the first place <yoctocell>podiki[m]: PurpleSym is working on updating the Haskell packages to the latest stackage lts. :-) <sneek>yoctocell, you have 1 message! <sneek>yoctocell, iskarian says: idea for further updater improvement: detect when a package inherits its source from another, and don't bother checking (unless it was specifically specified on the commandline I suppose) <yoctocell>But a lot of the packages aren't part of Stackage, so I am not sure how we should deal with those <yoctocell>iskarian: how exactly do we detect if a package inherits the source from another package? <iskarian>I'm not sure! Probably checking the source-location or something. It would be an optimization to put in (guix scripts refresh) for sure. I just wanted to put it out there :) <yoctocell>Ah, I am not too familiar with how source-location works, but something nice to have. :-) <iskarian>by the way, I discovered that remote-refs can cause a segfault if there are too many refs in a repo <iskarian>try: `guix refresh intelmetool me-cleaner' <podiki[m]>yoctocell: good to know thanks! i had a handful of packages I updated but was not systematic. also have a whole ton for haskell-gi (gobject introspection) <podiki[m]>I wanted to get taffybar in guix, but was running into haskell ecosystem issues <yoctocell>gnu/packages/flashing-tools.scm:428:13: 1.2 is already the latest version of me-cleaner <yoctocell>gnu/packages/flashing-tools.scm:387:13: intelmetool would be upgraded from 4.7 to 4.14 <civodul>iskarian: it'd be interesting to see if this Guile-Git patch avoids the leak (if it's one) when manipulating many references: diff --git a/git/reference.scm b/git/reference.scm <civodul> (proc out (reference-iterator->pointer iterator)) <civodul>- (pointer->reference (dereference-pointer out)))))) <civodul>+ (pointer->reference! (dereference-pointer out)))))) <civodul> (define* (reference-fold proc init repository #:key (glob #f)) <dstolfa>civodul: i always feel silly when i do that by accident, but don't worry, we all do it! :) <civodul>iskarian: if you want, you can check with "guix install guile-git --with-patch=guile-git=this.patch" or similar <iskarian>no worries. I noticed that if I make sure the return value isn't in tail position, it doesn't trigger. <yoctocell>iskarian: but 275,957 sounds like a lot of refs! <civodul>dstolfa: i'd blame scpaste.el, which puts both the content and the URL in the kill ring :-) <podiki[m]>yoctocell and PurpleSym happy to try to help on wip-haskell with the package updates, as well as adding all the haskell-gi packages (once I check them again) <yoctocell>podiki: Cool! I have been wanting to try out taffybar for a while, but never got around to do that. <podiki[m]>I'll take another stab now what we have ghc 8.10, I was running into issues with mixed versions of stuff before <podiki[m]>(and learning how haskell packages is quite messy in every incantation) <iskarian>civodul: I can still get a segfault with that patch. <yoctocell>heh, I have been playing with the cabal importer, and wow is it complicated <iskarian>(to be clear, I did `guix environment guix --with-patch=...', that should work, yes? <civodul>could you get a backtrace from the core dump? <civodul>or maybe i can just reproduce it locally? <podiki[m]>there was also a (partial?) stack package floating around, that would be good to get working <civodul>podiki[m]: Haskell packages need love, i'm glad you're looking at it! <iskarian>civodul: yes, I'm using yoctocell's last generic-git patch, unmodified <yoctocell>yeah, but when using Guix to manage Haskell stuff, there isn't really much use of stack :-) <iskarian>the repro should be `guix refresh intelmetool me-cleaner' but it's nondeterministic <podiki[m]>civodul: if I knew more I'd be more helpful, but learning a little! mostly I just use xmonad and want taffybar to try too, so that's the motivation <iskarian>I tried to prevent inlining of remote-refs; that didn't fix it <podiki[m]>haskell seems to be tough in lots of distros <yoctocell>yeah, nixos is the only distro that keeps up <yoctocell>I think I have packaged all the packages that exists on Hackage, pretty impressive <podiki[m]>yeah they seem to do well, and with their overlays (or whatever it is called), setting up environments with known versions <yoctocell>yeah, I wish Guix had something like overlays <yoctocell>I think there was some work on "parametrized packages", around a year ago <iskarian>civodul, oh I think I did an oopsie. Moving repository-close! to after the calculation of the return value fixes it. I think I assumed it worked like remote-disconnect in that resources were still available after closing, but I think it frees all memory. <civodul>iskarian: ah ha! indeed, that must be it <civodul>though this could/should be considered a bug in Guile-Git: no Scheme hacking should lead to segfaults <iskarian>Hmmm. Should I not be calling repository-close! at all in this case? Will it automatically be freed by a finalizer? <civodul>i think right now it has to be called, but it prolly shouldn't be that way <civodul>or rather: calling it prematurely shouldn't lead to segfault <iskarian>I know very little about how guile's ffi works, but I have a theory: by moving the calculation out of the tail call, it remained in the scope of 'remote-refs', so the memory of the remote-head-list wasn't yet freed. but in tail-call position, perhaps the calculation was no longer in the scope of 'remote-refs' so the memory was freed before the calculation occurred <PotentialUser-26>How would I go about adding kernel modules when running the installation image for guix system. I need thin provisioning but its not in the installation image kernel <roptat>I think you'll have to generate your own installation media <PotentialUser-92>PotentialUser-26: Note that you can run those `guix system' commands without running on a Guix System itself. <PotentialUser-92>so all you need is a machine you can install Guix, the package manager, onto <mbakke>oh my, new TeX Live packages on master <mbakke>I think I'll cherry-pick them to core-updates-frozen before merging, and update their hashes and other TeX Live 2019->2021 adjustments in the process <mbakke>probably won't be able to finish the merge tonight, but git rerere has my back :) <mbakke>in other news, there are a set of python-related patches on master that fixes things on core-updates-frozen eventually :P