IRC channel logs


back to list of logs

<lfam>A simple hack: OpenSSH built with LibreSSL instead of OpenSSL:
<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?
<lfam>Not as far as I know
<efraim>I assumed it did
<efraim>There's also opensmtpd
<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>sounds like a plan.
<jmd>I gotta go.
<jmd>hi all
<jmd>What does the "static-package" keyword do?
<civodul>Hello Guix!
<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.
<rekado>this slows me down a lot.
<efraim>is anything building now on the farm? according to 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
<civodul>so there's a number of queued builds for master now on
<civodul>efraim: ↑
<civodul>rekado: also, subversion is supposed to be available:
<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'
<civodul>efraim: we can add it if necessary
<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.
<rekado>didn't take much convincing.
<rly>rekado: it should also be possible to use both for some time, no?
<rekado>I haven't tried it.
<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
<civodul>which i think are good
<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: not yet.
<rly>civodul: so, I do want to manage things nicely :)
<civodul>got it :-)
<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>heh :-)
<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.
<civodul>just hasn't materialized yet :-)
<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>test-sigprocmask fails
<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>on systemd's future ability to run services in containers:
<civodul>anyone willing to write on using 'call-with-container' in a Shepherd service? :-)
<civodul>davexunit: this is for you ↑ ;-)
<civodul>"the goal is to move D-Bus functionality into systemd itself"
<civodul>Qubes promotes free BIOSes, for security reasons:
<civodul>that's good
<civodul>woow, in praise of free software:
<davexunit>civodul: it would be nice to have an abstraction where we can "containerize" any service
<davexunit>not sure how possible it is
<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.
<davexunit>that's true
<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>indeed, yes
<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
<davexunit>civodul: okay
<civodul>it could definitely manage them
<civodul>all we need to do is to spawn a separate shepherd process for the user
<civodul>when the system boots
<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?
<civodul>but anyway, that'd be interesting
<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
<davexunit>much thought needed
<civodul>so it'd need to be able to talk in something that's sort of a whole system
<davexunit>sort of, yes.
<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>civodul: yes, something like that.
<civodul>food for thought...
<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>Apteryx: glad you like it :-)
<civodul>i overestimated my abilities when i initially wrote "yeah all we need is to add a few lines in that file" ;-)
<civodul>but it worked well in the end
<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?
<civodul>lfam: we could ask them for HTTPS
<Apteryx>lfam: I'd say convince Savannah admins to use HTTPS
<civodul>they're very open
<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>yes, agreed
<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 :)
<civodul>lfam: bootstrapping issue in what sense? there's but it's not related
<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
<rekado>usually this will be /var
<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?
<Apteryx>or at least, anything useful?
<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
<bavier>to the latest guix version
<Apteryx>Oh. So it revert to using the guix "standard" version. OK. Thanks :)
<bavier>np, thanks for asking
<rekado>I can't seem to fix the HTTPS cert validation problem
<rekado>the daemon runs in an environment where gnutls is available
<rekado>the guix client does too
<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>urgh, that's not possible
<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 '' 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.
<sapientech>davexunit: okay awesome. fyi, when i try to build haunt from git, i get this:
<davexunit>hmm never seen that before
<davexunit>not sure what's going on there
<sapientech>anyway ill check back with any findings
<davexunit>all I know is that it doesn't happen for me
<davexunit>I use the guix.scm file for creating my dev environment
<sapientech>ill try that, one moment
<efraim>if I want to check if i'm on aarch64 in c/c++, I want '#if defined(__AARCH64__)' ?
<sapientech>davexunit: okay so getting issue w/ effective version of guile as 2.0 but i have 2.2 modules, this get resolved?
<buenouanq>I can't get gpg working with claws-mail like I used to - Anyone done this on GuixSD?
<buenouanq>gnupg@2 is not compatible with gnupg@1
<buenouanq>that's all it was
<bavier>interesting, sandstorm now can run without user namespaces:
<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
<ZombieChicken>Has anyone gotten GuixSD running on an ARM system?
<buenouanq>no, but I'm quite interested in that aswell
<buenouanq>would love to run this on a beaglebone
<civodul>new news!
<bavier>civodul: exciting!
<buenouanq>I won't be able to say I've touched the Guix server anymore though ( ._.)