<lle-bout>levels are like low, medium, high, critical <lle-bout>but you'll figure that out by looking at the actual data *nckx hopes that's handily included in the XML we already fetch. <nckx>I thought so but ‘become known’ might imply otherwise? <lle-bout>nckx: oh well there's a review process by NVD, score is at reporter's discretion <cbaines>which suggests that only releases prior to October 16th 2018 are fit for inclusion (including patch releases) <cbaines>which would make 3.4.24 released on Jan 27, 2020 not OK <lle-bout>cbaines: what about what's in the tarball? <lle-bout>cbaines: tarball has AGPL and Apache2, 3.4.24 <lle-bout>cbaines: well some files in the tarball are under SSPL <apteryx>lle-bout: I have Go 1.16.x locally, but it breaks packages so I'm trying to fix the tail of broken ones <lle-bout>cbaines: nevermind, let's just remove the package, "$ grep -R 'Server Side' ." in the mongodb 3.4.24 extracted tarball has some results in header files. <lle-bout>apteryx: 1.14.x is still OK security-wise however, there's some CVEs with encoding/xml in the standard library that werent fixed upstream but not sure why, it seems intentional <lle-bout>efraim: I was wrong, some files in mongodb 3.4.24 tarball have SSPL copyright headers. <cbaines>lle-bout, sure, I'm not personally against removing mongodb. <nckx>‘CVSS Version 2.0: Base Score: 3.5 LOW’ <nckx>‘CVSS Version 3.x: Base Score: 9.0 CRITICAL’ <nckx>I'm not finding a clear review score/reporter score field, but I'm not very familiar with CVE. <Gooberpatrol66>guix system image ignores the filesystem settings in config.scm and always generates an ext4 image. Does anyone know why that is? <i1l>it also seems to use MBR partitioning <i1l>idk, but as 'root-partition is exported, i think one can write a file, use-modules that .scm, then set! the root-partition value (or even just change the field somehow) <i1l>but works as is.. ok ***sturm__ is now known as sturm
*pkill9 ran a firejailed blender within a firejail sway, the blender instance started outside of sway <apteryx>that's crazy; I'm building jami in a pure environment which doesn't have gdk-pixbuf (it only has gdk-pixbuf+svg); yet it dynamically links to gdk-pixbuf <pkill9>is there maybe a package propagating gdk-pixbuf? <i1l>Gooberpatrol66: but please keep in mind that idk the matter at all. <kcurtet>Hi guixers, to pin a package in the `operating-system' with the `specification->package' i just need to add the @version to the package? <apteryx>yes; you should be good unless other packages in the profile propagated another version <kcurtet>Thx; I think it will not give me problems its for emacs-native <iyzsong-w>to 'pin' a package, we use that package from a specified version of guix. <kcurtet>iyzsong-w: thx; i do the same for the kernerl from a code i take somewhere <lle-bout>efraim: sed test failed on your branch: inplace-selinux.sh: set-up failure: CONFIG_HEADER not defined <apteryx>pkill9: I've now built it in a container of the same environment; found the problem; I was clearing the files of the client but there's this lrc middle ware that is not supposed to use GNOME/GTK+ stuff but somehow it was keeping references to it and polluting the build of the client <apteryx>so the problem was two-fold: gdk-pixbuf being propagated by a few packages around in Guix instead og gdk-pixbuf+svg; then there was that build pollution I forgot to cleanse. <apteryx>any idea of how I can share dbus in a container? <raghavgururajan>> apteryx: raghavgururajan: as a GNOME package maintainer I think this is an important detail that you should know: anything that propagates gdk-pixbuf should propagate gdk-pixbuf+svg to stay in harmony with gtk+'s own propagated libs. <lle-bout>apteryx: find the dbus socket and --share=<path> it *raghavgururajan goes back to zzZ <jmarciano>I have this problem http://ix.io/2Swb guix pull: error: got unexpected path `Backtrace:' from substituter, so what can I do to make guix package manager work again? It works on GNU Hyperbola/Linux-libre OS <lle-bout>jmarciano: I that error once it was due to glibc-locales not being installed in the root profile <jmarciano>I cannot install glibc-locales as the same error coes <jmarciano>as guix pull never finished due to error, I cannot do guix package -u or install anything <jmarciano>if Backtrace: comes from substituter, maybe I could change substituter, I understand it is server with packages <lle-bout>jmarciano: I didnt read your paste initially, you should never install guix with guix <lle-bout>jmarciano: installing packages works, it doesnt need 'guix pull' if you already have a guix installed <jmarciano>I did not install it with guix, but I was thinking that could be one way to upgrade it <jmarciano>installing packages does not work at my side as I get same error <jmarciano>I get this error: got unexpected path `Backtrace:' from substituter, it comes on installations of packages <jmarciano>otherwise, I would just install package, I need few of them <jmarciano>with --no-substitutes I get this error: guix: offload: command not found <lle-bout>jmarciano: how did you install GNU Guix exactly? <lle-bout>jmarciano: what's the output of 'guix describe'? <jmarciano>by following instructions in manual, this is not Guix OS, it is guix package manager <jmarciano>guix describe: error: failed to determine origin <jmarciano>hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version string is <jmarciano>It worked fine, I could install packages, after some time it failed to install new packages. <lle-bout>jmarciano: you used the shell-based installer? <jmarciano>yes I think so as I downloaded and installed by following instructions <lle-bout>These issues you are encoutering should have disappeared long ago (there was some reports earlier and they were fixed) <jmarciano>do I lose repository /gnu by doing new install? <jmarciano>and I do not know a way to remove guix entirely, is it manually to seach for files? <jmarciano>I will do that installation, but that is exactly what I did before maybe 2 months <jmarciano>I would like to overwrite Guix with new installation, but installer may say "it is already installed" <lle-bout>jmarciano: remove it before, it wont override <lle-bout>jmarciano: otherwise you can try modifying the script for it to ignore some things <lle-bout>marusich: efraim has made wip-ppc64le master mergeable with wip-ppc64le-for-master! <lle-bout>right now it fails due to sed SELinux, waiting for them to fix it, as for me, doing security and reviewing a Zig package <marusich>I saw, and I'm optimistic, but it doesn't pass 'make check', and I'm looking into that. Also it only postpones the inevitale breakage when core-updates is merged into master <lle-bout>marusich: of course, but gcc-8 can be done by then maybe <lle-bout>marusich: what are the 'guix' test problems on wip-ppc64le, do you have any idea? <marusich>on wip-ppc64le the problems are (1) make check fails (tests/syscalls.scm I believe), and (2) valgrind fails to build (thus guix fails to build) <marusich>on wip-pc64le-for-master, the problems I know about are that make check fails (test/syscalls.scm and tests/pack.scm) <lle-bout>marusich: I don't get the valgrind failure :-| <jmarciano>lle-bout: should I remove ~/config/guix and anything in /var related to guix? <marusich>so guix built successfully for you? I think you mentioned it before, I guess I'm just surprised it fails for me <lle-bout>marusich: it built but fails with checks <lle-bout>marusich: running a build of it again now <jmarciano>the install script should not IMHO try to download new archive if it was interrupted, archive should be kept. It spends data in those countries where it is very expensive <i1l>emm.. i saw some Nix packages. they are not written like "use modules a b c, code", but like "lambda (func_a, func_b, func_c, ...), code". this means that package manager searches for dependencies itself (as i understood).. can it be so in Guix? looks interesting and "automated". <i1l>i remember Guix has something like spec->package already. takes strings, returns packages it found. <lle-bout>marusich: any idea how to access unpacked source directory path from within a phase? <jmarciano>install scripts REQUIRES that /gnu does not exist <jmarciano>you could as well tell me to do it all myself <jmarciano>script itself should be made for all people more flexible, for example, it could ask to overwrite, or maybe to keep /gnu or something <lle-bout>jmarciano: don't act as if you were entitled to some shell-script installer that fits your use case <lle-bout>many things could be better in GNU Guix, best way to make it actually better is to contribute <marusich>lle-bout, i believe it depends on the build system used, generally. <lle-bout>marusich: I used environment variables to try and pass the unpack dir, but I feel like that's a hack <marusich>For instance, gnu-build-system has an 'unpack phase in which everything goes to the "source" directory and we chdir to id <marusich>Since the phases are deterministic, if you know the cwd for your phase, you can always write a with-directory-excursion form to go to it using a relative path <jmarciano>tips like that are useful for all Guix users <marusich>Another common trick is to put the source in an input and then access the input like any other, e.g. via assoc-ref inputs <lle-bout>marusich: I think I want the unpacked source <marusich>Anyway. check the build system's code in guix/build/whatever-build-system.scm <lle-bout>marusich: I checked but couldnt find a Scheme variable with the unpack dir unfortunately :-S <lle-bout>marusich: are you sure the unpacked source dir isnt named after the tarball..? <marusich>If the source comes from a tarball, the unpack phase will extract it and then invoke (first-subdirectory ".") to go to it. <lle-bout>marusich: ohh that's a useful function, I also saw NIX_BUILD_TOP env variable <marusich>the phase chdirs to it, so usually you don't need to chdir] <lle-bout>so I could actually use both to find the unpacked source dir <lle-bout>marusich: basically I need that dir before I have a package (zig) that can only run tests after 'install phase <marusich>yes, but since the phases are deterministic, I don't think it's that bad to use with-directory-excursion to temporarily go somewhere else for your phase, if you aren't already where you need to be, or if you can't get the directory via some other method <lle-bout>jmarciano: for the expensive data thing.. GNU Guix really isnt optimizing for that use case at all.. so I am afraid you will be better served with some other distro for that. However (when you don't have broken GNU Guix installs..) there's a feature to publish your store to your LAN (guix publish --advertise), so that creates some sort of cache, but downloaded things will still be larger than they really need to be. For size <lle-bout>minimization, some other distros are just better, not GNU Guix right now. <lle-bout>but you can certainly contribute on that aspect to GNU Guix (size minimization that is) <jmarciano>lle-bout: right now, just Guix offers me straight access to some software <jmarciano>other issue at hand is that my system sets LD_LIBRARY_PATH, such as /root/GNUstep/Library/Libraries:/usr/lib which conflicts with guix, then I need to $ unset LD_LIBRARY_PATH before running guix, is there way to keep both in alignment? <marusich>hey lle-bout , do you have a guix with a version later than 7e9d9f28e997e7faad28cdd1c416be174d6986e7 ? can you run "guix repl", then ",use (guix build syscalls)", and then ",pp (mounts)" and share the result with me? I don't have a recent version built on an x86_64-linux system and I'm curious to see what the output looks like there. <lle-bout>jmarciano: what kind of distro are you on..? <marusich>I'm building it but if you have one offhand that is up to date it would be convenient. <i1l>> LD_LIBRARY_PATH -- do Guix uses it? <lle-bout>jmarciano: I don't know the answer to your question, but just piece of advice if you want to run GNU Guix on another distro without running into weird problems all the time, keep your environment within the norm. <marusich>i1l, my understanding is that you can set LD_LIBRARY_PATH to override where theings are loaded from, but in Guix we use embedded runpaths to find libraries in /gnu/store, I don't think we use LD_LIBRARY_PATH for stuff like that. you can confirm by doing 'git grep LD_LIBRARY_PATH' to see how it's being used in the source, if you are curious. <lle-bout>jmarciano: distros people most commonly run GNU Guix (or any other software) on, since that's what users test the most often <lle-bout>default environments provided by those distros * <donotshake[m]>I'm trying to package something in go and am wondering how, if at all, to have two `#:import-path`s ? <jmarciano>lle-bout: yes, this LD_LIBRARY_PATH is not set by user, rather by OS <i1l>marusich: so jmarciano have no chance to get an conflict due to that e-var? <jmarciano>those LD_LIBRARY_PATH are installed from /etc/profile.d/ I have found here <lle-bout>jmarciano: Trisquel or any other Debian/Ubuntu-based are the most tested environments for GNU Guix on other distros AFAICT <marusich>I think if you set LD_LIBRARY_PATH it might conflict, since the linker will honor your request to search those locations for libraries. <jmarciano>I use Guix because I do not change OS, I need some software beyond it, that it is in Guix <jmarciano>maybe there is something that I can add to LD_LIBRARY_PATH so that Guix does not complain? <marusich>Generally speaking, on any given non-Guix distro, you need to be careful about how the environment interacts with Guix-installed stuff. Usually it isn't too bad, but you have to take care not to have environment variables set that will interfere with things. If LD_LIBRARY_PATH is set, then perhaps you can do start an environment in which that is not set, to see if it fixes your issue? E.g. "env -u LD_LIBRARY_PATH some-cool-tool-from-guix"? <jmarciano>but maybe there is path for Guix that I can just set and be fine? <jmarciano>other question: if software is installed by root, is it avaialable to other users? <lle-bout>jmarciano: each user has its own profile, but on GNU Guix System you can install packages in your system then it's available for every user <jmarciano>I see even though I installed glibc-locales I am not sure it generated locales, how to generate locales? <lle-bout>jmarciano: on my GNU Guix System installation I do not use user profiles, I install everything I need into my system then I use 'guix environment --ad-hoc <pkg> -- <bin>' if I need something once <lle-bout>jmarciano: restart your guix-daemon, as it runs as root, if you installed glibc-locales in your root user profile, it will take it from there too <i1l>lle-bout: even BROWSERS? to sys profile? is it an 192GB RAM box? <lle-bout>i1l: yes browsers to system profiles? what is the problem with that? it's not a 192GB of RAM box nope <i1l>or guix update is an alias to conditional with `weather`.. <lle-bout>i1l, jmarciano: the reason I do this is because I prefer to manage software updates in one single place *lle-bout looks at sss2's issue <i1l>lle-bout: just browsers not always already substitute ready. <lle-bout>i1l: then I can wait a bit for them to be ready, I also have offloading set up to another powerful server for development so that helps. <marusich>jmarciano, when using guix, I suggest unsetting environment variables that would cause system stuff to be used, like LD_LIBRARY_PATH. Try it out in a shell via "env -u LD_LIBRARY_PATH bash" or whatever. <jmarciano>can I pay $5 for somebody to make recipe for Leo editor? <marusich>I use a script like this in fedora to "activate" my guix environments, i.e. set the environment variables. I don't keep the guix environment variables active in all my shells. <jmarciano>marusich: thanks, I made now alias guix='env -u LD_LIBRARY_PATH guix' <lle-bout>jmarciano: I can look for packaging it but no need to pay anything, can't say when though, if it's easy it can be fast, looking at sss2's issue for now <marusich>You can modify it to unset env vars also, if they are interefering. <marusich>But the point I wanted to make is that it totally depends on the foreign distro <marusich>They are all unique snowflakes, and the way in which they might interfere, and the solution you might take, depends entirely on the distro and sometimes even on how you are starting your environment. <lle-bout>jmarciano: make a donation to GNU Guix as a whole then! I'll be happy about that! <jmarciano>sponsoring need not influence development, it may or may not be <marusich>e.g. when you ssh in, it's a different environment usually than if you log in via a graphical desktop <sss2>lle-bout, i have tried to install qt4, pyqt "meta" package and sip separately, but it does not helped <marusich>i have encountered similar issues, and usually the easiest path to a fix is to search guix-devel and the guix bug reports for keywords that help me figure out if someone has encountered the same problem before - sometimes a work-around for that specific distro has been shared on the list. <lle-bout>sss2: I will modernize and fix the pybitmessage package since it seems it still depends on python2 right now, not sure if upstream supports python3 <lle-bout>sss2: I see one probable issue it's that it uses propagated-inputs, I'll convert that to usage of wrap-program. <jmarciano>/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) <jmarciano>this error comes up even if daemon is restarted <lle-bout>jmarciano: I am not sure exactly try to reboot your computer entirely to make sure everything takes from the new environment <lle-bout>jmarciano: some of these errors may be normal and non-critical depending in what context they happen <jmarciano>now, since I removed previous guix installation, I lost /var/guix/profiles/per-user/admin/guix-profile <jmarciano>and cannot find where is instruction how to create profile for user <lle-bout>jmarciano: run "guix install <something>" it will create your profile <lle-bout>jmarciano: I am really confused by all these errors you are getting, they never happened to me. I am afraid I can't be of much help here, your installation of GNU Guix looks severely corrupted in some way. <lle-bout>jmarciano: are you simply running Hyperbola without anything special? <jmarciano>I don't think that my OS is influencing Guix <jmarciano>beyond LD_LIBRARY_PATH, there is nothing to interfere <lle-bout>jmarciano: try to 'guix pull' first there <jmarciano>substitute: error: make-session: unbound variable <jmarciano>I think that running guix with 'env -u LD_LIBRARY_PATH' would not prevent sub processes to again receive LD_LIBRARY_PATH set <lle-bout>jmarciano: I'll have to give a try on Hyperbola to see if there's any issues running GNU Guix there, but for now, can't say <lle-bout>if you can't run 'guix pull' you're stuck there <i1l>maybe make an shell script: <i1l>rather than on same line. sometimes it helped me, i think <jmarciano>the DNS resolving from default local network server is maybe making problems, so I changed nameserver to 8.8.8.8 and this error does not appear <lle-bout>jmarciano: 'guix pull' only modifies the current user's 'guix' command <i1l>lle-bout: is, to update the daemon on Parabola, pull should be performed as root? i forgot. <i1l>something like that was a case for on-tops. <lle-bout>i1l: how does your guix-daemon service look like? <lle-bout>I only use GNU Guix System so I am not very aware of GNU Guix on other distros and how it works. <i1l>never ran for long time on-top. <marusich>i1l, whatever profile you run guix-daemon from, you should upate that one. <marusich>the guix installer script that most people will probably use chooses to install guix-daemon in root's profile. so that's the one you need to update, probably. <marusich>to know for sure, you can check whatever it is that is invoking guix-daemon. If it's systemd, look at the unit file. what is it execing? it'll be guix-daemon, from some profile. That's the profile you need to update, to update guix-daemon. <marusich>lle-bout, i resolved the tests/syscalls.scm problem. seems like a bug in recent syscalls.scm code...i'll submit a patch when i respond to the email thread about wip-ppc64le-for-maseter <marusich>"ERROR: Wrong type to apply: "/home/marusich/guix-core-updates/test-tmp/store/8hyyfskwzj6986ff117sw3fpwhhzgrn1-bootstra <lle-bout>marusich: you asked me something about mount, I forgot <lle-bout>marusich: btw you should still have access to the proxmox x86 machines <marusich>how can this be...hmmm... what does cat /proc/self/mountinfo say? <marusich>For me on fedora and debian it looks like this <marusich>OK, so for you the mounts procedure works fine, because it assumes that type and source are columns 8 and 9 <marusich>but for me, it won't get the right type and source unless it uses columns 10 and 11. <marusich>I guess I'll ask ludo how he wants to fix that, since he introduced the code. It seems the optional fields column might not be included at all, as in your system. <lle-bout>marusich: I run GNU Guix System with kernel 5.11.3, but I should reboot <marusich>I see now that the optional fields are actually "zero or more fields", so i wonder if it even shows up as a single column... see man proc for details <marusich>I'll just ask ludo about it; it's almost midnight here. <marusich>my fix was to just change the assumption so it looks in columns 9 and 10 but clearly that won't work on your system, so we need something else <efraim>efraim@guixp9:~/guix$ file /gnu/store/2nfx2i62hpvqx7kfqphcvq4xbvrjwnp1-hello-2.10/bin/hello <efraim>/gnu/store/2nfx2i62hpvqx7kfqphcvq4xbvrjwnp1-hello-2.10/bin/hello: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /gnu/store/sipyfs2540b48b2sb9j8ypmybja1dvqb-glibc-2.31/lib/ld64.so.2, for GNU/Linux 2.6.32, not stripped <lle-bout>efraim: awesome! sed patch required for me because my Fedora ppc64le offload machine's kernel has SELinux enabled <efraim>lle-bout: I'll put something together <efraim>efraim@g4:~/workspace/guix-core-updates$ file /gnu/store/10ivcgn55wwv74dxwh58sh7hphrk540f-hello-2.10/bin/hello <efraim>/gnu/store/10ivcgn55wwv74dxwh58sh7hphrk540f-hello-2.10/bin/hello: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /gnu/store/dgyvjkdf3rypbffdz6vjmiblxax6y3pi-glibc-2.32/lib/ld.so.1, stripped <marusich>lle-bout, what's youry kernel? the one that produced that paste just now. <marusich>I am just now drafting an email for you ;) <lle-bout>marusich: on x86_64 I run GNU Guix System <marusich>efraim, do you mind if i rebase wip-ppc64le-for-master? I want to drop commit 8f52ea2 because it is not necessary (and actually contributes to a test failure) because it solves a problem that is not present on master. <i1l>lle-bout: .. due to some troubles on aarch64? (hi civodul.) <efraim>marusich: I'm ok with that. I almost have a patch for lle-bout for sed and selinux for wip-ppc64le-for-master but I can wait to push it <marusich>Is that similar to a48a3f0640d76cb5e5945557c9aae6dabce39d93? <lle-bout>marusich: I think they are also making it so it doesnt change the derivation hash on other archs <i1l>lle-bout: "using on 86" mean not on non 86. nothing. <lle-bout>i1l: I have a Talos II but GNU Guix's not working there yet, so my x86 laptop is all I have <efraim>marusich: yes, but in a phase for ppc64le only on master, with a note to keep the version in core-updates in the snippet <lle-bout>sss2: do you have a revision where pybitmessage worked? <marusich>efraim, the branch is rebased. i removed 8f52ea2d2bbd58c6f23af338f109b8ba3a4b4e86 from the branch. <sss2>lle-bout, i think so, but i need check it <efraim>marusich: I see you didn't squash the glibc patch <marusich>I will not touch the branch tonight; i need to go to sleep <marusich>Thank you for taking the time to update the commits to be less invasive so we can put them on master. <sss2>lle-bout, i gues it worked on Feb 26 2021 04:47:27 <sss2>i do not know how to get revision from generation <lle-bout>efraim: this commit message is kind of contradictory: kind of contradic <i1l>sss2: guix -p Generation maybe cmd, maybe? had forgot. i think gen == profile. ***apteryx is now known as Guest59538
***apteryx_ is now known as apteryx
<efraim>lle-bout: doh! I don't know what I was thinking <sss2>lle-bout, probably not ... guix: unrecognized option '-p' <sss2>lle-bout, sorry, i am relatively new guix user, so probably do not know many obvious basics <lle-bout>but it's i1l who tried to help you there <sss2>ah.., yes, still a bit sleeppy ) <i1l>ok, my bad. some --profile switch was in `guix`. <efraim>lle-bout: now try wip-ppc64le-for-master, I added a patch for sed *efraim goes afk for a bit <marusich>OK, efraim and civodul , I sent my email. <marusich>efraim, if you can figure out what's up with commit 2712703474137310c2cf4f1a3530500188b37b9f and the last problem I mention, that'd be great. I'll check it out more tomorrow, but I gotta sleep now. <marusich>And again, thank you for all your help! Maybe 2021 will be the year of the POWER9 Guix desktop :) <lle-bout>sss2: can't find a commit where it works for now <lle-bout>sss2: trying back in December last year now <civodul>marusich: yay for Guix on POWER9 and all that on the desktop! :-) <lle-bout>abcdw: reading your guix home email, exciting! <lle-bout>abcdw: it's really good you're creating videos of things <abcdw>lle-bout: Thank you!) I find it a good way to spread the knowledge and ideas) Also, I learn myself preparing for streams and talks. <lle-bout>abcdw: yes! we need more knowledge spreading across GNU Guix! :-D <lle-bout>abcdw: can't wait until I can use some GNU Guix System and home configuration from some repo where everyone centralizes best practices, knowledge and then code so we can all improve our setups without redo-ing everything all the time <efraim>marusich: looks like you ran into the same glibc-intermediate missing input that lle-bout ran into, that was fixed with the squash commit. I'm trying out make guix-binary.powerpc64le-linux.tar.xz now. I'll try to look at the test failures too but no promises :) <lle-bout>sss2: from august 2020 it worked but still trying to find something closer <sss2>lle-bout, for me it borken recently, and in february it was worked <sss2>oldest generation i currently have is feb 26 <lle-bout>sss2: well date of generation isnt date of guix pull, maybe you can switch to this generation and tell me guix commit, or try to read this generation's manifest <sss2>lle-bout, strange, it does not work on this generation now ..... <sss2>but i am sure what it worked .... <sss2>c3a7537396f11af7dd04c294714eb20980946083 - this commit, but it does not work for me now ( <sss2>hm..., seems it does not applyed <lle-bout>sss2: I am not sure changing generations changes output of guix describe <sss2>how to properly switch generation ? <sss2>looks like guix package -S does not work ... <lle-bout>sss2: it's the way to change generations <sss2>ok, switched generation, checked what changes applyed, unfortunately pybitmessage does not work on my oldest generation also ... <abcdw>lle-bout: that's true. A lot of reinvented wheels all over the user's repositories, however some of them are pretty neat) <lle-bout>sss2: guix time-machine --commit=25aac383865b1139336aca923a4d436704c74a8c -- environment --pure --ad-hoc pybitmessage -- pybitmessage <sss2>lle-bout, can i install only pybitmessage from this commit ? ***stikonas_ is now known as stikonas
<sss2>lle-bout, build from --commit=25aac383865b1139336aca923a4d436704c74a8c working, thx <zimoun>I am lost with Guile modules. Why (define foo (@@ (guix scripts environment) %default-shell)) returns an error: %default-shell: unbound variable? ***link2xt[nm] is now known as link2xt
<rekado>lle-bout: I think it would make sense to report the vulnerabilities you found to bug-guix instead of guix-devel <rekado>that way we can tag them as serious or severe and have issues.guix.gnu.org list them with the pile of other serious bugs :) <rekado>I’m afraid that they might get drowned out on guix-devel, and it’s difficult to see if a discussion resulted in a solution. <zimoun>rekado: the «perhaps it has been inlined» is an answer to my question? Or something else? <rekado>zimoun: yes, it’s an answer to your question. <zimoun>rekado: thanks. But I am not able to have anything defined in (guix scripts environment) in the REPL. It is annoying for testing one thing without going to Geiser or something like that. I mean “guix repl” then test some functions. <zimoun>rekado: how do you generate this “guix-env-perf.svg” file? <rekado>“perf timechart record <the-command>” and then “perf timechart -p guix -p guix-daemon” <xelxebar>rekado: Interesting. Now I'm wonding if there's some flag for the guix compiler to disable inlining. <civodul>looks like ci.guix hasn't built the latest grafts yet <apteryx>raghavgururajan leoprikler by the way, I found the issue with the guix environment --pure and icons not being available in a locally built Jami; there was propagation of both gdk-pixbuf and gdk-pixbuf+svg; and somehow the earlier appear first in LIBRARY_PATH. <apteryx>I've just push a fix for this (ensuring gdk-pixbuf+svg is the one used when propagated) on staging. <apteryx>if you had issues with some applications not displaying scalable SVG resource icons; try 'ldd' on it and see if it link to gdk-pixbuf instead of gdk-pixbuf+svg. <leoprikler>w.r.t. gdk-pixbuf vs. +svg, does this also fix problems, that occur in relation to GObjectIntrospection? <apteryx>I don't know; are there known problems with it? If so, we should document those on the tracker. <apteryx>Hmm, I doubt it fixes this, unless I'm missing something. <apteryx>It just resolves conflicts between propagated gdk-pixbuf and gdk-pixbuf+svg <civodul>jas4711: hi! looks like guix-x15b is off-line <rekado>are we accessing them through the VPN already? <ArneBab>Is there a specific reason why we don’t have a Lilypond on Guile3 in Guix — or is it just that no one did it yet? <rekado>leoprikler: it doesn’t even use Guile 2 <rekado>ArneBab: Lilypond upstream doesn’t even go all in on using Guile 2 yet, so we can hardly provide a variant of Lilypond that uses Guile 3. <ArneBab>rekado: it would make it much easier to test compatibility. I know that upstream only has a branch with Guile2 patches — but if not even Guix provides Lilypond on Guile2/3, who else should? <ArneBab>I built Lilypond-on-Guile2 some years ago locally. <rekado>I don’t think we should go out of our way to provide package variants that are known to be unsupported <leoprikler>you are free to write your own guix.scm for lilypond, but I think Guix as a distro is right here to not ship lilypond-on-guile2-warning-super-experimental <ngz>we do not even provide an up-to-date Lilypond with Guile 1.8 :) <ngz>(I failed to update it the other day) <ngz>ArneBab: It could made for an interesting external channel, tho. <apteryx>how does 'guix container' work? Its help text says the action is 'exec', but doesn't say how to specify which container the action should run in? <apteryx>ah, the manual is more up to date: guix container exec PID PROGRAM ARGUMENTS... <apteryx>so probably you get the PID via 'guix processes', which you can feed to the above command <ArneBab>Can you point me to up-to-date documentation on making external channels? <apteryx>eh, 32 GiB of RAM + 16 GiB of swap is hardly enough to build webkitgtk on 24 cores. <ArneBab>apteryx: you need less cores … (sorry :-) ) <ArneBab>seriously: yes, webkitgtk build times are annoying. <apteryx>ArneBab: I'm retrying with 12. It's a bit of a problem that offload doesn't honor --cores ***elibrokeit is now known as pacman-get
***pacman-get is now known as elibrokeit
<zimoun>civodul: “guix weather -m ect/release-manifest.scm --display-missing“ is nice but then it is cumbersome to chain and check what is concretely wrong. ***Allan[m] is now known as allan[m]
<zimoun>civodul: «;;; Failed to autoload make-zlib-input-port in (zlib):» with ./pre-env-inst guix lint foo. Looks related to the recent Guile-zlib change, right? <lfam>I want to narrow the scope of the c-ares graft to only use a patch rather than a full package update <lfam>This grafted update includes 8783 upstream commits, and changes the test suite enough that we have to disable it <lfam>I'm not confident it's "graftable" <lfam>It also seems that the fixed CVE was introduced after the version of c-ares that we had been packaging <lfam>lle-bout: What do you think? <lfam>In general, it's important to keep the scope of changes in grafted replacements very narrow, and they have to have the same ABI <zimoun>civodul: a04aef2430 about utils: Use Guile-zlib seems to break lint. <apteryx>ArneBab: thanks, the webkitgtk build passed with 12 cores <apteryx>lzip:7 compresses at a rate of about 700 KiB/s on a fast core <lfam>Well, the "ABI laboratory" suggests that the c-ares ABI is stable across these updates. Maybe it's worth just getting the package update now (our previous version was from 2008) <leoprikler>Would Gentoo sue us for copyright infringement if we were to sell T-shirts with the line "10 years grafting"? <ArneBab>apteryx: it’s not like I did much more than trolling you (though I knew that I was right, because that build just gobbles up crazy amounts of RAM per core) <ArneBab>apteryx: but anyway: I’m glad it helped :-) <lfam>Oh, I misread the version number of our old c-ares package. It's much more recent than I thought <leoprikler>Nice, just got 200% substitutes from ci.guix.gnu.org <sneek>jgart was in #guile 8 days ago, saying: I'll be happy to send a patch for the updated link if someone can confirm if I should use the one I linked above.. <leoprikler>it seems sneek has some side channel capabilities *vagrantc wonders if guile-zlib will just keep moving over one decimal place for each version <zimoun>vagrantc: maybe it is binary on 3 bits :-) <marusich>they should have called it "romantic versioning" <marusich>It's basically how everyone does versioning. <leoprikler>romantic versioning seems to already have been by backbone <apteryx>I'm trying to use --root with guix build -m manifest.scm --root=$HOME/.config/guix/profiles/name, and it produces two links rather than one, pointing to the debug output and normal output of coreutils. Hmm. <apteryx>I would have expected the root to point to the profile <apteryx>it seems to point to the first listed of the profile instead <apteryx>I guess I can use 'guix package -p ./the/profile -m mymanifest.scm' as a workaround <apteryx>perhaps that's expected; the manual says of 'guix build -m': Build all packages listed in the given; so it builds them one by one rather than building the corresponding profile. <rekado>leoprikler: I’ve seen reports of weird percentages before. Maybe it’ll itch enough one day to prompt an investigation :) <PotentialUser-32>Friends, have you ever used Heimdall? Does the app work well? Is this a stopped program? (The latest version is about 4 years ago) <Noisytoot>PotentialUser-32: I've used it to flash Replicant <Noisytoot>PotentialUser-32: I'm not sure there's an alternative (other than nonfree software) <apteryx>rekado: it also flickers badly; we should probably have it max at 60 Hz or something <apteryx>and doesn't handle well terminals of width ~ 80 chars or smaller <smartineng>Hello, I've just manually replaced ping/ping6 setuid with cap_net_raw+ep and it works so why in general guix system is not using capabilities by defaults? <lfam>smartineng: Basically, because nobody has done the work to make it happen <PotentialUser-32>have you ever used Heimdall? Does the app work well? Is this a stopped program? (The latest version is about 4 years ago) <smartineng>Ifam: manually it's trivial, just 'sudo chmod u-s /run/setuid-programs/ping && sudo setcap cap_net_raw+ap /run/setuid-programs/ping' <Noisytoot>PotentialUser-32: The first message was fine, as IRC nicknames are case insensitive <OriansJ>first verify that your device is detected with: adb devices <roptat>PotentialUser-32, heimdall should still work, but our android packages are stuck at android 7, because later versions use a different build system that is hard to implement <Noisytoot>PotentialUser-32: The command I used is: heimdall flash --KERNEL recovery-i9100.img --RECOVERY recovery-i9100.img <OriansJ>In the event that fails, turn on developer mode for your tablet. <Noisytoot>roptat: The version in Debian testing seems to be the same as the version in Guix <roptat>oh wait, heimdall is not part of android, forget what I said! <apteryx>roptat: eh, did not even know we had android packages <PotentialUser-32>roptat: My device (Galaxy J7 Core SM-J701F) is running Android 9, can I still hope? <apteryx>not like packages targetting the Android OS runtime <roptat>PotentialUser-32, yes, our android stuff works with my device which has android 10 <roptat>PotentialUser-32, you might want to add android-udev-rules to your system config if you're under the guix system <roptat>apteryx, I'm still aiming at having the runtime at some point :) <Noisytoot>roptat: So then you could run Android apps on Guix? <roptat>yeah, or build android from guix packages <roptat>imagine, guix system android-image android-config.scm <roptat>I'm dreaming, it won't happen soon ^^' <PotentialUser-32>I do not have much information about this, so I wanted to proceed this way (forum.xda-developers.com/t/rooting-j701f.4004753). Is this wrong? Should I use Replicant or LineageOS? <Noisytoot>PotentialUser-32: I don't think your device supports Replicant <roptat>Replicant is the free software alternative <roptat>but it's limited in devices it supports <roptat>so it's the only one we can recommend :) <PotentialUser-32>roptat: Sorry, there is no way, please suggest another way to root, thanks! :) <roptat>well, the situation around android devices is really bad :/ *Noisytoot accidentally left <roptat>Lineage is probably the best option you have, but it's not totally free, so we don't recommend it, but we don't recommend any alternative except buy a phone that's supported by replicant <Noisytoot>tpefreedom: In HexChat middle click leaves the channel <tpefreedom>I think middle click closes pretty much anything, at least when using MATE. <roptat>how was it? any part of the installation process we could improve? <tpefreedom>Or do something so I don't get to the end and have it fail because of missing keys <lfam>Did it tell you how to retrieve the keys? <tpefreedom>Also, I had to run the daemon I a second terminal <tpefreedom>yes for the keys but only once it failed the first time <lfam>Can you say more about the daemon? <tpefreedom>It needed the daemon to run to perform the first pull and I had to manually start the daemon myself <tpefreedom>Also this pull command is taking a long time for a bare package manager <PotentialUser-32>I'm in Iran, and unfortunately I can not buy a Librem 5 device directly (due to US sanctions) <Noisytoot>PotentialUser-32: Get someone to forward it to you? <lfam>Which command is that tpefreedom? <lfam>It's a little more computationally intensive than similar commands on other distros, like `apt-get update`. But it's usually not more than a couple minutes <Noisytoot>PotentialUser-32: The Pinephone also exists, but it may contain nonfree software <lfam>Yes, that's a good explanation of it, tpefreedom <tpefreedom>I know with pacman you have to sync before anything else so I did it here <lambdanon>Hey there, I was wondering if any DEs other than GNOME are integrated? I keep having a problem with XFCE where, upon locking, I am no longer able to get back into the session. <lambdanon>I have tried changing GDM to SDDM, but the same problem is still there <lfam>tpefreedom: It's a good idea to do it first with Guix too <tpefreedom>It's been at least 10 minutes and it's still going. <lfam>What does it say that it's doing? <lfam>And, what kind of computer are you using? <Noisytoot>lfam, tpefreedom: I once tried to run Guix System on a netbook, it did not work well <PotentialUser-32>noisytoot: Unfortunately, cowardly US sanctions have paralyzed us from buying a foreign product! <lfam>Sorry about that PotentialUser-32 :/ <lfam>I agree, the sanctions are cowardly and evil <tpefreedom>I got guix sd to work in a vm but it needs internet to install meaning I can't even try it on this machine. <lfam>Noisytoot: Yeah, it's not that fun to use weak machines with Guix <lfam>I use a Guix on a really slow machine, but I am patient <lfam>I think a core i5 from 2017 will be fine <lfam>I have something similar <Noisytoot>Client: HexChat 2.14.3 • OS: Debian bullseye/sid • CPU: Intel(R) Core(TM)2 CPU P8600 @ 2.40GHz (800MHz) • Memory: Physical: 3.5 GiB Total (1.2 GiB Free) Swap: 3.7 GiB Total (2.0 GiB Free) • Storage: 301.8 GB / 484.4 GB (182.6 GB Free) • VGA: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller @ Intel Corporation Mobile 4 Series Chipset Memory Controller Hub • Uptime: 1d 23 <Noisytoot>^ That's my CPU (and other unnecessary system information) <lfam>They say that Moore's Law is dead, but processor speeds come a long way since 2008, when that CPU was sold <Noisytoot>lfam: Is there any way performance of guix pull could be improved? <Noisytoot>lfam: Unfortunately new laptops don't work with libreboot <lfam>We have identified it as something that needs to be improved, and work is ongoing in the Guile compiler to speed things up. Already many improvements have been deployed <lfam>Sorry to say that using a build-from-source distro like Guix is never going to be that comfortable on a Core 2 Duo <lfam>But, we do want to improve substitute availability to the point where you don't have to build as much, including for `guix pull` <tpefreedom>I might just buy a laptop the lacks libreboot but otherwise operates at an A or B level on h-node <lfam>I recomemend always pulling a day-old commit on the Core 2 Duo. That way you are very likely to get substitutes <lle-bout>lfam: thanks for solving the version issues! will keep in mind! <lfam>Thanks for grafting all these packages :) <lfam>I noticed the issues when "ungrafting" on the wip-next-release branch. <lfam>The derivations of the "ungrafted" packages should match the replacement packages, but they were not matching <lfam>So, I poked around the derivations and the guile-builder files <lfam>So, I just pushed a new revision of the wip-next-release branch. It's up to date for current master ***Noisytoot is now known as [[
***[[ is now known as [[Like
***[[Like is now known as [[
***[[ is now known as Noisytoot
<lambdanon>Hi, I'm trying to lock XFCE, but every time I do so, I get a constant "Authentication Failed". I tried adding xlock into the services declaration, but this doesn't seem to work <leoprikler>lambdanon: that's because the relevant binaries also need the setuid bit <lambdanon>I see. Is there a way to do this in config.scm, or will I have to manually chmod u+s? <rekado>lambdanon: no, we don’t do things manually <lambdanon>Looking at the manual, I see this section: " <lambdanon>'"screen-locker-service package": Add package, whose command is program, to the set of setuid programs and add a PAM entry for it' <lambdanon>Which I read as saying that this should already add the relevant binaries to setuid? Or will it only add them to the setuid if I append screen-locker-service to some other expression which sets the setuid programs? <rekado>lambdanon: it extends the setuid-program-service-type <rekado>so you don’t need to do anything else <roptat>you need to configure your system with that service though, I think <lambdanon>I already did, so why am I still getting the problem where I repeatedly see authentication failing? <roptat>maybe it's not using the right binary? <lfam>Did you reboot after you reconfigured? <roptat>like, if you have also installed the screen locker in your profile, it's not setuid <lambdanon>If I put the screen locker in the packages declaration, isn't that adding it to my profile? Or will I also need to install it as a user too? <lambdanon>Ah, found the problem. I thought using screen-locker-service would automatically change xfce to use a different screensaver. It was still using xfce4-screensaver <roptat>oh, maybe we don't extend the screen-locker-service from the xfce service? <lambdanon>By extend, do you mean if I placed screen-locker-service inside the xfce-desktop-dervice sexp? <roptat>no, it's a bug in Guix, not on your side <roptat>but if you add xfce4-screensaver, it should work too <lambdanon>going to s/(screen-locker-service xlockmore "xlock")/(screen-locker-service xfce4-screensaver "xfce4-screensaver") <roptat>right, that's the solution for you <roptat>looking at other desktop services, they don't seem to add anything for the screen locker <lambdanon>That seems to have stopped the screen locker from saying authentication failed, but now it's not letting me in even though I got my password correct <roptat>maybe check num lock, caps lock and layout? <lambdanon>my laptop uses the US layout so it should fallback to the US layout. Caps lock is disabled, and num lock is off. <roptat>weird... I don't know how to help you :/ <lfam>I'm having an issue while trying to remove services from %base-services in a config.scm <lle-bout>should things required during tests be native-inputs? <bone-baboon>i1l: apteryx: Thanks for your help with "nomodeset" appending that to the line about the kernel solved that issue of the system going unresponsive. I now have Guix installed on the computer. <lfam>However, the removal doesn't take effect at all. When I pass this config.scm to `guix system vm`, it's no different than if I just used (services %base-services) <lfam>Does anyone know what I'm doing wrong? <lfam>That snippet I used is from the manual section Using the Configuration System <lambdanon>Got another problem. Tried removing the sddm service and add gdm, now gdm isn't launching <bone-baboon>apteryx: Now when I start the computer I maualy edit that line. You said this can be added to the operating system configuration. This is what I have come up with from reading Bootloader configuration of the manual `(linux)` <lle-bout>lfam: it looks right, are you sure nscd-service-type is contained in %base-services? <lfam>I've tried it with several other parts of %base-services, same problem <lfam>I started testing it while validating a new service I want to add <lle-bout>lfam: can you (display ..) the output of it? <lfam>I don't really understand services, so I'm hoping that somebody who does can help <lle-bout>lfam: (display (remove (lambda (service) (eq? (service-kind service) nscd-service-type)) %base-services)) <lambdanon>What do I do if I can't get my display manager to launch, and I can't enter a TTY to debug things? <bone-baboon>But it is not working and I get an error about an "extraneous field initializer (linux-arguments)". How should I be fitting this into the bootloader section of the configuration? <lfam>You should share your config.scm bone-baboon, so that people can help you with it <lfam>I would say, there is a field called linux-arguments, but nothing called linux-argument <lfam>lle-bout: I don't know where to put that or how to use it <lle-bout>lfam: put that outside of the operating-system definition anywhere <lle-bout>when you use the operating system definition, it will display <lfam>It didn't have any effect <lfam>Oh, actually now it did, it crashed <lfam>I made it first field of operating-system, and it crashed like this: <lfam>error: (operating-system (display (remove (lambda (service) (eq? (service-kind service) nscd-service-type)) %base-services))): extraneous field initializers (display) <lle-bout>lfam: don't make it a field, put it above the operating system definition <lfam>I don't think that operating-system can have a top-level (display) procedure <lfam>Alright, it printed the services, including nscd <lfam>I already know that it's not removing the service <lfam>I don't need to verify that <lfam>I'm trying to figure out why it's not <lle-bout>lfam: now you can try things until it does.. <nckxs_evil_goate>lle-bout: Go ahead. You're free to add other 'well-known' Guix contributors. ***nckxs_evil_goate is now known as nckx_evil_goatee
<nckx>lfam: Thanks, I was just having bouncer trouble. <nckx>lle-bout: Is Vincent on IRC? <nckx>Unless you've already started I'll take care of it if you like. <bone-baboon>I also tried `(menu-entry (linux-arguments '("nomodeset")))` but that did not work for me either. <lfam>In what way does it not work <lfam>Like, does it crash `guix system reconfigure`? Or just not have the desired effect? <nckx>bone-baboon: Any reason why you're putting it under boot-loader instead of putting (kernel-arguments (list "nomodeset")) in your operating-system, at the top level? <apteryx>bone-baboon: I think you can just add it to the kernel-arguments list of your operatingsystem, no? <nckx>(I'm without context, hence the question.) <lfam>Now that some more people are around, can anyone test that removing services from %base-services or %desktop-services is working for them? <lfam>As discussed earlier, I'm trying to use the code snippet in the manual section Using the Configuration System but it has no effect <nckx>I can't even keep the good & bad remove straight. <nckx>(There are two, one will not work.) <apteryx>is there something special in our handling of Qt? I built jami-qt in a Guix environment, and the QmlThread crashes with SIGSEGV, like so: Thread 7 "QQmlThread" received signal SIGSEGV, Segmentation fault. <lfam>Can you try again with --no-grafts, apteryx? <apteryx>I don't think there are grafts, I'm working off staging <nckx>lle-bout: Ping? (I know, that's rich coming from me) <lfam>Alright, thanks for checking <apteryx>there doesn't seem to be anything funky going on in the Qt build system <lfam>lle-bout: I figured out my problem with removing services <lfam>I was using the incorrect remove procedure. I should have used the implementation from SRFI-1, but instead I had been using the one from rnrs-lists <lfam>I didn't understand what you meant nckx, but I figured it out in a roundabout way <nckx>Another victim of Guile. <lfam>On Guix System, the missing module import hint suggests srfi-1, but on Debian, it suggest rnrs-lists <nckx>It wasn't meant to be that roundabout. <lfam>I looked them up the handy Guile Procedure Index <lfam>From the rnrs-lists page: "remove, remv, and remq are identical to the delete, delv, and delq procedures provided by Guile’s core library, (see List Modification). remp is identical to the alternate remove procedure provided by SRFI-1; See SRFI-1 Deleting. " <lfam>So, I could have used remp from rnrs-lists <bone-baboon>nckx: apteryx: Thanks for your comments. I now have it so it does not error on system reconfiguration. I am going to try a reboot and see if it eliminates the need for me to do manual edits. <lfam>The lesson for me is, Guix System is better! <nckx>lfam: The Guix manual, at least, should always mention SRFI-1 explicitly. If not that's a bug. You mentioned a snippet from the manual so I thought my message would be clear. <lfam>I just didn't pay attention to it <bone-baboon>Just before I do that. What program do people use to poweroff from the command line? I am used to using poweroff but it looks like it is not in the base packages and when I search for poweroff I do not find it. <nckx>I use ‘sudo halt’ the few times a year I switch off my laptop. <lambdanon>How much of a guile background is necessary for making a well-engineered Guix SD config? I've gone through the first 3 chapters of SICP, and that's it <lfam>I didn't realize there would be multiple implementations of remove from different libraries. It was just a lazy oversight <nckx>It's too easy a mistake to make. <lfam>Yeah, especially since the hint may be wrong <nckx>I had no idea that could happen. <lfam>lle-bout: It's okay, I got it working <lfam>I was importing the wrong library <lfam>lambdanon: I think you'll be in good shape if you have done some of SICP <lle-bout>lfam: it did remove it for me, just could determine <lfam>I bet you imported the srfi-1 library, which is the correct one <lfam>I had imported rnrs-lists <nckx>bone-baboon: loginctl mentions a ‘loginctl poweroff’ command which might not require sudo; I'm not going to test it now :) <lfam>jackhill: Hm, I think that's new :/ <lfam>What is your `guix describe`? <lambdanon>lfam: cool. Since I can't really do any maintenance on my box, I'm just going to reinstall with a minimal config.scm, and go and make a modular manifest for everything else. Is that what you're supposed to do? <lfam>There's not really a way you're supposed to do it <nckx>It's one of the recommended practices. <nckx>We seem to be reading the same thing differently then. <jackhill>lfam: bb5d84a0489a629d30bc2e978807caf20f46e329 last sucessful reconfigure was 80739ea480a7db667b83b45e3a08be740449f689 <lfam>jackhill: Can you share the entire log of the failing build? <lfam>In that case, can you share the command-line that you used, and all the output, in one paste? <lfam>Sorry if that sounds crazy <nckx>lambdanon: It's recommended not to put all your day-to-day software in your system.scm, but only a small set of ‘system’ packages (e.g. %base-packages, or %desktop) and everything else in a per-user manifest. The logic is that you can then reconfigure without having to rebuild your world. It sounds like what you described. <lfam>jackhill: And after that, try running the command again with --no-grafts. It's not safe to run your system without grafts, but I suspect the bug was introduced by a graft, and I want to test that hypothesis <nckx>But it's not like any other way is ‘bad’ or ‘unsupported’. Freedom! <lambdanon>nckx: That's exactly the problem I was having. I had a config.scm with around 50 emacs packages organized in a hierarchy. It worked, for a time, but it wasn't pretty <leoprikler>yeah, you should keep those 50 hierarchied emacs packages inside a manifest.scm instead :P <n1x_>when adding a package to the repos, is it generally preferable to get as many of its dependencies packaged as possible or is it preferable to try to get a minimal build? trying to package some fairly big golang stuff and I've noticed a lot of the time they'll build fine if don't pass in some dependencies that are being problematic (e.g. circular dependencies) <leoprikler>we normally go for full features, but there's no problem if you package a minimal version and revise it later <leoprikler>especially if there's circular dependencies and you'll need that minimal version for bootstrapping <leoprikler>Just leave a TODO: note in the code, so that people are not surprised <leoprikler>you can also tag your patch as WIP and have others help you if that's preferable <n1x_>yeah, that's what I was planning on doing. I really have no idea how to resolve some of these dependency issues. golang's protobuf libraries are a rat's nest of circular dependencies v__v;; <n1x_>so I figure if a minimal version builds that'll be best for now <jackhill>lfam: would you like my config.scm as well? <lfam>The second crash, it's a nondeterministic networking problem we are currently working on <lfam>It was going to download the grub-image.png instead of building it <lfam>Can you send a bug report to <bug-guix@gnu.org>? <jackhill>any additional information I should include there? <lfam>Please include the info I asked for. The config.scm can't hurt <lfam>It would be nice if you tried again with --no-grafts until it worked, or until it failed due to something besides a network error <jackhill>running again … no network errors so far 🤞 <bone-baboon>When it booted it did not automatically use "nomodeset" and the system was unresponsive. So I rebooted and manually used "nomodeset". Here is the config that does not error when I do a system reconfigure but does not automatically use "nomodeset". https://termbin.com/o25qr