<mark_weaver>ACTION finally pushed the faster grafting implementation to master <mark_weaver>cbaines: did you run 'make' in your guix source directory? <mark_weaver>cbaines: can you paste your OS config, and the error output, to a paste service? <mark_weaver>cbaines: also, what happens if you run "./pre-inst-env guix system build <config>" as your normal user? <cbaines>I've actually just done that, and it looks to have worked <mark_weaver>that won't actually switch your system to it, but it builds it anyway <cbaines>Just running reconfigure using sudo didn't work, but running build, and then running reconfigure using sudo worked <mark_weaver>because that reminds me of a known issue with Libreboot and newer kernels <mark_weaver>(I guess it would affect coreboot on some machines as well) <cbaines>I was trying to get the wacom package in to xorg, to get the graphics tablet I have working with Inkscape <mark_weaver>cbaines: btw, if you wish to always use the copy of guix that you built from source code (as I do), then there's a trick you can do to avoid the ./pre-inst-env <mark_weaver>cbaines: the trick is: make ~/.config/guix/latest a symlink pointing to the top-level 'guix' source directory. <mark_weaver>for each user that want to run guix and use that copy of guix <mark_weaver>for me, I make two of those symlinks: one from my normal user account, and one from ~root <mark_weaver>however, note that it's important to keep that source directory built and in working order. when it's not, 'guix' will not work properly. <mark_weaver>but if you get stuck, you can always temporarily remove that symlink <mark_weaver>(and when I say 'guix' will not work properly, I mean the 'guix' command. the other software in guix will continue to work) <mark_weaver>several guix developers, including me, have been doing that for a long time <jlicht>mark_weaver: this is very info to have :-) <mark_weaver>note that 'guix pull' will rewrite that ~/.config/guix/latest symlink to point to a freshly-built copy of 'guix' in /gnu/store <jlicht>mark_weaver: do you keep some (gc root) known working version of guix to prevent any issues with a broken git checkout? <jlicht>which you could link into .config/guix/latest when needed <Petter>Even I do it like this. Remember to do "make clean" and "make" after "git pull". <mark_weaver>jlicht: no, I don't bother with that. in practice, I don't find it difficult to keep my source directory in working order, and I don't need to run the 'guix' command very often. <mark_weaver>Petter: I find that I only very rarely need to run "make clean". <Petter>Oh. It failed the first two times without "make clean" for me, and so I generalized based on that. <balduin>@mark_weaver thanks for helping me yesterday :-) <balduin>@mark_weaver, I tested the use of options in the PKGBUILD file and it worked :-) <mark_weaver>balduin: you're welcome! I'm glad the investigation yielded fruit. Would you be willing to report this problem upstream, so that the AUR package can be fixsed? <balduin>guix is gnu software, but a package manager. What kind of packages can not or should not be contributed? <balduin>For example: Can skype, firefox or the atom-editor be contributed as package? <jlicht>balduin: skype: no, firefox: after rebranding and removing the non-FSDG matching parts <jlicht>heh, cool, atom-editor _seems_ to be released under a free license <balduin>@jilicht: yes, but Fedora, Archlinux and other distributions don't add it to their repositories. <balduin>@mark_weaver: you are the lead developer of guix? <mark_weaver>skype is definitely out. firefox would need some modifications to avoid steering users to non-free software (e.g. plugins and addons) and maybe some privacy enhancements. <mark_weaver>balduin: I'm one of the lead developers, but civodul and rekado are the maintainers. <mark_weaver>civodul is the principal developer, but he's on vacation now <mark_weaver>I'm not familiar with atom-editor, so I'm not sure about that one <balduin>@mark_weaver: debian replaced iceweasel lately with firefox-esr. I think they have been able to settle their differences. <mark_weaver>Debian is more strict than the GUN FSDG in some ways, and less strict in others. <mark_weaver>they are more strict in that they have more stringent requirements for non-functional data, e.g. documentation. <mark_weaver>GNU FSDG is more strict in that it requires that packaged software must not steer users to non-free software, and also must not include malware, DRM, or spyware. <mark_weaver>the GNU FSDG is not very long. I recommend reading it. <mark_weaver>we have GNU IceCat, which is a slightly modified firefox-esr, in Guix. Unfortunately, at present, due to lack of developer time, IceCat has not yet been updated to ESR 45. It's still based on 38.8, so it has unpatched security flaws and is currently not safe to use. <mark_weaver>at present, the best modern browser we have is 'epiphany' <mark_weaver>I agree this is not a great situation. There are discussions in progress to solve the developer issues with GNU IceCat <mark_weaver>I forgot that upstream Firefox now includes support for DRM. that would need to be removed before it could be included in Guix. <mark_weaver>So, if this is a problem for you, then I'm afraid Guix is not for you. <mark_weaver>I'm aware of that, but the GNU FSDG requirements are stricter, and upstream Firefox does not meet its requirements. <mark_weaver>also, it seems to me that even on the trademark issue, it fails to comply with clause 8 of the DFSG. <mark_weaver>so GNU IceCat is supposed to be doing the job of modifying Firefox to comply with our requirements. it just needs more help. <mark_weaver>anyway, on the plus side, it's quite easy to maintain local packages, or even arbitrary modifications to Guix itself. <mark_weaver>it's very easy to run Guix directly out of a git checkout. I myself always run Guix out of a private branch, with my own local modifications. I periodically rebase this branch on the upstream master branch. ***Digitteknohippie is now known as Digit
<mark_weaver>(alternatively, you could merge upstream master into your branch) <jlicht>balduin: on a side note: you inquiry pushed me to try my hand at building atom <jlicht>there is some good and bad news: building from their repo seems to work with our bundled node package :D <jlicht>but the build process pulls _a lot_ of packages from the npm registry, which contain minified and/or transpiled sources :/ <jlicht>so it might take a good amount of time before atom might be bundled with guix (if there are no license issues that prevent atom from being included anyway) <balduin>Maybe there is a way to compile Firefox without DRM support, add LibreJS and the other GNU IceCat plugins and put it into GUIX. This is just an idea. <mark_weaver>balduin: yes, it is certainly possible to do that. we'd need to change the branding as well, because Mozilla's trademark policy would require it, and a few other things. this is precisely the job of the GNU IceCat project. <mark_weaver>we'll get the GNU IceCat project back on track. I'm working on that behind the scenes. <lfam>mark_weaver: Congrats on the faster grafting commit! <lfam>Now I can drop it from my private branch :) <balduin>toxcore does not have any versioning schema. How should I determine the version and commit for toxcore for the package file? <lfam>balduin: If they don't have any sort of versioned release system, then I guess we will have to package an arbitrary Git revision. Check the manual section 7.6.3 Version Numbers for an example of how we handle this <mark_weaver>balduin: if there has never been a release, then I would recommend starting the version string with the date of the git revision, in the form YYYY.MM.DD <mark_weaver>to my knowledge, we haven't settled on a convention for this particular case, but if you grep for "version "201" <mark_weaver>but the remainder of the version should conform to the convention described in secion 7.6.3 <lfam>It was suggest to use 0.0.0 in the guix-devel discussion of this subject, but that didn't make it into the manual, so I think it's still up in the air <balduin>@mark_weaver: (version (string-append "2016.07.27-" revision "." (string-take commit 7))) is this okay? <mark_weaver>maybe it depends on whether upstream expects to ever start adding release numbers <mark_weaver>anyway, if the date string were used, it should probably have its own variable, like 'revision' and 'commit'. <balduin>this would be the output right now: version: 2016.07.27-1.2016.07.27 <mark_weaver>that's not right. the last part should be the git commit hash <balduin>okay, now how to I determine the sha256 hash? <OrangeShark>balduin: I actually wrote a package for toxcore and qTox <OrangeShark>like I you can chat with other people, but I haven't really tested the other stuff <balduin>@OrangeShark: okay, what more would you like to test? <lfam>Wow, does the video chat work? <OrangeShark>balduin: also to git the hash for a git repo, you need to clone the repo and then delete the .git directory. Then run guix hash -r the-directory <lfam>balduin: Also, make sure to check out the desired commit before deleting .git <lfam>OrangeShark: I'm going to try it <lfam>OrangeShark: Any particular reason to use libsodium version 1.0.8? We have 1.0.10 <lfam>Looks like you packaged a newer openal <balduin>@OrangeShark: how did you figure out all the dependencies? <OrangeShark>balduin: reading the build instructions for the packages and some trial and error :P <OrangeShark>I managed to get qtox to fix their qmake file to remove some of the hard coded dependencies, but there was still some problems like icons not being installed. <balduin>did anybody create a package for rust (programming language)? <OrangeShark>I think when building rust, it would download a binary of itself to build <balduin>I was wondering did somebody create a package for apache-webserver? <balduin>okay, stupid question someboy did: httpd 2.4.23 <mark_weaver>balduin: "guix package -s apache" would find it, since that searches the descriptions and not just the package names. <balduin>I was looking on the webpage under apache, but you named it httpd ;-) <balduin>is it enough to just use: #:use-module (guix packages) and specifiy the package in the input section? <mark_weaver>balduin: you need to 'use-module' the module that contains the package in question, and then use the scheme variable name (the identifier after the 'define' or 'define-public') as the name after the comma in the input entry. <lfam>Is anyone going to finish the tox packages and send them in? <balduin>@OrangeShark did a pretty good job. I hope he will send his package definition in. <Sleep_Walker>can anyone review '[PATCH] gnu: asciidoc: Use local docbook-xsl package.', please? <Sleep_Walker>(besides space between file name and '(variable-name)') :) <cehteh>mhm full disc encryption with a /boot doesnt work? <mark_weaver>cehteh: not unless you're running Libreboot or coreboot with GRUB as payload in your boot flash. The reason is that /boot is where GRUB is located. GRUB is able to mount a LUKS volume, but a typical BIOS is certainly not able to mount a LUKS volume. <mark_weaver>cehteh: this is not GuixSD-specific. if your BIOS is not capable of mounting an encrypted volume, then obviously the bootloader needs to be unencrypted. <cehteh>mark_weaver: i meant the 'usual' way with a unencrypted /boot partition <mark_weaver>oh, if /boot is a separate, unencrypted partition, then it should work. I haven't tried it myself, but it has been reported to work by others. <cehteh>i made a small /boot mounted it, grub is installed, but it erorrs out lacking something from the store <cehteh>why is installing guix still so much pain :D <mark_weaver>I don't remember clearly, there may be some pieces missing. <cehteh>there is a guix talk, i'll be surely there <mark_weaver>ah yes, there needs to be some commands added to the grub config to mount the LUKS volume before trying to boot. <cehteh>where is that documented .. i found some vague hints now :D <mark_weaver>I don't have time to walk you through it, but look in the GRUB documentation. for now, you could use the GRUB command line to execute the commands by hand. <cehteh>well from the grub commandline i can call cryptomount .. but it doesnt ask me for a passphrase and neither do i get a (crypto0) which puzzles me <mark_weaver>grub.cfg is generated from gnu/system/grub.scm. if you run guix from a git checkout, you can modify that file locally to add the needed commands. <mark_weaver>and if you can come up with a reasonable patch and submit it to us, we can consider it for inclusion. <cehteh>well i have to have it working here first :D <mark_weaver>I'm sorry, I haven't tried this myself, so I'm not in a position to help much <cehteh>maybe someone else here wakes up for help <cehteh>aaaah .. found it .. insmod luks in grub <cehteh>sucks a bit too, now one has to enter the passphrase twice, once for grub and once for linux <cehteh>i think a somewhat more proper solution would be to copy the /gnu/store parts needed for booting (basically the initrd's) into /boot <itorres>mark_weaver: concerning the artanis patch in guix-devel, thanks for the feedback. I'll do some substitutions in Makefile.in before the configure step <mckinley_>I'm trying to list the dependencies of an executable using ldd, but whenever I do, ldd reports line 117: ./eclipse: No such file or directory <mckinley_>I'm trying to get familiar with linking, and have seen others have had this problem, but I don't understand what's causing ldd to fail listing the dependencies. Anyone seen this before? <rekado>yay, bluetooth audio via pulseaudio works now. At the very least we will need to provide a pulseaudio service to simplify this, I think. The rest is messing with bluetoothctl, pairing, connecting, then using pavucontrol to redirect the audio stream to the bluetooth audio device. <janneke>mckinley_: assuming that eclipse a linux-fhs executable, you need to use patchelf to set the dynamic linker <rekado>BTW: we should update pulseaudio to the latest version. In core-updates? <davexunit>rekado: is that having bluetooth devices play audio on machines running pulseaudio? <davexunit>or sending pulseaudio output to bluetooth speakers? <rekado>this sounds straight forward but is surprisingly messy. <otremblay>Is GuixSD stable enough for day-to-day use as my personal dev machine's OS? <davexunit>otremblay: depends on your needs. I've been using GuixSD full-time for over a year. <davexunit>all of the most important software is there for me. <otremblay>Well, I'm using Emacs, I code in Go, I need some shell (bash/zsh do nicely) with some terminal emulator, but I guess that's all available cuz that's pretty basic. <otremblay>Other than that, like, a browser. And Pidgin. <davexunit>Go is definitely not basic, that's for sure. :) <otremblay>I'd assume it's possible to build Go from source <davexunit>it's not rare for software to assume things that do not hold true on GuixSD <otremblay>Petter: How's your experience coding Go in GuixSD? <davexunit>all I know is that it was a long road to get it to work :) <bavier>I've used it to build one package so far <bavier>otremblay: but if you use guix's go package and notice anything wrong, let us know <otremblay>Well I'm considering the usage. Usually I'd be halfway through wiping my computer right now, but in a fit of random panic at some point I decided it would be a great idea to encrypt my whole drive and now I'm not sure it's gonna be so easy to do the "partial wipe" dance I'm used to. <Petter>Thinking loud. Maybe you can use one temporary partition for your current stuff. Encrypt a partition for your system, get it working, copy stuff to it, delete data partition, expand encrypted partition. <Petter>Memory fails a little, but I believe I tried expanding an encrypted partition with success. <Petter>If I recall correctly you can only expand the end of an encrypted partition, so put this partition first on the disk and the "old stuff" partition last. <otremblay>Is it possible to use the partitions I have right now, even though they're encrypted? <otremblay>Also, as an aside: I just realised there's a guile-emacs package in GuixSD <otremblay>Are the emacs users in here using that or the regular emacs? <Petter>You can open encrypted partitions yes. <bavier>I use the regular, but I'm not much of an emacs programmer, yet <Petter>f.ex.: cryptsetup luksOpen /dev/sda5 my-stuff should make a dir in /dev/mapper called my-stuff <Petter>(after you've entered the correct passphrase of course) <otremblay>Thanks Petter, I might give it a shot during my vacations <davexunit>otremblay: the guile-emacs package is to make it easy for people to try it out and show that is a real thing <davexunit>there's still much work to do on it to make it something that can replace regular emacs <otremblay>I've always wanted to learn myself an actual Lisp, seems like Guile is good, there's also a free ebook. <otremblay>And the documentation can be read within emacs as well. On my way, then. XD <rekado>I’m using Emacs 25.1. Guile Emacs crashed on me (I think it was triggered by “desktop-save”), and since I absolutely depend on Emacs I couldn’t switch. <davexunit>yeah guile-emacs is only for experimental use currently <rekado>otremblay: Guile is fun! What is a little poor in Guile is discovery of libraries. The best way to discover stuff is to ask on the #guile IRC channel. <rekado>davexunit: do you know how “guix environment --container“ can be used to do guile-emacs development without having it mess with my real Emacs configuration (when I run it without ‘-Q’)? <davexunit>rekado: I imagine you just need to get access to the X server in the container and then it should work <davexunit>guix environment --container --share=/tmp/.X11-unix --ad-hoc guile-emacs <davexunit>I've thought about adding a --x11 flag or something <bavier>with all these C++ projects, it would be nice if GNU Make had some sort of 'memory throttle' option with its -j <jlicht>when debugging coredumps with gdb, I need to setting the directory is not enough (or I'm doing something wrong) <jlicht>currently, I set `set substitute-path /tmp/ /home/jelle/src/` in my .gdbinit, and then checkout the source in e.g. /home/jelle/src/whatever-1.1.2.drv-0/whatever-1.1.2/ <jlicht>basically mirroring the /tmp/guix-build structure <jlicht>Does anyone else have any experience with debugging coredumps of guix-installed sw? <bavier>anyone have a rough estimate of the disk space for all source tarballs used in Guix? <bavier>package manager built on ifps that go-ipfs is using to manage dependencies <mark_weaver>itorres: makefile variables can be overridden by passing arguments like (string-append "PREFIX=" %output) in the #:make-flags <mark_weaver>itorres: normally it is not necessary to do substitutions in makefiles <otremblay>bavier: I like the concept but I'm afraid by the lack of search <otremblay>Import by hash seems cumbersome. I like the general idea of it though. <davexunit>guix theoretically could do binary substitution via ipfs <davexunit>#emacs is a garbage dump of a channel. shame, really. <ooxi>If I release a package using guix, can users of multiple distributions (I'm primarly interested in Ubuntu, Debian and Fedora) use it? <ooxi>I'm maintaining a little game and I think all my dependencies are already included in guix. But releasing it for multiple distributions is a hassle :( <davexunit>ooxi: they can use it if they run Guix on their host distro. <ooxi>Is guix available for the most common linux distributions? What about Free/Net/OpenBSD? <davexunit>ooxi: guix currently only runs on gnu/linux systems <davexunit>most distros don't have packages for guix, though. <davexunit>ooxi: consider this, though. it's easy for distros to package things like your game for you if you make it easy to build from source. <ooxi>thanks for the info! guix looks really promising but until some distributions ship it it's not really a target for me <ooxi>you are totally right and some already do. But having one target instead of multiple would be really great <ooxi>and guix looked like it was :) <davexunit>I often hear game developers (I am one, too) worrying about how many distros there are, thinking that they personally have to provide packages for every distro. <davexunit>if I were you, I'd make a bundled binary release that someone can just extract and run (the lazy route) <davexunit>and make the game easy to build from source (./configure && make && make install) so that distros can package it <ooxi>Is there a tutorial on how to package something tiny for guix, preferable with dependencies provided by guix? <davexunit>a guix package must have all of its dependencies provided by guix, so it's not just a preference. <davexunit>ooxi: what language is your game written in? what libraries does it need? <ooxi>the game is already packaged for freebsd and netbsd and included in playdeb for ubuntu (but not officially) <davexunit>ooxi: okay, great! so far, it sounds like writing a guix package for this should be pretty easy. <ooxi>that's great news :) I'll try using the guix manual and come back when having troubles :) <davexunit>(though I know you said guix wouldn't be a good target for you, and I understand) <davexunit>ooxi: if you wouldn't mind lurking for a bit, I might have a code snippet to give you. <ooxi>well if it's not much hassle providing a guix package I will likely do it <ooxi>that would be great! learing by example is much easier (for me) than learning from manual <davexunit>ooxi: I've been providing guix package recipes in my git repos in a "guix.scm" file <davexunit>which has been a convenient enough way to make it easy for guix users to build+install stuff <itorres>setting PREFIX and doing a couple of substitutions looks far better than my first patch, although it stills feels hacky <davexunit>assuming you have a working guix installation, you could put that code in a file (let's call it "violetland.scm", for example) and run 'guix build -f violetland.scm' to build it. <lfam>I see two options. 1) I can rebase onto master and re-sign the 11 commits from core-updates-next. If we do this, I'd like for someone else to double-check that I have not modified the commits that I've re-signed. 2) Temporarily disable the hook and push the result of `git checkout core-updates-next && git merge master`, which I have prepared locally. <lfam>And of course, there may be other options which are superior <lfam>I don't really like 2, because I had to resolve dozens of merge conflicts. I think I resolved them correctly, but that's a lot of opportunities to make mistakes. <mark_weaver>itorres: bah, it looks like artanis' Makefile is kind of a mess :-( <mark_weaver>well, thanks for working on it. I'll look more closely later. <lfam>mark_weaver: Okay, I'm going to try pushing a copy of master as WIP-core-updates to Hydra, just to check that that works with the hook. If it works, I will then cherry-pick the commits to the branch. Then, I will ask for review <mark_weaver>we should also incorporate the available updates from GNU, e.g. gcc-4.9.x, glibc, and maybe some others <lfam>There are lots of patches in my Guix mailbox that will end up on this core-updates branch once it's ready. For now, I just want to get these 11 commits onto current master on Savannah <lfam>I meant that I will push to Savannah, not Hydra <catern>woo, I am pushing for Guix use at my job :) <Petter>Cool! What are the most central points you focus on? <catern>oh, well, heh... maybe "pushing" is too strong <catern>I *suggested* Guix use at my job, and the person I suggested it to, was very interested <lfam>If you end up using it, it would be really cool to read a report on your experience after it's been in use for a while <rekado>catern: is this in science/education? <rekado>I’m using Guix at work since more than a year on many machines and I’d be happy to assist if you have any questions. <bavier>oh, we don't have qtwebengine... :( <bavier>balduin: what are the struggles? <balduin>if I define libgc and gnu packages libgc in the module definition I get: $ guix build neko <balduin>i get: guix build: warning: failed to load '(gnu packages neko)': <balduin>guix build: error: neko: unknown package <bavier>balduin: do need to have your package definition somewhere in $GUIX_PACKAGE_PATH or in the git tree <rekado>balduin: note that the module name and the file path must match. <bavier>balduin: I assume from your command that you're not using a git checkout of guix <rekado>a module (gnu packages neko) must be in gnu/packages/neko.scm <davexunit>'#:use-module (gnu packages libgc)' is outside of the define-module form <balduin>I set the $GUIX_PACKAGE_PATH to ~/guix <balduin>@davexunit: yet it is outside. Nothing changes if I set the parantheses correct, I still get the same error. <mark_weaver>balduin: GUIX_PACKAGE_PATH should point to a directory with nothing else in it. <davexunit>the reason you get "unbound variable: gnu" is because '(gnu packages libgc)' is outside of the define-module form <mark_weaver>pointing it to your guix checkout will lead to problems <mark_weaver>(well, I'm making assumptions about what's in ~/guix) <mark_weaver>(for us developers, I guess ~/guix is often a git checkout of the guix source code) <balduin>@mark_weaver ~/guix is a simple folder in my case. I did not use git in it. <balduin>neko.scm is under ~/guix/gnu/packages <lfam>It worked for me when I cross-built locally on x86_64 <lfam>It actually seg-faulted on the build machine :/ <lfam>But, I can't load the link to "(2229 more builds omitted)" <lfam>Is there a better way to read the list of build failures? <balduin>I do not really understand how to define the build dependencies for neko (Boehm GC (libgc), zlib, sqlite etc.) <davexunit>balduin: simply uncommenting that line will *still* have invalid syntax <lfam>balduin: Also, libgc package module is named bdw-gc, not libgc. You need to import the module, not the package <davexunit>once you import the correct module, with the correct syntax, you can be well on your way to a working package build <lfam>So, #:use-module (gnu packages bdw-gc) <balduin>@lfam okay how do I figure out the module name for a package? <lfam>balduin: I use `guix package --show=foo` <davexunit>which can be directly translated to the scheme module identifier <davexunit>gnu/packages/bdw-gc.scm is (gnu packages bdw-gc) <mark_weaver>so that you'll see how it compares with master. ideally that later evaluation would be the closest evaluation on master to the last commit from master that was merged into wip-python. <lfam>mark_weaver: That *is* a better page to look at <lfam>I'm still not able to load the full list of failing jobs <mark_weaver>lfam: I usually just pick a few dependency-failed packages and see which dependency caused them to fail, and work from there. <bavier>is there any particular reason we don't have a chromium package yet? <bavier>nvm, I'm reading up on the qtwebengine/chromium fiasco <catern>rekado: no - the use case is a bit weak - it's for unprivileged package management - we're in a secure environment where developers don't have root <balduin>does guix have a mysql/maria db client (c connector)? <lfam>balduin: I would try `guix package --search=mysql` and the same for search for maria. You should find most of the relevant packages 