<retroj>i want to see the build log for the ola package i'm working on, and the trick i recently learned isn't working. ./pre-inst-env guix build ola --log-file <retroj>this shows me a file that contains only one line: grafting '/gnu/store/<hash>-ola-0.10.2' -> '/gnu/store/<otherhash>-ola-0.10.2' <bavier1>retroj: the graft itself is built with an implicit derivation that gets its own build log <bavier1>which is perhaps not expected; I wonder if that behavior should be changed <retroj>is there a package that provides javac? <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>Does #:make-flags apply to makefiles not in the root if the source directory? <retroj>antelopeal: no. i encountered that situation with the program 'di'. the workaround was to set the CC environment variable, and use --environment-overrides <antelopeal>Thanks retroj. I was able to port a program to guix. :) Although I have to edit my kernel conifg, I was able to at least get it built and installed. <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 <catern>package definitions for those packages? <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 <catern>bavier1: ah, that is a good point <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 ***lashdu is now known as drtan
<efraim>and I just realized enlightenment has build profiles, 3 for "PDAs" and 3 for PCs ***frafra__ is now known as frafra
<ronny>hi, whats the reason for guix to redo the whole thing in a own language? <brendyn>Because many people think the new language provides good features <ng0>sneek: later tell efraim: regarding what I said about AmA on reddit, it seems possible. HackerOne and also some games company did a team AmA recently <ng0>sneek: later tell efraim: regarding what I said about AmA on reddit, it seems to be possible. HackerOne and also some games company did a team AmA recently <jmd>ronny: ?? We don't have an "own language"/ <ronny>jmd: as far as i can tell guile is used as base with domain specific libraries <jmd>Well there are some libraries, yes. But the language is pure scheme. We haven't changed that so far as I'm aware. <jmd>As I understand it, that was one of the design parameters - to, as far as possible, use existing languages so as to make it accessible to newcomers and hackers alike. <quigonjinn>When calling guix system init , I get an error when the installation gets to grub : grub-instal: error: disk 'lvm/guixsd' not found. How come grub is looking for lvm/ ? <jmd>I think its because lvm is partially implemented but not complete. <jmd>s/lvm/GuixSD installation on lvm/ <quigonjinn>I'm not using lvm though. Just a luks device on dev/sda1, which contains an ext4 filesystem <sneek>Welcome back efraim, you have 2 messages. <sneek>efraim, ng0 says: regarding what I said about AmA on reddit, it seems possible. HackerOne and also some games company did a team AmA recently <sneek>efraim, ng0 says: regarding what I said about AmA on reddit, it seems to be possible. HackerOne and also some games company did a team AmA recently <jmd>quigonjinn: What other partitions are on the disk? <jmd>But you have a /dev/mapper how is that? <quigonjinn>jmd: because /dev/sda1 contains a luks device, which when opened with 'cryptsetup luksOpen' appears under /dev/mapper/guixsd <jmd>quigonjinn: I don't know. I've not used luks <quigonjinn>jmd: I will probably try manual grub installation. But the error just seems weird. ***frafra_ is now known as frafra
<efraim>rage doesn't really work for me at 0.1.4, and it doesn't change with 0.2.0, so I'm going to bump it and I'll see about making it play videos with gstreamer later <brendyn>Why does git status show all the .po language files have changed, when I haven't touched them? <jmd>brendyn: Because they git merged when you do a build. <jmd>Try building out of source and you won't get that problem. <brendyn>I want learn how I'm supposed to work o Guix <jmd>I mean, your build directory and your source directory should not be one and the same. <brendyn>If I just install Guix, then I can't change Guix code <ng0>you can just git stash those files if you don't work on them <brendyn>But I have no idea how to make guix work as a REPL with emacs+geiser <brendyn>How do you normally separate build and source directories? Do you just pull the repo twice and somehow link them? <brendyn>I suppose I'll delete everything and clone it again <brendyn>Well I want to hack on Guix, but then I'll need some work flow of making changes and then getting them into the Guix running on my computer <brendyn>But it may take 10 minutes or so to make a one line change and then repackage everything manually and reinstall <jmd>brendyn: Are you on GuixSD or another OS? <ng0>is the contribution section of the manual not clear? how can we change it if it isn't? we're happy to work on that :) <jmd>So you have followed the advice in the manual on how to build/install from git? <brendyn>Just confused If I should use Guix-git from AUR or something else <jmd>I've no idea what AUR is. <ng0>building from git means exactly what it does, git clone the guix git repository <brendyn>Right I have that, but I can't build it in the same directory, right? <jmd>Well you can. But then you get that issue with the .po files. <jmd>For that, and for other reasons, I recommend you build out of source. <jmd>just change to another directory build there. <ng0>it's not clear to me as well <jmd>What I have is all my source files in $HOME and another directory called /Scratch where I do all my building. <brendyn>How do you make it build there? with some ./configure option? <ng0>tht part is clear, but i think it's about an example command for make on how this would interact with each other <jmd>cd /path/to/build/dir ; /path/to/source/dir/configure ; make <jmd>brendyn: There is no special option. It just works the same way. <brendyn>I see, so it uses the working directory <jmd>the current directory, yes. <jmd>what I often do (not just on guix, but on other work too is) /path/to/source/configure --prefix=`mktemp -d -p /Scratch/$USER` CFLAGS='-O0 -g' <jmd>I have a big partition mounted on /Scratch <jmd>All other directories are backed up, but as /Scratch tends to get big, it doesn't. <jmd>That must be run from the source dir. <ng0>I've just sent a patch for documentation. Hopefully this fixes future occurences of people trying to give introductions into topics and terms in descriptions which are far too long. <jmd>ng0: I think the entire manual is becoming due for an overhaul. <brendyn>Getting errors saying I don't have help2man, although it doesn't seem to be stopping the build <ng0>help2man is only required to build something in doc/ <ng0>jmd: we're getting there.. rewrite should be avoided. adding small bits and pieces times after time :) <ng0>i have not looked at it, but you need all the build dependencies for the daemon. <jmd>ng0: I disagree. There comes a time when the whole thing needs to be rearranged. <ng0>sure, but we can change parts and have less time wasted with rewriting <ng0>when rewritting happens <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. <jmd>ng0: That quote you pasted is not even proper english. <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 ? <jmd>ngz: That would not be appropriate either. <alezost>ngz: it is surely a problem for GuixSD as well. Usually such hardcoded things are replaced in a package phase <alezost>ngz: grep for 'substitute*' in gnu/packages for examples <ngz>That's not really possible as I specified. The path is hard-coded in an image file for a virtual machine. You can only edit it from a Smalltalk environment. <ngz>substitute* is not an option. <jmd>How was that image file generated? <davexunit>ngz: so there's a binary blob in your source code <ngz>I'm not expert on the question, but I think this is source code automatically converted by the virtual machine. <davexunit>if you aren't able to replace the string you want, then it's certainly a blob <ngz>IOW I'm not even sure there's a plain text file representation of the code. Again, I'm not a smalltalk expert. <kyamashita>ngz: That seems pretty blob-like to me, too. If it's just smalltalk "object code" (or something akin to that) with source code nowhere to be found, we might not be able to do much. <kyamashita>ngz: Though I'm also not too familiar with smalltalk, changing strings hasn't been hard in any language's source code that I've worked with so far. :/ <jmd>Well by definition, if it cannot easily be changed, then is is not source code. <ngz>I think it requires a Smalltalk environment to be "easily" changed. It looks like more like a bootstrap problem to me. <ngz>kyamashita: yes. I suggested a package squeak-vm on the dev list recently. <ngz>This image is really a squeak file. <davexunit>it *really* sounds like an unreproducible blob <ngz>I doubt that. The license is GPL2+ so the source code is somehow available. <kyamashita>And Squeak claims to be licensed under the "MIT License" and the Apache License, version 2.0. <ngz>kyamashita: I'm talking about Scratch (the image) not Squeak. <ngz>The problem is that Scratch (the software) is gpl2+ but distributed as a squeak image. <jmd>If it is gpl, then the source code must also be available. <jmd>So get it, and package that. <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... <ngz>2.0 is obviously out of question. <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>kyamashita: Debian uses the image file. Parabole uses Arch packages, which, in turn, uses the image file. <kyamashita>ngz: I see now. The Debian package description for squeak-vm talks about that. I wonder how the image file is built. <brendyn>When I boot guix, the screen seems to get spammed by [[^3 over and over. <ngz>kyamashita: you're talking about the scratch image right? Because squeak-vm image is a solved problem, AFAIU. <ngz>In particular paragraphs 5 and 6. <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. <ngz>how do you "look" at the scratch image file? <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 <ngz>rekado_: there is no offline version for snap!, is it? <kyamashita>rekado_: Answered my own question. Seems to be licensed under the AGPL. <rekado_>I haven't tried installing it. Don't know if it requires server-side code. <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? <kyamashita>paroneayea: I need to eat something. I think I'll do that now. *grabs fruit* How about you? <ng0>i think i started the build 30 minutes ago? it effectively hashes the onion names, I know when I generated my names that it takes time. <ng0>bah, not 30... might be 60+ now <ng0>scalion is better, i'll package this too.. this is just for fun as those are very small packages <kyamashita>ng0: Deceptively small, I guess. Hooray for hashing! <efraim>i have onionshare packaged, just need to finalize cleaning it up and getting the patches ready <ng0>he. i packaged stem just to do onionshare and than refocused on other things <ng0>one more things to cross off from the gentoo > guix todo list. thanks :) <ng0>I think i will skip the tests and add a note. this is nothing i want to block hydra with for days.. :D <StefanX2ovic>Hello, I am new to IRC and guix... and I have a question. <StefanX2ovic>How should I write package description for a font Open Sans, if I want to specify more than one source files? <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 <StefanX2ovic>I appreciate your help, I must go now but I plan to check IRC logs for alternative answers to my previous question. Thank you. <paroneayea>I hope we can get guix ported and running on ARM machines <kyamashita>paroneayea: Same here! When my Libreboot-ed X200 becomes unrepairable, that is likely to be my next machine if it gets the RYF certification. <paroneayea>kyamashita: the FSF seems confident that it will, they've already pre-endorsed it <paroneayea>it's also a great sign that ThinkPenguin is a sponsor of the project, and working closely <kyamashita>Indeed. It looks like good vibes from all sides. <paroneayea>there's a video out there somewhere, "Good Call, Bad Call, with Bob Call" <ng0>as a card it is affordable, wrapping a laptop around it is terrible expensive <ng0>oh... i remembered incorrect then, i thought around ~1000 <paroneayea>ng0: that depends on whether you buy it fully assembled :) <brendyn>It is just version 1. The future will bring <$100 ciruit board updates with better cpu, quad core etc <brendyn>It has to get off the ground somehow <paroneayea>if you buy the card and the parts they ship the whole shebang to you for $550. If you want them to assemble it for you, it's $1200 <paroneayea>gonna use it as a mini desktop or server or play machine. <kyamashita>ng0: In combination, I'd say they're expat licenses or derivatives of such. If all else fails, you could just use the noncopyleft license and refer to the LICENSE file. <ng0>non-copyleft seems like a safer guess than expat <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 <ng0>yes.. very often I had to replace check with just test <kyamashita>It might be worth bringing up on the guix-devel mailing list to see what others think. <ng0>yes.. I will do so later <kyamashita>ACTION ventured out temporarily to get more food <jmd>How should one set the upstream ntp server ? <cbaines>I get loads of messages like "note: source file ... newer than compiled ..." every time I run guix, it also takes a while to start, does anyone have any tips? <cbaines>I'm running guix from the source repository, and have symlinked to that from .config/guix/latest and I have built it (but I have pulled in git recently) <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? <davexunit>if you run 'git pull', run 'make' to build what has changed. simple. <davexunit>bootstrapping and configuring only needs to be done when you change the tools you use for building guix <paroneayea>ACTION shoots a short patch to fix a copyright/license violation in guix <davexunit>you aren't going to be installing it so it's extraneous <davexunit>and you probably want to use --localstatedir=/var <paroneayea>I think a lot of people aren't aware of this in the free software world <cbaines>davexunit, this is for guix when running on Debian, and I used the binary install which installs in to / and not /usr/local <cbaines>if I use guix as a library, and don't set the right prefix, I get errors with things like finding logs, as it looks in the wrong place <davexunit>anyway, you don't need to do all this work every time. just run 'make' after you change the source code. <cbaines>I've managed to get somewhere at least with trying to automate the packaging of PyPI, I think I need to get around to actually writing an email to guix-devel some point soon <davexunit>we have 'guix import pypi' for assisting with python packaging <cbaines>I'm trying something slightly more drastic, that can cope with multiple versions of a single project, work around dependency loops and infer test dependencies from build errors <cbaines>I've managed to get sentry (the error tracking system) building (with tests), but haven't got it running yet <cbaines>(even setuptools is build with tests, something that I think the guix package repository doesn't yet do)