<cbaines>mekeor, if its a module, you need to use define-module, and export the package (e.g. using define-public) <cbaines>if its not a module, you need to use (use-module ...) style imports, and make sure that the file evaluates to the package <cbaines>It sounds like you could be mixing the two styles <cbaines>I think your getting close, guile doesn't like the package declaration <cbaines>that is the "source expression failed to match any pattern" <cbaines>Aha, great, I think I've just spotted it too <cbaines>One tip, you could neaten up a few of the lists by using what I think is called splicing <cbaines>e.g. `(("inotify-tools" ,inotify-tools) ("libxaw" ,libxaw) ,@(alist-delete "gtk+" (package-inputs emacs))) <cbaines>Something similar would work for the arguments <mekeor>i got it built some time ago already <mekeor>i was just trying to be able to manifest it ;) <ng0>uh.. why do people push things I'm still fixing? <ng0>I'm irritated by the kallithea related pushes.. <ng0>thanks? I was still bringing it up to date, but I'm not so fast <ng0>included fixing descriptions and a couple of other lines I wasn't happy with <ng0>ah... it was an unrelated fix in the python brahcn which just included stuff I worked on in the past... sigh. duplication. <ng0>dulwich, fastimport, ... <mekeor>i tried guix import but it didn't work. i want to learn guix packaging anyway, so i decided to try it on my own. <mekeor>the makefile for dzen is configured through config.mk where variables like LIBS and CFLAGS are defined. <mekeor>also, instead of './configure && make && make install', it needs "make install && cd gadgets && make install" or so <mekeor>should i still use the gnu build-system? <mekeor>OH, i got an idea! i could use substitute* to replace 'include config.mk' in the Makefile! <mekeor>i think it would work now, if i'd know the values i have to use for the variables in the makefile... <lfam>mekeor: The set-makefile-variables phase is just setting a bunch of variables, right? You shouldn't need G-expressions for this <lfam>mekeor: Often, things like CFLAGS and LIBS can be passed to #:make-flags. If not, you can still use substitute*, but in a different way <lfam>mekeor: Looking at the Nix package recipe, I'm not sure you want to copy it too closely. For one thing, there is no /usr in the build environment <lfam>What happens when you try to build dzen2 without any of the stuff from the Nix patchPhase? <lfam>I'd expect that you'd need to change PREFIX and hopefully nothing else ***thor is now known as Guest9972
<Apteryx>Probably a noob question: in the Geiser REPL, how would I go to print the value of the %default-authorized-guix-keys variable defined in (gnu services base) ? <Apteryx>I did 'C-c . u' in the 'base.scm' buffer to "use it" (just doing ",u (gnu services base)" wouldn't work). Then I tried (display %default-authorized-guix-keys), but it errors out. ***kelsoo1 is now known as kelsoo
<rekado>“just doing ",u (gnu services base)" wouldn't work” <– this is probably fixed by setting (setq geiser-guile-load-path '("~/dev/guix")) <rekado>$2 = (#<<file-append> base: #<package guix@0.12.0-2.b291 gnu/packages/package-management.scm:228 4929900> suffix: ("/share/guix/hydra.gnu.org.pub")>) <rekado>“display” would also work but it’s a needless complication <roelj>Can I safely assume that a module in Guix can load other modules in Guix with (resolve-module '(guix some module))? <roelj>Or, asked another way, are the Guix modules always on the load path when running Guix? <alezost>when running "guix ..." command – yes; the module load paths are added by 'guix' script itself <dale>Does anybody consider it a weakness that `guix package --install openssl@1.0; guix package --upgrade' leaves openssl-1.1.0c installed? <davexunit>dale: it's not clear what the problem is in that example. <dvc>mmh, I'm not sure what my opinion of what a package definition looks like and what is accepted as a coding standard. I'm not quite happy with the added ocaml packages - but maybe it's just me. <dale>I ask for openssl limited to version 1.0 and expect upgrades to respect that; instead the upgrade jumps me to the bleeding edge which I'm trying to avoid. <dale>It is not the behaviour I would want. <davexunit>if you don't want to upgrade openssl, you'll need to specify that <dvc>maybe the manual needs clarification on that? <dale>I understand that I can opt packages out of upgrade by specifying them on the command line, but that is a pain; <davexunit>where you write a scheme file that describes the packages in your profile <dvc>davexunit: I was talking about coding standard - are we talking about the same thing? <dale>If I have say version 1.0.1, and 1.0.2 and 1.1.8 come out, I would want the upgrade to give me 1.0.2 as I asked for the install of a 1.0 version. <davexunit>and the people that do code review are good at spotting style issues <civodul>dvc: i thought you reviewed the OCaml packages that were just added, no? <dale>I will investigate manifests, thanks. <civodul>dvc: at any rate, feel free to tell Julien if there's anything you're unhappy about <davexunit>dale: you have a different idea of upgrading than we do. <davexunit>you want what some call "pessimistic" versioning <dale>Hmmm, do you mean *we*, or *you* <civodul>openssl 1.1 is announced as the continuation openssl 1.0 <civodul>so it's an "upgrade", but at the same time, we also know there are incompatibilities <davexunit>right, semantic versioning is not the law of the land. <civodul>some distros would give the packages different package names in these cases <dale>But other distros aren't half as nice as GuixSD ;-) <civodul>for software with several parallel stable series, i thought we could have properties to describe what series to upgrade to <civodul>like gcc 5.3 would upgrade to 5.4, not 6.2 <dvc>to be fair to jullien - we don't have a section on what specifically a package definition should look like - it's details like (sha256 (base32 on the same line. I only reviewed it as being technically good and made some examples of what I think it should look like for the first 20 packages. I thought he'd see the difference... <civodul>i wonder if this would be too sophisticated though <davexunit>that would work. we have like 3 or 4 versions of ruby at this point, for example. <davexunit>I definitely don't like the version constraint stuff that other package managers do <civodul>dvc: (sha256 (base32 on the same line is not nice, but it's not the end of the world either ;-) <dale>Can you explain what a `property' is exactly? <rekado>dale: it's another field in a package definition <davexunit>a package can have an arbitrary set of key/value pairs in addition to the regular package data <civodul>dvc: you could point them at etc/indent-code.el next time <rekado>dale: we currently use properties to record the upstream package name in some instances <rekado>civodul, dvc: indent-code.el doesn't fix having the (sha256 ...) expression on one line, though. <dale>The problem is, it is not really at the package-definition level, is it? The version stem you want to stay confined in is determined by the --install command. <dvc>yes - but if everyone starts doing it differently we have an unreadable codebase over time. A good codebase is one where you can't tell that it wasn't all written by the same author. If I can tell who wrote what without looking at the git history - that's not good. <dale>To put that more concretely, if I execute `guix package --install openssl@1.0', that is the point at which restriction of --upgrade to the 1.0 branch should actually be established. <davexunit>I think this would be bad behavior, in general. <dale>I'm going to investigate the manifest thing, thanks for the comments guys. <davexunit>the manifest will only work if we indeed have multiple openssl packages <davexunit>in your openssl example, if a user happened to install openssl this way they'd stop receiving important security updates <rekado>dvc: you are free to change stylistic things if you're working on the package anyway. <dale>There would have been a reason for selecting an older version in the first place, and security updates, if possible, would most likely be back-ported to the older branch also. <rekado>dvc: but we should avoid additional commits just for stylistic reasons <dvc>rekado: yes I'm not planning on fixing this or scolding jullien. I want to know what we can do to prevent this in the future and how to handle onboarding new developers so that we can grow :) <davexunit>the guix you upgraded to would no longer have a recipe for openssl 1.0 <davexunit>running 'guix package --install openssl@1.0' again would fail <rekado>dvc: new committers read HACKING. Maybe we can add a few style things there (without going overboard)? <dale>I guess I'm going to have to look forward to that actually happening sometime in the near/medium future :-( <dvc>rekado: maybe I'm too OCD :) <rekado>dvc: I wonder the same about myself <rekado>I have a question about module-ref <rekado>I'm trying to get a reference to bash in a snippet <rekado>so I do (module-ref (resolve-interface '(gnu packages bash)) 'bash) <rekado>but Guix doesn't like this and says things like ERROR: No variable named bash in #<interface (gnu packages bash) 278c6c0> <rekado>(I'm trying to run a shell script in a snippet) <roelj>rekado: Why not resolve-module? (module-ref (resolve-module '(gnu packages bash)) 'bash) <roelj>#<package bash@4.4.0 gnu/packages/bash.scm:96 45d4180> <rekado>roelj: that gives me ERROR: No variable named bash in #<directory (gnu packages bash) 34dd5a0> <roelj>Hm, resolve-interface works fine for me too <roelj>Ah, it must be, because otherwise you'd get "no code for module" ... <rekado>it works fine in the REPL but it doesn't work when the code is in the package definition or in a snippet <rekado>when I quote it (to resolve the variable at build time) it says ERROR: no code for module (gnu packages bash) <roelj>So that probably means that at build time, Guix is not on your %load-path. <rekado> (module-use-interfaces! module (map resolve-interface '#+modules)) <rekado>I added (gnu packages bash) to the "modules" field <rekado>yes, the list of modules is quoted <rekado>(modules '((gnu packages bash))) <roelj>Shouldn't it be (modules '(gnu packages bash)) instead? <rekado>the module-ref stuff works in autoconf-wrapper, but it fails to work in shogun. <rekado>even when doing it in the top level. <rekado>How can I augment the patch-inputs in an origin expression? <rekado>I cannot seem to use %standard-patch-inputs, so I have to recreate that. <rekado>but using `(("tar" ,tar) ...) won't work as this seems to cause a recursive dependency <rekado>trying to hack around this by using ("tar" ,(module-ref (resolve-interface '(gnu packages base)) 'tar)) fails <rekado>ERROR: No variable named tar in #<interface (gnu packages base) 2468a20> <rekado>maybe this needs some more laziness <civodul>dvc: i agree with you regarding consistency, but there's a tension between achieving perfect consistency and facilitating contributions <civodul>so we must always ask ourselves what's the most important thing, if it's to have that one file properly indented, or to have continued contributions by that person <civodul>that doesn't mean we should give up on consistency <civodul>just that we should take it easy and provide tools for people to DTRT without doing several review rounds <dvc>civodul: I know - that's why we need better tools at some point... I'm trying - that's why I asked on IRC what the best way is to deal with this and what other peoples opinions are. <civodul>ok we're on the same line of thought :-) <civodul>i think indent-code.el is a good step in that direction <mekeor>XFT works. i don't know why XPM and Xinerama don't seem to work. also the man-pages are missing... <paroneayea>guix environment guix --root=/home/cwebber/genv/guix <paroneayea>guix environment: error: symlink: No such file or directory: "/home/cwebber/genv//home/cwebber/genv/guix" <civodul>paroneayea: looks like there's a bug here: it appeneded the dirname <nliadm>yeah, looks like you can only use a relative path until that's fixed <civodul>in the meantime, you can use a relative file name indeed :-) <mekeor>after a reconfiguration, i now can't login into the default x-login-manager anymore but instead get 'failed to execute login command'. anyone sharing this issue? <civodul>does ~/.xsession-errors contain hints? <mekeor>oh, it was because of my ~/.xsession <adfeno>Hi #guix! Do you know which email address I should contact to discuss problems with sending emails to mailing lists under @gnu.org? <mekeor>adfeno: in doubt, ask in #gnu, maybe? <void__>whats the current status of GuixSD ? <rekado>I'm using it on servers and laptops <void__>is it stable enough to use for normal desktop tasks ? <davexunit>guixsd has always been "stable" but it's always supported rollback <void__>now why should i use it over parabola gnu/linux-libre ? <void__>is guixsd considered minimal to parabola ? <davexunit>I wouldn't know how to compare either because it all depends on what software you choose to install <void__>guess the best way to find out is by testing it <davexunit>what guixsd and parabola have in common is being able to configure everything from the ground up pretty much <davexunit>guixsd uses a much more advanced package manger <void__>I dont plan on using that much software <davexunit>I think you're right that just trying it is the best way <void__>openbox-lxpanel-pcmanfm-compton-xchat-icecat-blender-mpv-inkscape-libreoffice-mupdf <void__>that's pretty much all of what i use <davexunit>for me, full-system rollbacks is the killer feature. <rekado>for me it's declarative configuration <void__>ugh i got an exam tomorrow and yer making me wanna try it so bad <rekado>I hate changing files somewhere in /etc and keep track of it all <rekado>void__: you better take some time to give it a try <void__>just to clear some confusion around <void__>guixsd is the official GNU operating system <rekado>GuixSD is a variant of the GNU system. <adfeno>There's no official GNU operating system. <void__>then why it's being hosted on gnu ? as guixsd (the distro) ? <rekado>and our vision in providing a GNU system is in line with the GNU vision. <rekado>because it's part of the GNU project. <void__>thanks for taking time to explain these important info to me <buenouanq>Guix"s wobsite is hosted under the main GNU domain though. <void__>guess I'll start testing guixsd tomorrow <rekado>the GNU view is that there's no *one* GNU operating system. <rekado>GuixSD also differs from other distributions in the bootstrap <rekado>void__: yes, send email to bug-guix@gnu.org <void__>Ill download it today and leave the work till tomorrow <mekeor>void__: i'd recommend you to check out the list of packages before trying GuixSD <void__>thanks for clarifying some stuff though <buenouanq>I don't - If it's not in the guix repos, you don't need it ;3 <adfeno>Yu don't have to install GuixSD if you don't want to. <void__>I want to dive into the world of GNU xD <void__>plus since it's built from scratch <adfeno>Yo're already in if you use Parabola. <void__>well it's similar to arch if not identical in some matters <void__>although the result is great imo <void__>but still you have to wait for arch devs ,pkgers to do the work <void__>for example lxpanel has a broken battery icon at 0.9.1.1 on parabola <buenouanq>in 5 years, everyone is going to be [poorly] copying what guixsd is doing today <void__>they told me to tell that to arch devs <buenouanq>it's so obviously the correct way to go about operating system building, that we ever didn't do it this way is just madness <void__>whats the kernel version in guixsd ? <void__>I'm afraid that wont boot on my intel cpu <void__>am although experiencing some stuttering <mekeor>void__: is most of the text not displayed for you either? <void__>Sorry I've got no access to whatever browser atm <void__>icecat, iceweasel are currently broken on parabola <jin>i run 'guix build gettext --fallback --no-substitutes --no-build-hook' <void__>as I said IceCat is currently broken here in parabola waiting for the packagers to fix it <Apteryx>rekado: Thanks for your reply regarding my question about %default-authorized-guix-keys. I thought this value should contain a "list of string-valued gexps" as is written in the guix-configuration Data Type summary in the Base Services node of the guix info. <Apteryx>Rather than the opaque looking "(#<<file-append> base: #<package guix@0.12.0-4.d9da gnu/packages/package-management.scm:228 4060f00> suffix: ("/share/guix/hydra.gnu.org.pub")>)". <Apteryx>My exercise is to try to programatically add a public key entry to the acl list structure which has the default value of %default-authorized-guix-keys. <Apteryx>So I can get some confidence in Scheme/Guile. <Apteryx>Looks like the %default-athorized-guix-keys is a file-append record defined in gexp.scm, and that it I want to see a lower representation (hopefully the string content of the file?) I must use the "file-append-compiler". <Apteryx>Is it possible to inherit from a record type and to extend (rather than override) one of its field? <davexunit>there's no syntax for it, if that's what you mean <Apteryx>Yes, I guess that's what I meant. I'm not at the level of hacking my way through yet. ;) <davexunit>for example: (package (inherit emacs) (synopsis (string-append (package-synopsis emacs) " Also, it's way better than Vim."))) <Apteryx>I'm still lost regarding how to extend (gnu services base)'s %default-authorized-guix-keys with an an entry of my own :/. I now understand that its value is a list containing a file-append record, but I have no clue how to use it. <davexunit>the modify-services macro can help with that <Apteryx>It's very straightforward after all! <Apteryx>I will look into the modify-services macro. Thanks for pointing me to it! I have to head to work. Later! <phant0mas>hey civodul, the coreutils version we have in core-updates has a variable ( cu_install_program)which is not expanded properly when cross compiling <phant0mas>According to the gnu make manual is happens because they use = instead of := <phant0mas>I will send them a patch and then patch our version <civodul>i haven't done the cross-build thing yet on hydra <phant0mas>civodul: I should have read the gnumake manual from the start, the whole problem was just one character! And please do when hydra has free resources to spend :) <efraim>phant0mas: ping me when you push it to core-updates, I'm ready to dive in again on aarch64 <phant0mas>efraim: ok, and this time I have an aarch64 machine in my home so maybe I can help! <efraim>Awesome. When I'm back at my computer I'll fix one of the patches I mangled and send you a link to where I have it mirrored on gitlab <quiliro>Gtk-WARNING **: Locale not supported by C library. <janneke>i system-reconfigured right after gnome-updates were merged; gnome does not work for me <janneke>i'm wondering...what are people using for their desktop/window manager? <mekeor>quiliro: do you also have issues with icecat not displaying most text on some websites? <mekeor>janneke: personally, i use xmonad. but it doesn't seem to be very common because it's not updated to the latest version yet <janneke>mekeor: thanks. i'm tempted to go back to sawfish...but that's not really alive; i would want to invest in guile-wm, but that does not work yet for me <jin>janneke: i will reconfigure my system more late! <janneke>jin: okay, i'd like to know if it works for you <rekado>janneke: since a few days I’m using stumpwm with rofi. <rekado>used xfce before but on my laptop my windows are mostly fullscreen by default anyway <rekado>stumpwm handles little windows better than other tiling window managers I used before (including xmonad) <mekeor>the *Guix REPL* buffer tells me "unkown argument to --listen" <mekeor>rekado: do you maybe have an idea how to fix this issue? <janneke>rekado: from the web it looks like stumpwm has info docs, but i cannot seem to find them (i installed sbcl-stumpwm and sbcl-stumpwm:bin) <janneke>from its introduction it looks like a good successor to sawfish for me <rekado>janneke: yes, they are missing. I already opened a bug report about this. <void__>any mail clients that respect freedom ? <void__>and an email service that respects freedom ? <alezost>mekeor: 2015-05-11 was a long time ago ;-) did you install emacs-guix with Guix? <erliphant>possibly a silly question - is it possible to download more than one source for a package? <alezost>mekeor: also could you paste a full backtrace from the Guix REPL? <alezost>erliphant: you can use origins in inputs; look at "guix edit tzdata" for example <efraim>grabbing patches from qemu-devel isn't that much fun <kyamashita>Guix packages don't have any dependency on Tcl/Tk version 8.6.4, do they? <kyamashita>rekado: Any packages using Tcl/Tk as inputs. I wanted to package a Tcl library that requires Tcl version 8.6.6. <rekado>kyamashita: I think it’s okay to update the tcl version. <rekado>that’s because Python depends on tcl. <rekado>kyamashita: yes, core-updates would be the correct branch. <civodul>mekeor: like you did, but you also need #:recursive? #t if you want the whole directory to be included <mekeor>civodul: where can i find the documentation of these kind of things? <efraim>python depends on tcl/tk i believe <mekeor>oh, well, it's in the guix docs actually <mekeor>still, i lack a utility to find out in which module a procedure like `locale-file' is defined <alezost>mekeor: did you find out what was the problem with --listen argument (in Guix REPL)? <efraim>i often end up with `git grep define-public\\ locale-file' or somethign similar <mekeor>i was about to write an email to the mailing list or so. so, i was about to set up my mail-client... <alezost>mekeor: ok, well, I actually asked you a couple of question an hour ago, but you didn't answered :-) <kyamashita>efraim: It's okay. Verification always helps. I just remembered Python's IDLE development environment. :) <alezost>mekeor: no problem, did you install emacs-guix from Guix or from melpa? <rekado>mekeor: a lot of the guix-specific procedures are defined in the manual. If you’re using an info viewer (like Emacs or “info” or “pinfo”) you can often use the index to find the correct place in the manual. <alezost>mekeor: could you paste a full backtrace from the Guix REPL? <rekado>to access the index in an info viewer just hit “i” <rekado>I found that I much prefer a well-maintained info document over any other documentation format. The index is really handy. <mekeor>ACTION uses emacs' info viewer much to seldom <rekado>(we’re now using texinfo for internal documentation at work just to allow me to use Emacs and the index.) <mekeor>alezost: uhm. wait.. well, what is a full backtrace? how to get it? <alezost>mekeor: I mean switch to the Guix REPL buffer, copy everything from it and paste it somewhere <mekeor>so it has something to do with 'sentinel' and/or '--listen', i guess? <alezost>hm, maybe something wrong with arguments; what is the output of "M-: guix-repl-guile-args" <mekeor>oops, sorry, there was an ellipse "..." at the interesting part <alezost>yes, there are some args missing; could you do it inside "M-x ielm" <alezost>I mean evaluate (guix-repl-guile-args) <alezost>oh, I see, give me a minute to describe... <mekeor>~/.emacs.d/temporary/guix-repl-1451iHF doesn't exist <mekeor>i have set temporary-file-directory to "~/.emacs.d/temporary/"... <alezost>The problem is that there is "~" in the file name of --listen argument. I will fix it in Emacs-Guix to make sure it is expanded. But this is rather surprising for me. Did you maybe set `temporary-file-directory'? I always thought it's default value is "/tmp/" while for you it's apparently "~/.emacs.d/temporary/" <alezost>... and yes, you are faster then me :-) <mekeor>alezost: should i leave it to be /tmp or is it fine if i expand ~? <alezost>mekeor: for now you may set it like this: (setq temporary-file-directory (expand-file-name "~/.emacs.d/temporary/")) <alezost>mekeor: no problem, thanks for letting me know about it <HoloIRCUser>Can I run services in Guix as non-root? Something like systemd user services... ***HoloIRCUser is now known as jmi2k_
<alezost>jmi2k_: not exactly, but you can use shepherd to run your user services (that's what I do) <alezost>I recommend to start with a shepherd manual <jmi2k_>jmi2k: for example: "herd start gpm" fails with: "error: connect: /home/jmi2k/.config/shepherd/run/socket: No such file or directory" <alezost>sorry, my keyboard repeat keys sometimes <alezost>jmi2k_: you can't start GuixSD's services as user; you need to make your own shepherd config file with services <jmi2k_>alezost: I'll look in your config, I think it's enough. Thanks ;) <mekeor>btw, i fixed my issue concerning text not appearing on some pages in icecat by changing my default font family from Noto to something different. i'm not sure what causes this issue. anyone using Noto in Icecat? <mekeor>it might be a locale-issue as well <alezost>jmi2k_: well, my config is not simple, I don't recommend to look at it for the beginning :-) Basically, you need to make "~/.config/shepherd/init.scm", then start "shepherd", and then you can use "herd" commands as user <kyamashita>Is there a way to access the source code of another package from within a package definition? <kyamashita>Wait... I found some documentation. Maybe there is another way. Is anyone familiar with the Tcl Extension Architecture? :-D