<ardon>Hi, has anyone gotten ocaml to work on Guix with the core library? I've just started reading Real World OCaml, but the ocaml toplevel doesn't find 'topfind' in Guix. This is my ocamlinit https://bpa.st/53RQ and the packages I've installed are ocaml-4.07, ocaml4.07-core, ocaml4.07-dune, ocaml-ocp-indent, ocaml4.07-findlib, ocaml-merlin and emacs-tuareg. This is a related issue on Nix https://github.com/NixOS/nixpkgs/issues/16085 ***jonsger1 is now known as jonsger
<jab>what's going on guix? <char[m]>When using guix shell --root, shouldn't $GUXI_PROFILE be set and sourced inside the new shell? ***Xenguy_ is now known as Xenguy
***iyzsong-www is now known as iyzsong-w
<ns12>Hello, what is "guix package: warning: package 'glibc-utf8-locales' no longer exists" supposed to mean? Where can I get my locales? <ns12>I got that ^ during "guix package -u". <nckx>glibc-utf8-locales was not intended to be installed by users. <AwesomeAdam54321>nckx: the glibc-utf8-locales package was removed because of its arbitrary choice of utf8-locales included <AwesomeAdam54321>unless --disable-deduplication is given to the guix-daemon, glibc-locales is actually much smaller than it says in the package information <nckx>Because both exist. See ‘guix package -A ^node$’. <nckx>When you ‘guix install node’ Guix will choose the highest version. ‘guix install node@10’ will install the lower. <nouun>Hey, I'm trying to create a shepherd service which starts when you start x and I can see in 'sudo herd status' that there's one called 'xorg-server' but when I try add that as a requirement it says that xorg-server isn't provided by any service. <apteryx>building a new version of the Guix package (bumped locally): error: Server does not allow request for unadvertised object 199da75a8adf37381c32ee1e3028b08b94703584 <apteryx>and then... Failed to do a shallow fetch; retrying a full fetch... <apteryx>lumberjack123: 'guix refresh -rl node@10' may give cues <apteryx>apparently the world depends on node@10 <nckx>It's not clear if this is the sin or the punishment. <brendyn>Is it possible to post a patch series in a one go rather than doing the debbugs dance, starting with one email then waiting for debbugs to respond with the bug id? <ArneBab>How can I configure user-cron? (that users can invoke cron -e to edit their crontabs and have scheduled jobs) <AIM[m]1>How do I make the custom package I made to show up in specification->package? <brendyn>AIM[m]1, probably making your own local channel work <brendyn>i have one i set the url to file:///home/b/guix-brendan <brendyn>Note that this will pull the latest commit of that git repo, not the working directory, so you have to commit changes <AIM[m]1>So that's why it kept throwing errors, huh? <AIM[m]1>I just put some system wide custom fonts in the config.scm <brendyn>Another choice is to use GUIX_PACKAGE_PATH. That is faster to use nad iterate on, but a bit messier in the long run. <AIM[m]1>Currently I'm trying to do stuff the official guix way <brendyn>Do you know how to create your own channel? <jpoiret>you can use the -L switch too for guix commands <jpoiret>this is something that most people are unhappy with <ArneBab>jpoiret: for experimenting I just change stuff in the repo, then use make and ./pre-inst-env <jpoiret>oh for sure, i was talking about AIM[m]1's question <jpoiret>that's what i do too (except for very exotic changes) <allana>Hi guix! Guix system services and config files. Is it in practice more appreciated for people to supply external config files or to have config files generated from scheme when configuring services? <civodul>allana: hi! the latter, but with an option to insert raw config contents <brendyn>ArneBab, but if you have channels, how do use them with your git checkout guix <jpoiret>brendyn: with either -L as a command line option or GUIX_PACKAGE_PATH i think *civodul got their childhurd back \o/ <ArneBab>brendyn: I didn’t use channels with that yet <civodul>apteryx, nckx, efraim: i'd like to "guix deploy berlin-nodes.scm" so we can build again for i586-gnu; any objection? <cbaines>getting back to the hurd stuff sounds exciting :) <florhizome[m]>Can shepherd virtual services provide some kind of a template or are they just a tag that groups services with a distinct functionality? <efraim>civodul: I don't actually have anything to do with berlin <efraim>all I can say is assuming both the sending machine and the receiving machine are the same architecture we shouldn't run into the problem rekardo was having previously with binaries for the wrong architecture <AwesomeAdam54321>florhizome[m]: A virtual service is just a nickname that can be used by multiple services <AwesomeAdam54321>florhizome[m]: Can shepherd virtual services provide some kind of template <- Can you elaborate? <florhizome[m]><AwesomeAdam54321> "florhizome: Can shepherd virtual..." <- well, having virtual services makes a lot of sense since different processes can share some functionality but also it doesn’t seem to be able to account for much complexity in difference between services sharing a nickname. So I thought a virtual service maybe should have some more information about the functionality associated with its name, imagining it somewhat like a template, <florhizome[m]>and the actual services would define how they fill those slots. I guess it would be kinda like a class–object relation but I‘m not sure since I don’t know much about oop <nckx>sneek: later tell civodul: No objections from me! Happy hurding. <apteryx>sneek: later tell civodul OK for me too; as long as you don't need to reconfigure berlin itself, it should be fine *apteryx is running a system btrfs raid10 test to recover some confidence <AwesomeAdam54321>florhizome[m]: It should be possible to do that by defining custom slots for each service providing the virtual service, but I'm not sure how other services would check those slots <euandreh>If I'm doing "guix pull" locally and running "guix deploy"s, do I also need to "guix pull" on the remote machine? <nckx>Depends on why you ask. The deployment doesn't care about any remote guixes, of course, but nor will it mess with them. You can't say 'oh, I deploy changes to this machine weekly, therefore my remote user's guix can't be a year old'. <singpolyma>Deploy is effectively system reconfigure but over ssh, yeah? <mbakke>'guix gc --verify' does not seem to cope well with I/O errors from btrfs ... the store paths are effectively skipped instead of repaired <mbakke>I had to manually extract the inode number from dmesg, run 'find /gnu/store -inum NNN', and 'guix gc -D' the affected items in order to repair them <mbakke>I think a non-checksumming FS would just serve the corrupt file, and then 'guix gc' would detect the problem and repair automatically <mbakke>side quest: how to figure out which GC root is holding a specific item? 'guix gc --referrers' does not give any output, yet 'guix gc -D' fails because the item is alive <euandreh>nckx: I'm coming from an "keep the server up-to-date and secure" point, and IIUC the other thing I need is the unnatended-uptrade-service-type <apteryx>mbakke: wouldn't you fix this kind of errors at the Btrfs level? using btrfs scrub <GNUtoo>hi, is there something to do when one sent a patch and didn't get any review in 2 weeks? <apteryx>GNUtoo: you can bug a committer about it here <apteryx>another thing to help is review other's work <GNUtoo>I've done that but I fear I can only review simple patches <GNUtoo>iskarian might have been interested in reviewing my patch but for some reason that person isn't available on IRC <gnucode>sneak later tell iskarian to speak to GNUtoo <gnucode>can someone help me out? don't we have a bot called sneak or something here? <gnucode>nice! GNUtoo I was mispelling sneek to sneak <gnucode>:) I actually thought sneek was a real person for about 5 minutes once. We had a great conversation. He's a good friend. <gnucode>Maybe I should add in the manual some documentation about how to use sneek. <GNUtoo>We also have that issue with our bridge in #replicant (that's also why I want to update it, we run an outdated version) <gnucode>GNUtoo: can you send me a link to the sauce (source code) for sneek? <gnucode>GNUtoo: Is he sentient already? AI has taken over the world!? <GNUtoo>A software to bridge several instant messaging networks, but we use it to bridge several IRC channels <gnucode>sneek: are you a human ? Or advanced/heartless/killing AI? ***wielaard is now known as mjw
<gnucode>GNUtoo: hmmm. well I should probably do some actual work now.... :( <GNUtoo>It appears like that if I send a message from OFTC: '<SIC> O|GNUtoo| message', so sometimes people write to SIC <GNUtoo>The difference is that since there are humans behind, they can tell that SIC is a bridge <phodina[m]>Hi, could you please suggest what is the best way to add patches to inherited package definition? Looked around for something like modify-sources but couldn't find one <phodina[m]>* something like `modify-sources, * modify-sources` but <GNUtoo>with transformation options probably <GNUtoo>ah maybe that only modify an existing package, so scratch that <maximed>phodina[m]: package-with-extra-patches <maximed>There's also a transformation named --with-patch or something like that <SeerLite[m]>phodina: Hi, I've seen `(origin (inherit (package-source <super>)) ...)` a few times <unmatched-paren>is it safe for me to update my kernel yet? (I currently have it pinned to 5.15.16 because any later kernel either doesn't boot or hangs when i try to launch a desktop. I see in the logs that there's some iwlwifi-related bug in linux-libre causing it [i have a (currently unusable, for obvious reasons) iwlwifi card in this laptop]) <unmatched-paren>oh, yeah, another thing: there are some dmesg messages about the deblobbed wifi. they're annoying, because the hijack the login prompt. would they disappear if i `modprobe.blacklist=iwlwifi`? <florhizome[m]><AwesomeAdam54321> "florhizome: It should be..." <- i guess you could use inheritance but I think in practice that would turn out very hacky on any more complex subject <phodina[m]><maximed> "There's also a transformation..." <- Thanks, that's exactly what I'm looking for. <unmatched-paren>i got rid of quite a lot of kernel messages by blacklisting pcspkr and iwlwifi, but not the login-prompt hijacking ones <unmatched-paren>the text pops up like this: `password: [blah blah blah]` while i'm typing my password <lfam>I don't know how to control that stuff... I'm sure people here can advise <unmatched-paren>(probably unrelated, but nouveau's initialization seems to fail: `sec2 ctor failed: [i can't remember the rest]`) <apteryx>I can't get 'make check-system TESTS=installed-os' to pass; is it just me? <apteryx>it always fail with 1 or 2 unexpected failures <apteryx> FAIL login on tty1 / FAIL getlogin on tty1 <lfam>Which commit are you on apteryx? I can try to reproduce it. I assume this is on x86_64 <Guest40>guix package: warning: Consider running 'guix pull' followed by <Guest40>'guix package -u' to get up-to-date packages and security updates. <Guest40>that's after 'guix pull', why would an OS break like this out of the box? This is a fresh install. <lfam>It's not broken. It's just warning you that there updates available <lfam>Oh, it's after `guix pull` <Guest40>it loops, all it produces is that same message <lfam>I would do `hash guix` or `bash --login` to update the location of the `guix` command <lfam>It changes after the first `guix pull`. It changes from the system-wide `guix` to the per-user `guix` managed by `guix pull` <Guest40>it's insane that an OS called guix would break it's primary package management tool <lfam>Concretely, it changes from /run/current-system/profile/bin/guix to ~/.config/guix/current/bin/guix <cbaines>this can also be caused by not using a profile in your shell quite correctly <lfam>Anyways, it's a UI problem for which a solution has not presented itself <lfam>It is mentioned the manual section Getting Started, because it's a known issue <lfam>But, like I said, a solution has not been devised <Guest40>I'll try again in 6 months, guix is still in beta <lfam>At least it was over quickly <lfam>It could be helpful to look for other programs that change their locations like this, to see if they handle it more gracefully <apteryx>lfam: I'm on master, with 3 extra test-related only commits on top <lfam>Guest40's experience is probably very common <nckx>apteryx: scrub works only on multi-device (or, well, dup data but who does that) file systems. Plus, guix should just work. That's a pretty bad bug, would make an interesting system test (dm flaky...?). <the_tubular>I'd agree, guix probably has the "highest" entry bar of every distro I've used <nckx>If it's still in beta it's still going to be in beta in 6 months. *nckx agrees with the_tubular <lfam>Maybe user skeleton should include a dummy ~/.config/guix/current/bin/guix which points to the system-wide Guix <apteryx>nckx: dup data is a very recent default I think; but I get your point :-) <lfam>That way, the location would never have to change <the_tubular>Apart from documentation, are there other ways to lower it's entry bar ? <lfam>I think the point is to not require documentaiton <lfam>Any time a user reports a problem like that, you can assume at least ten other people have not reported it. So, one focuses on fixing it <lfam>What I mean is that instead of merely documenting workarounds for problems, fix the problems so the documentation is not necessary <the_tubular>Also, there's nothing wrong with looking at documentation, I'm not the biggest fan of the cookbook and how it's layed out. But documentation should be avaialble and straight to the point when someone encouters a known problem imho <lfam>The issue reported by Guest40 is definitely a bug <lfam>It's just a bug that we've aren't fixing <lfam>But over the years I've realized that, for many users, warnings are basically fatal errors <lfam>They won't ignore them or accept them <lfam>Sending an email did not work? <the_tubular>It did, but through the web ui, i encountered problems <lfam>Right. We had to disable the web UI submission form <lfam>Not enough people to help maintain the web UI <the_tubular>I already asked the question in the past, but never had an answer I liked. Maintaining guix is a huge undertaking and I feel like the developper are overwhelmed. We should find a way to draw more pair of eyes on guix <apteryx>lfam: and yes, I'm on x86_64. Beware though. install tests are crazy expensive (they needs to build the whole Guix as a start) <lfam>Yeah I know. It will take a while <lfam>the_tubular: It's true. There are a lot of people who send patches but not that many want to get involved more deeply <lfam>That's part of "getting involved" <the_tubular>I don't feel like I've got all the knowledge to involve myself in any serious manner. <lfam>I think a lot of people have the impression that only experts can help out. But really one only has to be motivated and willing to work with others <singpolyma>I think the ramp from "sends patches" to "reviews patches" is not clear. I assume it involves having a lot of patches accepted first <lfam>Well, that's the guideline for commit access. Anyone should feel free to review patches if they know how to apply and test them <lfam>Of course it helps a lot to combine review with committing <singpolyma>> As a rule of thumb, a contributor should have accumulated fifty (50) reviewed commits to be considered as a committer <lfam>Once you get going, 50 is a small number :) <singpolyma>lfam: well, but it can take several months to get one in, so 50 will take awhile I expect :) <lfam>Hm, that's a bad situation for the patch queue <nckx>apteryx: Wow, really? That's surprising! I've no opinion but that must confuse a fair share of new users wondering where half of their drive went. <apteryx>Sorry, it's -d dup (just the metadata) <apteryx>so probably it wouldn't have helped here <lfam>But, on the other hand singpolyma, I'm not really reviewing patches right now <nckx>Anyone is welcome to review patches. There are no conditions as long as your reviews make sense. <singpolyma>nckx: sure, but a review from a non comitter only helps if changes are needed I guess. A comitter still needs to review eventually <singpolyma>Though since most feedback on my patches ends up being "this is not a complete sentence" maybe I can write a robot to do that part, haha <the_tubular>But, even when you don't thinkg about guix in particular. I don't know much about Nix, but I feel it isn't as popular as it should be. <nckx>True, but it really helps if the patch has been workshopped so the 'committer' only has to review 'privately' & sign off, not wait for another reply cycle. <lfam>We can't underestimate the impact of poor hardware support <apteryx>singpolyma: yes, but having a 2nd opinion is very valuable, no matter what <nckx>singpolyma: It sounded like you got the impression that reviews aren't welcome before you have commit access. If that's what people think we have a problem. <apteryx>properly auditing the license is not too difficult but time consuming, for example <nckx>Review-wise we have several problems. <the_tubular>And also, another point. I feel like a lot of people are submitting patches for new packages, but I really don't see activities with people writing services to configure the said new package <singpolyma>nckx: "not welcome" might be strong, but I did not get the impression that submitting reviews was something you should self-select to do since that's pretty unusual across other projects I participate in <singpolyma>the_tubular: well I can't use services (not using system) so I only write packages it's true <the_tubular>I wasn't even thinking about that ... singpolyma that's a totally fair point <singpolyma>If I start using guix home I may try to add stuff there <the_tubular>Guix home is a good feature that could bring new people on the ride :) <singpolyma>nckx: so your idea would be something like "if you have some patches in enough that you can tell this package in debbugs feels off go ahead and reply with your impression" ? <singpolyma>Also, I don't want to sound complain-y. I've gotten waaaay more stuff into guix in 6 months that into Debian in 15 years, so could be worse ;) <apteryx>maximed: did you have something more to add to #54235 (sysbench), or was it good to go? <nckx> singpolyma: To be frank, that was my unquestioned impression of the status quo. I see enough fresh names and 'I'm not a committer but...' mails that I didn't think much of it. <singpolyma>nckx: since I don't know who "the names" are very well it's not always clear to me a review is from a "fresh name". Though a couple times there has been a review by one person asking for changes and later someone else comes and comitts it before I got around to changing, so that's probably what happened. <nckx>Saw one such today, in fact. I'll explicitly reply 'no, that's fine, great even, thanks' from now on. <nckx>singpolyma: Well that's not great either. <nckx>Unless you mean they made the changes for you. <singpolyma>Sometimes they make changes for me, but not usually the same changes, heh <singpolyma>Not unusual for reviewers to have different opinions on things IME <nckx>That's a pity, reviewers shouldn't ignore each other, at least address those differences. <apt9>Hello all. A month or two ago, I heard that Guix was going to simplify package definitions soon, so I decided to wait for an update before doing a deep dive. Is an update imminent, or should I just go ahead and learn the current version? <singpolyma>apt9: it's always evolving but no time to learn like the present <nckx>The biggest change has been made apt9 . Not all packages use the new style but just ignore them, they're stupid. <nckx>No offence dumb-package[m]. We weren't talking about you. *the_tubular is confuzzled <apt9>nckx: Hmm. So this would be on the latest image? <singpolyma>Right after you use a installer you run guix pull to get the newest version <apt9>singpolyma: I meant the development image rather than the 1.3.0 image, but I guess it's more fluid than I realised. Thanks for the tip. <singpolyma>apt9: a recent dev installer probably has it, but I still recommend running guix pull *apteryx summons current-guix/prebuilt to help with debugging install tests more nimbly <lfam>apteryx: On commit, 62fd3cf5b76cd4c5ce460704bcdd549c1f2077dd, the installed-os system test passes for me <apteryx>OK, I'm running them on a 2nd machine now <unmatched-paren>a code peer-review tool for email-based projects would be really, _really_ good for guix <singpolyma>unmatched-paren: isn't the peer review tool for email based projects just... a mailing list? <apteryx>lfam: OK, it passed on the 2nd (faster) machine <apteryx>perhaps just the timeout on the file to appear (10 s); I'll try raising that <apteryx>good news, boot from a raid10 btrfs array works, according to a new system test <apteryx>so the berlin boot issues are probably caused by the RAID controller somehow <maximed>apteryx: I haven't looked much at the source code of sysbench & ck, but otherwise looks good <maximed>would be nice to eliminate the global undocumented %build-inputs in favour of #$/#+(this-package-(native-)input) or the like, but that's a separate thing <maximed>you might want to verify that changing docbook-xml-4.1.2 doesn't cause too many rebuilds though <apteryx>maximed: thanks for the feedback; good call on docbook-xml; it has 2463 indirect dependents <apteryx>which makes it core-updates material <maximed>apteryx: it's about the same order of magnitude as the 'staging' branch (up to a small factor), so maybe 'staging' (or a temporary 'ck-sysbench' branch) would be appropriate? <maximed>I mean, the staging branch hasn't seen much activity and the numbers are more rough guidelines. <apteryx>maximed: about having to tune the #:tests? argument to disable them when cross-compiling; isn't that always the case (that tests are disabled when cross-compiling?) <maximed>apteryx: For all build systems, tests are run if and only if #:tests? is #true. <maximed>For most build systems, #:tests? is #t by default (when compiling natively) or #f (when cross-compiling) <maximed>This default is overriden by whatever's in 'arguments' <maximed>Now, more concretely, suppose you want to cross-compile an emacs package (emacs-foo). <maximed>emacs-foo comes with a few tests that were enabled (arguments (list #:tests? #true [...])) <maximed>The build-system has a default #:tests? #false (because it's emacs-build-system, and even if it weren't, we are cross-compiling). <maximed>But the default is ignored, because emacs-foo explicitely sets #:tests? #true. <maximed>So when the 'check' phase is run, it notices that #:tests? is #true, so it tries to run the tests (even though we're cross-compiling!) <apteryx>perhaps longer term we should handle this in build systems instead of as default values? <apteryx>so that having to know to handle this with care wouldn't be needed <maximed>apteryx: Do you mean something like letting 'check' inspect the 'target' argument, <apteryx>yes; would that be possible (for core updates) ? <maximed>and not run the tests when target is not false? <apteryx>weird, when I apply the patches using 'git am -s', I see: bug#50299: [PATCH v5 13/24] gnu: ruby-ffi-rzmq: Respect #:tests?. (e.g. "bug#50299: " appear in there) ***jonsger1 is now known as jonsger
<maximed>apteryx: I think 'git' bases the first line of the commit message on the 'Subject' header of the e-mail <apteryx>ah, so perhaps it's due to emacs-debbugs ***roptat_ is now known as Guest5602
***irfus- is now known as irfus
<apteryx>maximed: for your info, in the future I'd group same-package/same-scope changes into single commits; it's easier to handle