<aeva>is there a way to try to install an older version?
<lfam>aeva: Yes, you can try installing it from a Guix Git commit older than HEAD. I reviewed the package, and it did build when we added it. But, you would be missing any security updates in ledger's dependency graph if you did that
<lfam>Since both failed tests are related to time, and tzdata is a dependency of ledger, I wonder if it needs a newer tzdata package, if there is an issue with your clock, or if the tests simply "expired". I see code that deals with time expire all the time. It's really annoying
<lfam>Our tzdata is not the latest version. But we shouldn't update it on the master branch since it would require ~900 rebuilds.
<aeva>which one will help me figure out why I don't have any money faster? :D
<lfam>I'll update it on core-updates if it's not already there. You could try building ledger with that commit.
<lfam>Personally, I don't need an accounting program to answer that question ;)
<efraim>i don't think tzdata has been updated on core-updates
<lfam>Most installations of Guix will have a localstatedir of '/var'. You will want to use the same localstatedir
<lfam>Okay. First, clone our Git repo. Then, use `guix environment guix` to put all the Guix build dependencies in your environment. Then, `./bootstrap && ./configure --localstatedir=/var && make`. Afterwards, there will be a script called 'pre-inst-env'. It makes it easy to use the Guix you've just built: `./pre-inst-env guix build hello`
<lfam>So, to use some commit, check it out and then use the 'pre-inst-env' script
<lfam>Please let me know if that doesn't make sense
<aeva>I think I'm going to have to do this on someone else's machine for now - I think I need to fix my budget before I have the spoons to try to do this the right way >_> I appreciate your trying to help me a lot though
<mark_weaver>building guix from a git checkout is not much harder, although it takes a bit longer. "rebuild the entire package manager from scratch" definitely makes it sound much worse than it really is.
<mark_weaver>on another note. why do test suites *suck* so badly?
<mark_weaver>an inordinate amount of my time is spent dealing with poorly written tests that fail intermittently, depending on the load on the machine, or the time of day, or fail on some platforms, or with newer versions of dependent libraries, etc.
<lfam>Okay, I guess the problem is with beginning execution itself. This is the end of my knowledge. But anyways, GuixSD does not claim to support execution of binaries built for other systems. I've done it with Go binaries, but those are basically statically linked and self-contained.
<lfam>Maybe it's worth trying to package eclipse for Guix
<lfam>I'm sure that error message is misleading, btw
<lfam>I've seen misleading "No such file" messages in several cases
<lfam>schumaml: In general, we make it work on our end. Sometimes we do find broken upstream build systems, and we try to help the upstream project fix it. But typically not. We (and Nix, who use similar techniques) have thousands of packages, and we couldn't do it if all the upstream projects had to adjust to us
<jmd>schumaml: I left #gimp just now, because I didn't want to participate in an argument. I don't want to participate in one here either.
<lfam>I don't know what happened in #gimp, but I don't want there to be a bad relationship between us and gimp. I hope we can provide a great gimp package.
<schumaml>nah, I was pretty sure that everything would be like you have just confirmed
<lfam>I will say that application plugins typically require a little extra from our packaging.
<kyamashita>I'm updating my GIMP installation right now. We'll see if everything is in order.
<lfam>Now, sometimes upstream projects use build systems that make it very difficult for us. For example, they hard-code assumptions about the filesystem hierarchy rather than using a proper build system like Autoconf, Python setuptools, cmake etc. But that's rare, because software developers typically don't want to spend their time rolling their own relatively half-baked build system from scratch.
<schumaml>lfam: a summary of the discussion in #gimp would be: jmd didn't believie that it could be a task for guix to make this work, and I disagreed
<jmd>schumaml: That is a total misrepresentation of what I said.
<lfam>I think that when computer programmers disagree on the internet, it's usually a consequence of poor communication, rather than a real technical problem.
<rekado_>seems to be “unstable” – it depends on an “unstable” webkit release.
<kr2>Hello, to configure X11, do I have to add (slim-service #:startx ...) and remove the slim service from %base-services, via a filter for (not (equal? 'slim (service-type-name (service-kind service)))), or is there a better/easier way to do this?
<lfam>random-nick: I would read "Nix: A Safe and Policy-Free System for Software Deployment" by Eelco Dolstra et al, and then "Functional Package Management with Guix" by Ludovic Courtès. Those papers will introduce you to the functional packaging model, and clarify some of the improvments made in Guix
<roelj>But then there's no load balancing across mirrors, is there?
<lfam>roelj: I'm suggesting you use their load balancer, which is what our mirror system does.
<lfam>Our system only uses the mirror list if their load balancer doesn't respond
<lfam>I think we should not puch much energy into our SF mirror system right now. I want to wait and see if they change everything again. As I said, their support claimed that *no* changes had been made. So, it seems like they are disorganized, and I don't want to put more energy into riding their wave of chaos
<lfam>I don't have a clear or precise reason. If they want us to package a Git commit, that's their choice. But all the different distros will end up packaging different commits, which seems suboptimal.
<lfam>It will become harder for security advisories to announce which versions of the software are okay, since hashes are not something that sort chronologically
<lfam>Or logically. It doesn't make sense to sort hashes at all
<roelj>Maybe something along the lines of: A developer (hopefully) puts thought and care into making a release, marking it as a definite point to build on. Developers generally do not put the same care in git commits, because bugs introduced in them can easily be fixed with another commit, or worse, by amending a commit (changing its commit ID).
<lfam>I think we should just package the latest commit. If it's broken, we file a bug report.
<ng0>i know libtoxcore $head works, because that's what my patch uses ;)