<lfam>What do you mean by "more readily available"? It seems easy to install it with Guix <lfam>The dependency comes from `guix pull` fetching the Guix source code from a Git repo <str1ngs>do you mean I can just do guix package -i guile-git and that will provide the dependancy needed fro guix pull? <str1ngs>I'm trying with guile-git environment. see if that works <str1ngs>I guess my understanding was wrong. I thought without guix pull I could not install guile2.0-git <str1ngs>which made this seem like a chicken/egg problem <str1ngs>ya I think this still the case, since without guix pull. guile2.0-git is non existant <str1ngs>I think how I got around this before, was I build guix from git , and install guile2.0-git by hand <str1ngs>please correct me if Iam wrong though <lfam>Indeed, guile2.0-git was added after the last release. At that point the full set of Guile 2.0 dependencies weren't yet packaged. But there is guile-git, which uses Guile 2.2 <str1ngs>mind you I might actually need to install guile as well <str1ngs> lfam ya I think I need to build guix from git to get around this <str1ngs>the guile2.0-git does not seem to get satisfied other wise. <lfam>Hm. civodul, any advice for str1ngs, who is unable to install guile-git and thus cannot `guix pull`? Was there some specific commit they need to pull from? <lfam>Like, `guix pull --commit=deadbeef && guix pull`? <lfam>Or maybe they are missing some environment variable <civodul>lfam: good question, sirgazil reported a similar issue a while back <lfam>Okay, I can look in the old bug reports <civodul>i don't have any ready to use solution though :/ <civodul>perhaps picking an appropriate commit for which guile-git is known to build well <str1ngs>the problem is that you need guix pull in order to get guile2.0-git <lfam>I'm confused about why it wants guile2.0-git instead of guile-git <str1ngs>probably because pull comes from master <str1ngs>not sure what the difference is from guile2.0-git and guile-git <lfam>On the master branch Guix uses guile-git <lfam>One is compatible with Guile 2.0, the other with Guile 2.2 <lfam>Take care to sanitize the last one appropriately <lfam>Hm, what if you try the recommendation in that message? <str1ngs>I did do that, but really its not effective since my version of guix is already 0.13.0 <str1ngs>I surprised this has not come up before. <lfam>What is the stable tarball? You mean the 0.13.0 release? <lfam>Okay, and what is `guix --version`? <str1ngs>which does not list that from --version btw <str1ngs>probably because I had to autoreconf <str1ngs>I can rebuild without autoreconf I guess <str1ngs>I don't think that's the issue here though <str1ngs>ya if I don't autoreconf the m4 macros wont find my guile2.0 and if I install guile22 I have to rebuild gnutls with guile support since there is no guile tls package for 22. <lfam>What do you mean? Does the Guix package guile2.2-gnutls not work for you? <str1ngs>there are a couple of factors here. my distro which fedora 27 does not have a guile gnu-tls package. so I can not build guix with guile2.2 <str1ngs>atleast it does not have a gnu-tls for guile 2.2 it only has it for guile 2.0 <str1ngs>so I guess with I do guix pull it tries to use guile2.0-git instead of guile-git? <lfam>It sounds like you built Guix based on Guile 2.0, so it needs the Guile 2.0 versions of its dependencies <str1ngs>I could possibly rebuild guix from tarball using the install guile gnutls <str1ngs>actually I could install all depends for guix master and just build it from git <str1ngs>but it's quite to bootstrap process. I don't see a normal user figuring this out easily to be honest <lfam>I think many of us started with the binary rather than the source tarball <str1ngs>I think even with the binary this could be an issue <str1ngs>maybe not, I should sandbox test the binary install <str1ngs>the binary would still need guile2.2 and guile gnu-tls 2.2 off hand <str1ngs>which means I need guix built with 2.2 I guess <lfam>Right, that's because you configured Guix to use Guile 2.0, which was not officially supported for the 0.13.0 release <lfam>We don't have Guile 2.0 package variants of all the Guix dependencies at the 0.13.0 release tag <str1ngs>at some point I'll have to go back to my distro and resolve the fact they dont have gnu tls 2.2 . actually there guile support is pretty shitty <str1ngs>I'm still concerned with this guile-git dependency. seems like an added pain point for anyone building from source. but I'll assume you guys know what you are doing :P <str1ngs>lfam: alright, I thing I figured this out. thanks for your patience <str1ngs>buenouanq: I dunno if I'll do that quite yet. personally if guix had <str1ngs>faster mirrors and was more streamline I'd be more inclined maybe <lfam>Dealing with this new dependency has been a pain point in a few ways. Sorry about that :/ We know there is room for improvement with `guix pull` and deployment in general <str1ngs>like I installed the hello package and somehow libpng was installed. which seemed odd <str1ngs>don't mind me I'm an anal retentive user. I'm kinda picky so forgive my criticism <lfam>You can inspect a variety of types of reference graphs with `guix graph`. This should help explain why that happened <str1ngs>well, I'll invest more time into using guix atleast <lfam>I don't know off-hand why, but I do know that libpng is a core dependency. Most if not all of the system depends on it indirectly <str1ngs>libpng core dependency seems odd to me <lfam>Not technically "core" but very low-level <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 <lfam>Or "derivations would be built" :p <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 <daviid`>I talked to civodul about this a long time ago, but failed to convince him to change that and make guile-gnutls a full idependent project, that would be the only solution <daviid`>str1ngs: I want: git clone guile-gnutls; bootstrap; configure; make; make sitall <str1ngs>that still dependant on the gnutls sources though. I mean libgcc does this aswell <daviid`>I already have gnutls and gnutls-dev here, I have guile, gcc ... <daviid`>str1ngs: all bindings on earth depend on you to have the correposning lib installed, that is perfectly fine :):) <str1ngs>right but this is distro issue though <str1ngs>like my distro does have split package for guile-tls but only for guile2.0 <daviid`>it is not a distro issue, yu did not get it yet <daviid`>i do not want to rely on debian for that <str1ngs>why not they split package libgcc it's the same effect <str1ngs>no different the splitting header files ala -dev <daviid`>as i said, i failed to convince the authors <daviid`>nerver mind, go back to work now ... <str1ngs>I do think some work could done to make this easier across the board though <daviid`>only guile-gnutls authors can solve this problem <str1ngs>well when all the guile uses only use guix that compounds the problem aswell <daviid`>what is difficult to understand is that not only guile-gnutls is not a separatepackage, but guix source tree does not provide it <str1ngs>daviid`: if you had a way to only install guile-tls would that resolve your problem? <str1ngs>well technically guile-gnutls is configuration option for gnutls <str1ngs>I mean if I really looked I bet it's also an install target <str1ngs>which means you can built it out of the gnutls source tree and install only the bindings <str1ngs>assuming you kept version matching in effect <daviid`>str1ngs: let's move on to work again, nice of you to try to help, but you won't solve this for me I'm afraid :) <str1ngs>well Ideally your distro should split package it, just like they do for libgcc <str1ngs>I know you dont' agree on that point. but that is the right way to handle this <daviid`>str1ngs: yu don't understabd, I don't want a distro package <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. <ng0>welll... so it did build. <ng0>rebasing after months helps <str1ngs>ng0: I generally offload my building to my powerful workstation. not just guix specifix <ng0>I'm just looking for general CI at the moment. The moment cuirass can build more than just guix specific stuff I'd give it a shot. For now I'm using our Gitlab instance <str1ngs>CI is bit different I guess, I was think more for user land installs <ng0>for me CI is more useful. I have around 75 branches and 6 GUIX_PACKAGE_PATH repos <ng0>that's just the guix work <ng0>gnURL is now building on our Gitlab, aswell as 2 python modules I work on. There's much more I need to load off and build and check somewhere <str1ngs>I was reading about gnurl the other day <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 <str1ngs>my understanding is gnURL is mainly for GNUnet? <ng0>it's basically open to use for anyone who wants to use this subset of cURL in their code <str1ngs>right, just I thought GNUnet wast the driver for it. <str1ngs>maybe because I read your blog on gnunet.org <ng0>it originated within GNUnet, yes <ng0>and is a project within GNUnet (but located on the git of taler at inria (for whatever reason)) <str1ngs>we need something like the dat project or ipfs <str1ngs>not sure if you are familiar with those. GNUnet has similar features <ng0>GNUnet has goals and functionality beyond those <str1ngs>I like the idea of content addressing and name resolution <str1ngs>I need to play with GNUnet some I think <str1ngs>also libchop was way ahead of it's time. but seems to not be actively maintained? <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. <str1ngs>I just quickly looked over its' features . was impressed with what I saw though <ng0>I'm rewriting the Documentation, I'm working on the new website, on rewriting the testsuite, fixing up the python code, trying to get the guile bindings p again, etc <ng0>researching into OR for GNUnet <ng0>also the FS integration thing for Guix in the long-term <ng0>it's just that someone needs to care for them and extend them. <str1ngs>p2p distributed guix derivatives would be assume <ng0>as well as the python, java etcbindings <ng0>the most active work is rust bindings, which are not yet publicly released <str1ngs>does gnunet have a protocol prefix ? like ipfs:// or dat:// <str1ngs>reason I'm asking is I'm writing a web browser in C and guile scheme. and I want to eventually add p2p support <ng0>uh. no idea right now, iirc yes in FS but I'd have to look it up. You know when you are watching and reading something daily sometimes you forget it exists :) <ng0>You could send an email to the gnunet-developers@gnu.org list asking, because I'll go to bed now <str1ngs>no worries, this has me intrigued though. if i can add gnunet support to my browser that would be fun <ng0>actaully I think you shouldn't have to. or at least I'd need more info to tell you wether you are approaching this right or wrong for GNUnet. <ng0>but, Iwon't answer anything of reasonable after 2 AM :) <bavier1>oh cool, the Guix group is featured on Libreplanet.org this month <ngz>Hello. "./pre-inst-env guix build <package>" exits with error "guix build: error: gnu/packages/xdisorg.scm:292:2: package `libdrm-2.4.83' has an invalid input: ("pkg-config" #<syntax-transformer pkg-config>)". <ngz>I cannot remember the steps used to "repair" pre-inst-env. How could I do that? <ngz>(repairing, not remembering, which is bound to fail) <wigust>ngz: Hello. syntax-transformer is related to macro expansion, I guess. But I'm not sure what *.go file fails. Maybe pkg-config.go <wigust>ngz: So removing gnu/packages/pkg-config.go may help. <brendyn>Has anyone tried packaging mist/geth ? Looks like it might require a lot of work <efraim>sneek: later ask ng0 were you working on kdenlive or just pitivi? <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. <rekado>wigust: is this on i686 or x86_64? <efraim>i switched my aarch64 build machine to `guix build --no-grafts --keep-going $(guix package -A | cut -f1,2 | sed -e 's/\\t/@/')` and i've made it to the <wigust>The only thing I changed is input libjpeg-8 -> libjpeg <wigust>ACTION thought that libjpeg-8 may missing, but it's not true. Fails to build with libjpeg-8, too. <rekado>is the Emacs package in Guix segfaulting or a modified version? <rekado>oh, I didn’t realise that 24 isn’t 25. <ng0>hey! so for a test (before rewriting it) I need access to dbus' system socket. is this possible in Guix builds with python or do I need to ignore this test for now? <sneek>Welcome back ng0, you have 1 message. <sneek>ng0, efraim says: were you working on kdenlive or just pitivi? <ng0>dbus.exceptions.DBusException: org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory <ng0>efraim: still not finished as I'm still searching for the solution to the last bug <ng0>seems impossible with guix build env <ng0>there's a solution in gtk.scm, but idk if that can be applied to my situation <ng0>aha, the pythonic way is to use dbusmock I guess <str1ngs>what mess I had to build guile 2.2, gnutls with guile 2.2 support. and physically delete guile 2.2 files just go get guix to build so I can guix pull sanely <str1ngs>none of that probably made sense, I'm just venting <str1ngs>also since guile 2.0 is not supported . configure.ac should probably not even check for guile 2.0 I guess <catonano>str1ngs: I run into missing guile-git for pulling too. I just keep a local guix checkout and I use that to guix pull <catonano>str1ngs: maybe it's corner cutting. That's just what I do <str1ngs>it's not really guix fault. partially my distro's fault. I'm working to resolve it once I grasp these scope of issue <str1ngs>personally I think separating the package modules out of guix would help alot of theses. issues. I would thing guix api is stable enough at this point <str1ngs>updating guix just to get package updates. creates bootstrapping issues <str1ngs>I'm not sure if that could even be done. so don't mind my ignorance <brendyn>It's been discussed many times and devs are penerally against it. <ng0>or whoever maintains it :) <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. <civodul>ACTION thinks he caught the bug that broke the installation tests <mb[m]1>Not sure what the best version string for glibc is. 2.26.0-91-gaa.. perhaps? <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. <ng0>I noticed that but did not drew the strings to look into it.. <mb[m]1>ng0: I have a WIP branch for hypothesis and will try to push it to core-updates ASAP. <ng0>highly appreciated, as I want to work with hypothesis <ng0>it's no rushing matter though, I first need to read more into hypothesis and learn <ng0>QuickCheck is really fascinating :) <mb[m]1>civodul: Let's also update glibc to 105-g0890d5379c. <civodul>what's 105-g0890d5379c? the latest known-good commit? <mb[m]1>It's the tip of the 2.26 branch. The problem was with LOCPATH. <civodul>PASS: /gnu/store/5ij9lw604gx0g2hl5nq09m2n40dk3d19-iso-image-installer ***pksadiq_ is now known as pksadiq
<cbaines>civodul, I'm having a problem with the profile change made earlier <cbaines>ERROR: Wrong type (expecting exact integer): line <efraim>Same, but I have to admit I try not to run 'make clean' if I can help it <cbaines>efraim, if your talking about the setvbuf issue I mentioned, I've tried running make clean, but I still get the problem <civodul>what's the derivation that triggers this? <civodul>normally the profile derivation runs on Guile 2.2 <cbaines>looks like I'm getting the issue using guile-2.0.14 her <civodul>like "guix package --bootstrap" or something? <civodul>cbaines, efraim: fixed in 2815fca1423cf72e6f3d0e774f1058bcbf8dfdbf :-) <civodul>cbaines: so that was "guix environment --bootstrap", right? <cbaines>the exact command I was using was: guix environment --fallback --pure --container -N guix <civodul>oh, 'guix environment' and 'guix package' were still using 2.0 as the guile-for-build <civodul>switching to 2.2 makes things a bit faster: <civodul>"time guix environment guile -- true" is 2.5 seconds now, was 3.3 seconds <ng0>did the OpenNTPD service already land, or did I imagine that? <OriansJ>civodul: nothing is faster than the code that doesn't have to run <ng0>oh, there is something even faster: the code that wasn't written so it is much smaller in size and executes faster than non-running code <OriansJ>ng0: you are absolutely right, how did I miss that? <ng0>I'll have to revisit and finish the tlsdated service, so that's coming at some point aswell.. will openntpd be in something like gnu/services/time.scm ? Otherwise I'll move it there when I rebase