<drakonis>this silly hypothetical comes from a discussion i'm having elsewhere <nckx>Is there an answer to that hypothetical that can't be nabbed out of context? The answer to that is the opposite. <Noisytoot>drakonis, Yes, but GNU would probably fork it <nckx>I think the FSDG are (much) newer but I don't have a source. <nckx>Which is mainly to how old (199x) the DFSG are. <drakonis>there's also other things to consider in this <drakonis>guile and shepherd are also gnu projects <drakonis>the comedy option would likely be guix with racket <dstolfa>nckx: submitting the patch now. do you have some time this week to review this and the package patch (which together make the legacy interface of strongswan work) <Noisytoot>drakonis, Then it should be called Guix (Guile Nix) <dstolfa>(i will also write the documentation for this and submit a patch for that too) <dstolfa>so that users can refer to the info page and so on <Noisytoot>"Xiden is available under non-free licenses for a nominal fee." <drakonis>its going to wind up like nix down the road <ixmpp>Guess im stuck with guix for now then <dstolfa>i wouldn't consider that a bad thing ixmpp :P <dstolfa>i find guix very hackable and enjoyable to use generally <ixmpp>I love guix technically, tbh <dstolfa>i don't think there's a single system out there that i would bother going through so much trouble to just get my work environment up <drakonis>its mainly the issue that contributions arent going to flow back <ixmpp>And there are still things that can improve <dstolfa>there will always be things that can improve <dstolfa>ixmpp: packages are remarkably easy to write, and so are relatively simple services <Noisytoot>There's also Nix, but that contains nonfree software <ixmpp>dstolfa, drakonis: Yes, but i consider nix/guix to be an alpha version of what this idea will actually end up as <dstolfa>in fact a lot of the packages you can just guix import <from> <name> <dstolfa>imo, guix is already very far ahead in this idea space <dstolfa>the whole integration with shepherd, guile in initramdisk, etc <ixmpp>Might end up like emacs, literally undying <dstolfa>this is already really far ahead from others <drakonis>xiden's novelty is to work on distribution <drakonis>the only excitement i feel about it right now is racket related <ixmpp>I just really want to few the Next Generation of this concept <ixmpp>Xiden isnt it, but it at least tells me people are thinking <drakonis>there are a few others but they arent public yet <dstolfa>ixmpp: i think there are incremental improvements that need to happen first, for example being able to do `guix import buildsystem /path/to/top/makefile` to translate the whole buildsystem of say, linux (in makefiles) to an EDSL in guile <dstolfa>so all builds could be described with an EDSL <dstolfa>i don't think you need to reinvent the wheel to achieve things like this, you can just as easily extend guix to do it <drakonis>hmm right now i'm absolutely jazzed to get guix deploy working <dstolfa>that's kind of its advantage really. it's built on a very hackable, turing-complete language that is REALLY good at making EDSLs <Noisytoot>drakonis, Are package definitions also written in Rust? <nckx>dstolfa: Should do, I'll make a note. <ixmpp>As i say, maybe so, guix is much more malleable than nix, but also moves slower and has less mass. Nix has the issue that it has stagnated, horribly, and cannot ever fix that without *drastic* change that their beaurocracy will not allow <Noisytoot>Nix also uses GitHub and contains nonfree software <ixmpp>Noisytoot: Terms and conditions apply etc <dstolfa>ixmpp: imo that's okay, having looked at some nix packages, they are 80-90% shell. kind of defeats the purpose <ixmpp>I literally dont came about free software purity, so thats actually a good thing for me <ixmpp>I hate nix, preaching to the choir, but i still rate both of these ideas an initial iteration. 10 years from now we'll have very much more advanced things <ixmpp>Noisytoot: Honestly, i dont care <dstolfa>ixmpp: i agree that we'll have better things in 10 years, but i personally believe that given that guix is as hackable as it is, it will be fairly straightforward to pick up those ideas <ixmpp>Please, i dont need the gospel <ixmpp>dstolfa: Thats why i say guix might go the emacs route and become immortal. One of the reasons im here now <dstolfa>ixmpp: ah, i missed that part, been a long day for me sorry :) <drakonis>step 1 is to successfully merge guile with emacs <ixmpp>drakonis, Noisytoot: indeed, the agressive pushing of "freedom" was genuinely one of the main reasons i avoided guix at first <drakonis>i've had someone complain to me about that on a different channel half an hour ago <dstolfa>nckx: also, thanks! i'll have time during the weekend to address any comments you might have hopefully :) <ixmpp>I hate proprietary software, but it's stifling at this level <drakonis>it works against guix's growth to do this <Noisytoot>ixmpp, Having proprietary software is one of the main reasons I avoid Nix <nckx>ixmpp: Guix ‘aggressively pushes freedom’? Oy. <dstolfa>IMO guix is one of the very few that does freedom 0 right <drakonis>nckx: the proselytising to the unwashed masses is the problem <ixmpp>Nix also avoids nonfree stuff <nckx>It doesn't. It merely refuses to endorse non-free software. <detrout>I admit I wish it was easier to find the guix non-free repository that has the non-free firmwares in it. <ixmpp>It's a reason to avoid this entire community <nckx>This IRC channel is mostly the choir, so preaching is mostly pointless :) <drakonis>i've had some people complain to me about this and saying it is why they've been avoiding guix <Noisytoot>Having nonfree software and using GitHub is a reason to avoid Nix <drakonis>proselytising to people who're interested in getting into guix in here is a turn off <nckx>There are people who feel ‘preached at’ when you mention something's 100% free. Happened to me. <ixmpp>Honestly, and im not sure if it's breaking the rules to say this, but i sorta planned to see if i could make a large-ish repo to make guix accessible to those not so prudish about nonfree stuff and make things easy <drakonis>there are a variety of reasons to avoid nix <Noisytoot>ixmpp, I don't think that's breaking the rules, but linking to it probably is <drakonis>the rules are to not recommend it if i'm not wrong <nckx>Rules aside, calling people prudish just isn't very nice. <ixmpp>nckx: I dont care if somethings free, thats good. What i care about is Noisytoot pinging me over and over to let me know that the nix community might not spend every waking breath banging the freedom drum <detrout>I know of a non-free guix channel that has firmware and a different one with some games in it <dstolfa>i personally like that guix by default doesn't recommend any non-free software because i personally don't want to run any non-free software. that doesn't mean you yourself shouldn't be able to do so on your computer. i'm sure most people are aware of what the ramifications of non-free software are and they are free to make their own decision <Noisytoot>I was answering "im not sure if it's breaking the rules to say this" <drakonis>it is entirely out of my own volition to engage in such things <nckx>ixmpp: Noisytoot pinged you exactly twice. <dstolfa>as an aside... did my patch get through? i got no ACK from debbugs <nckx>It's not close to an unusual delay yet. <dstolfa>ah okay, i'll give it an hour then :) <nckx>Noisytoot's mail arrived seemingly immediately, life (and greylisting?) aren't fair. <nckx>I don't actually know if that's the reason. You could check your mail server logs if you have them. <ixmpp>As an aside, i was here to pass time while my guix fetched, but seems it was going snailpace cause i was on the wrong ethernet <dstolfa>yeah, last time i sent one it was instant too, i guess it depends on debbugs' mood <nckx>ixmpp: The wrong ethernet? There's a better one? <nckx>My laptop only has the bad ethernet jack. <nckx>Now Guix is CPU-bound as the lords intended. <dstolfa>Noisytoot: currently i just use gmx.com. i'll host my own at some point when i'm not a student and can afford to pay for a few servers monthly to act as frontends that i pull from to my local storage :) <Noisytoot>I think your first email needs to be manually approved <dstolfa>Noisytoot: i have, and it was instant last two times <nckx>drakonis: That's an excellent idea. <dstolfa>i think debbugs just doesn't like me right now *nckx balances the scales. <drakonis>ixmpp: idk i was going to use nixos for that a while back, but it actually never worked <ixmpp>drakonis: If nix is masochism, a mailserver is suicide <nckx>But it's the *fun* kind of masochism. <drakonis>i would've jumped ship from nix and never come back if i wasnt <nckx>I'm talking about personal mail. Never host others' mail until you can both afford to pay what that actually costs. <drakonis>i have a domain atm that i want to do more things with <ixmpp>I have a mail domain, using protonmail though <dstolfa>ixmpp: you could just alias it if you prefer <hrnz>be aware that a lot of people just won't take your mail if you don't have "good reputation" <hrnz>and if you're just starting out, you don't <drakonis>hmm, i'm trying to figure out how to use guix deploy on linode <drakonis>that sounds like a lot of wacky ass excitement i tell ya <dstolfa>ixmpp: you could have your public facing domain just forward everything to your protonmail <drakonis>its largely so i can stop pointing people to my shitty gmail domain <ixmpp>dstolfa: Protonmail allows custom domains <ixmpp>I have everything in one, protonmail, AND a custom domain <hrnz>protonmail runs freedom-deying software. <ixmpp>Im ok with that. I pay for the covenience and sin <drakonis>welp guess i'm writing `linode-environment-type` <drakonis>gonna brush up on my guile skills beforehand and refer to linode docs where necessary <dstolfa>i ought to configure my emacs the bright theme at night is killing my eyes <dstolfa>even with a very aggressive night light <drakonis>i dont know if i can use ssh for that yet <hrnz>drakonis: a lot of monitors have an adjustable backlight. It's great. <hrnz>you're also killing your eyes when you stare at a monitor in a completely dark room. <hrnz>Fortunately freedom-respecting lamps are cheap <dstolfa>i can get behind freedom-respecting lamps given how many IoT devices want to just send literally everything you do to a server (though, i would just call them regular lamps, not freedom-respecting lamps) <dstolfa>drakonis: way too many people get them forced on them by renting a flat <oriansj>dstolfa: have you considered installing and using redshift? <dstolfa>oriansj: i'm using gnome's night light, and on a pretty aggressive setting too. it's just that the default white emacs theme kills my eyes regardless <nckx>What else does anyone do with emacs. <dstolfa>well, i just kind of opened it and started writing code without configuring it since guile works nicely out of the box :) <oriansj>nckx: use it to write notes and code? <nckx>I've heard you can edit text with it too, but I assume they were talking about their .emacs. <dstolfa>emacs makes a great proof assistant too, btw! <nckx>Another useless thing I'll now probably try. <dstolfa>nckx: having written an unhealthy amount of both, i'd say that if you prefer more of a "pure mathematical approach with more automation" go for HOL, but if you prefer more programming-oriented view go for Coq <oriansj>last edit date of my .emacs was Dec 7th to disable Another freaking keymap for insert <dstolfa>which is pretty much just programming <nckx>I've only ever played with minikanren. <nckx>dstolfa: guix-patches@, right? <nckx>That's correct, nothing in the mod queue, I'm sure it will show up in the morning. <dstolfa>i wonder if there's someone manually clicking: "allow mail" before it even arrives at guix-patches@ mod queue :D <nckx>Oh, guess what literally just arrived in my mailbox (really!) <dstolfa>it must be some kind of filtering set up <nckx>Obviously, sneek has something to do with it, and worried that we were on to her. <dstolfa>well i think she deserves a botsnack for letting it go through then <nckx>There is filtering, but unless it's running on a Pentium, I don't think it's to blame for sometimes hours-long delays. <dstolfa>i mean it could be running on a pentium, or even a fully free MIPS CPU if it's on gnu.org <dstolfa>i wouldn't exclude it as a possibility <hrnz>nckx: that's not impossible (and called graylisting) <hrnz>the mailserver temporarily rejects mails with the expectation that a legitimate sender will come back later <dstolfa>hrnz: but surely the sensible thing would be to apply graylisting on the first, or second email, not after you've let two through already? <dstolfa>first two were instant, and the third one took an hour <nckx>hrnz: Greylisting is something else, and I mentioned above that's probably not it. <nckx>We can't say for sure without logs of course. <nckx>It possible to have redundant clusters of incoming mail servers which each maintain their own greylists, so depending on which on randomly accepts your mail you might wait eight times or only one, but I don't think gnu.org does that. ***niko is now known as o
***terpri is now known as robin
<ixmpp>okay, so turns out i already had guixsd on my laptop <ixmpp>but this makes things EASIER <ixmpp>i now have vague config that i can pilfer and use <ixmpp>damn, i don't think i have the config for this machine <ixmpp>nevermind, i'm dumb, it's at /run/current-system/configuration.scm <raghavgururajan>sneek, later tell nckx: I tried [1] `btrfs check --repair` [2] `btrfs scrub` [3] `guix gc --verify=contents,repair`. But I still get the "/home/rg/.guix-profile/bin/chromium: error while loading shared libraries: /gnu/store/6yn16h7la1cj64gm5gvklhijcd4k1zgb-cups-2.3.3/lib/libcups.so.2: file too short". Thoughts? <ixmpp>one downside to everything being guile <ixmpp>is that i can't glance at what stuff's up to using htop <ixmpp>because it's all hidden in that mysterious guile process <ixmpp>hey, the bootloader keeps trying to assume my store is at /gnustore <ixmpp>it's not, and hasn't been for 3 generations <ixmpp>can i get the bootloader reinstalled without that weird state ***ix is now known as Guest9020
***Guest9020 is now known as ix
<ixmpp>Damn, this gets better and better ***sneek_ is now known as sneek
***o is now known as niko
<robin>ixmpp, at the risk of stating the obvious, the /run copy is (supposed to be) transient; you should copy it to /etc/config.scm if that got lost somehow <robin>just checking :) (i'm a bit paranoid after accidentally nuking a guix system install while messing with lvm) <ix>drakonis: did it! Got me a rudimentary weechat service now... <manumanumanu>this is on a foreign distro. Is this doing some build daemon thingie that my user can't access? <mange>Are there a bunch of messages before that with more details? Does it happen again if you run guix pull again? <manumanumanu>but "mange" seems like a nick where that might not be a problem. <leoprikler>manumanumanu: Sorry, I broke guix pull, it should be fixed now <tissevert>how does one use the guix repl efficiently ? when I open mine I have no auto-completion, in fact I can't even recall the previous lines I've typed ^^ <tissevert>is that a problem in my configuration or is that the expected behaviour ? <emestee>tissevert: guile readline startup config is missing <emestee>however what you _might_ wanna do is configure the repl to listen and connect geiser to it from emacs <tissevert>emestee: hmmm I don't know how to use emacs (I don't even know what geiser is ^^) <emestee>if you are going off to lisp land, emacs is your best friend <tissevert>so probably not the more obvious move for me (but I'll try and keep it in mind if someday I go emacs) <emestee>you don't have to use it but you'd be much happier if you did <emestee>emacs is a platform, i do everything in it, shell scripts, diary, calendar, planning, mail, even irc sometimes <emestee>but its strongest side probabl is the lisp support - you really dont want to spend your life in live repl <tissevert>it's tempting but on the other hand I like to have simple tools and be able to give one or the other a try, to be able to replace parts of it <tissevert>ok, honnestly the repl was already so much better with readline support ^^ <emestee>yeah but eventually you'd want to write code in chunks in an editor <tissevert>so my next question was going to be if you people activated readline manually each time or if there was a user config file or something but I think I know the answer already: «no we just use emacs» ; ) <emestee>tissevert: you just put these lines in ~/.guile <tissevert>ohh, even better ! well that could be a way to survive until I have some time to retire to a monastery on a high mountain and learn to master emacs-fu *tissevert isn't crying, you are <civodul>(and on Guix System ~/.guile is ready for all that!) <civodul>on Guix System it's created by default <tissevert>and I've been playing with guile a couple times since yesterday trying to find procedure-documentation <tissevert>anyway thanks everyone, I'm having a much better time in guix repl, and now I can find my way in procedures documentation <PurpleSym>civodul: Ah nice, improved speed! Do you also have memory usage on your radar? `guix environment` is relatively heavy-weight right now (>100MB/instance). <civodul>PurpleSym: i haven't payed much attention to memory usage yet <civodul>lemme know if the graft speedup works for you! <civodul>i've tested several cases, including 'guix system', and that seems to help <PurpleSym>civodul: I’ll give it a shot, once CI has caught up building R packages after the upgrade :/ <civodul>is it just me or emacs-guix broke again? <civodul>%max-returned-list-size: unbound variable <ss2>Is there a list of available platforms Guix can build on? Just setting up qemu-binfmt. <civodul>mothacehe: oh, my bad; i'll push a fix shortly <PurpleSym>I’m only seeing three workers on the CI status page. Is that correct? <ecbrown>ss2: guix/packages.scm defines %supported-systems <ecbrown>i am unaware of e.g. guix --list-supported-targets :-) <ecbrown>you're welcome. i looked in cuirass and it looks like x86_64-linux, i686-linux, armhf-linux, aarch64-linux, i586-gnu, powerpc64le-linux <ecbrown>perhaps these are machines that are implemented build targets, may not be the same as the source code above <ss2>hm, I was just thinking of spawning a qemu-binfmt-service-type service, and just wondered about all the available platforms. I don't think that I'll need them all. <ecbrown>well, i think this is a smaller set than qemu provides *ecbrown notes that cuirass really gives database a working over. good move going to postgres! <civodul>mothacehe: fixed as fe509e017fa1c0e3d0b057784b081def3aa621ad <civodul>i wish we had tests for that, but it's tricky <civodul>apteryx_: generic-html updater issue fixed in 1e8ebb16c997eeeb65ef1205e930dcce0f0e0345 <tissevert>hey ! where did the default wallpaper go ? ^^ <apteryx_>PurpleSym: I see the same. Only two ARM machines are there (dover and overdrive1) <mothacehe>apteryx_: PurpleSym: It's normal, I'm deploying a new Cuirass release on the workers. <mothacehe>which will hopefully fix the substitute timeout issues :) <rndd>could anyone tell me how to use gccgo in guix? i've installed gcc-toolchain and gccgo but cannot build .go files <apteryx_>I'm rather confused by the crate-build-system. I'm trying to have .rlib installed and reused. So far I've managed to have them installed; but I'm confused about how inputs are treated. It seems adding a rust-* package as a regular input field somehow gets seen as a /gnu/store/...-rust-$name-$version.crate on the builder side <apteryx_>in other words: $ guix build rust-log -> /gnu/store/...-rust-log-0.4.14, but in a cargo-build-system phase, (assoc-ref inputs "rust-log") -> /gnu/store/...-rust-log-0.4.14.crate <mothacehe>civodul: deployed works fine again, thanks for the quick fix! <tissevert>does it mean substitute shouldn't timeout anymore ? <apteryx_>OK, I see that expand-crate-sources does that now, for the cargo-inputs and cargo-development-inputs, and it's a transitive operation <apteryx_>(it takes the package-source from each rust input) <apteryx_>ah, and the inputs end up in host-inputs, while native-inputs end up in build-inputs, which explains why I'm not seeing my regular input in the build environment <apteryx_>it seems the in the gnu-build-system we add the inputs to the build-inputs unless cross-compiling <apteryx_>should we do the same for other build systems? <tissevert>I thought I saw someone mention using neovim here, was that in a terminal or using one of the available graphical frontend ? I haven't found any in guix search and I was wondering if there were (even unofficial) guix packages around <pkill9>tissevert: i use neovim in the terminal <pkill9>graphical vim is in the gui output of the vim package (vim:gui) i thinkl <pkill9>ah, the grphical vim is in vim-full <pkill9>and the command in that is 'gvim' <tissevert>yeah I use gvim from vim-full already but today is one of those days when I find mysterious things in my config and it reminds of people who mentioned neovim as clearer and I considered giving it a try <tissevert>and well I like a GUI : ) so I was surprised there wasn't any yet for neovim and wanted to know if someone had worked or started working on such a thing <tissevert>why do people keep suggesting I try emacs ? ^^ yeah, I'll eventually give it a try <pkill9>ah didn't know neovim had a gui version <tissevert>and I think I was using a Qt version when I was running lxqt from some other distribution long ago before I met Guix <civodul>the Ada GCC front-end? i don't think so <jackhill>I believe GNAT needs to be bootstrapped with and Ada compiler, so work is needed to be done. <jackhill>That's cool/unfortunate that coreboot uses Ada <GNUtoo>It's probably to make sure that it has less bugs <GNUtoo>At the beginning it was very unstable <civodul>let's not nitpick on English though :-) *GNUtoo isn't even sure if bugs are countable or not... <GNUtoo>It probably depends on the point of view <GNUtoo>But at least we can count the ones in the bug reports <civodul>when i look at issues.guix.gnu.org, i do feel like i'm drowning in bugs, suggesting they're more like a fluid, indeed <tissevert>but if it was uncountable you'd probably use it without the trailing 's', «less bug» <tissevert>ohhh once again I have trouble predicting the expected hash for a package : ( <tissevert>I cloned the package, went into it, checked out to the expected release tag, then did: guix hash -r . <tissevert>the hash I get is different from the one guix got when I tried building the package : ( <civodul>tissevert: try "guix hash -rx /path/to/checkout" <jackhill>civodul: are you surprised? It seems like the common way to implement languages these days (even if GNAT is older) <tissevert>so, does that mean guix excludes .git when it computes this hash during a package build ? <tissevert>thanks, I'll try and remember -rx as a good default <civodul>jackhill: i'm surprised that coreboot has bits of Ada, not about the bootstrapping issue :-) <hiruji`>Hi all, I've disabled substitutes and now want to rebuild my entire system locally. <hiruji`>Is there a command to do this? I can't find it. <hiruji`>Already have, on my main machine (this one ;^) <civodul>you can "check" builds, but "rebuilding everything" is not really supported <civodul>for instance, you can run "guix build --check coreutils" <roptat>as long as builds are reproducible, it doesn't make a lot of sense to rebuild everything :) <hiruji`>I'd just like having everything built locally from source. <roptat>ideally, you would have disabled substitutes when installing the system, but you'd have spent a very long time in the installer <roptat>now that you've disabled substitutes, everything you don't have yet will be built from source <roptat>you'll notice when we merge core-updates, because you'll have to rebuild everything again <hiruji`>Well in the future I hope Guix grows to get something akin to Gentoo's useflags. Then in the future I can truly, and finally, dump Gentoo. <hiruji`>I just don't like any of Potterings/IBM Redhat's work. They both seem keen on forcing poor software down your throat, which does nothing but burden the user for most. <civodul>i'd hope you come to Guix for what it provides rather than an alternative to things you dislike :-) <roptat>I don't know, I find the shepherd painful to use sometimes, I quite like what systemd does most of the time. I guess it's a matter of taste :) <GNUtoo>hiruji`: there was some conversation about that on the mailing list at some point <hiruji`>Of course, I love Guix for it's reproducability and Scheme configuration. It is nearly perfect. <hiruji`>GNUtoo: Yes, I read that. `Parameterized Packages' <roptat>(don't get me wrong systemd on guix would be a mistake, let's rather improve the shepherd) <GNUtoo>Since it's an important architectural decision it will probably get time to be done right <hiruji`>I remember that flaw SystemD had which let the user brick the motherboard if they rm -rf'd their root *GNUtoo is for init diversity as they all respond to different use cases <GNUtoo>And systemd also has its uses cases <hiruji`>He did not understand the hostility on why this was bad, and just closed the issue. <stikonas>hiruji`: well, it wasn't a flaw of systemd, it was a flaw of motherboard if wiping variables causes it to brick <stikonas>no matter what init system you use, you can always mount efivars <hiruji`>stikonas: No, SystemD mounted something as rw that it shouldn't have. <GNUtoo>proc is also nice, it's a bit similar to guix in the sense that it takes care of launching the various daemons to abstract their configuration through UCI <hiruji`>Should not be re by default; that is not sane. <mschilli>I have a beginners question regarding packaging that I hope to get some help with. <hiruji`>Put your question out there. Somebody will answer. <mschilli>I have added the package, installed it locally and tested it successfully. <GNUtoo>Bug happens, once Linux was crashing on a Samsung netbook which made it write its crash to flash up to the point where it would overwrite code <GNUtoo>And when that happened the laptop was bricked <GNUtoo>If Windows crashed it could also have bricked that laptop <mschilli>Now I want to override the `check` phase to add a test to the package. <hiruji`>GNUtoo: Yes, but Potterings response to this particular one was bad. <GNUtoo>What's interesting to note is that the UEFI on that flash chip is nonfree so I wonder if people got the legal right to repair something that was broken because of the manufacturer... <mschilli>The tool in question comes with a shell script and some sample input so I'd like to use that. <GNUtoo>Like if you don't have a backup for instance... <GNUtoo>hiruji`: this is why having some diversity doesn't hurt <hiruji`>No of course not, if you got repair it then they couldn't milk more money out of you. <mschilli>I have confirmed it runs successfully when launched inside `guix environment --ad-hoc` for my new package. <mschilli>I also managed to make this script run during the check phase. <rekado>roptat: that’s by design! The shepherd wants you to hack on it :) <hiruji`>Though.. We still lack diversity in operating systems. <hiruji`>Windows, or UNIX. These are your only choices. <hiruji`>Both are terrible, in their own respects. <rekado>mschilli: can you show us how it fails? <mschilli>The build log only says the shell script fails withs status 127. <mschilli>So I am looking for a way to see the actual output generated by that script so I can figure out what's going on. <rekado>perhaps the build environment lacks an input <rekado>that sounds like it tries to execute something that it assumes is on PATH, but can’t find it. <mschilli>I'm pretty sure if I can see that, I'll figure it out. I jsut don't know where to look. <rekado>you can keep the failed build directory with “-K” <rekado>so if the script writes some log you’ll see it there <mschilli>tissevert: yes, it's a bash script and patch-shebang handles it according to the build log. <tissevert>rekado: thanks for the tip, I could've used that a couple weeks ago debugging tests of one of my local packages <mschilli>rekado: I don't think there is a log output. I'd need STDOUT/STDERR. <tissevert>but STDOUT/STDERR should be visible in the output of guix build I think <rekado>roptat: seriously though: I’d like us to have a shepherd hackathon one day <rekado>mschilli: may I look at the script? Or would that spoil the surprise? <GNUtoo>Though I still have to find the time to add the FSDG distros to debootstrap somehow *tissevert is going to advocate for runit <tissevert>«runit for guix ! runit for guix ! guix with runit !» <GNUtoo>roptat: and Trisquel for instance uses systemd, including for configuring the DNS AFAIK <rekado>mschilli: could you also share the package definition please? <mschilli>I also figured I screwed up making bowtie-build available or sth liek that. <mschilli>And I'd like to understand the issue so I can learn for the future. <mschilli>It's just bothering me I cannot find the output. <mschilli>If it is a missing binary on PATH, bash should at least throw a 'no such command' error. Where would I find this? <tissevert>mschilli: I think that's what it tries to say with the 127 return code <mschilli>command "run_tut.sh" failed with status 127 <mschilli>tissevert: Sure, 127 might tell me 'some command not found'. <mschilli>I find it odd to have a test script throwing an error message (not just a code) and this not showing up anywhere. <apteryx_>isn't there an error in the log earlier? <mschilli>apteryx: No, before the check phase, I have a successful build phase. <apteryx_>mschilli: also, are you running this from Geiser, or via the Guix CLI? <mschilli>Also, if I disable the test, I can install the package and run the test manually without an issue. <apteryx_>in doubt, use the command line interface, as Geiser sometimes get confused with (current-error-port) or something <mschilli>apterryx_: since I don't even know what Geiser is, I assume the second. ;-) <tissevert>mschilli: just my two cents but, exiting printing the error code, that's what your script does, right after the call to bowtie-build <apteryx_>OK. Geiser is a REPL for Guile that runs in Emacs <rekado>mschilli: the script does not set up PATH, and it assumes that mapper.pl and miRDeep2.pl are on it. <mschilli>I am running `guix environment --ad-hoc <my-package>` on my system. <tissevert>isn't your script simply doing that, hiding the message ? <rekado>I’d like to see the package definition to see how the script is called <rekado>maybe we don’t even get that far in <roptat>we could do the same, it would save us ~36MB in python <mschilli>those perl scripts are installed by the package itself, the other one is an input. <roptat>and installing idle in a separate output would save another 5MB if I count correctly <rekado>mschilli: my guess is that this is all a very red barrel of herring and the error happens earlier. <rekado>“installed” only means copied to some unknown place in /gnu/store <mschilli>But you got me thinking: check is run before install, right? <rekado>they won’t magically appear on PATH <rekado>in the gnu-build-system it is, yes <mschilli>So that's the difference between runnning it manual. <rekado>for some packages it’s impossible to run the tests before installation; in that case we move the check phase around, somewhat awkwardly <mschilli>I'd need tor run the test after installing the package. <rekado>but ideally we’d run the tests before copying things to the store. <rekado>would it be feasible to just add the build directory to PATH and run the tests before? <mschilli>So I could just modify the environment in the check phase and all should be fine. <mschilli>The only downside is that the test would not cover the install phase of the package definition. <rekado>yes, you can add a (setenv "PATH" (string-append "this-location-right-here:" (getenv "PATH"))) <mschilli>So if a future version add a script that is required on PATH, the check phase would work, but install would not install the new script. <rekado>right, it’s meant to test for miscompilation, not that the scripts have been installed to the correct location. <rekado>it’s up to you when to run the tests <rekado>whichever is more worthy of tests <mschilli>I'd still love a way to see the error message telling me which binary is not on PATH. <rekado>(or you could add yet another test phase… you can add as many as you feel you can justify) <rekado>yeah… I’d like to see the invocation still <rekado>because there’s a chance that the test script isn’t actually executable and the 127 is about the script itself. <mschilli>so: (with-directory-excursion "tutorial_dir" (invoke "run_tut.sh")) <rekado>is the “run_tut.sh” actually executable? <mschilli>rekado: when I manually clone the repo, yes. ***dekenevs is now known as mitzman
<mschilli>Otherwise I'd hope for an error message telling me so. <mschilli>bash should throw a 'not executable' error. <mschilli>That's why I came asking here for where to look. ;-) <rekado>I suppose you could do (invoke "bash" "run_tut.sh") and see if that helps <rekado>the 127 error is cryptic, but there’s really not much Guix can do about it. <mschilli>I could. Or I could preserve the failed build dir as you suggested earlier. <mschilli>But how come bash throws an error message when not run through Guix? <mschilli>Suppose run_tut.sh would contain some printf statements, were would I find that output? Directly in the build log? <rekado>mschilli: invoke does not use bash. <rekado>invoke merely wraps system*, which is a syscall. <mschilli>OK. So that at least explains the issue. <mschilli>I'll try explicitely running bash to see if I can get the error this way. <rekado>(“system*” is not the syscall; “system*” uses “execve” or similar; that’s the syscall) <rekado>uhm, execve wouldn’t ever work on scripts <rekado>it doesn’t cause evaluation of the shebang, or am I wrong? <rekado>I’m wrong says the execve man page. <ix>Do any of you use guile as a shell? :D <mschilli>(invoke "bash run_tut.sh") still does not produce any message in the build log. <mschilli>I'll keep guessing what the problem is then and try fixing it blindly. ;-) <mschilli>I definitely need to modify PATH given that install did not run yet at this point. <rekado>“invoke” (like “system*”) needs to have every argument spoon-fed, one spoon at a time <rekado>what you’re thinking of is “system” (without the *), which *does* call /bin/sh and feeds its only argument to that shell. <rekado>jackhill: my take is that it’s not fine to make *others* use non-free JS; but if you use it to set up hosts that’s up to you. <jackhill>rekado: yep, that seems reasonable. I guess the question is could the Guix project benefit from these resources, or do they come with too many strings <civodul>i'd be somehwat reluctant in distributing substitutes coming from there <mschilli>I can already report that adding the src dir to PATH for the check phase fixes the 127 error. <mschilli>I'll still see if I can get the message to show for the next time I need to debug this or another package. <rekado>generally, I prefer to have physical access to the build machines. <rekado>even more generally, though, I prefer it when no unknown people have physical access to the build machines. <rekado>I’m not anti-cloud, but it’s summer. <ixmpp>Hey, again guys, when i `guix system reconfigure`, my grub.cfg assumes the store is at /gnustore/, which it isnt and hasnt been since the first generation. How do i fix that? I have to manually go in and replace it every time for now <ixmpp>`doas guix system reconfigure /boot/config.scm && doas sed -i 's#gnustore#gnu/store#g' /boot/grub/grub.cfg` lol <mschilli>OK, this is strange: I undid the change to PATH and tried with (invoke "bash" "run_tut.sh") and it *works*. How is that possible? I double checked: removing "bash" is enough to cause the 127 (without error message). <mschilli>So my take is `invoke` fails to recognize the shebang and that's causing the 127. Maybe because run_tut.sh was patched by patch-shebang but install did not run yet? <mschilli>I feel uncomfortable pushing a package that works but where I don't understand how/why? ;-) <rekado>mschilli: I don’t know why invoke doesn’t do the expected thing with the shebang. <rekado>with “bash” it obviously works because you’re leaving all the work to the shell <mschilli>but how does it find the scripts if they are not on PATH? <rekado>I don’t know what the heuristics are <rekado>like, the script is in the same directory as the things it calls — will bash even attempt to search PATH then or launch things from the current directory? <mschilli>I tried (invoke "bash" "-c" "echo foo;exit 1") and I do get the foo message as well as the exit status 1. <efraim>unless it's the trivial-build-system, yes <mschilli>I'll try to mess with the environment to make the tutorial script fail. I just want to see that I get an error if it fails before I conclude no error means it ran successfully. ;-) <mschilli>efraim: It's the gnu-build-system. That explains then. Thanks for the help. <efraim>you can try (unset "PATH") IIRC if you want to unset it <efraim>no, unset is bash, it would be (unsetenv "PATH") <mschilli>rekado: very misterious. The run_tut.sh script is ot in the same directory as the perl scripts it is calling. Also, the perl scripts are only wrapped even after the install phase. <ix>Any chance i can load firmware in the initrd? <asterope>I found a workaround for the issue with all those "incompatible bytecode version" warnings after guix pull <asterope>I removed guile from the profile and it's fine. I don't know why it worked though <mschilli>(invoke "bash" "-c" "./run_tut.sh") results in the check phase to run through. <mschilli>(invoke "bash" "-c" "./run_tut.sh;exit 42") has it fail with erro code 42 instead. <mschilli>However, The output of the 42 error version also contains the follwoing error message: <mschilli>./run_tut.sh: line 9: mapper.pl: command not found <mschilli>./run_tut.sh: line 15: miRDeep2.pl: command not found <mschilli>command "bash" "-c" "./run_tut.sh;exit 42" failed with status 42 <mschilli>So the script *is* failing without the path adjustments but somehow this is not picked up by Guix. <mschilli>As such, this has no value as a test. ^^ <yoctocell>ixmpp: re /gnustore/, maybe you could look at the build script for the grub.cfg? <yoctocell>run `guix system build /path/to/config.scm', which gives you a directory containing all the build scripts <roptat>civodul, oh, python 3.10 has a --without-static-libpython option <roptat>civodul, although it's not released yet, and doesn't work with python2 <roptat>so I'll just remove the .a, and add a comment to replace that phase with the proper configure flag in the next python release <dstolfa>i got a wacom tablet today and it works perfectly on guix with wayland, love it <roptat>should I use fedora's patch, or a phase to remove libpython*.a? <ixmpp>yoctocell: cant quite tell whats going on <ixmpp>In /gnu/store/bj0dygrlwyjfc1b3nvwg2cdil8rgd852-grub.cfg-builder theres a lot of (substring 5 <storepath>) <ixmpp>I cant see where /gnu is being prepended <ixmpp>> (string-append "/gnu" (let ((file <ixmpp>"/gnu/store/idh5g98bi8wxkl01xmhkman12yi6ydjd-grub-image.png")) (if (string-prefix? "/gnu/" file) (substring "/gnu/stor <ixmpp>e/idh5g98bi8wxkl01xmhkman12yi6ydjd-grub-image.png" 5) file))) <ixmpp>No, that is it, what on earth <ixmpp>But then i checked gnu/bootloader/grub.scm and it gets kinda crazy <yoctocell>Hmm, why is one of them "/gnu" and the other one "/gnu/"? <yoctocell>I will have to look at (gnu bootloader grub) <ixmpp>yoctocell: Aha! I figured it out <ixmpp>Looking at the code didnt help too much but it did give me a hint <ixmpp>I had my store mounted to "/gnu/" <ixmpp>So the grub code was replacing it unbalanced <yoctocell>I have made a smiliar mistake by setting my home directory to /home/<user>/ instead of /home/<user> <soheilkhanalipur>Guix system works very slowly on a computer with 8GB RAM! More than 2 hours have passed and progress of building Ungoogled Chromium is 50% 😕 <solene>soheilkhanalipur: do you base your claims on the time for building chromium? <mschilli>Chromium takes a lot of RAM to build from source. <solene>chromium may be the biggest opensource project to build... <mschilli>I have 16 GB of RAM on my notebook and I can barely build it. <dstolfa>solene: i think you're right... hard to think of anything with more stuff to build <solene>firefox isn't that good either, the Rust compiling processes can take like 3 GB / thread and you easily run out of memory <solene>dstolfa: chromium, gcc, llvm, webkitgtk4, rust and firefox... that the package list my computer spend the most time compiling <solene>but chromium is far ahead in term of time to compile <dstolfa>yeah, all of those are nasty but as you said, it's hard to think of anything that takes more resources and longer than chromium itself <mschilli>solene: libreoffice also can take a while ;-) <solene>mschilli: hmm, it's not that long to compile but yeah, that would go with firefox <ix>So i have a shepherd service ***sneek_ is now known as sneek
<ix>Cause no logging, etc <ix>The exact same command is fine in my shell, though <dstolfa>ix: could you share your code on say, paste.debian.net <ix>(i know, there are smarter ways to do this) <ix>I just want to figure out *why* this wont work, and how to debug such things <ix>Shepherd services run as root, no? <ix>I dont see what could be different <mschilli>Is there an easy way to create a temp dir during a build phase and clean it up afterwards? <ix>Arent builds sandboxed? Mktemp -d <dstolfa>ix: hmm, have you checked that what you're passing into make-system-constructor is what you actually expect it to be? <dstolfa>you could just (display ...) it to make sure, for example <ix>dstolfa: it says it expects a string that it runs in a shell <sneek>Welcome back nckx, you have 1 message! <sneek>nckx, raghavgururajan says: I tried [1] `btrfs check --repair` [2] `btrfs scrub` [3] `guix gc --verify=contents,repair`. But I still get the "/home/rg/.guix-profile/bin/chromium: error while loading shared libraries: /gnu/store/6yn16h7la1cj64gm5gvklhijcd4k1zgb-cups-2.3.3/lib/libcups.so.2: file too short". Thoughts? <ix>Replace make-system-constructor with display? <dstolfa>presumably you could just have (start #~(display #$(file-append ...))) <dstolfa>it wouldn't actually start anything, but it would print it for you <nckx>Or just (mkdir-p "/tmp/dir) (do stuff), why bother creating a unique name & cleaning up. <ix>Wrong type to apply: "#<unspecified>" <ix>Im still not solid on G-exps <dstolfa>i would expect iproute to need to be #$iproute there, but i'm not 100% sure <dstolfa>haven't really used iproute for anything, but i wouldn't be surprised <dstolfa>ah no wait, you're using file-append <nckx>raghavgururajan: Btrfs won't help you here, the files contain bogus data but are valid as far as it's concerned. What does guix gc --verify=contents,repair actually print? It can only restore damaged files from substitute servers that have a copy. If that's not possible, try to delete each store item like you deleted that empty file a few days ago: delete all GC roots to it until ‘guix gc -D /gnu/store/<each damaged item>’ succeeds. <ix>dstolfa: string-append like that fails too <dstolfa>ix: could you try to just (display #$iproute)? <rndd>hi everyone! does anybody use gccgo in guix? <ixmpp>dstolfa: Wrong type to apply: "#<unspecified>" <ix>Seriously am i doing something very wrong <roptat>ixmpp, sorry, did you share what you were trying to do? <roptat>ix, you keep changing name, that's confusing ^^' <ix>Sorry :p both start with ix, to mitigate that :p <roptat>file-append is looking for a file, but there's no "bin/ip link set..." in the iproute2 package ;) <ix>So i need to file-append and THEN string-append <rndd>does anybody use docker service in guix? <roptat>(I used string-append, but you can use file-append instead) <ix>roptat: awesome, thanks so much! <roptat>ix, no because you'd get a string, and it's not a function <rndd>i've added docker service type but get "Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?" <roptat>instead, you use invoke, and separate each argument <roptat>(or system* but that's discouraged) <ix>Well, i get a lot further now <ix>But now it exits 127, which is no such file? <ix>Throw to key `%exception' with args `("#<&invoke-error program: \"/gnu/store/kcndcj1hsb18i2id3flsrfnzk8q8d34v-iproute2 <ix>-5.12.0/bin/ip\" arguments: (\"link\" \"set\" \"enp4s0u1\" \"down\") exit-status: 127 term-signal: #f stop-signal: #f> <ix>nckx: i just worked tht o <rndd>drakonis: yep i've reconfigured but when i try to start dockerd i get "Service dockerd could not be started.herd: failed to start service dockerd" <ix>Not used to sbin still existing. It doesnt on nix <ix>nckx: any reason not to do it in guix? <dstolfa>rndd: that's because dockerd is not a service <Guest98>hey guys! I'm trying to use guix with haskell (guix environment --ad-hoc ghc) and its taking a long time building a bunch of stuff, I kind of expected it to just pull the relevant binaries not build stuff. Any suggestions? <dstolfa>and it provides dockerd and containerd <rndd>dstolfa: well, "herd: service 'docker' could not be found" -_- <dstolfa>rndd: have you enabled it in your system configuration? <dstolfa>rndd: all you really need to do is add (service docker-service-type) to your /etc/config.scm in your services <rndd>Guest98: do guix pull, after that try to install ghc <nckx>ix: No. The arguments pro and contra are both pretty meh, no? ‘Save some string-appends, bytes, hacker time’ — ‘deal with a tree-wide move, rebuild, breakage’. <dstolfa>rndd: what is the output of `herd status`? does it contain both `dockerd` and `containerd` as a result of having the docker service enabled in your system configuration? <Guest98>ah ok, I'll try to do `guix pull`. Any safe way to cancel `guix environment --ad-hoc ghc`? or just Ctrl-c? I heard the installations are atomic <dstolfa>rndd: ...oh, have you added yourself to the "docker" group? <rndd>dstolfa: yep, containerd is "+" but dockerd is "-" <dstolfa>let me look at my system configuration, maybe i'm forgetting something <rndd>Guest98: ye, ctrl-c, you may also run guix gc to clean <rndd>just pull recent channel <rndd>also, you use guix as system or as package manager? <nckx>ix: I mean, if someone volunteered to *do* it they'd probably be allowed to. <Guest98>rndd: im using it as a package manager on arch linux :) <dstolfa>rndd: no clue, does `guix system reconfigure` complain with something, or does everything run fine? <nckx>/sbin doesn't *add* value. <rndd>Guest98: have you added suggested lines in your .bashrc? <dstolfa>so reconfigure ran fine and you still don't have dockerd in your `herd status`? <Guest98>rndd: no... I didn't see it mentioned in the installation instructions, only nss <ix>nckx: i'll perhaps bear in mind for when i actually understand how all of guix works <dstolfa>rndd: did you put in any configuration in your docker-service-type, or just using the defaults? <rndd>dstolfa: i have dockerd in my herd status as stopped service. use default (not good in non default herd services) <dstolfa>rndd: out of curiosity, what happens if you just run dockerd in your root shell? <rndd>Guest98: so, run guix pull. if it will suggest adding lines in .bashrc after completion - add them. then run new bash console and try create env with ghc <rndd>dstolfa: "bash: dockerd: command not found" <dstolfa>for some odd reason, you don't have dockerd installed <rndd>as on previous installation <rndd>can system config give different results? <rndd>so, what info i can provide <dstolfa>could you share your entire system configuration? make sure to strip any passwords or private information you don't wish to share <rndd>dstolfa: i would like, but i use some channels and packages wich are not acceptable to mention here <apteryx_>rndd: did you try restarting it? It's sometimes finicky. <apteryx_>Also try restarting the services it depends on (containerd IIRC) <dstolfa>rndd: hmm, not sure, maybe nckx can weigh in on this <apteryx_>I had a problem in the past where it'd fail to start because containerd had crashed, and hurd didn't restart it somehow <nckx>Adding lines to .bashrc sounds like very dangerous advice. When does Guix suggest this? <rndd>nckx: on foreighn distros after guix pull <rndd>i have it on debian and fedora <rndd>nckx: i cannot say right now <drakonis>i know which ones you're talking about but they're unlikely to influence the outcome <rndd>but it restarted after restarting containerd <dstolfa>rndd: it's probably best to put things in .bash_profile rather than .bashrc, maybe move everything there and then test? <rndd>dstolfa: i dont this issue right now. i can think now only about docker service <rndd>well, herd says that dockerd requires containerd dbus-system elogind file-system-/sys/fs/cgroup/blkio file-system-/sys/fs/cgroup/cpu file-system-/sys/fs/cgroup/cpuset file-system-/sys/fs/cgroup/devices file-system-/sys/fs/cgroup/memory file-system-/sys/fs/cgroup/pids networking udev <rndd>am i need to check this services availability? <Guest98>dstolfa: found this in the manual The end result is a new guix command, under ~/.config/guix/current/bin. Unless you’re on Guix System, the first time you run guix pull, be sure to follow the hint that the command prints and, similar to what we saw above, paste these two lines in your terminal and .bash_profile: <Guest98>GUIX_PROFILE="$HOME/.config/guix/current" <rndd>as i see it mentioned in manual so this is not and issue <kani>trying to solve a new issue now <kani>so have to use a separate pc <kani>tried adding amdgpu to initrd <kani>drakonis, console freezes during boot <kani>everything still works, but nothing on the screen <drakonis>oh, must be one of those firmware thingabamobs ***lispmacs[work] is now known as forthmacs[work]
<kani>im uhh, ¨not using linux-libre¨ <kani>so i should have all the firmware, right? <roptat>I think I've heard people complain about 5.12 <rndd>kani: this is not really write place, but ye (you should read readme of channel u use, they mention how to use only needed firrmware) <roptat>(though it was unrelated I think) <rndd>maybe i should reinstall or something <kani>rndd, ah, so less firmware might fix it? ***forthmacs[work] is now known as lispmacs`
***lispmacs` is now known as lispmacs[work]
<kani>ok hang on, iĺl join somewhere we can talk freely <mschilli>Can I assume grep to be available during a build phase or do I need to add an input for it? <nckx>Guest98: You shouldn't add those lines to .bashrc. You'll catch bugs. ***Server sets mode: +Ccntz
<lfam>Currently Guix serves a wide range of security postures, from `curl install.sh | sudo bash -` to "I build *everything* from source" <nckx>bayfront took oddly many seconds to join. <nckx>That's what ‘bayfront-log has joined’ means. <lfam>Anyways, if there is a substitute server it should probably offer it's key on whatever it serves as a web page <nckx>It's not a service. Someone has to ssh into bayfront and sudo su - rek ado and type ‘znc’. 😒 <dstolfa>how does guix handle package deletions? namely, if someone has installed package X, but package X is deemed unsuitable for guix and it gets removed for whatever reason, what happens? <lfam>dstolfa: When doing operations on the profile containing X, you'll get a message "guix package: warning: package 'X' no longer exists" <lfam>I think Guix will leave that part of the profile alone <nckx>dstolfa: It'll be missing from newer pulled Guixes so you can't update or reinstall it. You'll have to remove it from your manifest to be able to ‘guix package -m’ (or ‘guix system reconfigure’ if it's a system package) but the old binary can stay in your ‘guix install’ profile for as long as you like. And you can always bring it back with an inferior or a local copy. <lfam>The imperative method `guix package -u .` will keep working <Noisytoot>I am updating lmdbxx, who's only dependent is nheko, the Git repo used in the package definition is no longer maintained, but there is a fork that is required to build the latest nheko, should I update the homepage to the Git repo of the fork (that does not seem to have a proper homepage)? <lfam>Eventually your profile's disk usage will double, as the dependency graph moves on <nckx>There are quite a few packages that do this, unfortunately. <nckx>With luck, there'll at least be a README there. <lfam>The next generation of supply chain attacks <nckx>Noisytoot: Because ZNC is the shit. I'll update it to 1.8.whatever, because why not.