<buenouanq>I've been using GuixSD as my main driver for about a year now with no real issues. (there was a flub during the switch from Guile@2.0 to Guile@2.2 the waves of which still seem to be sloshing about in some places, but this is the think I can think of)
<lfam>str1ngs: If you installed hello (`guix package --install hello`), a variety of things are done to build the new profile. This includes things like setting up the man page database, some XDG databases, some icon theme collections, etc. My guess is that libpng was required for some program involved there
<str1ngs>that might explain that. I'm overlooking that guix would need some environment
<str1ngs>that makes sense now that you mention it. I was thinking more in terms direct depends.
<lfam>This can result in counterintuitive activity, like downloading some new versions of packages even when removing a package from your profile!
<lfam>That can happen if you do something like `guix pull && guix package --remove hello`.
<lfam>The set of package metadata is first updated, and then a profile operation is requested. There could be new versions of the packages required for the profile operation
<str1ngs>yes, for my worksation I don't mind the extra work. but when I'm on my notebooks it kinda bothers me. since the same operation from my normal distro seems like less work really
<daviid`>the fact that there is no separate guile-gnutls bindings (from gnutls) is a serious problem for me: I just can not install guix because of that (from the source, and I don't want to install the tarball, unless to 'steal' the guile-gnutls modules, which not that easy, it has lib (in C) as well ... very unfortunate
<lfam>daviid`: Can you elaborate? I'm not sure I understand the nature of the problem
<daviid`>lfam: there is no guile-gnutls 'project', you can't git clone guile-gnutls; ./autogen.sh; ./configure ...; make; make install
<daviid`>not confusing, it puts developer like me in a dead end (2y I can't install guix)
<daviid`>str1ngs: it does not matter, but debian. the thing is I don't want guile from the distro ... debian does not have a package but i would not use it if it had, because I want to be in control wrt guile ... a dead end
<str1ngs>yes I agree, but debian does not have a guile 2.2 tls package?
<daviid`>not that I'm aware of: again, if it had, it would ask me to install guile, I don't wna tthat
<str1ngs>I have the same problem on fedora actually. in fact fedora has even less guile support then debina
<str1ngs>if you don't want a distro package. you can match distro version and install with the right install target
<daviid`>as my situation proves... you alwasys must have the optiob to clone the source tree of a 'binding' project and build it locally, always
<str1ngs>it's actually easier to maintain this type of binding.
<str1ngs>again try building libgcc without gcc source tree
<daviid`>ok, I'm off this conversation now, let's work...
<str1ngs>like I hear ya . I think there is stuff here that can be improved
<ng0>hey. is there anyone using fvwm here? I briefly tried updating it to 267 (2.6.7? I make no dots in my branch names) a while ago and didn't succeed for whatever reasons I can't remember building it
<ng0>I should get a server upgrade or extend one of the home servers so that I can build all relevant parts of my branches and point to logs.
<ng0>Using gitlab CI with Docker building Guix to build the thing I want feels extremely wrong on so many levels… but I could try it.
<str1ngs>I was somewhat surprised to see curl fork to be honest
<ng0>it is very likely that we will be using wget2 in the future, but cURL in recent times started to include some of the reasons why the fork started back then before I took over maintainership in their roadmap/todo list.. but one of the ideas requires lots of work in cURL. so it might be more realistic that wget2 will be usable for us before cURL incorporates the proposed ideas of gnURL, making gnURL no longer
<buenouanq>I feel that gnunet is trying to do too much too early - I wish more priority would be given just to solidifying the core and protocols and APIs, and leave functioning clients for later and third parties.
<ng0>It's difficult at this stage of the public presentation of GNUnet to grasp the full scope(?) of GNUnet. I hope to fix that step by step.
<wigust>Does anybody have emacs-24 working on current Guix? I took a recipe from 4c2a38c25f65f7c069228ff923d0ef0785d5f47a but both emacs and emacs-no-x-toolkit segfault on current Guix http://paste.debian.net/998845.
<brendyn>You mention API stability, but the freedom to change the API is cited as the main reason.
<str1ngs>ng0: I do hope to get his fedora issue resolve. it's the least I can do
<ng0>str1ngs: I did not mean to sound sarcastic. I've started the sentence the wrong way
<ng0>it's good that it is in Gentoo. It's just bad that distros try to apply their usual standards to guix as a package
<ng0>that's also why it's not officially in Debian.
<str1ngs>changing guix API is find just have you or fork then. enforcing updating guix just to update packages does not seem logical to me. bare in mind my knowledge of guix as a whole is limited so I could be completely off base here. take this from a new user stand point
<str1ngs>ng0: I don't think packaing guix is nessicary . for me it's the lack of guile 2.2 support. atleast with fedora. I think debian based are better in this regards though
<ng0>2.2 is guile stable release, if that's not in Fedora, this should be addressed
<str1ngs>guile 2.2 is installed but there is no guile tls. and I suspect that some guile m4 macros are not working. or they don't work on fedora
<str1ngs>eg GUILE_PROGS m4 macro does not work on fedora it will find guild 2.2 headers etc but then it gets confused because there is a /bin/guile2
<str1ngs>not sure if this is guile issue in general or fedora related only
<brendyn>Well it's a functional package manager in a very literal sense. changing guix will could change the resulting packages effectively
<str1ngs>dunno if I buy that. I'll take your word on it I guess
<ng0>on a related note, 2.2.3 was released with 2.2 now in in the .pc file of it
<str1ngs>dunno know if that will help. mind you it could. I don't thing this is pc file related though. I suspect it's the ordering GUILE_PROG uses
<str1ngs>I did notice that guix is using GUILE_PKG([2.2 2.0]) though. from what I understand guix does not support 2.0 so 2.0 is not even needed. this would not impact normal users though.. or maybe it does.
<ng0>I'm updating hypothesis, hoping that 3.40.0 fixes what I work with. It requires pytest at runtime, but pytest requires hypothesis, so do we just keep it as it is (not include pytest in propagated-inputs in hypothesis)?
<mb[m]1>ng0: The rabbit hole is even deeper. It also requires python-attrs, which also depends on pytest, which depends on hypothesis.