<mark_weaver>(we should rig our default 'check' phase to search for and print **/test-suite.log in event of failure) <mark_weaver>if you pass -K when building, it will be left in /tmp/guix-build-* <mark_weaver>but it would be nice to have that information available in hydra's build logs <mark_weaver>especially for spurious test failures that happen only occasionally <mark_weaver>but also useful for architectures that developers may not have their own machines for. <mark_weaver>arranging for failed builds to leave things in /tmp in the absense of -K would require some deeper changes to how the daemon operates, and I'm not sure I want to give builds access to do that. <ng0>today i started packaging darcs because i wanted to checkout something which requires having darcs. however: how am I supposed to package chell? chell depends on options and options depends on chell oO <bavier>ng0: I think I solved that at some point a while back, but never got it merged <ng0>bavier: darcs? or chell? <bavier>ultimately, create a "bootstrap" package with one <ng0>I have most of the dependency graph packaged <bavier>ng0: some of the other ghc packages do something similar I think <ng0>mark_weaver: i don't know.. i went with what "import" gave me. <ng0>thanks, i'll look into it <bavier>ng0: see ghc-clock-bootstrap e.g. <bavier>ng0: thanks for working on it, darcs would be a nice package to have! <mark_weaver>ng0: sometimes, when two packages depend on each other but one of the dependencies is optional, we can do something like this: first build an initial version of package A, with some features disabled due to lack of B. Then build B based on the initial version of A, and then build a fully-featured A that makes use of B. <mark_weaver>ng0: e.g. look at the "cairo" input to poppler, in gnu/packages/pdf.scm line 83 <mark_weaver>cairo and poppler depend on each other, and that's how we handled it in that case. <ng0>or the rust-stage0 jelle created in addition to my rust <ng0>i can't really say i like haskell: Your branch is ahead of 'origin/master' by 17 commits and that's still 10 missing <ng0>i don't even know enough haskell to describe that one package which had no description and was just some files I could not describe. <ng0>so it's just commented now with ; It has no description <ng0>due to the lack of any readme or whatsoever <ng0>i think chell is optional. <ng0>so not optional. i'll bootstrap options <ng0>eh. i'm tired, what am I writing. nevermind. i'll figure this out somehow. <doncatnip>how to start a 32 bit system within a 64 bit install using guix system vm ? is there a parameter or do i specify it in the config somewhere ? ***sprang_ is now known as csprng
<mark_weaver>doncatnip: did you try passing --system=i686-linux to guix system vm ? ***frafra_ is now known as frafra
<doncatnip>no because there is no --system option listed when doing --help, i just now found it in the online docs, though :) <doncatnip>seems to work, but only with --fallback for some reason, at least it's building now <ng0>how can I build those define and not define-public packages to see if they build? set them define-public temporarily? <mark_weaver>ng0: you can do something like this: guix build -e '(@@ (gnu packages commencement) diffutils-boot0)' <ng0>i needto write this down.. sometimes you forget that the language used by the system is more flexible than what I had before, with the expresion builds etc <kete>I think I found a package to define: droid font :) <ng0>is haskell so funny that it allows building circles like that just for the pleasure of science? options depends: chell, chell-quickcheck. chell depends: options. chell-quickcheck: chell, chell-quickchell. I blame science. <OriansJ>Now the question becomes do I try to find a trivial lisp compiler written in lisp1.5 or do I simply give up that hope and simply do it myself? <doncatnip>meh i give up too .. 32 bit vm would of been a neat alternative to multilib but for some reason it pulls in inkscape on a lightweight desktop which fails its tests <doncatnip>correction: gsl fails as dependancy of inkscape <mark_weaver>gsl-2.2 and gsl-2.2.1 fail some tests on i686, and it seems likely to be a real problem, as opposed to a flaw in the test suite. <mark_weaver>sadly, it seems to be increasingly common for upstream releases to not work on i686 :-( <ng0>I'm not done with the dependencies of darcs i see.. but i think it's easier if I send the 18 dependencies I already did? <mark_weaver>inkscape is used to convert an svg grub background to png, and what's why it's needed here <ng0>or do you think everything+darcs in working state is better? <mark_weaver>if you run guix out of a git checkout, then you could simply revert the gsl update, or disable its tests, in your tree. <mark_weaver>it might be that I should revert the update on master for now.... <mark_weaver>this is really not acceptable to be unable to build systems on i686 <doncatnip>well as it stands it cant be installed with any graphical stuff on a 32 bit system <lfam>Revert and file a bug upstream <lfam>Even if they intend to drop support for 32 bit platforms, they can clarify it, and we can show the clarification to other upstreams that depend on gsl <doncatnip>there ought be a better way to "svg conversion" other than pulling in inkscape and all its dependancies <mark_weaver>doncatnip: long ago, I tried switching to using librsvg, but that failed to work on the SVGs we have. <mark_weaver>doncatnip: anyway, I just reverted the 'gsl' update on master. so, if you 'guix pull' again, you should now be able to build the i686 system. <doncatnip>aight :) but i need at least some sleep first <ng0>haskell is a dependency hell. <jmd>I have found gimp good for converting svgs. That too however is not without a lot of dependencies. <mark_weaver>gimp uses librsvg, so I guess it probably handles our SVGs incorrectly as well <mark_weaver>to be honest, I don't know if the problem is in librsvg, or in our SVGs <jmd>I'll try. Which svgs in particular? <mark_weaver>jmd: /grub/GuixSD-fully-black-4-3.svg from our guix-artwork git repo <jmd>Why do we have a separate repo for artwork? <mark_weaver>it does include our website. not sure if that belongs in the same repo as our code, dunno. <jmd>I suppose it was to reduce the time doing a clone. <lfam>You could also give a designer access to the artwork repo without giving them access to the main Guix code <mark_weaver>hmm, I just loaded that file with emacs, which uses librsvg, and it seemed to do the right thing. maybe it's fixed now, and I can revive my old patch to avoid using inkscape for this. <lfam>Interestingly, inkscape depends on librsvg indirectly, via gtk+-2 -> gdk-pixbuf+svg <jmd>Seems to look ok in Gimp too. <lfam>ACTION cheers for mark_weaver <mark_weaver>it appears to work now, so I can eliminate the requirements on both inkscape and imagemagick <mark_weaver>hmm, well, we may need to keep the 'imagemagick' dependency. I can't see to get rsvg-convert to scale the image to a desired size automatically <mark_weaver>I may end up using Guile's FFI to access the librsvg API directly <cehteh>is the offload stuff supposed to work? i am playing with it in virtual machines and it errors out <mark_weaver>the offload stuff does work. it's the basis for hydra, and several other people use it too <lfam>cehteh: Are your VMs read-only? <cehteh>btw 'guix build --no-substitutes hello' was the test <cehteh>i can offload/login as normal user right? <mark_weaver>cehteh: you need to create /var/guix/gcroots/tmp on the slave machine. it must be writable by the user that runs the offloaded builds. <mark_weaver>maybe the bit is missing from the manual. if so, can you email bug-guix@gnu.org about it? <cehteh>i thought the daemon handles that <cehteh>will do (but i am lame, i'll just post this irclog) <cehteh>should we have a 'default' offload user, perhaps as service definition?` <mark_weaver>I'm not sure. maybe post your thoughts to guix-devel? I have to work on something else now. <cehteh>i run into more errors now, but ok i send a note <cehteh>4:20am .. i take a nap and test this stuff tomorrow <twotwenty>in my guix I lack commands like find useradd ... <mark_weaver>the way to add users on GuixSD is to edit the OS config and re-run "guix system reconfigure <config>" as root. <efraim>It looks like scaleway has armv7 serverlets again, I'll have to grab one soon <twotwenty>is that the only way I can install software system wide to ? <efraim>there's not too much that you need to install system-wide, most you can install per-user <twotwenty>I get the logic of user environments vs systemwide <twotwenty>my question is can I invoke the guix command to install software systemwide <rekado>twotwenty: you can install software into a shared profile. <rekado>that’s what I do at work when we need to have the same set of software available for all members of a group. <rekado>guix package -p /path/to/some/shared/.guix-profile -i a b c <rekado>users of that profile only need to source the profile’s “etc/profile” at shell startup <cbaines>Any quick tips on mixing build systems? <cbaines>I'm trying to use the python and glib-or-gtk build systems together, and haven't quite worked it out yet <cbaines>The glib-or-gtk build system seems to just inject two extra phases, which suggests that mixing the two might work... <brendyn>My package does not have a .desktop file. Should I embed it in the package definition? There is one in the debian pckage, but it would probably take more lines of code to add that as a source and unpack it <cbaines>brendyn, would another option be to add it through a patch? <brendyn>I could make a patch, but it's I change so small I can't quite decide which is better <efraim>i think in some packages we generate one <alezost>cbaines: look at 'emacs-pdf-tools', I think it's the only package where 2 build systems are mixed (gnu and emacs) <civodul>cbaines: you would choose one build system, and then add phases taken from the other <brendyn>efraim: Is it customary for a project to provide it's own .desktop file? Should I simply add one upstream? <efraim>brendyn: if the upstream project provides the .desktop file then they can also take care of translations for it and other stuff <efraim>so yeah, in general its something they should be taking care of <brendyn>Right, this project has nothing of the kind it seems <brendyn>How would I go about adding it to facilitate translations? <jmd>brendyn: What we did for pspp was to have a script generate the .desktop file. That script contains the marked up strings. <brendyn>Btw, how can I utilise geiser with guix? Like how can I jump to the file with the definition of inkscape? <brendyn>or pspp. If I'm in Emacs and I want to jump to this pspp definition, how can I do that? <brendyn>It seems if I'm going to hack on Guix packages, it would be desirable for me to make Guix use my local git repo rather than load from the internet, and just use git pull <brendyn>jmd: You mean you did that upstream? <brendyn>I'm rather confused about how I'm supposed to deal with this <brendyn>There is no .desktop file in the original package. debian has one but they have not added it upstream as if it doesn't matter to them. I can hard code an English version but this does not seem the way to go <wingo>civodul: ^ pretty interesting; the internal/external distinction is interesting <jmd>brendyn: Well it's always hard, when upstream refuses to co-operate. But if debian is maintaining one, then can we pinch theirs? <brendyn>Ah I think I understand. Guix packages are using format which calls the synopsis to be embedded, and that will add language support? <brendyn>Well I do not know if they are cooperating or not <brendyn>One of their pull requests has been sitting there since June but there is I can't see if they ever tried to add a .desktop file <civodul>wingo: i don't fully understand the motivation; sounds like a bit of added complexity at first sight <civodul>but i'm not familiar with typical Cabal workflows <alezost>brendyn: in emacs you can use "M-x guix-edit" to jump to inkscape (or any other package definition). If you want to jump to your git checkout, use (setq guix-directory "/path/to/your/guix") <brendyn>Currently the problem I have is that I have made a new package file and modified local.mk, but I don't want to have to wait untill my additions finally get accepted untill I can use them myself <alezost>brendyn: you can use guix from your git checkout, see (info "(guix) Building from Git") <alezost>brendyn: you can use "C-x C-e" to evaluate it or "M-: (info "(guix) Building from Git")" <wingo>civodul: i think the motivation is having one build tool with the possibility of different optimization levels, building in-tree against some installed libraries <wingo>i think there's a gap in guix right now for in-tree builds <wingo>it could just be a gap in my understanding :) <wingo>cabal can dispense with autoconf also, which would be a nice thing... <wingo>you know, we could probably add a module to guix that could be the non-autoconf build system for guile <wingo>computing the build/etc phases based either on a manifest of some kind or possibly even automatically/conventionally <wingo>but now i have a guix question <wingo>which package provides "gs" ? <wingo>my ps2pdf invocation no longer works, after having upgraded guix <wingo>ps2pdf 2016-04-lwaftr-management.ps; <wingo>make: *** [Makefile:14: pdf] Error 127 <wingo> /home/wingo/.guix-profile/bin/ps2pdfwr: line 44: exec: gs: not found <civodul>efraim: you had add a patch to re-add 'gs' to 'ghostscript', right? <ng0>70 percent of darcs dependency graph is out (23 patches) <ng0>thanks for the info about git send-email, made this much easier. <ng0>now that I have thrown 23 more patches in addition to the 25(?) which still need reviewing and/or merge of myself to the list, who needs a review of their patch? <ng0>ah, new awesome patch. doncatnip, i'll review and test that <ng0>I'll follow my own complaining now.. at least 1 review per week when I can manage it <efraim>civodul: I might still have it around somewhere, I think I just added a phase to symlink gs to gsc or gsx or something <civodul>efraim: right; could you push it to core-updates before we forget? <civodul>and probably remove ghostscript-gs as well <efraim>+ (add-after 'install 'create-gs-symlink <efraim>+ (lambda* (#:key outputs #:allow-other-keys) <efraim>+ (let ((out (assoc-ref outputs "out"))) <efraim>+ ;; some programs depend on having a 'gs' binary available <efraim>+ (symlink (string-append out "/bin/gsc") <efraim>+ (string-append out "/bin/gs")))))))) <efraim>that's basically what my patch was <civodul>rather (symlink "gsc" (string-append out "/bin/gs")) <efraim>ah, I was symlinking to /gnu/store, that'll symlink to the same one, just where it "ends up" after pulling in ghostscript ***frafra_ is now known as frafra
***frafra_ is now known as frafra
***frafra_ is now known as frafra
<ng0>sneek: later tell civodul: it's not as user-friendly as a webbased solution, but it is something we already have and what could for us right now, later moving to something different when we have tested the other thing. <jmd>sneek: later tell sneek to stop talking to himself. <civodul>ng0: indeed, the ITP idea is a good one <sneek>Welcome back civodul, you have 2 messages. <sneek>civodul, ng0 says: it's not as user-friendly as a webbased solution, but it is something we already have and what could for us right now, later moving to something different when we have tested the other thing. <ng0>for the moment it works. i'm not satisfied, but it would bring some improvement. add to that some lines which encourage to review, like i wrote in som email i nthat thread, and we get a base for whatever we use at some point in the future. <jmd>Does a service automatically install its necessary packages, or does that have to be done explicitly? <ng0>the service defines the package in the service as far as i understand it? <ng0>when it is a service which depends on a package <ng0>but tor-service for example does this <ng0>there is a freedom of expression which makes writing services difficult to get started with <ng0>I see that I am too lazy for writing this email... I was asked about the current state of lvm, dm-crypt and encrypted GuixSD. /boot is no requirement, but all the rest should be encrypted with dm-crypt. <ng0>what are some people using here, leaving out libreboot, to achieve this? how do you do it? <civodul>jmd: Shepherd services have a 'start' method, which is a gexp, and this is usually where you refer to the package <jmd>Ahh. What does the #$ mean? <jmd>Where in that ssh example is it determined that sshd runs as the ssh user ? <civodul>nowhere; the sshd binary itself expect a user called 'sshd' <jmd>So I'd need a wrapper for a binary which didn't do that? <ng0>btw.. i've started work on gnunet-service as I'm stuck with git-service ***frafra__ is now known as frafra
<janneke>playing with jlicht's npm importer...nice <civodul>janneke: i've haven't looked in detailed yet, but kudos on getting android-tools + MinGWv2, BTW! <davexunit>janneke: I'm concerned that android-tools is using bundled dependencies. did you look into this when packaging? <janneke>davexunit: re android-tools: no, i was in fasted way to revive phone-mode <janneke>civodul davexunit: i expect quite some more work on android-tools to get it up to "distro-standard" <ng0>writing the basic gnunet-service was so much easier than git-service :) <kete>I'm so glad that eshell has tab completion for guix commands <jmd>How can I reconfigure a running system from a different guix source ? <lfam>jmd: You can do `/path/to/source/pre-inst-env guix system reconfigure ...` <lfam>It's just like using the 'pre-inst-env' script to build a package from a Git checkout <lfam>What went wrong? I use it all the time <jmd>lfam: I'll paste a stack trace <lfam>If there is a stack trace, I bet there is some ABI breakage in the built objects of the Git tree. Otherwise a mistake in the code <jmd>Wtf! paste.lisp.org doesn't accept general pastes anymore. <lfam>What do you mean? A general paste? <jmd>lfam: Seems to work. Thanks. <ng0>what do i need to pass to my qemu / guix system vm / so that it has network + can call outside? <lfam>ng0: With `guix system vm`, it should "just work" <lfam>For `guix system vm-image`, it should work if you follow the example in the manual, 7.2.14 Running GuixSD in a Virtual Machine <lfam>But, those examples only allow the VM to "call outside". The host cannot connect to the VM <ng0>i run it with a specific testvm.scm where I include the service i test. <lfam>There are more advanced ways to set up QEMU networking, but this seems to be the simplest way <bavier>there's a patch pending on guix-devel to upgrade and "fix" the ldc package <bavier>the fixing part I think should rather be to propagate llvm's zlib input <bavier>a better fix even would be to patch llvm's llvm-config to include -L flags in its output <jmd>Is there a way to recover /etc/config.scm after messing it up? <brendyn>If I need to split a package into several smaller packages, do I have to add the same source definition to all of them? It seems like a lot of redundancy. <bavier>brendyn: you can use (package ... (source (package-source other-package)) ...) <bavier>brendyn: or simply define a scheme variable for the origin that gets used in each package <ng0>eh... how am I supposed add something to the guix system vm .scm line? when i append -net default -net nic,model=virtio or just -net nic,model=virtio i get guix system: error: e: unrecognized option <brendyn>Hmm I'm not sure what to do. I'm not sure if I need to separate out sendpraat since it is a separate .c file. It doesn't even have a version number. Should it be a separate guix package? <lfam>brendyn: Are you referring to Ludo's request to unbundle praat's dependencie? <ng0>more or less i figured it out now, differently.. still having different problems. will be a while until I can post the service <brendyn>lfam: That, and also I noticed that The Praat source comes with an additional useful program called sendpraat which is from a single .c file, but is not compiled by default. I'm wondering how to handle that. It seems there is no reason this would be used on it's own so should I have my guix definition even further to include it, patch the make file?, or add it as a separate dependancy? I don't know <brendyn>(Sorry my English is broken at the moment since I'm tired) <lfam>brendyn: If it's useful, and related to praat, I would add a build phase to build it and install it alongside praat, in the same package definition <lfam>You can see a rough example of how to do this in the package definition of certbot <brendyn>How do I find the default build flags? <brendyn>I may only need to append one or two <lfam>I'm not an expert on the build systems. The gnu-build-system is defined in 'guix/build-system/gnu.scm'. <lfam>The default value of #:make-flags is empty <brendyn>I guess that makes sense since GNU packages just do configure; make; make install <lfam>I'm not sure I understand your question about the bundled dependencies from the mailing list. What is being suggested is to delete the bundled dependencies and try replacing them with pre-existing packages. <brendyn>I don't know how that is even possible ***tschwing_ is now known as tschwinge
<lfam>In the package definition of kodi, you can find an example of how to use an origin snippet to delete a bundled dependency. Origin snippets apply to the source code of the package. They affect what you get from `guix build --source foo`. <lfam>And, to add pre-existing packages as inputs, you simply add them to praat's list of inputs. Grep in 'gnu/packages' for 'inputs' for examples <brendyn>Yes but if I delete them I've deleted half the program and can't build it anymore <lfam>Try using our packages :) <lfam>And, to add pre-existing packages as inputs, you simply add them to praat's list of inputs. Grep in 'gnu/packages' for 'inputs' for examples <lfam>For example, the flac package, in gnu/packages/xiph.scm <lfam>Do any other distros package praat? Often you can copy their work if there are complications :) <brendyn>I'm not sure anyone understands what I'm trying to say. Praat statically compiles to a single binary. How can I possibly replace that with inputs? <lfam>Interesting, I wonder why. Hard to believe praat would modify the flac library significantly <lfam>Ah, I didn't realize it created a static output <lfam>I didn't see that in your recent message to guix-devel <brendyn>Yeah, there is not even a configure phase. I've picked the most non-GNU package ever :/ <lfam>Building against external libraries is not specific to GNU. Almost all of the Guix packages do this :) <brendyn>Ok, so how can I add a phase to compile this one .c file? Presumably I don't want to run (system* "gcc ...") <lfam>I recommend trying to unbundle what you can. And I also recommend saying on guix-devel what you said to me. That praat is designed to be a static binary, with no dynamic linking, and that Debian does not unbundle FLAC. You might also want to dig in to Debian's packaging to see what they've done. <lfam>Does the makefile address it? <lfam>If not, it might be possible to add a line to the makefile to build it <brendyn>Well It seems I can do this two ways: I can edit the source make file to compile sendpraat, or I can add a custom build phase in scheme <lfam>If you edit the makefile, then you will have a patch to send upstream :) <lfam>It's nice to help the other distros by sending improvements upstream <ng0>that is when they accept it and you have the energy to discuss with upstream about patches.. <brendyn>Well upstream has chosen not to do this for some reason. They say on their site how to build sendpraat but neglect to put it in their makefile <brendyn>I can try. I mean I don't even know how. Presumably I need to make a github account and fork the repo <lfam>Are you familiar with Git? <brendyn>not really I'm just starting to learn it now <lfam>I notice that praat bundles espeak. I've tried packaging espeak, and it's very complicated. <ng0>i'm open to proxy patches via my github account, if they do not accept email patches. no need to create an account if you don't want to <brendyn>There are a lot of things that could improve. For example there is no internationalisation what so ever <lfam>So, I think it's okay to use the bundled espeak <lfam>Honestly, I would just try to copy Debian's choices. They usually do the right thing with respect to bundling <lfam>It looks like praat's modifications to the FLAC library are needed so that praat can avoid using a real build system, but I guess that's their choice <brendyn>I've been using debians package. Debian has their own icon and .desktop files which don't exist upstream. I wonder if they even tried to send them upstream? <lfam>Honestly, based on the choices of the praat developer regarding the build system, I wonder if they would be willing to accept "best practices" goop like .desktop files <lfam>But, you could try sending them upstream. It's worth a shot <brendyn>Well, lets just say for the current release I include them myself. I'd at least like to learn how to do this. It seems the only way this is physically possible If I include the debian source file as a source and extracte the files. <brendyn>Or a patch file containing the svg and desktop files? <lfam>I'm don't know if we have any packages that add .desktop files <lfam>Okay, I would copy what that package does :) <brendyn>.desktop files are plain text and can be embedded in a few lines, but .svg's are bigger <lfam>So, Debian created their own icon? <brendyn>Actually, I wonder if the svg is actually secretly hidden in the source somewhere <brendyn>No idea. The praat website has a .gif. I have no idea where the .svg came from <lfam>Our approach is a little different to Debian's. We try to provide the software with as few modifications as possible. Whereas Debian basically forks everything to create the most cohesive experience they can. <lfam>I hadn't considered the issue of icons, but perhaps they are creating icons too <lfam>You picked an ambitious first package :) <brendyn>I like the minimalism, but I don't want to make something dysfunctional <lfam>I don't have much experience with icons. That's a subject I don't have any advice about :) <brendyn>I have experience with nothing. I've never contributed to a project before <lfam>I wouldn't call it minimalism. We do try to configure our packages to be full-featured. But, we don't think that distros should do significant development of packaged software <ng0>we had/have packages which add .desktop files... and even one which assembled a .desktop.. <brendyn>Ok so how about I just package 6.0.19 as is with no icon , and then try sending the icon upstream to see it can be included in 6.0.20 ? <ng0>but i don't know names.. grep for what you can think of <brendyn>Was there any reason those packages chose not to send .desktop files upstream instead? <lfam>So, unless you want to contribute a real build system to praat, your package will include those bundled copes <lfam>For the rest, I would try to unbundle them by deleting them in an origin snippet and adding our corresponding packages to praat's list of inputs <lfam>And then, report your results to guix-devel, with links to those modification statement READ_MEs, and also to Debian's package <brendyn>So would these unbundled versions be separate packages available to guix package -i or simply scheme symbols available only in the linguistics module? <lfam>I bet we already packaged those libraries. You will need to import their modules into the linguistics modules, and then add them to an inputs field of praaat <brendyn>Yeah, and then I need to modify the makefile somehow? <ng0>..... is there no service which creates a 'real' /home/ng0 i could look at? I need .config etc to be present <lfam>Oh, I forgot about the makefile. I guess my suggestion is wrong, unless we rewrite the makefile. <ng0>damn client. replace /home/ng0 by $HOME <ng0>this is what happens when your irc client is a pipe. <lfam>brendyn: Okay, reply to guix-devel with a link to the makefile, those REAM_MEs, and the Debian package, and ask for advice. <brendyn>all the files are compiled, and then linked together. presumably, the guix version of flac etc needs to be able to frankstein together into the praat binary and magically work <lfam>Yeah, the praat developers made a choice that was easy for them and hard for everybody else. Oh well <lfam>See what the rest of the mailing list says <lfam>By the way, Nix packaged praat as-is, although they are a little less rigorous than us in my experience <lfam>At least about issues of bundling <lfam>I was trying to qualify my statement to be polite. <lfam>They are ahead of us in terms of hardening the distro, anyways :) <davexunit>several times I've had a problem, looked at Nix to see how they solved it, and realized that they just said "fuck it" <brendyn>Praat seems to work with hardening, but I neglected to add it as it seems Guix devs are going to make hardening opt-out ? <lfam>We haven't implemented anything with respect to hardening yet <lfam>So, nothing to add so far <lfam>Short of contributing a full Autotools build system to praat, I don't think we can do anything about the bundling <brendyn>Well I was hoping to go through life without learning C <lfam>Hard to be a computer programmer knowing no C at all, since almost everything is written in it :) <brendyn>I've looked at C and it doesn't make any sense to me <lfam>I don't think that praat will require you learn C <ng0>you laugh, you cry, you yell, you debug and debug and years later you have picked up bits and pieces of languages you never wanted to learn... <lfam>It's easy to learn to read C. That's often enough. Writing C is fraught with peril :) <brendyn>I learnt to read Chinese so I should be able to read C <janneke>i'm trying to add the node-gyp package/buildsystem to jlicht's npm <ng0> i think i need the patch which recently got to the list, where home-directory can be created in /var/lib/ <janneke>but now i get: ./pre-inst-env guix build node-gyp <janneke>ice-9/boot-9.scm:65:2: Throw to key `vm-error' with args `(vm-run "VM: Stack overflow" ())'. <janneke>i suspect some sort of circular dependency, how can i see/debug that? <brendyn>Ok so if the build command is: gcc -std=gnu99 -o sendpraat -DUNIX `pkg-config --cflags --libs gtk+-2.0` sendpraat.c <brendyn>What do I need to add to the makefile to make that happen? <lfam>janneke: Looks like it. I'm not sure of the best way to debug it. I've used `guix graph foo | grep bar` to see if bar is in the transitive dependencies of foo. That's for cases when I know that bar depends on foo <lfam>brendyn: Try adapting that example in the certbot package definition <lfam>Well, that's what I would do. I know it doesn't involve editing the makefile <janneke>lfam: thanks...i was hoping for some verbose flag that would print all visited packages... <lfam>janneke: It may exist, I'm no expert <lfam>janneke: My introduction to Guile was when I made my first Guix package, only 1 year ago :) <lfam>I'm still very much a beginner <janneke>my (client's) project has "only" 40 toplevel npm dependencies <lfam>Glad to hear they are a client :) <janneke>that expand into "only" 281 leaf packages <lfam>You should "just" package them all ;) <janneke>it turns out that some of these packages need node-gyp to build <janneke>and people still think node/npm is so much easier than guile... :-/ <lfam>Somebody should make an NPM fractal viewer, written in JS <lfam>Fractals of dependency graphs <lfam>Because that's what this sounds like <janneke>now i'm starting to wonder how many of the 281 leaf packages actually need another build system ... :-) <brendyn>is there an image viewer I can pipe a png to instead of having to make a file/ <ng0>and it should be written in assembler <lfam>brendyn: I have wondered this myself <brendyn>Maybe there is a program that recieves stdin, writes a temp file and opens a command with that file? <lfam>Sounds like a case for a shell script :) <janneke>haha, now i have a package: node-assert-plus that has a Makefile, which invokes `npm install' <brendyn>Amazing. Praat only has 6 billion trillion deps. Not bad. <ng0>I would call my build system 'everythingsucks', you would define dependencies with $name sucks, things you can not have are $name does not suck,... <ng0>execute it with \\make $makefile suck <bavier>now we just need to work on our power8 port ;) <brendyn>Do you think gtk will ever die and we can just have Qt? <bavier>wow, just looked at the talos specs. impressive <dvc>So does guixsd need anything special in the kernel config? <dvc>And I've found an issue with cross-compilation - I'm not sure if it's a bug or not <dvc>native-inputs and inputs are both available as #:key inputs when compiling natively <dvc>when cross-compiling native-inputs are in native-inputs but not in inputs <dvc>and when compiling natively native-inputs aren't in native-inputs <dvc>does that make sense? <lfam>As a non-expert on Guix internals, it seems to make sense to me <dvc>But this means that we need to write the same code twice basically once using inputs and once using native-inputs <lfam>"when compiling natively native-inputs aren't in native-inputs" is inconsistent, but it should work, right? <dvc>if native-inputs where in native-inputs that would work <dvc>it would be nice to remove them from inputs to force phases to work for both native and cross compilation <lfam>It's over my head. I haven't read this code closely. <dvc>but neither is the case currently AFAICS <dvc>;; Apply the neat patch. (system* "patch" "-p1" "--force" "-i" (assoc-ref native-inputs "patch/freedo+gnu")) <dvc>As an example native-inputs needs to be inputs when compiling natively, I think that's a bug <dvc>lfam: what to do? =) open a bug report? <lfam>dvc: Sure. I don't understand the issue yet :) <lfam>And I don't really work on that part of the code... yet ;) <dvc>in one case patch/freedo+gnu is in native-inputs and in the other case in inputs <dvc>or which part isn't clear? :) me neither... <lfam>I think you should file the bug report. My ignorance is not a rebuttal to your report :) <ng0>ouch.... i know why i can't test successfully... I create my VMs with a readonly filesystem in the config.scm. <ng0>of course gnunet can't download the hostlist this way <lfam>`guix system vm` always creates read-only systems. `guix system vm-image` creates writable systems <ng0>vm-image runs out of space when copying the files.. hm <brendyn>Turns out Praat has Windows and Mac icon files of a variety of sizes... <dvc>they are readonly because they are in the store <dvc>to make it writeable just copy the store path into a writeable location <dvc>and update the run-vm script accordingly <brendyn>ACTION needs to package libicns.... down the rabbit whole he goes <janneke>ACTION stumbles on a package that runs eslint <Pooff>Question: are non free firmwares really less harmful than non free drivers? <quigonjinn>Pooff: imo, both are hamrmful, it's pointless to argue which is worse. <brendyn>Well, firmware runs on a different chip to the cpu so it's sorta like hardware sometimes,... but not really ? <brendyn>sometimes the firmware is of critical importance since it may allow remote access even when the computer is off if there are backdoors <Pooff>well, some almost-free distros make a real difference between the two <Pooff>refusing closed drivers but accepting the firmwares <ng0>easier to audit, not automatically more secure, same like free software.. see most bugs like in openssl.. they are discovered but sometimes sit for years until they are discovered <Pooff>there should be a rationale for this <brendyn>Pooff: I think the main reason is that it is harder to give up on nonfree firmware because it is hard to get rid of them, and often really hard or illegal to try reverse engineer <ng0>also easier for researchers and students to learn on <quigonjinn>Pooff: as brendyn said, there are only a handful of computers that can run on free firmware <brendyn>giving up on nonfree firmware significantly reduces the amount of computers you can use, to like 3 laptops <ng0>RE is often illegal, which is why the recent FCC ruling is borderline stupid and dangerous to science and democraty <ng0>sorry, clarification: RE on drivers can be illegal depending on where you are <Pooff>openBSD accepts firmwares and they are very security focused <Pooff>do they think firmwares = no risk? <brendyn>Well either you need the firmware, or you aren't going to use them and they will just sit on the hard drive doing nothing? <ng0>if you go down *all* the way you see how deep the rabbit hole goes... there are papers on how incredible insecure everything is or can be we use, and how little is done in that regard and which exploits exist <Pooff>you could purchase only free firmware compatible motherboards, wifi etc <ijp>a computer that doesn't do anything is very secure <brendyn>I heard some people complaining about not being able to do things like Gentoo's USE flags. Is there a way to do that? <dvc>brendyn: not globally, but you can create a function that returns a package, taking *USE flags* as parameters <dvc>depends on the usecase <dvc>for the u-boot package we have a make-u-boot function <dvc>but I don't think there is anything wrong with it <dvc>if you create a package-name-configurable, but then alias package-name with some default values <dvc>on the security issue (non-free drivers vs non-free firmware) more free the better, but sometimes there's no other option... <jmd>If I wanted to take civodul's ssh service example and use it. What would I have to do? <dvc>which example can you post a link? <dvc>do you have guix running on whatever distro? <jmd>(third time today I've cut and pasted that link. I must define a macro for it.) <lfam>jmd: Make a file 'gnu/services/openssh.scm' in your source tree, and then you should be able to use it from your OS configuration <jmd>lfam: "use it from your OS configuration" - what does that mean? <jmd>(I've done the first task. and I've added it to local.mk too) <ng0>i can not test this any further.. i can assume, but I have the feeling the vm is too limited for what I need and I can't use my own system(s) for testing services. my experience with gnunet packaging tells me this is good to go for a general basis service... I'll add some more options, document, and send ot the list once the private stress i have currently is gone <lfam>ng0: The git-service? I can test it on my hardware later. I'm interested in using it :) <dvc>add (service openssh-service-type) to your services <dvc>see gnu/system/examples/bare-bones.tmpl for an example <lfam>We don't usually add the service-type directly to the services list, right? My knowledge is a bit weak <lfam>jmd: Hm, it might be missing the last piece, something like (define* (openssh-service #:optional (config (openssh-config)) (service openssh-service-type config))) <dvc>You'll also have to import gnu services openssh <dvc>lfam: there's no openssh-config ;-) <lfam>Yes, "something like" :) <dvc>it's not meant to be used <dvc>and I'm not sure anyone has actually "run the code" <lfam>Sounds like a good project for somebody to pick up :) <jmd>ice-9/eval.scm:393:14: Unbound variable: openssh-service <dvc>I'm busy and I think someone already has... :) <lfam>jmd: Right, it actually doesn't export openssh-service. That's the piece that I think might be missing <dvc>jmd: yep there is no openssh-service in (gnu services openssh) <lfam>Also, it should go in (gnu services ssh) :) <jmd>lfam: That code you pasted seems to be syntactically incorrect: <jmd>gnu/services/openssh.scm:41:0: source expression failed to match any pattern in form (define* (openssh-service #:optional (config (openssh-config)) (service openssh-service-type config))) <lfam>I expected it wouldn't work as-is, hence "something like" :) I would take a look at the lsh and dropbear services to get an idea of what's missing <dvc>lfam: meant take a look at the dropbear and lsh services =P <jmd>So reconfigure seemed to have been successful. However, after reboot, it seems to have done absolutely nothing at all. No entry in any log that I can see. No process running. Nothing. How does one go about debugging? <brendyn>Sometimes after I build a package, I want to try building it again but guix refuses to. How can I force guix to build it anyway? <lfam>brendyn: pass --check to `guix build` <lfam>If the package is grafted, I think you need to pass --no-grafts as well, or else it will just repeat the grafting operation <dvc>jmd: you shouldn't have to reboot. herd enable openssh-service and herd start openssh-service should do the trick <ng0>lfam: no, gnunet-service. git-service need input too. <lfam>ng0: Ah, I wouldn't know how to test gnunet-service <ng0>it's not posted. i am working on it. <jmd>dvc: Thanks for the tip. <jmd>herd: service 'openssh-service' could not be found <dvc>what does herd list-available say? <jmd>Usage: herd ACTION [SERVICE [OPTIONS...]] <dvc>I'll have to pull up the code again, but in the shepherd-root-service-type it should say what it's called <dvc>jmd: a little resourcefullness please xD herd help? <dvc>jmd: just kidding, had a couple of beers, not trying to be rude... <jmd>I had six last night so I'm not at my best. <brendyn>How can I list all files installed by a package>? <dvc>find $(guix build PACKAGENAME) <brendyn>That would work if guile didn't always spew out information about newer source files <lfam>That stuff should is spewed onto stderr. dvc's suggestion does work <lfam>In my opinion, the command line tools actually compose very well <lfam>You can do all sorts of tricks like that <brendyn>But that will result in the package being built if it is not installed <lfam>Either there is a binary substitute available from the build farm, in which case you can download the substitute, or there is no substitute, and the build farm can't know the list of files, because it hasn't created them yet. <lfam>Is there some way to improve this situation? <dvc>lfam: I don't think so, for that we'd have to predict the outcome of a program, and we can't even predict if a program halts so... <lfam>Maybe we could to Cuirass a feature that would send a list of files when asked <dvc>lfam: or did you mean without downloading the substitue? that would be possible <lfam>Maybe we could *add* to Cuirass <lfam>It would be possible, but is it implemented yet? <lfam>My involvment with the build farm and the Hydra server has so far been peripheral, but it seems like nobody from Guix has really stepped up to develop Hydra <lfam>I think we are all rooting for Cuirass now <dvc>well if you look at how many (regular) contributors we have, it's not that many. And there is so much stuff to do... <lfam>Yes, tons of stuff. A good reason to integrate the CI server into Guix rather than continue to rely on Hydra :) <dvc>I'm waiting for the day I can run cuirass on my own server. It's so annoying to have to wait for something to build... And if you change your branch to work on something else it sometimes screws things up :/ <dvc>Besides my laptop is running a temperature... <brendyn>Hmm what's the simplest way to rename and install some files. I seems like it would be nice if copy-file automatically made the relevant directories so we don't have to use (mkdir-p) all the time ***kelsoo1 is now known as kelsoo
<brendyn>There seems to be a lot of mkdir-p redundancy in package definitions 