<sneek>nckx, lfam says: No, nothing in particular. I just wanted to be sure we weren't missing any important bug fixes. Sometimes projects see no official activity for years while the distros patch critical bugs. So you get something like Jasper, which we added the latest release of before realizing there were many unpatched bugs
<nckx>Ooh, just in time for ML holy war discussions.
<lfam>Heh, I'm never sure how to leave notes for idle people
<nckx>lfam: I run an always-on (and Guix-powered! whoo) ZNC instance, so should see everything eventually. But in general: nope, no clue.
<Apteryx>What happens when we "refresh" a package in git (bump its source url/version/hash) ? Does this new version replace completely the "older" version, i.e. make it impossible to install the older version?
<geemili>I'm trying to install gnome-terminal, but it says gnome-terminal not found. How do I fix that?
<Apteryx>geemili: What command are you running exactly?
<geemili>Apteryx, I am running guix system reconfigure
<geemili>I'm trying to specify it in a manifest file
<Apteryx>guix system reconfigure /path/to/your/config.scm ?
<Apteryx>And in your config.scm you have gnome-terminal listed in the (packages ) sexp?
<Apteryx>And did you not forget to put gnome in the top defined (use-package-module ... gnome)
<Apteryx>Otherwise the gnome-terminal symbol would not be defined, I think.
<geemili>Apteryx, I have to put gnome in the (use-package-module)? How do I figure out which package module a package is in?
<Apteryx>Will open the definition of the 'gnome-terminal'. And at the top of the file there should be a line like: "(define-module (gnu packages gnome)"
<Apteryx>This tells you that this package lives in the (gnu packages gnome) namespace.
<Apteryx>or gnu.packages.gnome module if you want a Python equivalent
<Apteryx>Normally you'd have to use (use-module (gnu packages gnome)) at the top of your config.scm to make the gnome-terminal symbol (definition) available, but there is syntactic sugar to make this more concise: (define-syntax-rule (use-package-modules module ...)
<Apteryx>Or, if you don't like the idea of having to hunt for the location of a package definition, you could also use the specification->package procedure which will resolve this for you. You'll want to read about it in the "7.2.1 Using the Configuration System
<civodul>seems to be similar in spirit to 'guix lint -c cve', if i read correctly
<ng0>I'll deactive/delete my github account once more, so the open issue on pybitmessage and pyqt4, I hope I can communicate it this time outside of github, last time this way of communication was succesful but not very efficient. But I know we have some people here using github, so if they insist on github, I'll point it out here if necessary.
<efraim>I think I have a working patch for CVE-2016-9082 against cairo, i'll post it to the list soon-ish
<sirgazil>Are packages supposed to have unique full-name values?
<bavier>sirgazil: yes, in order to avoid name conflicts in the UIs
<sirgazil>I'm trying to fix an HTML validation error on Guix website that involves duplicated IDs. Package names are used for anchors, but I get duplicated <package> objects (ruby-2.3.2) and duplicated full names (ruby-2.3.2, llvm-3.7.1, gfortran-4.9.4, armadillo-7.500.0)...
<sirgazil>bavier: Oh, really? Then the code in the website may be doing something wrong...
<bavier>sirgazil: well, it's not enforced per se, so its possible there really are some name conflicts
<sirgazil>civodul: Yes, exactly. I don't know why that is happenning. Although it may be that packages page has the duplicated IDs as well, but the validator does not show them because it chokes with that huge page (9.9 MiB) :)
<paroneayea>jmd: I did do that, though after reading the recent stumpwm post on the list, I was wondering if the reason why I didn't get it working was because I put the stumpwm package in the operating-system definition and not specifically the bin output
<paroneayea>davexunit: I have a networked printer I print to in debian fine
<paroneayea>I think we're missing the foomatic files for it to work in guixsd
<ng0>one of our prototypes needs to be build with rust, so I'm interested but I have very little experience with rust. it depends on what needs to be done
<dvc>it's been a while, I need to refresh my memory on the issues that came up. bundling the cairo dependencies into a tarball would make a lot simpler
<ng0>maybe you can take your time, refresh the issues, list them, write them to the mailinglist and people can pick them up. I don't think i'm the only one interested in this
<dvc>the problem with packaging any modern language is that they have 100's of dependencies, and you can't just use any version. so my naive importer simply imported the latest, and that leads to problems
<paroneayea>but it wouldn't specifically be a guix talk (though that would be a component of "lisp as the gnu machine today") but also would be looking at lisp machine history (from my ameteur research)
<Apteryx>Hi. I just updated python-pip to version 9.0.1. When I do: "pip list", there is now a warning output at the beginnig of the installed packages, which reads: DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
<rekado>would be neat if we could automate building updated packages automatically.
<Apteryx>rekado: Another thing, I saw that pypi importer seems to always list the inputs as "propagated-inputs" rather than just "inputs". So to make things right human intervention is still necessary.
<Apteryx>Not sure if you have such a limitation with your CRAN imported.
<rekado>re lisp machine: AFAIU what’s great about them is that anything you can see can be inspected and modified as a lisp object. We have something like that with Emacs, but we lack a blissfully tweakable system like that outside of Emacs.
<paroneayea>rekado: indeed, that's one nice thing about them
<paroneayea>not the only nice thing, but maybe the nicest :)