<dftxbs3e>Trusting trust is a good academical problem but in practice it's not the threat most of the time. <vagrantc>OriansJ: i bet it's three times that in actuality! <vagrantc>dftxbs3e: and yet it is actually used to attack things <pkill9>when has it been used to attack things? <vagrantc>all of the times except when it matters? :) <OriansJ>pkill9: you go after firmware and hardware designs with that class of attack. <OriansJ>vagrantc: stop posting snapshots of my life <vagrantc>there are notably two characters in that scene... <OriansJ>also last count #bootstrappable had only 1 security person (me), a handful of Lisp programmers/students and 1 paid LLVM developer <OriansJ>terpri: only the single stick is at the absolute bottom of the graph <nckx>Hm. Since my recent hiatus I can no longer copy text (both primary selection and C-c) from Hexchat on Wayland. Anyone else encounter that? <noproto>almost certainly a wayland bug. hexchat on xorg here, it works. <nckx>...*of course* it's non-deterministic... <terpri>OriansJ, with a wafer of silicon below :) <terpri>nckx, no problems with hexchat-on-xorg here either <OriansJ>terpri: that is the project *AFTER* we finish the whole hex0 to EVERYTHING <OriansJ>we bootstrapped a minimal haskell from hex0 and Gnu Guix; give us some time it has only been 4years of active work <terpri>i'm really impressed by bootstrappable's rapid progress. how do you boil the ocean? one drop at a time <nckx>Thanks terpri. It decided to ‘fix’ itself here, which is ‘great’ and not ‘frustrating’ at all. 👍 <OriansJ>terpri: I wouldn't consider 4years rapid progress, as without the help of Guix keeping up with the bootstrap paths from GCC 4.7.4 for us, we would never catch up. <nckx>Except they've managed to create life in it, too. <OriansJ>who knew the easiest way to bootstrap a C compiler is to just write one in Assembly. <OriansJ>So easy we did it multiple times (even multiple cross-platform C compilers too) <noproto>guix was such a cool distro to try. thanks to all of the developers here for helping create it. <noproto>i hope icecat eventually can do most web browser things like display numbers on a webpage. <noproto>maybe its just a font issue, not sure. <terpri>k&r's original compiler must've been in pdp-11 asm. it was of course a much simpler language then <OriansJ>The world's First C compiler written in Assembly was BDS-C (doesn't support structs or array[][]) <nckx>noproto: It is. Install any font (e.g., font-gnu-freefont) into the same profile and it should resolve itself. <OriansJ>The second was cc_x86 (which supports structs) <vagrantc>noproto: yeah, i had some surprising font issues using icecat <noproto>nckx, yep, that fixed it! for anyone who reads the channel logs in the future, run in your terminal: `guix install font-gnu-freefont` <terpri>font-google-noto is useful as well (notably it covers CJK characters which freefont, according to its faq, doesn't currently) <dissoc>is there an easy way to install guix system from a preconfigured disk-image .iso? <dissoc>i see you can do the guix system disk-image -t iso9660 install.scm but I'm looking to just do a silent install with a pre made config file <nckx>terpri: True, my suggestion was needlessly Eurocentric. <nckx>OTOH Noto is 1.5 GiB or so? <vagrantc>font selection is a really annoying thing. i feel like "back in the old days" i never had to worry about fonts. nowadays it tends to make various things unusable on major system upgrades (not guix specifically) <terpri>yeah, noto is 1.5gb installed, vs 18mb for unifont <terpri>noto might have better emoji support too (just guessing because it's from google; i think android uses noto these days?) <nckx>terpri: It has all the mojo yes. <nckx>It's why I have it installed (swaybar mainly). <nckx>Full-colour monstrosities. I keep an older copy of Noto around with better ones. <marusich>Does debbugs-gnu-search work for anyone? It sends me in an infinte loop, asking me to supply attributes etc. <terpri>dissoc, isn't that what "guix system image -t iso9660 $foo.scm" does? produce a preconfigured image? (i've only used vm-image, never tried it for normal installation) <marusich>It asks, "Enter search phrase", I hit enter because I don't want to specify one, it asks "Enter attribute," I enter package, it asks "Enter packages:", I enter "guix", it asks "Enter attribute:", I hit enter because I'm done, it asks "Enter severities:", I hit enter to accept the defaults, it asks "Enter attribute:", I hit enter because I'm done, it asks, "Enter severities:", and from here we loop. <nckx>I think they want an image that will itself install that system, unattended, which I don't think exists. Although it sounds like the kind of thing someone might've written for their own use and not advertise. <terpri>symbola has decent b&w emoji support, iirc, but doesn't seem have a guix package <nckx>The old Noto is colour too, but better-looking if you disregard humans (which are yellow blobs). <nckx>I'll have to try Symbola, white icons would probably look spiffo. <dissoc>yeah i wanted an unattended install. i think i can write some guile to do it. i browsed through the files and I dont think it would be that hard <mroh>marusich: debbugs is often somewhat weird if used interactive. What works well is calling it via elisp like `(debbugs-gnu '("serious" "important" "normal") "guix" nil t "")` <fnstudio>hi i'm experimenting with `guix deploy FILE` (using the manual examples as a starting point); i get this error: "extraneous field initializers (system)" <fnstudio>does it indicate any obvious error that i might be making? <dissoc>are you able to post the config somewhere? i can take a look <fnstudio>(i'm running guix on a foreign distro, in case that might make any difference) <dissoc>i dont think you use system anylonger for machine <dissoc>i think you are to use operating-system instead of machine <fnstudio>ok, dissoc, thanks! let me try that way... <dissoc>you can always look at record type when in doubt <fnstudio>dissoc: true... i could have looked at it in the code... <fnstudio>dissoc: debugging another error now, but at least i'm progressing, thanks again <dissoc>i think i ran into the same problem when i played around with deploying to digital ocean. did you follow a tutorial? <fnstudio>dissoc: although i'm a bit confused since i also saw recent blog posts recommending the use of images - as in you create it locally and then upload it to digital ocean or something like that <dissoc>that might be the case. i dont really use DO for much these days. i just deployed and then deleted the droplet to try it out <fnstudio>dissoc: do you use (or can recommend) any other guix-friendly VPS provider, if i may ask? <dissoc>with custom-images i think DO would be fine. there's always linode and vultr too. i would be interested in using custom-image on DO myself. i could probably try it really quick. assuming it goes smoothly <fnstudio>dissoc: keep me posted if you end up trying, if you want, i'll do the same if i get anywhere with my tests :) <dftxbs3e>marusich, running builds now with 64 cores <dftxbs3e>marusich, was already running some but since you changed something that would cause a rebuild, I just canceled <dftxbs3e>marusich, could you push the three patches I sent you? <dftxbs3e>so I can modify guix package to reference wip-ppc64le branch and build from there <marusich>You authored the last two, right? I don't see commits in the git repo with similar changes <marusich>Just checking so I can fill in the metadata correctly <dissoc>fnstudio: sounds good. i am building image right now to try. then i have to upload but i am currently on slow connection. maybe in a few hours to test <fnstudio>dissoc: yes, i fixed another couple of simple mistakes in my test script, but now i'm stuck with a "HTTP post failed: 422 ("Unprocessable Entity")" reply <dissoc>fnstudio: i think you might have to add a tag <fnstudio>dissoc: i think i'll work on it tomorrow <fnstudio>dissoc: hm... no, it doesn't seem to be that <dissoc>look at the DO api and see what is required. if i recall correctly i got that message as well. im pretty sure a tag was required and that fixed mine. but maybe you are missing something in addition to that. ssh-key maybe? <fnstudio>dissoc: yeah, good point, i'm cross-checking my script, the DO API, and what's in gnu/machine/digital-ocean.scm <terpri>ah right, i'd forgotten about guix deploy, and didn't realize dissoc was talking about VPSes (still mentally stuck in the pre-cloud era ;)) <terpri>i should try it with linode sometime <dissoc>fnstudio: well i got the custom image uploaded to DO and droplet created. it booted and i can see the console but i dont have time to do much else right now <dissoc>fnstudio: so i did 'guix system disk-image -t qcow2 config.scm' . then uploaded to custom image in DO interface. make sure to upload image to the region you wish to deploy to. and make sure you select one that's actually available to deploy droplet <dissoc>but word of caution: i have no clue what im doing so dont do anything i say <dissoc>terpri: i was initially wanting to create a iso with unattended install, or minimal, maybe just hostname input for installing on physical machines <apteryx>I wonder what's that caused by: unexpected build daemon error: stoi <apteryx>probably from this in local-store.cc: return stoi(str); ***apteryx_ is now known as apteryx
<timmydo>i'm trying to write a service for guix... is there a way to get more logging out of shepherd? it's failing to start my service <timmydo>ah looks like #:log-file might be enough <dissoc>timmydo: yeah. check the output of the file you configure there first <timmydo>i had a paren in the wrong place earlier and i think #:log-file was probably going to the command line of the app so the file wasn't appearing <dissoc>i struggled quite a lot for the first service i wrote. if you need any help i'll be around for a few hours <dissoc>i would recommend avoiding doing any kind of crazy configurations and just start with static values. get it to work that way first <timmydo>yeah, it's been an experience. i'm picking up scheme at the same time. i'm not sure if i have fully gotten the feel of what the development cycle (where to store my source, how i should edit the guile load path, etc.). <dissoc>if you're creating services and packages probably best to just have them in a git repo and add it as a channel <timmydo>looks like the service started correctly. but i'm running it as a user instead of root so i'm listening on a nonstandard port. once i figure out how to get nft to redirect the port maybe i'll write it up <timmydo>i had a little trouble getting the auth to work on the git repo but it's working now. but my set up isn't ideal since i have another computer that i'm testing on so i don't want to make a commit every time i fix a typo <timmydo>having the file local and using --load-path was probably easiest for me until i got that working <timmydo>do you happen to know the guix way to do something like this? sudo sysctl net.ipv4.ip_forward=1 <timmydo>oh thanks. should've searched for sysctl not ip_forward... <timmydo>er it's there also.. hm wonder how i missed that <fnstudio>thanks dissoc, i took note of the command to generate an image, i'll try and play with the digital ocean env type some more and then i'm definitely going to try the image method as well <fnstudio>hi, is it completely outlandish if i wanted to launch a guix deploy script as a standalone script? <fnstudio>that's meant to be run as `guix deploy script.scm` <fnstudio>however, in order to debug it, i was wondering if it might make sense for me to modify the script so as to launch it as `guile script.scm` <fnstudio>(if that makes any difference, maybe not?) <fnstudio>i'd like to be able to debug the connection to a remote API (digitalocean) <fnstudio>and i was thinking of inheriting from the digital ocean env type but injecting a print or debug statement of some kind, if this is how these things are debugged <db48x>fnstudio: check the source of guix deploy and see what it does <daphnis>seems that i don't get a grub menu when i use an lvm-on-luks boot partition <hapster>hello everyone. I am trying to prepare for a fosdem talk but have a problem with icecat <hapster>when I watch a video, the sound is pitched down by like an octave which makes viewing videos a pain <hapster>however, this is the case for only some scenarios: on youtube, I dont have that kind of problem <hapster>but it is, on guix system, a problem with the fosdem stream <hapster>does anyone know which package I would need to install / which setting to make to fix this? <pinoaffe>hapster: I have this same issue on some streaming sites, playing the stream directly with mpv (and youtube-dl if necessary) usually works <hapster>pinoaffe: have you already filed a bug report? <pinoaffe>hapster: no, i've talked about this with people in this chat before <nckx>hapster, pinoaffe: This is a ‘well-known bug’. Nobody's managed to fix it yet. <nckx>Like pinoaffe I use mpv (which calls ytdl behind the scenes) to watch such vidz. <hapster>nckx: pinoaffe thanks for the pointers :) <nckx>As a committed IceCat user it bugs the hell out of me, but debugging multimedia isn't my jam. May you have more luck! <hapster>nckx: well dont put your hopes on my abilities in that matter :D <civodul>hey ho! just had an inspiring talk about Lisp as a shell <civodul>and now janneke will start talking about bootstrapping! <hapster>civodul: has the talk already started? <hapster>I am streaming it on mpv and there is no video signal <ioa>something seems to be wrong with the stream <hapster>ioa: so you also cannot see anything? <ioa>also in the browser version <ioa>hapster no, as others in that room <civodul>can't see anything yet, dunno what's up <hapster>alright, so a bit of waiting will be required :D <ioa>I hope the hard cut setup won't interfere with the talk when the stream does start again :( <civodul>great talk, great analysis of the choices to be made and what it implies <NieDzejkob>civodul: would you happen to have a link to the video of the Lisp REPL talk? <civodul>NieDzejkob: nope, it should show up soon i guess? *civodul rushes to grab a bite, like a normal FOSDEM :-) <jlicht>rekado_: congrats on the gwl release, and the talk! I got one coworker to see the light yesterday :-) <hapster>why does the shell see "GUIX_PROFILE", but emacs command (getenv ...) doesnt? <nckx>hapster: Did you export it? <apteryx>I'm watching the video in Icecat now; I don't seem to have the sound glitch. <apteryx>wingo: thoroughy enjoyed your talk, thank you! <spk121>I'm sad that I'm not jetlagged and freezing my butt off in Belgium, right now. *nckx doin' that for you (it's snowing here!) <bqv>Is the build offloading feature well-used? <bqv>I.e is it stable in most circumstances? <bqv>Ok that explains this <nckx>Hypocritical of me to say, but please report a bug if you have the time. <bqv>I'll attemt to fix it first <bqv>apteryx: where are said videos? <hapster>nckx: so you mean that even if something is visible to the shell I need to export it (probably via (setenv), right?) in order for it to be visible to emacs? <nckx>In order for it to be visible to any child process. Unexported variables ($ i=foo) are just local. <nckx>Guix doesn't export GUIX_PROFILE because AFAIK it's an implementation detail, and the notion of ‘the current profile’ is flawed (they should compose & layer, e.g. system -> user -> guix environment -> ... on a Guix System). <nckx>GUIX_PROFILE makes sense while setting up the profile, not once in it. <hapster>but in my init.el I want to point to the sbcl binary (setting up sly). Wouldn't I need GUIX_PROFILE for that (or specifying the path manually)? <hapster>so then I would use PATH and take the list element that I need, right? <hapster>nvm, I guess I will find that on my own in the elisp manual. thanks :) <nckx>I'm not much of an emacs guru. Is there no ‘which’ equivalent? <nckx>Otherwise, yep, implement one yourself ☺ <nckx>executable-find looks like it. <hapster>when I want to install an earlier version of a package, the correct command is "guix package -i PACKAGE@VERSIONNUMBER", right? <hapster>does that mean that it is necessary to keep around the definition of the older package? <hapster>I am saying that because I recently updated a package (pioneer) which built fine but which errors out on execution. Thus, I wanted to see if I could install an earlier version of but couldnt <nckx>hapster: Yes, Guix can only build/install the exact package versions/variants that come with that Guix version. We don't keep older packages around unless there's a good reason to. But! guix time-machine should do what you want. Read up on it, try it, & ask any questions you might have. <nckx>You will need to look at the git repo to know the commit that updated Pioneer, there's no way to automatically query that (yet). ***p is now known as Guest57293
<Guest57293>guix install: error: build of `/gnu/store/pb6m90pjqzwcqcnkrwk574sxi11h63pz-libjpeg-turbo-2.0.5.drv' failed <apteryx>civodul: that system explorer thing is so cool! Thanks for making/presenting it :-) <nckx>Guest57293: There should be a lot of context, and an en error log file name printed along with that message. Paste both to paste.debian.net. If the log file is .bz2, use bzcat to view it. <nckx>Guest57293: That exact derivation builds fine here, so it's somehow related to your machine. A substitute (pre-built binary) is also available from ci.guix.gnu.org, the default substitute server. Did you disable it on purpose? *nckx AFK for some minutes. <rekado_>Guest57293: I suppose this is output from the test suite of that program? <hapster>apteryx: truuuue, guix explore rules <rekado_>Guest57293: as nckx wrote you should be able to get a binary from ci.guix.gnu.org <nckx>Guest57293: Please provide the information I asked for, not a single useless line. That FAIL is obviously not from libjpeg-turbo itself. <nckx>Probably some crypto library with a time-bomb in the test suite set to fail after a certain date :-/ <nckx>See point 7 in the ‘(guix)Binary Installation’ section of the manual. <hapster>I'm literally blown away by the possibilities offered by guix explore. I hope something similar is going to exist for guix package at some point <hapster>meaning that I get to see more in-depth information about what is going on within a package and in its specific elements <nckx>I'm obviously missing a cool. <nckx>Oh well, something to look forward to. <hapster>whaaaat, sorry to hear that, its quite nice (as always when he gives a presentation :D) <Guest57293>ncks: thanks finally it seems to continue the work after make pull and add ci.guix.gnu.org repositories <civodul>mothacehe, cbaines, janneke, roptat, zimoun, and whoever is interested in hosting a session at the Guix Day tomorrow: let's have a chat and coordinate on ##guix-fosdem! *civodul listens to Will Byrd in the meantime <cbaines>Is there any reason for ##guix-fosdem vs #guix-fosdem ? <zimoun>cbaines: ## are for temporary by convention if I remember correctly <hapster>can anyone tell me what is needed for 'guix import nix' to be successful? <hapster>do I need to fetch nixpkgs manually or is there something else that I need to do in preparation? <hapster>because the videos on the guix hp use 'guix import cran' in a straightforward manner, and it is now not the first time that I try to search for a nix package definition of a package I suspect to be packaged - and running into errors while doing so <zimoun>g_bor[m]: hey! Do you plan to be there tomorrow? <fnstudio>cbaines: great talk, thanks (any chance the slides are or will be published online?) <civodul>apteryx, mbakke, nckx: hey! stop by ##guix-fosdem if you'd like to discuss tomorrow's sesions <fnstudio>cbaines: oh excellent, very kind, thanks v much <OriansJ>cbaines: isn't the polite thing to do is have javascript to do the hiding before doing the partial reveals so that people who do not enable JavaScript can still see the contents (all at once but eh) without having to do inspect element and deleting the class? <cbaines>OriansJ, I have no idea, I'm assuming the presentation won't work without JavaScript support <OriansJ>cbaines: without javascript and just deleting the class from the top div it just becomes just paragraphs of text without formating <nckx>hapster: I'm afraid the Nix importer is prone to bitrot, and might require a running & configured nix-service-type to even work. <nckx>In short it's probably the most temperamental of the mainline importers. <efraim>is it worth fixing or should we just take it out? I feel like we've had this discussion about it for years <zimoun>even “guix import nix hello hello” fails with an ugly BackTrace. <nckx>I've never even tried it. Nix packages are so trivial to port, and the importer can't do any of the non-trivial stuff anyway. <nckx>amiloradovsky: You there? <nckx>You're bouncer or client is spamming the channel with joins & parts. <zimoun>nckx, I agree with efraim. I am not convinced it is worth fixing so let just take it out. <nckx>zimoun: I agree with efraim & myself too, so that makes four of us. Fine by me! <nckx>Will you do the honours? <zimoun>raw remove or with a message; “guix import nix foo” saying «this importer is removed blablabla»? <nckx>I don't think that's needed. Maybe a news item. <apteryx>civodul: sorry, my son took me for a walk ;-) <bqv>apteryx: oh no I wanted to listen back to the earlier talk, not current ones <zimoun>nckx: fine. Well, I am doing some stuff about the recursive importers bug#45984, so the remove can part of it. :-) ***ChanServ sets mode: +b *!*@2001:4b98:dc2:43:216:3eff:fea7:8a37
***amiloradovsky was kicked by ChanServ (Banned: Please fix your client or bouncer and let us know.)
<nckx>Does anyone know who that was? <bqv>Guys... `guix archive --import` has been running for over an hour <bqv>I feel like its building somethin@ <bqv>But nothings on htop <bqv>What the heck is it doing <bqv>With all that memory and so much cpu <nckx>bqv: What did you pass as input? <bqv>archive --export /gnu/store/...-linux-5.10.12 <bqv>Not recursive, but all deps should be present <nckx>That's happened to me before, passing a large but not ridiculous (several GiB?) archive on stdin, see memory usage balloon to a few GiB. But it did finish. <nckx>Does stracing it reveal any movement? <bqv>nckx: so strace attaches but outputs nothing?! <efraim>findutils-boot0 fails on aarch64 on core-updates <bqv>Ok I think I'm just gonna kill it <lfam>bqv: As always, please share the exact command you're having trouble with <lfam>I wonder, are you passing the data on standard input? <bqv>lfam: yes, I passed the nar via stdin <bqv>I didn't realise there was an alternative <lfam>Okay... it sounds like the command is waiting for input <lfam>Sometimes people pass the nar as an argument <bqv>Should I pass it as argument then? <lfam>You example, "archive --export /gnu/store/...-linux-5.10.12", is confusing <lfam>Not sure if you are trying to import or export <bqv><bqv> Guys... `guix archive --import` has been running for over an hour <lfam>Yes, but you didn't show what you actually tried <bqv>the export was from a different machine. I copied over the nar, and tried the import <bqv>guix archive --import --authorize < %nar% <lfam>That's for authorizing a substitute signing key <bqv>But, it's not authorized <bqv>It complains about key <lfam>Then, do `guix archive --authorize < key` <bqv>Where do I find the key <lfam>It was likely waiting for that <lfam>Check in the manual section "Invoking guix archive" <lfam>You'll have to create the key <bqv>Well, gotta wait for my machine to unfreeze now <civodul>bqv: keep in mind that 'guix archive' is low-level, it's something one rarely has to use (if ever) <bqv>I know, but neither guix copy and offloading were working for me, whereas archive worked well enough to get me a bootable system <bqv>It still boots, thats good <bqv>lfam: you're my saviour <lfam>You're welcome! Please remember next time to share the exact command right off the bat <lfam>It will save you time :) <fnstudio>hi :) anyone knows if there's an equivalent to debian's `dpkg --listfiles <package-name>` (not even sure the question makes complete sense in the guix world) <fnstudio>roptat: cool, thanks - so this means that everything pertaining to a package is self-contained in a single folder (or at least the bulk of it, eg other than user level configuration) <fnstudio>(i feel i'm still asking the most basic questions) <lfam>There are packages with multiple "outputs". That is, they create more than one directory in /gnu/store <fnstudio>lfam: oh yes, sure, that's my fault - i misphrased it <lfam>roptat's example will still work, though <fnstudio>lfam: following roptat's advice, i do see my particular package to generate two /gnu/store folders for instance <fnstudio>what i wanted to say is that (more or less) everything is cointained in a number of package-specific folders under /gnu/store ? <lfam>When Guix builds a package, the results of the build are put into /gnu/store <lfam>There are observable effects outside of that, however. The database in /var/guix/db will be updated, and there will be some other changes in /var/guix <lfam>But, that stuff is not considered to be from the package <pineapples>Which am I supposed to use: (spice-vdagent-service) or (service spice-vdagent-service-type)? <dissoc>spice-vdagent-service just calls (service spice-vdagent-service-type config) <PotentialUser-60>Finaly I can run: guix package --export-manifest > /tmp/boom && guix weather --display-missing -m /tmp/boom <dissoc>fnstudio: i got a reasonable digitalocean guix custom image going now. if you try it dont forget to also add --image-size <dftxbs3e>hello, does "$ guix build --check lz4" work for anyone? I'm getting failures for lz4@1.9.3 but a substitute is available so I very much wonder how that's possible, it's due to failing tests and the failures look very deterministic. <lfam>Well, if you are getting a substitute, then it did build at some point <lfam>In my experience, the lz4 test suite is flaky <lfam>It probably depends on some details of the hardware being used <lfam>It likely expects to be run on something quite powerful <lfam>Did you search for your error message? <dftxbs3e>lfam, yep nothing in the bug trackers of lz4.. I built on both powerful and not powerful machines <bluekeys>Hi guix. I'm taking a look at an app called miraclecast. It says it requires systemd. Is that going to be a big problem? <lfam>I don't know what you mean dftxbs3e <dftxbs3e>bluekeys, check out other GNU/Linux distribution without systemd check if they successfully packaged it, from the description it looks like it may be a big problem but also looks like it could be patched out easily. <lfam>I wouldn't worry about it too much. Like I said, the tests are flaky <dftxbs3e>lfam, can we disable the tests on master then? <lfam>No, it's better to run them <dftxbs3e>but it makes my builds fail, so what do we do? <lfam>You can use the --without-tests package transformation option if you need to avoid them <lfam>Or, report the bug upstream so they can fix their test suite <lfam>I think of lz4 as one of those packages that can only reasonably be built on certain computers, like chromium and icecat <dftxbs3e>lfam, I'll send a patch to GNU Guix that disables the specific tests that fail for me, because lz4 is a dependency to many things it's not OK to leave it like that IMO <lfam>Okay, but things are working fine for Guix users <lfam>It's kind of a self-inflicted problem in your case <dftxbs3e>lfam, it fails on 3 machines of mine :-/ <lfam>What kind of computers are they? <lfam>And, can you use substitutes? <dftxbs3e>AMD Epyc 7nm one, Dell XPS 9300 2020 and Talos II <lfam>Interesting, it's working for me on AMD EPYC 7451 <lfam>I recommend reporting this to lz4. They have a responsive bug tracker <lfam>Yes, /gnu/store/p70n3mihgjq5wvvx93lj7dwbfrrzff1m-lz4-1.9.3.drv <dftxbs3e>lfam, this is the CPU: AMD EPYC 7402P 24-Core Processor <lfam>I'm sorry it's failing for you but it's not clear that disabling the tests is the right thing to do. Presumably, that could protect you from some problem in the software, right? <lfam>Or, they are flaky but work on the build farm <dftxbs3e>I think in the interim we should disable these specific tests until upstream makes them not flaky. <lfam>I disagree. We should at least report it upstream and wait for their advice <dftxbs3e>:-( - and --without-tests=lz4 doesnt work somehow <dftxbs3e>I don't know, it still runs tests. ./pre-inst-env guix build --without-tests=lz4 guix <lfam>I don't that guix depends on lz4 <lfam>I'm not sure what's going on <lfam>In general, if someone is having a problem with some package that can't be reproduced, we shouldn't rush to work around that by deploying a change for all Guix users <dftxbs3e>lfam, it does not directly but it does directly, can't --without-tests modify packages recursively? <lfam>"guix graph: error: no path from 'lz4@1.9.3' to 'guix@1.2.0-12.dffc918'" <lfam>I was also able to rebuild that lz4 derivation on Intel i5-6300U <dftxbs3e>It really fails on 3 machines of mine with 3 different configurations and all <dftxbs3e>One machine runs GNU Guix over Debian Buster, the other Fedora 33 ppc64le with GNU Guix on top and my laptop runs GNU Guix System <lfam>So, what I would do is 1) report the problem upstream and see what they think 2) report it to guix and see if anyone can reproduce it and 3) in the meantime use substitutes <dftxbs3e>(I can't use substitutes, porting to powerpc64le-linux) <lfam>lz4 has *just* too many dependents (309) to change on the master branch <lfam>We could bend the rules if we needed to, since 309 is not really many more than 300, but I'm not convinced it's appropriate at this time <lfam>And like I said, the lz4 upstream is very responsive to reports like this. It would not be a waste of time to report <jonsger>lz4 fails with `--cores=12` for me but succeeds with `--cores=6` <lfam>Interesting. I'll re-run it on that EPYC machine, which has a lot of cores <lfam>I mean, I'll specifically choose a high value for --cores= <lfam>Something that is mentioned upstream (did anyone else go there yet?) is that they don't expect the tests to be run in parallel <lfam>Or, they aren't really sure <dftxbs3e>I saw that, but does it run them in parallel in GNU Guix? <lfam>I'm not sure if the tests are being run in parallel or not <dftxbs3e>Parallel testing isnt disabled so it may be running them in parallel <lfam>Another useful piece of information for a bug report <bqv>Folks, where do I get an /etc/ssl from? Mine's missing <bqv>Or, it's a dead link <lfam>It depends on how they run the tests. They seem a bit weird since they are written in python and use valgrind <lfam>bqv: Did you look it up in the manual? <bqv>I'm ..not sure how to <bqv>I don't know what package/service <lfam>You could search for '/etc/ssl' <lfam>It's there, but anyways, add nss-certs to your system packages <bqv>Is there a better way to search the manual, then? <lfam>Please, tell us what you tried <bqv>I'm using `info guix`'s index search <lfam>Otherwise you risk burning us out <bqv>I was getting there! Its hard to type fast on a phone, gost <lfam>The all-in-one web page is my go-to for searching <bqv>Damn. I avoid browsers when possible <bqv>That's why I liked info guix <dftxbs3e>CTRL-S then type: /etc/ssl - then press CTRL-S to iterate on results <lfam>I like the browser because it offers the most ergonomic experience for someone who grew up using "normal" computers <bqv>I thought that only searched current page for some reason <dftxbs3e>bqv, it searches the current "file" I think, and since GNU Guix manual is all in one file AFAICT <dftxbs3e>lfam, could build derivation on my laptop using --cores=1 <dftxbs3e>lfam, since that's already indicated in their issues, I'll submit a patch to disable parallel tests in GNU Guix <lfam>Okay, can you also report it upstream? <dftxbs3e>lfam, there's already an issue for parallel tests failing so.. I'll add a comment there saying it also happened to fail for me. <lfam>Thanks, you should include your error messages, since that report shows different failures <efraim>I went to bump xorriso and I downloaded substitutes from berlin <Sharlatan>how to fix build issue with Cthon *.c file not found? <leoprikler>Uhm, does cython actually produce it at any point before that? <Sharlatan>I try to generate them manually in before bulid phase <leoprikler>perhaps you fudged the paths? Or perhaps they did? Try `guix build -K`? <leoprikler>As far as I know from packaging renpy, cython calls should be managed by the build system, i.e. probably setup.py <leoprikler>That's why I tell you to run `guix build -K` -- then you can do ls and stuff in /tmp/guix-build-astropy-... <nckx>bqv: Glad it worked out in the end. You might be interested in ‘guix copy’ depending on your set-up. <bqv>nckx: i did try that first, it seems to have issues with the machine i was attempting to copy from, as did machines.scm <bqv>so rather than fiddle for too long, i wanted to get things at least functional and worry about fixing that later <Sharlatan>leoprikler: nope *.c file is missing after buld <bqv>i'm typing to you now from guix, technically :) <bqv>(emacsclient over ssh from guix) <leoprikler>In that case it seems it wasn't generated. Do you find it elsewhere perhaps? <nckx>bqv: What did ‘guix offload test’ do (if anything)? <bqv>a basic question, if i want to run the command 'echo 100 > /sys/class/...' on startup, i'd need to create a service, right? <nckx>You might need to ‘sudo -i ssh <offload user>@<host>’ to prime .authorized-keys. <bqv>nckx: offload status returned my other machine correctly, offload status always had a lisp error, usually with struct_vtable iirc <bqv>sorry, second status -> test <raghavgururajan>So I created a new user "test" in my config.scm and reconfigured the system. But when I login as test and do guix pull, I get "guix pull: error: while creating symlink '/home/test/.config/guix/current': No such file or directory" <Sharlatan>I see _np_utils.pyx which is had to be converted to *.c file but something went wrong. <Sharlatan>leoprikler: great it's passed now, but question why it's not handled by build-system or setup.py? <leoprikler>It is handled by setup.py, the warning for missing cython is just cryptic. <raghavgururajan>I manually created ~/.config/guix dir and re-tried guix pull. Now I get "guix pull: error: while creating symlink '/home/test/.config/guix/current': Permission denied". <raghavgururajan>Okay, I did `sudo rm -r ~/.config/guix` to reverse `sudo mkdir ~/.config/guix` and did `mkdir ~/.config/guix`. Then I re-tried guix pull. Now works. <lfam>It's weird, I don't remember this problem in the past <efraim>also $HOME/.cache/guix/checkouts/last-expiry-cleanup is sometimes owned by root <civodul>could be the case on Ubuntu if you do "sudo guix pull" or similar (their sudo preserves $HOME) <lfam>civodul: I just noticed it on Guix System when starting from a fresh `guix system vm-image`. I had to do `mkdir -p ~/.config/guix` <lfam>Oh, I was talking about the other bug, not related to ~/.cache/guix <civodul>lfam: oh right, i was referring to efraim's comment <lfam>Your guess sounds probable <rekado_>efraim: I hit this recently and I thought I must have run something with sudo, but I couldn’t remember. (I don’t recall if this was on Guix System or elsewhere, sadly.) <lfam>I can't fathom the use case for it <lfam>I mean, the weird environment it creates <lfam>I assume it was useful on some ancient unix <lfam>Maybe the one from jurassic park <civodul>"sudo make me a sandwich" (quote from a t-shirt you'd see at FOSDEM) <lfam>I tried it and it just screwed up my kitchen <lfam>All the food is in the dishwasher for some reason <lfam>I should have used `sudo -i` <pineapples>If "sudo guix" is a headache, how do I update my Guix System installation then :( <nckx>‘guix pull && sudo guix system reconfigure’ is fine. It's ‘sudo guix pull’ that's the problem. <nckx>& a few others. It's good that we're not artificially limiting users but maybe there's a way to detect objectively wrong usage? *nckx crawls back into the C hole. <lfam>We could eschew sudo and integrate authentication and escalation into Guix <lfam>Like, on certain Debian flavors, you can do `systemctl reboot` and it will prompt for a password <nckx>Who threw a turd into my hole. <nckx>(That's polkit, I believe.) <nckx>Or Guix could detect it after the fact (‘oops, your ~/.cache/guix is owned by root, chown -R it to continue’) without getting in the way of legitimate sudoing. <civodul>pinoaffe: i do "guix pull && sudo guix system reconfigure", that's fine! <nckx>The current error message only helps you the second time you encounter it. <pineapples>civodul & nckx: Thanks! That's what I'm used to doing/runn8ing <leoprikler>+1 for guile polkit, but we don't even have a non GI-based guile-dbus <bqv>the whole channels concept goes away in nix if you use flakes, because your channels are declaratively specified as part of your config. possible to do that with guix? <bqv>cause that'd avoid this headache too <nckx>Channels are declarative. <rekado_>bqv: you can use channels in your manifest (see inferiors) <bqv>i did see those. perhaps i'll try that <bqv>nckx: e.g. your config is a repository, your "channels" would be in it, versioned alongside your system config, rather than separately in .config/guix <nckx>I think inferiors handle that (but maybe I misunderstand). You can't tie channels to system configuration (dunno if Nix does); how would users use them? <nckx>I think I see what you mean and that inferiors are the answer, but it's late ☺ Gud nite. o/ <nckx>(.../me should take another look at Nix...) <bqv>nix doesnt by default, but nix's new flakes feature does <civodul>bqv: Guix "channels" and Nix "channels" are two different things <civodul>Guix channels provide some of the functionality of flakes (pinning Guix to a specific revision) <bqv>So i see, but should i want to move my config to a new machine it still requires shifting and pulling the channel manifest as well as the system config. im a bit spoilt from using flakes, but i much prefer having that all in one <bqv>not to mention not having to worry about root channels vs users' channels <pineapples>bqv: I, too, much prefer having my channels specified in my system configuration. Would be nice if I didn't have to (extra-special-file my channel.scm file) but just declare it in the system configuration, and if I could use my remote channels from the live installation environment, without having to split the system configuration *pineapples hopes that make sense <gn21[m]>Hi, I'm trying to install the telegram by guix on my trisquel gnu/linux and give this message at the end of the compilation: the compilation of /gnu/store/n68qcxi8xpb0ic1a01gkmfh3871rgwp-materialdecoration-1.1.0.drv failed <pineapples>so that I wouldn't have to split the system configuration in order to install Guix System* <pineapples>Btw, yes, I can generate an installation image that contains modules from the channel I need, but, in the case I need to install the OS somewhere else, I'd like to be able to reproduce my work environment, using the stock ISO images from the Guix website