<retroj>davexunit: okay.. i tried including that as an input, and the configure script still reported not finding javac
<antelopeal>Hello. I'm trying to port a package to guix but the problem I am running into is that during the build phase make cannot find "cc" while the configure phase can find gcc and I don't know how to make cc point to gcc.
<retroj>antelopeal: sometimes you can set the environment variable CC=gcc
<retroj>depending on whether the Makefile in question supports it, in arguments, #:make-flags (list "CC=gcc")
<antelopeal>Oh the kernel config is fine. I guess now begins the hard long road of debugging to make sure it works.
<catern>hello, I am curious about your distribution design opinions #guix. guix is in favor of the distribution model, where package definitions are centrally maintained. but is there any case in which it would be better to have package definitions maintained by individual software-writers? like... I'm thinking about the ideal situation for GNU... wouldn't it be ideal for the maintainers of GNU software also to be the maintainers of the guix
<antelopeal>Is there anyway to set a store binary to be suid? or do I set a binary to be suid during build phase in my scm file?
<bavier1>catern: at this point Guix hasn't published an external API for its package definitions, so it would be burdensome, as we adjust out internal APIs, to communicate and coordinate those changes to external package maintainers
<bavier1>catern: some people do already maintain their own package definitions outside's guix's repository, and Guix supports this through GUIX_PACKAGE_PATH
<antelopeal>Does anyone want my firejail scheme file? The program builds but there are several issues with the binary and I don't know how to proceed debugging them to get the issues resolved.
<catern>having package definitions maintained by one group lets you avoid exposing a stable package definition API. though, OTOH, having package definitions maintained by individual maintainers kind of allows maintainers to avoid exposing a stable building-their-project API... I wonder if that's useful?
<brendyn>Would it be possible to make a GuixSD iso that runs on OpenStack? If I can get Guix on an OpenStack VM I can setup a buildserver on the supercomputer at my University
<jmd>Well yes. I don't object to small updates happening too.
<ng0>I for one missed beginners sections on writing services... packages are clear enough, many many examples, but when you start with services you are on your own
<jmd>Also I think there needs to be a lot more index entries.
<ng0>and it can't be a one person work because it needs review and shouldn't take a year or two.
<ng0>I don't know where I would put "if you move around stuff from one module into another, please respect past copyrights and move those too accordingly to what you move where". Contributing > Submitting Patches > seems like the place where people should check..
<jmd>I think it should be directed by one - perhaps two people, with input by others. Those people can delegate chapters, or sections to other people.
<ng0>that's not even contrbuting, that's also reviewing, because reviewers have failed to see it in the past too
<jmd>Otherwise what we get is your typical wikipedia article.
<ng0>reminds me that I wanted to translate the article on convivenza which I think can be useful for us
<quigonjinn>jmd: i did system init with "--no-grub" and it finished, but grub was apparently installed correctly from before (with wrong grub.cfg). I booted from external grub and it worked.
<jmd>quigonjinn: I'm glad you got it working. Maybe there is a bug in how grub.cfg gets generated. I don't know.
<ngz>Hello. I have a question about a package I'm writing. This package has an hard-coded expectation to find files in /usr/share/package which I cannot modify. This is probably not a problem on GuixSD but it sure is with Guix on a foreign distribution. How can I force the package to think /usr/share package is really .guix-profile/share/package ?
<ngz>You can probably inspect the image from squeak and see the source code, but I don't think you can modify it using traditional tools.
<ngz>But then again, I don't know how development is done with Smalltalk.
<kyamashita>ngz: If you're talking about the current MIT Scratch (https://scratch.mit.edu), it appears to depend on Adobe Flash, notorious for being proprietary *and* insecure. Where can I find a Squeak image of Scratch?
<ngz>kyamashita: I'm talking about Scratch 1.4, which is distributed with Debian, Parabola...
<kyamashita>Parabola doesn't seem to have source code in its build tree for scratch. That's certainly odd. Let's look at Debian...
<doncatnip>whats the best way to replace guix with my own guix branch on guixsd ? would make install suffice ?
<kyamashita>doncatnip: I suppose you could try writing a package definition for your branch of Guix, using your source code in the definition. I haven't done that yet, so I'm not sure how to help specifically.
<kyamashita>doncatnip: I don't think make install would work, because Guix's store files are immutable unless you use Guix to change them around (installing, garbage collecting, building source packages, etc.).
<ngz>Basically, the so-called image is really squeak source code.
<ngz>That is what I thought: "The Squeak programming environment will start up, allowing you to view and modify the Scratch source code."
<kyamashita>ngz: I see. And everything I've seen related to these two has been free software, at least at a glance. I don't see a problem with packaging the tools to manipulate these files if they're free software and buildable by Guix recipes.
<kyamashita>*package definitions, not recipes. I've yet to eat breakfast. :-P
<ngz>Good. So I'm no longer and evil packager trying to introduce blobs all over the place ;) So back to point 1, is there a way to work around the /usr/lib hard coding besides providing my own scratch image file?
<kyamashita>ngz: Oh geez, I'm looking at the image file now. I can see the issue. X-D
<kyamashita>ngz: We'd definitely have to build our own image file, from the looks of it. It does seem to be a bootstrapping problem.
<kyamashita>I just opened it using the GNU "less" command-line utility. It appears to be mostly binary with some text in there.
<ngz>Ah. I thought you were opening it using Squeak
<rekado_>re Scratch: at the Coderdojo Berlin I'm always pushing for "Snap!" because it's written in JS and doesn't depend on Flash.
<kyamashita>But then our problem would be solved! ;) The best way forward I see is contacting the Lifelong Kindergarten Group at MIT to see if it's possible to build a custom Scratch image like you're specifying.
<brendyn>Hmm, seems I can't get GuixSD on the network without iptables
<kyamashita>ngz: I share the "avoid GitHub" sentiment. Hopefully this will be a useful effort.
<ng0>so i package something where the make test runs a test with an enormous long wordlist, maybe not even long, but hashing the results takes very long, I think it will run for some more hours on my buildserver, should I just disable the test in this case?
<ng0>the README is a mimicry: 'If make succeeds, you might want to run a simple functionality test/demo with' :D
<ng0>StefanX2ovic: I think you could take a look at the gnu/packages/games.scm, there are some applications with multiple source files, if it helpsyou. i have not used this in practice yet, so I personally can't help
<kyamashita>I agree. In the worst-case scenario, we can just make the license field more specific later. You're welcome.
<ng0>recently when I pointed out to someone and they added a make check which just calls the original make test, I was wondering if our gnu build system should try for make test and make check.. this seems to be very common test instead of check
<cbaines>I guess I need to recompile guix more frequently
<cbaines>I'm running: guix environment --pure --container -N guix -- sh -c "./bootstrap && ./configure --prefix='/' && make -j4" after doing a git clean -dfx and that seems to work ok, but is there a better way?