<ng0>OriansJ: I'm slowly working on getting guix to run on pkgsrc platforms, but that's another kind of thing.. I still have a coupld of guile dependencies to go before I can compile it on netbsd <ng0>because of the compatibility mode of bsd I don't think we would need full native builds, but they would be nice <ng0>at least most bsd based systems I know have linux compatibility <OriansJ>ng0: I thought it was more of a linux compatibility wrapper but anyway; I am hoping the BSDs pick up guix and setup their own binary package servers <ng0>I'm just doing it because i need it to wokr with. because it's pkgsrc I will leave it up to people to switch the location to /gnu/store instead of /usr/pkgsrc/, but have to think about the maximum path length a location in the default pkgsrc prefix could have.. ***malaclyps is now known as ct_twitch
<daviid>OriansJ: had to leave, I'm back. Yes, agreed, which is why I did ask, then I did not recommend ... for the reasons you exposed ... which I agree with <daviid>but maybe, if guix (the pkg manager) is not working 'out of the box' o tp of freebsd, maybe the guix team (so to speak, someone interested I mean ...) should solve this: the easiest it is to recommend to install and us guix for guile newbies and even more advanced, the better ... <daviid>it should become almost automatic: you want to learn, play with or develop advanced apps, libs, any s/w in Guile Scheme, then install Guix, on any distro <OriansJ>daviid: well I agree that guix really could use more help from *bsd developers as it can solve many of the package problems the BSDs have. One must remember, despite the impressive results to date, guix is heavily understaffed. *daviid then have to hide, because he's not sing Guix yet :), just becuse I'm an upsteam guy, working on to many projects, all more complicated then the other, exclusively using the autotool chain (which is fine with me), there are enough guizxers out there, but computer vision, gobject introspection, advnaced lib, far to few, then every minute of my free time is for these projects <daviid>OriansJ: but there are a lot of guixers, where as next to zero extremely impotant lib binding or full scheme projects ... AI, computer vision, advanced Posgresql (and modern, well documented, well tested) bindings, and many many many more we miss <daviid>today, it is impossible to use guile for an advanced project (ok, with the exception of Guix itself): we just do not have the approrpirate bindings, nor full scheme advance libs that can fight aother 'languages out there', and in a few years only, other languages acheived what we still do not. So, every single minute of my free time, I will dedicate to these projects, and let you, wonderfull guixers, package all these, and hopefully my <lsl88>hi guix! a quick question, about environments. If I create an environment, how can I remove it, I mean, I exit, but how can delete it "forever", ie: when I create the environment I start as if I never used before? <iyzsong>lsl88: You don't need, it's just a shell script to setup some variables. Those variables depend guix packages, when the environment is used for the first time, packages are built or fetched. You can run 'guix gc' to free some disk space used by the 'environment', but really it's not needed.. ***ct_twitch is now known as malclyps
***malclyps is now known as malaclyps
<lsl88>iyzsong: I see, but I kind of want to start them over again, just make clean is ok? <lsl88>- I am speaking about guix environment guix - <iyzsong>unlike other virtual environments (python, etc), different guix environments share most (if not every) things in /gnu/store, and is declarctive. <lsl88>I see, that is why I just can exit and that's it, and if I add another "ad hoc" I get they are getting fetched, right? <lsl88>that was a doubt I had from the very beginning <iyzsong>yes, you need to 'make clean' for the workspace for guix, not for the 'guix environment'. <lsl88>thank you :) that was what I needed :) <chrislck>I've messed up installation and wish destroy every trace in my local ubuntu build. <chrislck>rm -rf /var/guix, and /gnu, and what else? <chrislck>cool thanks... messed up my previous install and couldnt' reinstall <chrislck>ack same error as before - glibc-utf8-locales ***rekado_ is now known as rekado
<rekado>reinstallation rarely ever solves problems <rekado>the locales thing is mentioned in the manual <chrislck>a bit more complicated that I'd hoped for <pkill9>chrislck: where are you trying to instlal locales? and why aren't you able to? <chrislck>perhaps the manual needs reading carefully <efraim>the last line suggests the guix-daemon isn't running <olivuser>Hello everyone. So I tried to run guix system disk-image to generate an image file. I tried both directly writing on a stick or not doing so - in both cases, my computer (i7 4660 processor) froze. Is my machine just too slow to run such commands, or am I doing something wrong? <OriansJ>daviid: you might be right; I did git log --format='%aN' --since=30.days | sort | uniq -c | awk '{if($1 > 75) print $0}' | wc -l on netbsd's git history and it looks like the netBSD team is just 2 people larger than the guix team (in terms of active members) but they also look like they are less active in general than guix developers. <nckx>olivuser: Your computer is certainly not too slow (and even if it were, it'd be just that: slow). That shouldn't happen. Is there anything in your system's logs about what went down? <OriansJ>olivuser: Generation of an image file happens on machines that are more than a decade old; now depending on if you are building packages like chrome or firefox into your image, there may be a extremely high memory pressure which could result in your system hitting a memory exhustion condition. <olivuser>OriansJ: alright, so I would have to take packages like icecat or texlive out of my config file? <OriansJ>olivuser: well, see what happens when you do; if you still have have trouble then I was wrong and we would need to look at other possible causes. <ng0>OriansJ: but you are comparing packaging and a base of an OS. pkgsrc + pkgsrc-wip compared to guix' gnu/ directory would be better I guess? <OriansJ>ng0: yes that absolutely would be a more direct comparison but it would make the results even more lopsided with Guix absolutely domininating pkgsrc in terms of active developers and in number of commits per day. But somehow I don't think the *bsd are likely to realize it yet. <efraim>Are there more Guix contributors than pkgsrc? <OriansJ>efraim: git log --format='%aN' --since=90.days | sort | uniq -c | awk '{if($1 > 20) print $0}' indicates yes <phenoble>So I have this private git repo from which I'd like to git-fetch in a package declaration. <phenoble>How do I do that? Looks as if that's not possible. <efraim>If you trust your store to stay private you could pre-fetch it and set the source to a location in the store <OriansJ>phenoble: are ssh keys not an option? <phenoble>efraim: Yes, that'd be an option, thanks - though I'd like to have this fully automated. <phenoble>OriansJ: Ah, right. Yes, that'd be probably be the clean way to do this. <phenoble>OriansJ: I forgot about ssh keys for git, thanks <efraim>I'm not sure but I think rakudo needs perl6 libs to run the tests <OriansJ>efraim: after double checking with https://github.com/NetBSD/pkgsrc the numbers are closer than the previous estimate; I'm guessing the other repo was a little bit behind. It however is a close race right now (21 vs 26 active contribs) if we assume the listed URL is the most accurate date of pkgsrc development progress (I am using git://git.sv.gnu.org/guix.git for the guix metrics). <efraim>Also I saw a commit that pulled in some of ng0's work from the wip tree <efraim>I only have the git mirror but I don't remember who was listed as the author <ng0>pkgsrc is CVS, github is only synced occasionally. pkgsrc-wip is git <ng0>pkgsrc-git totals to 502 authors <ng0>but i don't know what you're discussing, I just find stats comparisons a bit alienating in volunteer projects <lsl88>hi guix! is sb online to help me with gpg keys? <janneke>perl: warning: Please check that your locale settings: <chrislck>small update - I had locale problem because my locale is en_AU.utf8 and looking at lib/locale/2.28 there's no en_AU.utf8 there. <chrislck>anyone knows a good video of intro to guix compared to regular unix distributions? a trailer of sorts <quiliro>On Emacs I still cannot export to PDF even after: texlive-bin texlive-latex-tools and texlive-latex-base, have been installed <quiliro>I can't find the base file `mf.base'! <quiliro>! LaTeX Error: File `graphicx.sty' not found. <kmicu>Hi quiliro, it looks like texlive-latex-overpic has graphicx. Could you add it and try again? <rekado>chrislck: the problem is with glibc-utf8-locales. <rekado>chrislck: it only contains an arbitrary subset of utf8 locales. <rekado>chrislck: install glibc-locales instead. It contains all locales, including yours. <nly>Hi, is pierre neidhardt here? <thorwil>hi! i have an issue with inkscape's png export, which is affected by the version of pixman <thorwil>currently packages is pixman 0.36.0, the one i'd have to try is the very latest, 0.38.0 <thorwil>i guess i could inherit the package and just change the version and hash? <thorwil>but i wonder what a chain of packages having to be rebuild migt be caused that way <cbaines_>thorwil, unless there's a reason not to update pixman in Guix, you could look at upgrading the pixman package within Guix? <cbaines_>guix refresh -l pixman will help understanding the effects on other packages <thorwil>"Building the following 1216 packages would ensure 3262 dependent packages are rebuilt" <cbaines_>That's a lot, like a third of the packages in Guix! <nckx>On to core-updates it goes. <cbaines_>This could be why it's a bit out of date. ***cbaines_ is now known as cbaines
<nckx>commit 35b259eed055e288eadb2365b5ab4e8b15f363a7 | gnu: pixman: Update to 0.38.0. <nckx>It's already on core-updates. Nothing to do but wait. <thorwil>i wondered if i could change the inkscape package to have its own pixman, but of course pixman is _not_ a direct dependency <cbaines>thorwil, as it's on core-updates, you could try using Guix from core-updates. That should provide inkscape using pixman 0.38.0. <nckx>thorwil: Or you could use a ‘replacement’ package on your box to graft the changes *if* the two pixmen are binarily compatible. <nckx>Hackery will be involved. <mbakke>thorwil: Another option is to create a "pixman-0.38" package variant that inherits from pixman. See e.g. enchant-1.6 from enchant.scm. <thorwil>mbakke: wouldn't that mean that i also need variants of those innkscape dependencies that depend on pixman? <mbakke>The package-input-rewriting method might come in handy... :) <ym555>wow worst place this could happen in <OriansJ>ym555: no that would be in #windows; here we get along great with the #nix group