<Apteryx>lfam: Is there no LibreSSH to match the LibreSSL project? <lfam>Apteryx: OpenSSH and OpenSSL are totally separate projects as far as I know. They just both happen to have OpenSS in the name <lfam>OpenSSH and LibreSSL are both developed from within the OpenBSD project <lfam>OpenSSL is not part of OpenBSD <Apteryx>I thought OpenSSL originated from OpenBSD as well? <Apteryx>By the way; are errors thrown during the build a show stopper or something which can be tolerated? It about these errors that xsltproc returns when I build the manpages of udisks: Error: no ID for constraint linkend: udisks.8. <Apteryx>It seems they don't have any impact; the manpages still get output. It only has to do with the validation of the docbook DTD; the links should point to valid IDREF but they aren't. <jmd>That is really a policy that the package itself decides. <jmd>An error is something which causes "make build" to return non-zero. <Apteryx>jmd: I guess "guix build" would fail if "make build" returned non-zero? <jmd>If it was using an unmodified gnu-build-system, yes. <jmd>- I meant to write "make" not "make build" - <Apteryx>jmd: OK. I'll send my patch to guix-devel, with the output so that it can be discussed and hopefully resolved by someone more knoweldeable with docbook. Otherwise, it's still an improvements as we will now have manpages for the tools bundled in the udisks project. <jmd>What does the "static-package" keyword do? <rekado>first day of building icedtea spent building subversion :( <efraim>that always mildly annoyed me, having to build subversion to build git <rekado>it’s sad that so many substitutes for arm are missing. <efraim>is anything building now on the farm? according to hydra.gnu.org everything's done <civodul>rekado: M-x guix-hydra-queued-builds does not list that many ARM builds <civodul>so it might be that the builds have been reclaimed from hydra <civodul>we had a guix-daemon misconfiguration that led to too many things being reclaimed upon GC <civodul>(essentially it was missing the --gc-keep-* options) <civodul>but otherwise, there shouldn't be that many missing substitutes now <civodul>also, evaluations were stopped yesterday while doing a GC <jmd>Is there a way to indicate that a package should not be built? that is to say, it is only to be used as a basis for other packages. <civodul>jmd: you could make it a private variable <jmd>The trouble is, the purpose of the exercise requires me to put the base in its own module. <efraim>oh, the cmake-build-system doesn't have substitutable? as an option <civodul>jmd: you could mark it as "hidden", with 'hidden-package' <efraim>i was thinking of using it with x265 so I could have yasm as an input for the tests, but yasm would make x265 cpu-specific <efraim>in the end it didn't seem worth it, i don't think most people use x265 as the command itself, more likely through ffmpeg or the like <efraim>just like how there's currently we have libx264 but not x264 <rly>What's the largest guix deployment that you know of? <civodul>rly: i think it's the one rekado is working on, on a 250-node cluster in Germany <rly>civodul: I have something cool working with Nix now, but I do find the Guix approach nicer in principle. <rly>civodul: having said that, Nix is already state-of-the-art, and trying to convince people to use Guix is I think one bridge too far. <rekado>it's also very nice in practice :) <rekado>I'm using Guix very successfully at work. <rly>rekado: it should also be possible to use both for some time, no? <rly>rekado: do you use nixops or whatever the guix variant is of that? <rly>I think the major disadvantage with Nix is that the development tools are non-existent. <rly>For Scheme they at least exist. <rly>Albeit often also of low-quality. <civodul>rly: the "equivalent" of NixOps for Guix doesn't exist yet <civodul>as for the development tools, there's Guile and Geiser <rly>civodul: not being able to use NixOps seems like a problem. <civodul>so i gather you're targeting a cluster where you have NixOS, not just Nix, right? <rly>civodul: I am currently just building Docker images. <civodul>and you use NixOps to populate them? <rly>civodul: so, I do want to manage things nicely :) <rly>civodul: in a sense, it's a bit of a Scheme vs Common Lisp discussion; both are better than using PHP. <civodul>to populate Docker images, we wouldn't need a full-blown NixOps-like tool <civodul>so we could provide a 'guix system docker-image' command that creates a Docker image of GuixSD <civodul>and probably that would kind of cover this use case <civodul>we've been discussing this possibility for some time here <rly>The code in Nix to create Docker images is not that complicated. <rly>In a sense, one can regard Nix also as a compilation target. <rly>(for configurations) <civodul>you mean Nix-the-language or derivations? <rly>Mostly the semantics, but I don't particularly care about the way those are formatted then. <rekado>tried to build diffutils from source on arm, but it failed :( <rekado>I think the success of building gcj is enough to justify the patches. Will send to guix-devel soon. <rekado>sneek: forget I think the success of building gcj <civodul>anyone willing to write on using 'call-with-container' in a Shepherd service? :-) <civodul>"the goal is to move D-Bus functionality into systemd itself" <davexunit>civodul: it would be nice to have an abstraction where we can "containerize" any service <civodul>davexunit: currently we have to explicitly use-modules the right thing, and add a 'call-with-container' <civodul>so the Shepherd itself doesn't know what's going on <davexunit>do you think Shepherd should know or that Guix that should create services that use call-with-container? <civodul>if shepherd knew about it, it could provide a nicer UI <civodul>like one that allows admins to list containers, enter them, etc. <civodul>OTOH, that we can do it without shepherd even implementing it is nice <davexunit>would require code duplication or extracting call-with-container as a standalone library that guix and shepherd depend on. <civodul>compared to systemd, we don't *have* to build things in the shepherd <civodul>we simply import the container module and get the feature for free <davexunit>civodul: I guess it's a matter of if we want containerized services only for GuixSD or for any shepherd user. <davexunit>one use-case is for containerizing user services for unprivileged shepherd processes. <davexunit>I know that several people, myself included, run additional shepherd processes as our own users to handle things like the emacs daemon, gpg agent, etc. <civodul>long-term, it's best to have call-with-container as a separate library that Shepherd can use <davexunit>which I think opens up a new topic: it feels like Guix should be able to manage these user services <civodul>all we need to do is to spawn a separate shepherd process for the user <davexunit>the current blocking issue is that GuixSD services are not written for unprivileged use. <civodul>oh you'd also want to reuse existing GuixSD services? <davexunit>but perhaps containers could be used to get around this. <davexunit>civodul: yes, and my main use-case is a better 'guix environment' <civodul>wouldn't that be a 'guix system environment' in a way? <davexunit>here's the scenario: to work on a ruby web application you not only need ruby and some libraries, you also need a running database server. it would be *great* if a better 'guix environment' abstraction could manage running these additional daemons <davexunit>people are using 'docker compose' to accomplish this today. <civodul>i know, but that needs some thought because 'guix environment' in inherently talking in terms of packages currently <civodul>so it'd need to be able to talk in something that's sort of a whole system <davexunit>this train of thought stemmed from others wanting environments to be more first-class <civodul>maybe we need <environment>, which would be half-way between <profile> and <operating-system> <davexunit>there is a lot of overlap with full GuixSD systems here, but I believe there is an abstraction to be found that will allow both to be described with the same primitives. <davexunit>I need to think about it more, or write a blog post with my thoughts that will help some concrete implementation strategies show themeselves. <civodul>that's definitely an area worth looking at <davexunit>I think it would be very good if we had this. it would be a direct replacement for 'docker compose'. <ng0>milkytracker is "broken" right now, they moved domains because they lost access to their domain. I'm preparing a patch right now <ng0>okay, done. I'll send the patch and I'll be away again <Apteryx>civodul: Nice workaround for bug 24703! <civodul>i overestimated my abilities when i initially wrote "yeah all we need is to add a few lines in that file" ;-) <Apteryx>civodul: Haha, yeah, seemed like it was tricky figuring out all the details! <civodul>yeah i learned about RTL and the machine description files <Apteryx>With this sorted, what will be required to "fix" affected packages, such as fontconfig? <civodul>as i wrote there, in the end we'll have to rebuild everything <civodul>but in the meantime, we can incrementally rebuild things <lfam>I wonder, is it better to try hosting our own Git repo, or to try persuading the Savannah admins to enable HTTPS? <Apteryx>lfam: I'd say convince Savannah admins to use HTTPS <lfam>Okay, I read the previous bug reports and have my responses to their questions / objections in mind <civodul>what we really need is the libgit2 bindings, though <lfam>Sure, HTTPS is not a panacea <lfam>But... it feels urgent to pick the low hanging-fruit <civodul>good thing is amz3` and OrangeShark have been working on guile-git, which makes me hopeful :-) <lfam>Yes, I've been happy to see the progress <Apteryx>civodul: Do you have an idea of how long it takes to rebuild the Guix packages with the current infrastructure? <Apteryx>civodul: nevermind, just saw your last post on the bug's thread. <civodul>lfam: do you want to email them to savannah-hackers-public@ ? <lfam>civodul: Yes, I'll hopefully have enough "down-time" at work today. Or else I'll do it late tonight. <lfam>There's no HTTPS bootstrapping issue for us, right? :) <lfam>I guess I could find out by trying it on my own server :) <Apteryx>I don't see the "pre-inst-env" script using latest git? Where should I look? <lfam>civodul: Right, I couldn't think of what the problem might be. But I hadn't thought of the gnutls bootstrapping issue, so I think my crystal ball is faulty ;) <lfam>Apteryx: That script is created when you build Guix from the Git repo <rekado>Apteryx: you need to first bootstrap and configure <lfam>Apteryx: Make sure to pass the right --localstatedir argument to ./configure <Apteryx>OK. I'll follow the doc more closely. Thanks <civodul>bah, i can't seem to use my email client properly today! <Apteryx>Is "guix pull" a wrapper over "git pull && ./configure --localstatedir=/var && make check" or something similar? <Apteryx>And, if I point my ~/.config/guix/latest to guix' git checkout, would a "guix pull" work as a shortcut to "git pull && ..." ? <Apteryx>civodul: Are you using emacs for mails? <bavier>Apteryx: 'guix pull' won't manage a git checkout for you <bavier>Apteryx: the ~/.config/guix/latest is used to look for guix modules though, so pointing it into a git checkout is possible <Apteryx>Does that mean that, when my ~/.config/guix/latest links to my git checkout, "guix pull" doesn't do anything? <bavier>Apteryx: it'll just overwrite the link, I think <Apteryx>So it'l rewrite the link to the same thing? <bavier>Apteryx: after a 'guix pull' ~/.config/guix/latest will point into the store <Apteryx>Oh. So it revert to using the guix "standard" version. OK. Thanks :) <rekado>I can't seem to fix the HTTPS cert validation problem <rekado>the daemon runs in an environment where gnutls is available <rekado>I use wrapper scripts that source an /etc/profile file of a Guix profile where gnutls and guile are installed <rekado>is there something else I need to set? <rekado>some environment variable to point at the system's cert bundle? <rekado>hmm, it should look in /etc/ssl/certs by default <rekado>could it be that the ca-bundle on this system is too old...? <rekado>how can I disable cert checking when using guix package? <rekado>I tried "--no-check-certificate" but that's not permitted <rekado>gonna revert the commit locally for now <rekado>tried setting SSL_CERT_DIR but that didn't helyp <rekado>always the same error: guix/ui.scm:1220:8: X.509 certificate of 'mirror.hydra.gnu.org' could not be verified: <rekado>ah, setting SSL_CERT_DIR in the daemon environment fixed it <sapientech>davexunit: getting Throw to key misc-error with args ("make_objcode_from_file" "bad header on object file: ~s" ("\\x7fELF\\x02\\x01\\x01�\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00") #f)Aborting. <sapientech>when doing `haunt build` after `guix package -i haunt` <davexunit>sounds like you have a mix of guile 2.0 and 2.1 modules <sapientech>davexunit: yes i think that may be the case. i have guile-next and guile installed from guix <sapientech>originally i only had guile-next modules in my path, and even that didn't work :/ <davexunit>the bug here is that haunt should have its load path set in stone. <sapientech>right thats what i assumed it should do. im now using guix environment and making headway <janneke>i could use some help to make the guile build deterministic <davexunit>sapientech: I need to learn how to implement it and get a new haunt release out. there are some things that are only in my git repo. <davexunit>I use the guix.scm file for creating my dev environment <efraim>if I want to check if i'm on aarch64 in c/c++, I want '#if defined(__AARCH64__)' ? <buenouanq>I can't get gpg working with claws-mail like I used to - Anyone done this on GuixSD? <bavier>oh, seems they now use something like guix-daemon <bavier>i.e. a root-owned process that creates sandboxes <buenouanq>why is export PATH="/home/$USER/.guix-profile/bin:/home/$USER/.guix-profile/sbin${PATH:+:}$PATH" or whatever not in .bashrc by default? ***Guest60422 is now known as sturm
<buenouanq>I won't be able to say I've touched the Guix server anymore though ( ._.)