<NieDzejkob>Formbi: Try adding #:rust rust-1.44 to arguments <NieDzejkob>the default rustc for package builds is 1.39, which is about 35 weeks old. This will not be necessary after the next staging merge <rekado_>janneke: with the latest Hurd VM image I see “warning: call to primitive-fork while multiple threads are running; further behavior unspecified. See "Process" in the manual, for more information.” <rekado_>this happens when downloading substitutes <rekado_>so I abort it and restart “guix build hello”, but I get an error about the sqlite database being busy <zimoun>Hi, where is ocamlfind in $GUIX_ENVIRONMENT? I am doing "guix environment --ad-hoc ocaml", do I need to run something else? <jackhill>you're welcome, glad you got it working. <jackhill>writeup is great, thanks for doing that. <zimoun>NieDzejkob: ah yes, thank you. That's it. Well, maybe a story like gcc-toolchain for others compiler like haskell-toolcain, ocaml-toolchain, etc could be helpful <bavier1>I'm a bit disappointed that they decided to not follow up on bugs they "discovered" in libgcrypt ***catonano_ is now known as catonano
<leoprikler>"To replace GnuTLS, you might want to use OpenSSL." So instead of one project riddled with CVEs you want me to use another one riddled with CVEs? <badair>how do I prevent gnutls tests from running when cross-compiling from amd64 to ARM? <badair>I can see there's a patch relating to gnutls cross-compiling from janneke. <badair>hendursaga: I see you mentioned PinePhone recently. I also have one and am slowing trying to get Guix on it in my free time. <GuixNewbie8128>Q: Does anyone else have issue with Krita [x86_64\Linux] not launching? <tho1efx>I love the guix blog and ludo's writing. <tho1efx>AFAIHS the explanations are always clear and comprehensive. <badair>hendursaga: I looked at some of the NixOS work and scrapped together some u-boot stuff and the pine64 kernel. Trying to cross-compile now, probably have to switch to building guix from source instead of trying to work outside the tree. <badair>hendursaga: Waiting on employer approval before I can share-alike though (shouldn't be an issue). <tho1efx><hendursaga "badair: Cool! I look forward to "> As do I, guix on arm is a little rough for some ;) <apteryx>cbaines: any use for ruby-bond and ruby-iruby ? their builds are broken <apteryx>ruby-bond is unmaintained for like 6 years <listlist>rekado_: Is this project your repository? Now it looks like it cannot be successfully built in guix. ***apteryx is now known as Guest45514
***apteryx_ is now known as apteryx
<cbaines>apteryx, I think I was just interested in using iruby when I packaged it <cbaines>iruby looks like it's still active, so it would be nice to fix if possible <cbaines>I did spot #42115 which you raised, maybe the quick fix for that is just to not run the tests <PotentialUser-79>hi, i've been wanting to try out guix some, download the 1.0 install on first laptop, was fine no problems.. now i just downloaded 1.1 but when i select how to partition the disk the installation starts over from the beginning. Anyone else has that problem? <PotentialUser-79>hmm.. checking the date i think both where ver. 1.1.0.. so it is only on the new laptop there is a problem. <PotentialUser-79>ok back... found a mail in the list describing my problem, doing a loop in installation when on nvme. says i can build a new iso using: guix system disk-image --file-system-type=iso9660 gnu/system/install.scm <PotentialUser-79>but using the install.scm i found in gnu/store/blabal/system/install.scm gives me a build error on 1 of the packages... <leoprikler>I'd recommend building this disk-image from a local git checkout of guix <leoprikler>Either point it to the commit you're already using (compare to the output of `guix describe`) or build it once and then use ./pre-inst-env <reepca>hmm, net was out for awhile after my system restarted following a power outage. Power outage reset the hardware clock, so until the net came back up the system thought it was 2014. Meanwhile icecat was started up automatically and it disabled some extensions I like due to certificate issues. ntpd has since corrected the time, but even after restarting icecat the extensions are still disabled. <reepca>welp, reinstalled it and it seems to be working now... <raghavgururajan>nckx: Thank you! I received all the required substitutes. :-). Also, I can look into gjs issue and build it myself. <sneek>Welcome back raghavgururajan, you have 4 messages! <sneek>raghavgururajan, nckx says: No need to ping ‘nckx, nckx[m]’ for multiple reasons, not in the least that I never use Matrix. I logged in once, to set the official #guix channel's favicon, that's it. <sneek>raghavgururajan, nckx says: Build started. Can't say how long it will take this time. Farm's under heavy load. <sneek>raghavgururajan, nckx says: Everything else built. *nckx kicks sneek for flooding. <nckx>raghavgururajan: Let me know what happens (and what the bug was). ***dingenskirchen1 is now known as dingenskirchen
<nckx>raghavgururajan: Both are correct English. sneek's just a picky eater. ***sputny1 is now known as sputny
<sneek>Welcome back civodul, you have 1 message! <sneek>civodul, zimoun says: Is a new presentation at JDEV? Or a recycled one? <NieDzejkob>civodul: Hi! You should know - how do I contribute to guix-past? Is there a mailing list, or do I open a merge request on GitLab? <civodul>zimoun`: my talk at JDEV will be mostly "already seen" but with some new stuff towards the end <civodul>you can create an account and make a pull request if you want <civodul>there's at least efraim, rekado and myself who can push to the main branch <NieDzejkob>hmm, the process for that on GitLab Inria seems a bit involved <efraim>I suppose you could also just send a patch to the guix mailing list and tag it as guix-past <civodul>NieDzejkob: ah, dunno, maybe we need to add you to the members? <NieDzejkob>> External users need to request an external account from an Inria member. <dftxbs3e>is it possible to contribute to GNU Guix on Gitlab? <dftxbs3e>I wish GNU Guix had something like Gitlab or Sourcehut for contributions <efraim>with the channel authentication I end up cherry-picking commits before signing and pushing them anyway <civodul>NieDzejkob: hmm i think efraim for instance got an account without asking me for anything <efraim>I was able to create an account, IIRC I had the default of 0 repositories <efraim>and then I think civodul added me to the guix-hpc group/something <civodul>NieDzejkob: i'd say create an account, and then we'll add you to the repo <civodul>but note that it's signed & everything <civodul>efraim: do you remember how you did that? <civodul>we should add a link in README.md if it's this obscure... <efraim>I might've found the signup link at another gitlab instance and copied the path over <zimoun`>civodul: cool! So I am planning to watch it. <civodul>zimoun`: you created an account right? do you remember how? <NieDzejkob>now to figure out which past versions are actually useful... <civodul>were you looking at specific pieces of software? <NieDzejkob>yeah, I'm hoping to package old versions of RGBDS <zimoun`>ah yes, I remember it was not straightforward :-) Let me check <NieDzejkob>the project has a history of some subtle breaking changes... <NieDzejkob>is it a good idea to inherit from the package in the main guix channel? <NieDzejkob>FWIW no other changes are necessary, just the version and source need to be changed <NieDzejkob>I can see that, for example, autotools inherits, but boost doesn't <civodul>it depends; you might want to be explicit about what should be inherited and what shouldn't <civodul>like if there are patches or arguments that vary from version to version, you'd rather not inherit them <civodul>BTW, note that this is primarily for versions not reachable via time-machine/pull <NieDzejkob>yeah, the package was added to Guix too recently :P <civodul>i don't have an actual time machine to offer :-) <civodul>bah, i don't even know how to create an account, i'll ask my colleagues <civodul>NieDzejkob: in the meantime feel free to send patches by email! <zimoun`>civodul: BTW I think you can only invite 50 externals <NieDzejkob>civodul: Yeah, I will once I get this patch finished <pkill9>i have an idea, a launcher that brings up a list of all available packages, and if you select a package that isn't installed, it installs it automatically, and then have an mcron service that removes packages that you accessed htrough that interface that you haven't used in x amount of time <pkill9>installs it automaticlaly and runs it* <pkill9>and if you select that package again through the launcher and it's installed, it just runs it ***jonsger1 is now known as jonsger
<civodul>the suggested CPEs are very useful tho! <apteryx>yes, we should add such suggestions to our own linters <nckx>apteryx: A lot of the warnings are bogus but yes, useful tool. <civodul>apteryx: they can make such suggestions only by comparing with other distros, i guess <apteryx>the source of the site is open, I should check :-) <civodul>i wonder how repology determines that "CPE information is missing" since we only add it when it differs from our package name <nckx>civodul: They want it to be explicity set for each package. :-/ <zimoun`>civodul, apteryx: speaking about lint, "-c archival" should be run more automatically. So maybe outside the real linting. And I plan to add the hg and svn support in the coming days. <zimoun`>civodul: thanks for #42286. The rate limit is really annoying! <apteryx>zimoun`: shouldn't we add lint to our pre-push commit hook? <apteryx>(well, for those committers using the pre-push hook, which is hopefull most/all of them :-) <apteryx>but as mentionned in past discussions, the hook should be moved server side to ensure it happens. <apteryx>yeah, it seems the implementation is only looking at the information it it knows the repo *can* mention it, and complains when it isn't present: "CPE information defined for the package:<div>{{ mcpes.panels(problem.data.cpe) }}</div>was not found neiter among known CVEs nor in NVD CPE dictionary, so it may be invalid." <nckx>raghavgururajan: Shouldn't it be a list? (list "--disable-static" …) But 127 means ‘command not found’. <janneke>rekado: i remember seeing that warning and the hangs too. about the sqlite being busy, could it be that a guix-daemon is still "hanging": kill that and continue? i don't know if the sqlite patches really fix this too, although i haven't seen a hang in some time <apteryx>it parses the cpe_name from a Guix package <nckx>Right, but it doesn't fall back like we do. <raghavgururajan>nckx: It is for librsvg-next. You can see that part of code in the current code base. <nckx>I don't get it. What are your changes (your local diff)? Removing (native-)inputs? I could see how that leads to a command not being found 🙂 I need (a lot) more info to help you. <janneke>obviously this "fork while multiple threads" is worrysome, and a bug that "we" should find and fix some time... <PotentialUser-99>I'm a new guix user, I can't increase the resolution. When I do, it logs me out and doesn't increase the resoluton. <raghavgururajan>nckx: Btw, the older line "(assoc-ref gnu:%standard-phases 'configure))" works. <civodul>nckx, apteryx: actually they consume guix.gnu.org/packages.json, so we can just set cpe-name everywhere there <apteryx>civodul: very good point. Should bring down the issues they flag to a much lower count than 700 something. <nckx>Interesting approach that avoids the discussion and allows us to make future changes. I ilke it. <nckx>raghavgururajan: That diff isn't against current master though, right? I mean, it removes a commented-out ‘gnu-configure’ phase. <efraim>raghavgururajan: I already fixed the librsvg-next configure flags in master. It needed native inputs and inputs, otherwise it tries to run configure with /bin/sh <nckx>raghavgururajan: I don't understand why you remove (native-)inputs. Why don't you think that's the reason for not finding something? <efraim>Native inputs weren't listed in that phase a few days ago <nckx>So what efraim said in the meantime but without less double negatives. <nckx>‘You can see that part of code in the current code base’ I assume that meant master. <raghavgururajan>nckx: I mean the commented part, which I initially shared via paste bin. <nckx>So wip-desktop? I suggest you rebase (or cherry-pick if too expensive) efraim's changes. <efraim>The librsvg-next bump was also a bunch of new crates <efraim>The configure phase thing was bugging me for months <nckx>raghavgururajan: I can't know that if you don't tell me. You tend to drop patches without context in a pastebin, I understand (I have the same problem sometimes) but you need to explain what they mean. <zimoun`>apteryx: yeah pre-push git hook could be a start. But there is an hiden issue: the number of request per hour (-: And it could be possible to ask leveraging this rate limit but only for one specific machine. <raghavgururajan>nckx: I apologize. I was asking in doubt if I did something wrong in that snippet. <mihi>Hello, nice that a Hurd image is now available to download. I managed to import it into VirtualBox, and it booted once, but then I probably made a mistake and tried to grow the partition with gparted on a Linux live system. Now it does not boot any more, it tries to fsck, and then "settrans: /servers/socket/1: Device or resource busy". See https://paste.debian.net/hidden/06173c84/. Any ideas how to fix? <nckx>raghavgururajan: I didn't mean to sound annoyed, I'm not, I'm just busy and want to be efficient. <mihi>(or is the error somewhere else? I only have 25 lines on screen and cannot scroll back) <mihi>running fsck from Linux fixes some things, but does not make it bootable again <nckx>raghavgururajan: So do you still have questions now? Basically, you need to apply efraim's fixes to wip-desktop somehow or you risk duplicating a lot of their work. <nckx>This is the least-fun part of decentralised (git) development, but it's unavoidable, I'm afraid. <nckx>mihi: I don't know the first thing about the Hurd, but I think you got the (or an) interesting bit with ‘Usage: fsck [OPTION...] [ DEVICE|FSYS... ]’, i.e. fsck isn't even called with [the right] argument. *apteryx presumes nckx replied with some fancy happy unicode emoji that I don't have a font for ;-) <mihi>unfortunately I don't know enough about Guix startup (or guile) to find out which arguments it even tries... <mihi>I've been running ArchHurd and Debian Hurd, and I know a bit about Debian so I know how I can drop into an early shell, and I know enough about Hurd that I could verify i the translator inodes are correct or maybe correct them. But with Guix my problem is how to get to a shell (except replace fsck with a shell script that invokes bash...) <nckx>apteryx: That is a safe assumption! <NieDzejkob>mihi: on a Linux kernel you'd add --repl to the commandline <nckx>mihi: There's no bash to invoke. There's Guile, and that's it. <mihi>and also unfortunately mounting the filesystem on Linux messes all the translator inodes. Maybe I should move the disk into my Debian Hurd VM and mount it there...? <nckx>In Guile you can use ‘,bournish’ to get something that… smells kind of like sh, but honestly, I find it useless. <PotentialUser-99>My machine seems to keep going into suspend, even though I've disabled it. I'm using GNOME, could that be the problem. <sneek>raingloom, you have 1 message! <sneek>raingloom, walter[m]1 says: hey I fixed my udisks issue by adding polkit-service and polkit-wheel-service to my system.scm <mihi>ah ok got into repl, but the help message is too long for my scrollback :( <mihi>unknown meta command: bournish <apteryx>at the initrd? I'm not sure the static guile used there supports it. <nckx>civodul: Unknown meta command bournish. <nckx>Or my memories have been replaced by robots while I sleep. <raingloom>it used to drop you into Bournish but when i last had to... resort to using it, i also couldn't get back into it <civodul>nckx: you need to ",use(guix build bournish)" first <nckx>I'm as yet convinced that's a regression. <nckx>raghavgururajan: I'm idle (currently bumping some packages) if you have any more outstanding questions. <mihi>nckx, civodul: no code for module (guix build bournish) <mihi>Also, I don't think that Hurd even supports initrd or initramfs, usually GRUB loads your root filesystem translator as a multiboot module <mihi>I also found that there is (system "ls"), but I have no idea how to show the output :( <nckx>mihi: On Linux it just prints to the console. <mihi>I only see $1 = 1073741832 <mihi>I assumed it would be the pid or some stream file descriptor or something <nckx>But then on Linux ,bournish just works too. <nckx>mihi: "The value returned is CMD’s exit status as returned by ‘waitpid’’ <nckx>Which is ‘the process ID of the child whose state has changed’. <nckx>I have no idea, this all goes in the pile ‘Hurd weirdness’ to me. <nckx>…the VM I started to test ‘--repl’ just freezes… <mihi>ok thanks for the help anyway. From the first look I really liked how Guix Hurd was working (it does not try to look like Linux does, as Debian or Arch Hurd, but show the concepts of Hurd better). But while I am used to Hurd sometimes breaking, I don't like that the tools to diagnose seem to be so brittle you cannot even load some statically linked bourne-like shell... <mihi>and due to the guix store paths, I cannot even guess where one might be lying on the disk. So will have to examine the disk from Debian Hurd later (afk for now) <janneke>mihi: i think that "settrans: /servers/socket/1: Device or resource busy" is mostly harmless, and that the problem a non-checked filesystem is? the hurd image is experimental; we should make sure that --repl or dropping into a bash shell works, but we're not even there yet. thanks for trying and reaching out, i'm sure things will get better soon! <nckx>mihi: The initrd doesn't contain a shell because there's no need for one, not because it's too brittle to load one. Yes, the Guix initrd is brittle and not pleasant to debug, but for *other* reasons 😛 <janneke>you should "always" have things like /run/current-system/profile/bin/bash etc <nckx>Having a bloated ‘debug initrd’ for humans would be a nice option, or ideally a better sh in Scheme. <nckx>GNU gash seems eminently usable. <janneke>yeah, an initrd with gash,gash-utils would be cool (and probably *large*) <nckx>Yeah, I checked but I'm not sure what to think. ‘self’ size for gash+utils is about ~9 MiB. There are bogus(?) things like pkg-config in the output, too, though, and my initrd alrady contains glibc but that might be a me-bug. <nckx>So that gives us solid error bars between 9 and 143 MiB :o) ***bmpvieira_ is now known as bmpvieira
<apteryx>nckx: readline would be a must IMO. But it's technically infeasible so far (static guile has no support to load dynamic modules). <nckx>It's a (potential) mess. <mihi>janneke, how many of those are symlinks. While afk I got thinking what would happen if the /hurd/symlink translator got broken... But will check now :) <mihi>Also, I believe there is a busybox port to Hurd. But I guess I'll try myself if I can link that statically and use from Guix Hurd <mihi>I am able to chroot into the system and run /run/current-system/profile/bin/bash. But showtrans /servers/* shows no translators assigned to the inodes. However I am not sure if there should be some. I will add some and look if it gets better. <janneke>mihi: yes, if /hurd breaks, symlinks don't work <mihi>not sure if that was what fixed it, I added translators to most things in /servers (proc, exec, ...) and now the system boots again. :-) <mihi>so next thing to try if the repl works too <mihi>I still cannot get repl to either ,bournish or (system "/run/current-system/profile/bin/bash") <mihi>but yeah now I will be careful, and I know that I should just mount the system from Debian Hurd and chroot into it. <nckx>mihi: I think that's expected. system invokes the ‘command processor’, i.e. sh, so chicken/egg/all that. Try system* <mihi>By the way, any easier way of setting $PATH when chrooting from non-guix into guix, than doing it manually /run/current-system...? <mihi>system* works in the sense that I now see output, but input gets partially consumed by the repl and by the bash... <mihi>seems to be deterministic though, if I press every letter twice, I get both to run the same command <mihi>but seems i sent Ctrl+D to the wrong one now :( <janneke>mihi: yeah, like i said: great that you try...but we've been creating throw-aways systems/images until now <mihi>I don't expect much. To be honest, the ArchHurd is not better... <janneke>i haven't really addressed second-boot robustness, especially now that we are using --snapshot for the chilhurd service :-) <mihi>(they don't even get their init system to restart the console service if it crashes or somebody hits Ctrl+Alt+Backspace) <janneke>(still, it's awkward/embarrassing that such breaks :-) <mihi>(and the maintainer admitted he only tested it in a chroot from Debian Hurd, so all the translator setup was also never tested...) <janneke>but next step is getting some build nodes up <janneke>then we can have at least some sensible regression testing and native builds <apteryx>interesting. Attempting to build 'ruby-sinatra' seems to hang on gem install, peaking the cpu doing so. <nckx>Matrix does not seem that much more reliable a replacement for IRC. <nckx>Oh, I got trolled by Audacity… <PotentialUser-30>hey, i've tried installing guix 1.1 on my laptop, but failed cause no nvme.. i was adviced to try do a local git, build it and do an iso from that.. that failed in more ways than i can count.. :D anyway i then tried'latest' iso from download.. it has the nvme whatever and this time i got through the graphical install guide <PotentialUser-30>but it then failed during installation with some 'fatal: reference is not a....' <nckx>PotentialUser-30: …‘tree’? Including the full error message would be a start, since this related to a specific git repository. <nckx>It means that whatever Guix is looking for has vanished somehow. <nckx>Any URLs in the message would be very helpful. <PotentialUser-87>tryin latest iso: build of guix-1.1.0-15.03deb1e.drv fail (1 dependancy failed) looking at the log i was pointed to says git-minimal-2.2.7.0/bin/git checkout <somehash> failed with error 128 <nckx>PotentialUser-87: Anything would help. Even a photo of your screen, or an uploaded log file. Sanity check: in the installation environment, did you connect to a network & can you talk to the Internet? less $(guix download https://gnu.org) should return <title>The GNU Operating System and the Free Software Movement</title>, for lack of a better idea (I don't know if wget/curl/links is available). Is there anything (at all) ‘special’ about your network? <nckx>Are you behind a proxy, firewall, …? <nckx>It would be great to get as much of the log output as possible. <nckx>Especially since you seem to have to reboot every time. <nckx>The hell. I can reproduce it with the time machine. ‘fatal: reference is not a tree: 03deb1e891b8a8b21888e5e047017fd6a3ea7a5f’ <lfam>Is that a commit from our repo? <nckx>lfam: It is if you add a d to the front! <lfam>If you add another letter then it's 41 characters <lfam>Sorry if I am missing something here <lfam>I just don't understand where this commit ID came from <nckx>lfam: No, I thought you meant my time machine commit, which also starts with 3de… <lfam>I'm looking at PotentialUser's failed command, and the version string, and from what I can see, that commit doesn't exist, so it's expected that checking it out would fial <nckx>Well, without the—ANYWAY. d3eee3c0643a20ba06941ba45d9d27146a8b634d is the commit that updates Guix to 03deb1e891b8a8b21888e5e047017fd6a3ea7a5f, the bogus/failing commit. <nckx>lfam: It's certainly ‘our fault’, not theirs. <walter[m]1>Hi guix. My system locale is set to en_US.utf8. In tty login shells, `locale` shows the correct locales. However, from rxvt-unicode inside i3wm (with ssdm), `locale` shows an empty LANG and every LC_* set to POSIX. <walter[m]1>and I believe this is causing unicode chars to display incorrectly inside urxvt <lfam>walter[m]1: My guess is that the your system locales are at a different version than your user's locales <lfam>The locales are incompatible between versions *nckx had to restart cuirass-web again. <lfam>walter[m]1: The first step is to see if this is the issue <lfam>What does `guix gc --references /run/current-system/locale` say? <walter[m]1>lfam: /gnu/store/l6afn2v9hkgms9basdf941k63dm1d5hr-locale-2.29 <walter[m]1>/gnu/store/zxb6xrby0n56nc44s04z8zrixid66rkl-locale-2.31 <lfam>Now do `guix package -I` as the user who is having trouble <lfam>Pick a package from the list and pass it to `guix gc --references ...` <lfam>The version of glibc in the reference list must match one the two that you saw in the list of system locales <lfam>Must match one of the two <lfam>(the locales come from glibc, if you were confused about why I'm comparing locales and glibc versions) <lfam>Then my hypothesis was wrong <lfam>In rxvt, I would double-check by starting a new login shell with `bash --login` or equivalent for whatever shell you use <walter[m]1>same output from `locale` (empty LANG, POSIX locales) <lfam>The system is using both 2.29 and 2.31 <lfam>That's good. It helps with transitions <lfam>Hm, I'm stumped. I don't use desktop Guix, however, so I'm not the expert on this area <lfam>I would try using GDM because that's what we support, primarily <walter[m]1>well I appreciate the help, I did not know about the --references switch <lfam>I assume something is messed up with our SDDM support <lfam>Yes, the three Rs of Guix references. --references, --referrers, and --requisites <lfam>Super handy for debugging <lfam>I recommend checking out mailing list archives for talk about SDDM. Maybe it's already been discussed <nckx>Poor PotentialUser, heroically gathering data we no longer need… ***ChanServ sets mode: +o nckx[m]
<nckx>sneek: later tell PotentialUser: I was able to reproduce your failure with an older Guix. Not sure what exactly went wrong yet, but not a problem on your end. I've built an installer that's even newer than ‘latest’ & shouldn't suffer from this bug: <https://www.tobias.gr/guixworkaround>. Made from 100% unmodified upstream Guix, just fresher. Sorry for your trouble and your time! <nckx>That probably won't work but I need to go AFK. <lfam>joshuaBPMan: Usually there is a list of package names in those comments. If there is not, you might need to refer to upstream installation instructions. But if you haven't noticed anything missing, it's probably okay ***cjpb0 is now known as cjpbirkbeck
<lfam>In a lot of cases those TODO comments are obsolete and should just be removed <lfam>Many of them date to the early days of Guix <PotentialUser-66>back again :) tryin to install latest iso i got the message: build of guix-1.1.0-15.03deb1e.drv failed <sneek>PotentialUser-66, you have 1 message! <sneek>PotentialUser-66, nckx says: I was able to reproduce your failure with an older Guix. Not sure what exactly went wrong yet, but not a problem on your end. I've built an installer that's even newer than ‘latest’ & shouldn't suffer from this bug: <https://www.tobias.gr/guixworkaround>. Made from 100% unmodified upstream Guix, just fresher. Sorry for your trouble and your time! ***cjpb0 is now known as cjpbirkbeck
***cjpb0 is now known as cjpbirkbeck
***cjpb0 is now known as cjpbirkbeck
<joshuaBPMan>hmmm, my emacs doesn't seem to be able to move gif images. <alextee[m]>nckx (@nckx:matrix.org) changed the room name from #guix to GNU Guix & Guix System (#guix). <joesmack>back again again :) @sneek - i tried the new fresher image of upstream. and although i really appreciate the effort to help out, i still ended on exactly the same error with a pointer to this log: https://paste.debian.net/1155843/ <joesmack>anyway, i fight on tomorrow, just wanted to give an update, thanks for the help so far <lfam>It's something we are going to have to fix upstream <civodul>we'd "just" need to download the CPE database in (guix cve) <apteryx>from their point of view, not specifying cpe-name methodically for each package is unwieldy. <apteryx>I still don't really get it, I need more time to think about it. <raingloom>anyone working on GCC 10 patches for cross compilation? it's not entirely clear to me how the previous patches were built. i have guesses, but i'm not so foolish as to underestimate GCC's complexity. <civodul>apteryx: i hadn't seen it, thanks for the link! <civodul>the tool is interesting, but i must say i very much dislike the "I can query potential problems for you" approach <civodul>IMO we should just add the missing bits to our tools <nckx>apteryx: I quite like civodul's suggestion of feeding Repology the complete list that it demands through packages.json (using our rules), without having to add IMO redundant cruft to the actual package definitions. <raghavgururajan>The tests fail with error "D-Bus library appears to be incorrectly set up; failed to read machine uuid: UUID file '/var/lib/dbus/machine-id'", despite (setenv "DBUS_FATAL_WARNINGS" "0") in 'pre-check.