IRC channel logs

2016-03-25.log

back to list of logs

<jmarciano>what would be in Guix, a command to list the files belonging to a package?
<rain1>jmarciano, one easy way is
<rain1>find $(guix build which)
<jmarciano>that is for one file
<jmarciano>in Debian, if I do: dpkg -L package-name, I get list of files belonging to one package
<jmarciano>btw, how do you make package definitions, do you use emacs, or directly in some editor?
<str1ngs>files are sored in the store. I you konw the location in the store, you can just use find
<str1ngs>e.g. find /gnu/store/cf2pqc3xg14qpcpjc32xd65r51lsrd16-which-2.21
<jmarciano>aha, yes sure, I will make function for that.
<jmarciano>I guess that should be in guix package manager
<rain1>emacs
<jmarciano>aha thanks, good to know
<str1ngs>just keep in mind you need the right hash
<str1ngs>you can have many versions of which only one of which is being used by your profile
<jmarciano>rght hash is for the hash of package from sources?
<jmarciano>I mean, I have much to read, now it works, I can load guix into guile, before I could not. I feel power now.
<jmarciano>and emacs features for package management are great, I don't need any more to work in console
<str1ngs>readlink -f $(which bash)
<str1ngs>would give you the store path
<str1ngs>from there you can use find.. so...
<jmarciano>yes like that
<jmarciano>only tht shall be in a function, implemented in guix, like guix package --list-files bash
<str1ngs>maybe I don't know enough about guix yet to comment on that.
<str1ngs>this is not pretty...
<str1ngs>find "$(readlink -f $(dirname $(which bash)))/../"
<str1ngs>and this does not work for packages that do not use PATH
<rain1>hehe
<rain1>hack!
<str1ngs>aye very much so :P
<rain1>I'm hoping I can get IPFS working on guix
<rain1>has anyone got that gonig?
<str1ngs>I could
<rain1>seems like gccgo is different to the go they use...
<rain1>so it might not build
<rain1>trying anyway
<str1ngs>use go
<str1ngs>oh ipfs is not easy to build
<str1ngs>I need to get wpa-supplicant into my guixsd install
<str1ngs>when you set get it working what do you mean?
<str1ngs>say*
<rain1>oh just built and running correctly
<str1ngs>one sec I'll build it. and explain how to do it. I should keep better notes :(
<str1ngs>with go most binaries just work. to the binary downloads are viable
<rain1>str1ngs, I just asked in #ipfs and it seems like they use a different compiler than gccgo
<rain1>so it probably wont work on guix
<str1ngs>guixsd?
<rain1>yes
<str1ngs>just use the golang tool chain
<str1ngs>is there a golang package?
<rain1>I might try to use gccgo to build golang
<str1ngs>no need too.
<str1ngs>just use gcc
<rain1>I'll try
<str1ngs>also gccgo is just a frontend. so its actually using most of the golang source anyways
<str1ngs>git clone http://golang.com/golan/go ~/go
<str1ngs>you need to bootstrap it but that pretty easy
<str1ngs>just checkout go1.4
<str1ngs>use go/src/make.bash then copy ~/go to ~/go1.4
<str1ngs>clean out ~/go and checkout tip
<str1ngs>then rerun ./make.bash on tip
<rain1>ill try it!
<str1ngs>hmm there is no golang package
<str1ngs>I guess you could though install gccgo and then use the go tool.
<str1ngs>that should just work
<rain1> https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00428.html
<rain1>this whole thread about golang
<rain1>but it's not actually in guix ?
<str1ngs>maybe I'm searching wrong :(
<rain1>str1ngs, no you're right its not in packages..
<rain1>i wonder why
<str1ngs>it's not easy to package . its not very FHS friendly :(
<str1ngs>but would not matter with guix I would think
<str1ngs>let me try the gccgo package
<str1ngs>and hope guix doesnt want to build the world :P
<str1ngs>personally with go I just use $HOME/go
<iyzsong>morning guix!
<rain1>good morning
<rain1>str1ngs, yeah i've been building gcc for a while :)
<str1ngs>gccgo 4.9 :(
<str1ngs>5.3 or bust baby!
<str1ngs>the edge shall bleed
<str1ngs>rain1: did you do a guix pull?
<str1ngs>cause that helps alot
<rain1>yeah
<rain1>I think
<str1ngs>package defintions are compiled along with guix if I understand right?
<str1ngs>gccgo 4.9.3 is to old I would thing
<str1ngs>think*
<str1ngs>rain1: I would use $HOME/go for now
<str1ngs>building the golang toolchain is pretty trivial.
<str1ngs>its using go 1.2 you want atleast go 1.4
<rain1>damn does that mean im out of luck+?
<rain1>maybe we could upgrade the gccgo package
<str1ngs>its upgraded with gcc
<str1ngs>so when gcc gets bumped so with gccgo
<str1ngs>will*
<str1ngs>but just use $HOME/go . with golang reference toolchain
<str1ngs>also you can build on one machine and just copy to another. provided glibc is not that old
<str1ngs>even then you can force a static build without glibc
<str1ngs>it only uses glibc for nss. and go has a built in one if you tell it to use it.
<str1ngs>sorry resolver not nss
<rain1>bash: gccgo: command not found
<rain1>but i installed it?
<rain1>maybe i only built it
<str1ngs>what about go
<str1ngs>$(which go)
<str1ngs>err $ which go I mean
<rain1>there's no binary
<rain1>that's weird!
<str1ngs>its possible with 1.2
<str1ngs>gccgo didnt always use the "go" tool
<str1ngs>hydra.gnu.org is to flaky how do I change to use mirrors?
<rain1> https://gitlab.com/rain1/guix-wiki/wikis/FAQ
<rain1>here are a couple mirrors listed
<str1ngs>thanks
<str1ngs>whats the hash for your gccgo build?
<rain1>/gnu/store/1xsd8qd6i0zkzwxa53rp5palcfxb7xqb-gccgo-4.9.3
<rain1>it's got ./libexec/gcc/x86_64-unknown-linux-gnu/4.9.3/go1
<rain1>go1: internal compiler error: in go_langhook_post_options, at go/go-lang.c:264
<rain1>Please submit a full bug report,
<rain1>this package might be a dud
<rain1>I think I should report it maybe
<str1ngs>let me check it out
<str1ngs>but IMO 4.9.3 is a waste of time in terms of gcgo
<rain1>sure
<str1ngs>and using $HOME/go is best approach
<rain1>we just want to get a bootstrap chain going
<str1ngs>bootstrap chain for guix?
<rain1>gcc < gccgo < golang < IPFS
<str1ngs>golang < IPFS
<str1ngs>less work
<str1ngs>golang toolchain builds in less then a minute
<rain1>what do you build it with?
<str1ngs>it uses gcc
<str1ngs>but just for some bootstrapping. most is in go theses days
<rain1>ah so building it from c compiler output
<str1ngs>so its pretty much self hosting
<str1ngs>it mainly need a c compiler for cgo
<str1ngs> https://golang.org/doc/install/source
<str1ngs>my way is easier though :P
<str1ngs>I just build go1.4 form the git repo. then cp it to ~/go1.4 then checkout go1.6 and build it with ~/go1.4
<str1ngs>want a script?
<str1ngs>:)
<anthk_>doesn't go get do everything automagically?
<rain1>im trying gccgo-5
<rain1>if that gives me aworking go to bootstrap golang then I will be good
<rain1>if not i will give up
<sapienTech>hi there, just checking to see if my GSOC proposal email went through
<sapienTech>im looking at the logs and i don't see it :(
<mark_weaver>sapienTech: without knowing your email address, I cannot say.
<sapienTech>applogies, sapientech@openmailbox.org
<mark_weaver>sapienTech: did you subscribe to the list before sending it?
<sapienTech>yrd
<sapienTech>yes*
<mark_weaver>yeah, I don't see it
<mark_weaver>when did you send it?
<mark_weaver>the first email sent to the list might be delayed. I'm not sure how it works.
<sapienTech>hmm strange, i sent it 5ish hours ago
<lfam>My experience is that the first email can be delayed for a long while
<cehteh>greylisting
<mark_weaver>does GNU use greylisting?
<mark_weaver>(I'm familiar with it; I use it on my own mail server, but I wasn't aware that GNU used it)
<cehteh>dont know, but delaying the first mail would explain that
<cehteh>also its still quite effective
<efraim>looks like gstreamer 1.8 is out
<civodul>Hello Guix!
<jmarciano>I am searching for a link that explains how GNU free software shall be packaged... if somebody knows
<janneke>jmarciano: you may be looking for https://www.gnu.org/prep/standards/
<jmarciano>very nice, for one nice person who wish to develop new software thanks
<civodul>request for testing! https://www.fdn.fr/~lcourtes/software/guix/guixsd-usb-install-0.10.0pre.x86_64-linux.xz
<davee__>gsoc
<civodul>what do people think of https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00674.html and the diagram therein?
<rekado>I find the diagramme confusing, to be honest.
<rekado>Why are there arrows from "developer" to "build daemon"?
<rekado>and what is "system profile" in the "guix installed on GNU/Linux"?
<rekado>I don't think it is a good idea to put both GuixSD as well as "guix installed on GNU/Linux" in the same diagram.
<rekado>what do the arrows mean?
<jmarciano>Guix package manager is better to tell to people, to avoid confusion.
<jmarciano>and there shall be GNU Operating System somewhere on top of GuixSD
<civodul>rekado: yeah, i had that feeling too
<rekado>what is the significance of the connection between "The Store" and "System Services"?
<rekado>I don't really understand what the diagram wants to tell me.
<civodul>right
<rekado>also hydra looks really important, being central and all.
<civodul>yeah
<civodul>i like the idea of having illustrations, but this one doesn't look good to me
<rekado>I wonder if it could be improved. Or if it would benefit from not trying so hard to explain everything.
<rekado>it looks like it explains a lot if I would just take more time to absorb it, but there are many things it doesn't even mention.
<rekado>What I don't see in the GuixSD case, for example, is why I would even want to use GuixSD over "Guix installed on GNU/Linux".
<rekado>it looks exactly the same.
<rekado>so in GuixSD the system profile is in the store.
<rekado>big deal.
<rekado>and the system services have a different colour.
<rekado>it doesn't show me that the whole system is in the store and "checked out" on boot.
<rekado>so maybe there is no value at all in showing GuixSD vs Guix+foreign
<rekado>not in the same diagram anyway
<civodul>yeah
<civodul>oh well
<rekado>not sure how to put this in a more constructive manner, though.
<civodul>wget -q -O - http://sph.mn/o/bs
<civodul>"access pipeline rules and develop first-class value-add management and increase sales"
<civodul>"create and provide premium world-class point-to-point channels"
<rekado>:)
<civodul>davexunit, rekado: what's up with guix-web? :-)
<civodul>the world (notably jmarciano) demands it!
<civodul> http://bugs.gnu.org/22972
<davexunit>civodul: heh, well, it needs a lot of work!
<davexunit>I'd like to find a better javascript library for the FRP stuff, for one thing.
<civodul>OTOH for the purposes of browsing the package list, it seems to be doing ok no?
<davexunit>yeah it works OK for that
<civodul>oh but we'd need a way to take the package list from a separate process
<civodul>so that it can show the latest list without having to be restarted
<davexunit>loading the package list is starting to get long :)
<davexunit>civodul: that's pretty easy to do
<civodul>good
<davexunit>just hit the package list endpoint again
<davexunit>and stuff it into the package list "signal"
<civodul>what do you mean?
<davexunit>which will propagate
<civodul>oh
<davexunit>the user could hit a button to refresh the package list a la pressing 'g' in a emacs list buffer
<civodul>oh but we're miscommunicating
<davexunit>oh
<civodul>i was referring to the server
<davexunit>ohhhhh
<davexunit>of course
<civodul>the server needs to update its package list
<davexunit>yeah
<davexunit>hmm!
<davexunit>that's trickier
<civodul>yeah
<davexunit>the package list isn't supposed to be stateful ;)
<civodul>heh
<davexunit>well, we could have guile reload all the (gnu packages _) modules
<davexunit>but there will be more to it than that
<civodul>yes, because the <package> structure could change as well
<civodul>so i think the server should not manipulate package objects directly, at least for this use case
<davexunit>that makes a lot of things more difficult to do, though
<civodul>or maybe it could respawn itself and retain the open connection file descriptors somehow?
<davexunit>that is more reasonable
<civodul>yes
<civodul>food for thought
<civodul>davexunit, paroneayea: make sure to click whatever needs to be clicked on the GSoC web site :-)
<davexunit>oh there's stuff to click?
<davexunit>I sent the email to the GNU people about being a mentor
<civodul>the "I want to mentor" buttons
<davexunit>didn't realize there was more than that
<davexunit>okay
<civodul>on https://summerofcode.withgoogle.com/
<civodul>blech
<civodul>rekado: would you like to (co-)mentor things?
<rekado>civodul: yes. I think I could do this for one of "Graphical package / system manager", "Packages for foreign distributions", and "Installer wizard for GuixSD".
<rekado>I don't see any "I want to mentor" buttons.
<jmarciano>civodul: you know, I deal with mass of people on my side. If SSL is not working as expected, they simply don't subscribe, or their browser warn them to "take care", so they rather go away.
<jmarciano>if we think of thousands of new people coming to website, that is important to handle. SSL warnings
<davexunit>civodul: it says "You are mentoring for GNU Project" for me
<ng_>we have ssl warnings?
<davexunit>am I good? do I have to say that I am mentoring a specific project somewhere?
<jmarciano>"The connection to this website is not fully secure"....
<ng_>using which browser?
<ng_>or client
<jmarciano>I know what it is, it IS fully secure, but that warning can be handled by placing // links instead of http://
<jmarciano>icecat
<davexunit>jmarciano: firefox gives a nice green lock for https://gnu.org/s/guix
<ng_>oh, right
<jmarciano>I refer to specific page: https://www.gnu.org/software/guix/packages/
<jmarciano>Firefox is making the warning even larger than Icecat
<rain1>yeah that page has a warning about http inside https
<rain1>sicne forever
<davexunit>this type of error doesn't stop people from viewing pages
<rain1>its probably just a font or image resource
<davexunit>what stops people is untrusted cert warning pages
<jmarciano>it does not stop us, but it does stop some people.
<jmarciano>when I deal with thousands of my people, I know when they go off, or land on the page, and why.
<ng_>does this page get external non-tls resources?
<ng_>I can't open it rn
<jmarciano>exactly, links to images/scripts shall be // if external pages also support SSL
<jmarciano>thinking of thousands of people that I could send to the website, I rather tell you
<ng_>btw, just trying out the new QubesOS setup, I really like the setup, simple.
<davexunit>it's all images
<rain1> http://planet.bazaar-vcs.org/images/logo.png
<ng_>but if we can fix it, why not fix it?
<rain1> http://www.gimp.org/images/wilber_the_gimp.png
<rain1> http://www.gnucash.org/images/banner5.png
<ng_>that's a reasonable bug report
<rain1> http://www.speex.org/images/logos/parrot_speex_org-3.png
<rain1>it's just these images
<jmarciano>those images have no SSL
<ng_>hm. get the images and put them into our repo or somewhere with tls?
<rain1> https://www.gnucash.org/images/banner5.png
<rain1>looks like some of them even have https versions hosted
<jmarciano>maybe some yes, speex not, and bazaar is wrong SSL
<rain1>I'll do a proper bug report of this if it is wanted
<jmarciano>such images is better to host on domain
<ng_>rain1: yes, please
<jmarciano>also when someone links to foreign images, somebody could include javascript instead of the image
<jmarciano>even if it is called .png
<ng_>nope, i don't like the QubesOS installer. third time I have to restart that tmux python thing
<civodul>davexunit: i guess you need to click on specific proposals, and then click on the "I want to mentor" button there, and possibly add comments
<civodul>jmarciano: i haven't seen the warning you're referring to; could you be more specific?
<jmarciano>rain1 has seen the warning.
<civodul>so rain1 will fix the bug? :-)
<civodul>fine with me :-)
<ng_>it needs discussion I think, wether to import images to our side so it can be served without using insecure traffic or external resources in general, or not.
<jmarciano>I would rather add, no foreign websites shall be included on page, but well, I did not design it.
<davexunit>civodul: hmm not seeing the npm proposal yet
<jmarciano>external resources then keep logs of each GuixSD website user....
<jmarciano>speaking about "privacy"...
<jmarciano>in fact the one domain belongs to "canonical.com"
<rain1>civodul, I was going to send a report tommorow but if other people are on it thats fine!
<jmarciano>bazaar-vcs.org Organization: Canonical, Ltd
<rain1>loks like just a couple http: need changed to https:
<civodul>davexunit: now that you mention it, i don't see it either
<jmarciano>rain1: don't host foreign images.
<civodul>davexunit: is the npm person around?
<jmarciano>don't link to foreign images, better
<civodul>davexunit: if not you should email them right now because there's only a few hours left
<ng_>logs are only bad if they are kept for an indefinity amount of time, running a server you need them for a short time to interfere if something happens. that said, I don't follow that myself, but it's reasonable to have it just in one place for minimizing the logs.
<jmarciano>ng_: by linking to foreign image, one is giving information as in this case to Canonical Ltd, a company not so friendly to free software.
<rain1>hm that's a good point...
<ng_>i implied that.
<ng_>more or less
<jmarciano>Why would they know how many visitors come to GuixSd, from which websites, countries, etc?
<rain1> http://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website
<rain1>site is AGPL :D
<civodul>+2
<civodul>+1, even
<jmarciano>how do I unpack with Guix, rar packages? or is it non-free?
<ng_>also, gripping that train of thought, I think hosting a .onion mirror of guixsd.org would be okay.
<rekado>jmarciano: the official unrar implementation is non-free AFAIK.
<rain1>How do these logos get put in the packages page at all?
<rekado>but there's another implementation
<rekado>haven't tried packaging it yet
<jmarciano>I just told the guy to re-pack it, as it is not free
<jmarciano>I don't care really
<jmarciano>I push back, use free software, finito.
<rain1>gnu-package-logo function
<rain1>I don't understand there is no logo field in here http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnucash.scm#n38
<ng_>that's a gnu software, maybe there's something related to gnu.org hosted projects
***ng_ is now known as ng0
***ng0 is now known as ng_
<davexunit>civodul: I sent an email to them
<davexunit>jmarciano: some types of .rar archives can be unpacked with free software
<jmarciano>davexunit: which package or name of software?
<davexunit>jmarciano: dunno
<davexunit>maybe unrar?
<davexunit>may not be packaged
<davexunit>in general its best to just avoid rar archives
<jmarciano>unrar is non-free, ok never mind, I already told the client to repackage
<davexunit>in my experience rars are used exclusively for illegal distribution of copyrighted material
<davexunit>;)
<rain1>haha
<jmarciano>people in third world countries, like Tanzania, have nothing better on computer
<rekado>there is http://unarchiver.c3.cx/, which claims to have support for rar.
<davexunit>which is weird because there is free software that can produce archives, unlike things like WinRAR which is shareware
<rain1>this isn't related to guix but i read they have provided an 'internet' to angola, which only has wikipedia and facebook :(
<jmarciano>ahaa yes
<jmarciano>FB pays that some countries have only FB on their phones, for "free"
<jmarciano>so people get jailed to FB and communicate exclusively
<rain1>it is very worrying and sad to me
<davexunit>yes, it's terrible.
<jmarciano>I got unar on Debian,ok
<jmd>WTF is FB ?
<davexunit>facebook
<jmd>oh that.
<rekado>unar =/= unrar
<ng_>some carriers in germany had (have?) that. connections to the mobile page of facebook.com were not charged.
<ng_>but internet thing of facebook is not the same
<jmarciano>what is internet thing of fb?
<ng_>internet.com or what that project to lock in people into even tinier bubbles was called.
<jmarciano>of things?
<ng_>i meant internet.org
<jmarciano>Peruvian people will certainly not use it as depicted
<jmarciano>cool looking, deceptive advertising
<jmarciano>Governments: Provide essential information to your citizens through Free Basics... and governments do believe to single company.
<jmarciano>but speaking of FB, as much as I paid to FB, I will pay double to GNU/GuixSD
<jmarciano>I confess, I used the useds.
<jmarciano>And by looking into web stats, what is written here: https://info.internet.org/story/platform (like 5x more searches...) is simply not true.
<jmarciano>in emacs, I don't see command to directly install package by name, like guix-package-install or something
<jmarciano>OK I used: guix-search-by-name
<ng_>what's the average disksize of guix mirrors? above 25GB, above 200GB or more?
<civodul>ng_: currently mirror.hydra.gnu.org has ~12G in cache
<civodul>but that's only a subset of the packages
<ng_>thanks
<ziz15>i'd like to try guix in virtualbox.is there a way to make the download file into a bootable iso?thanks
<ng_>I only aim for a mirror right now, I have plans for later to provide a build node, at the time when I can switch from debian to guixsd on servers.
<ng_>don't know if another mirror will have any significant effect after the new server is ready, but i can always downsize.
<civodul>ng_: i think a mirror really helps if it is quite widely used
<ng_>it should be "almost" without bandwith cap. I say almost, as I can run a tor relay without any problems in traffic per month at this isp.
<ng_>speed at 100MBs
<ng_>is 12 GB just the case of hydra sitting on a vm and things getting garbarge collected very often, or is close to what we have in binaries currently?
<ng_>feels smalls
<jmarciano>do we have in GuixSD some "stability" principles? Like Debian is conveying "stable version", "development", etc. I have got a feeling that packages are upgraded too frequently, and I can imagine interruptions in future. I like stability.
<davexunit>jmarciano: we're in beta, so no, not right now.
<ng_>civodul: in case hydra finally ends up on its own server, and the disk might be bigger, would you consider 25GB enough (I plan for 50 for the beginning including system and my own (low trafficed) services) or should I just watch and be flexible?
<davexunit>25gb sounds low for a mirror
<ng_>well civodul said 12GB cache atm
<davexunit>okay so not as low as I thought :)
<jmarciano>ok
<ng_>waiting to send out the new contract request/question, that's why I'm asking. initial 50GB would include ~3GB base system, maybe 10GB at max my own services, and the rest cache, open to scale up.
<lfam>I would make it as large as possible. It's useful to cache things for (at least) months.
<lfam>For example, new users who are using the 0.9.0 installer could benefit from cached substitutes of that release. Although by making it annoying for them, it does give seem to motivate some to complain until we recommend `guix pull` ;)
<ng_>currently I could go for 100GB, above that I would need to calculate. So 12GB is currently all the packages which are build in one cycle before it gets cleared? I can't get like 600GB, i would need another isp for that, prices are just to high for that with this one and for bigger sizes I prefer to bring my own dedicated server later with guixsd. I trust in-berlin from their history, support and how they are
<ng_>organized.
<lfam>ng_: I think that 12 GB is definitely not a full "cycle". For example, texlive-texmf will take up 1/4 of that.
<lfam>I think 100 GB will be good.
<ng_>yes, suspiciously small the 12GB
<lfam>Maybe 12 GB of RAM ;)
<lfam>The thing with provided substitutes for 0.9.0... it might be a feature to drop substitutes that far back. As soon as those users start web browsing, or using DNS, they are probably going to be attacked via fixed bugs in OpenSSL and glibc
<ng_>if only that one friend wasn't at ovh.. would be perfect for a cache
<lfam>What do you mean?
<ng_>well i have a friend who has lots of diskspace and no cap on bandwith, but he's at ovh, which is a security liability from what i've read
<lfam>Oh, I didn't realize that
<lfam>Is there something special about OVH? I feel like any hosted provided requires trust from the customer
<lfam>s/provided/provider
<lfam>I don't see how a running server can be effectively secured against physical attacks. I'm not an expert though
<jmarciano>ServerPronto has good deals: https://www.serverpronto.com/dedicated-server.php
<ng_>i had doubts about them and no comments from other people so far other than one friend in france who told me they are way too friendly to law enforcement agencies, but the subcompany in question (kimsufi) sells "dedicated" servers for 15 euro/month .. i just have a funny feeling about it.
<lfam>civodul: What do you think about the python-pytest update? http://lists.gnu.org/archive/html/guix-devel/2016-03/msg00932.html
<lfam>Where should it go?
<ng_>so the new instance @ in-berlin will be: 2gb ram, 150GB hdd and 1 full virt cpu of the host machine. which leaves about ~100GB for cache.
<jmarciano>they have even the option "Install your own OS"
<lfam>ng_: Yeah, I figure that any datacenter operator will cooperate with law enforcement. There's no reason not to when they can put you in prison or worse
<ng_>i know
<ng_>but even for cooperating they were said to be too friendly
<lfam>That's why we need systems that are designed to work on untrusted servers. Tarsnap is unfortunately not free software but I think its design serves as a good model
<ng_>never got any 2nd opinion on that
<ng_>just what i heard
<lfam>The only solution to this problem is to run your own datacenter ;)
<ng_>"LEA could just walk right in, they have their own room in their DCs, unlike other IT companies in france OVH is VERY cooperative"
<lfam>Their own room! Talk about hospitality
<ng_>:) it's only for the coffee
<lfam>Do they have their own maitre'd?
<ng_>no, seriously, I never got a source other than what this person in france knows/heard
<ng_>*any
<CompanionCube>don't online.net also offer cheap dedicated servers? wonder how friendly they arwe
<ng_>not anymore in a way i wanted last time i checked
<jmarciano>Also nice privacy provider in Oslo, Norway: https://servetheworld.net/en-us/colocation/
<ng_>also, I would use iceland for offshore hosting, but like all the locations I like it would be way above my budget with the requirements I have with the friendly company. looking directly at DCs there's whatevertheirnamewas.. thor something they were once called, starting at ~150€/month but also capped for dedicated server. I ran into these "too expensive for reasonable business" problems with OpenNIC last
<ng_>year.
***nckx is now known as nckx|offline
<ng_>advania they are now called
<civodul>lfam: since there's LO among the dependents, it might be best to make a branch that we'll merge after the release
<civodul>WDYT?
<ng_>i'll just think about that email (upgrade of my things at in-berlin) some more.
<lfam>civodul: Sure. Am I able to create new branches on savannah? Do I need to worry about kicking off new builds if I do that?
<lfam>In the meantime I'll test the libreoffice build to make sure it doesn't break
<lfam>civodul: Also, is there a signature for the pre-release of the new installer?
<civodul>yes, just append ".sig"
<civodul>lfam: and yes you can push new branches
<lfam>Okay, thanks!
<lfam>Too bad about the 7 character commit id being too long!!!
<df_>OVH is fairly popular for hosting seedboxes so they can't be that bad
<lfam>I can't even do `git checkout dd21`. Oh well!
<df_>given that copyright infringement is, of course, the worst crime that could be committed on the internet
<ng_>df_: yeah that's the other side i head
<ng_>*hear
<civodul>lfam: we should allow users to specify a different test directory, with a shorter name
<civodul>this is ridiculous, but hey!
<civodul>efraim: i stumble upon https://github.com/redox-os which suggests that the Rust folks have done more Unix tool reimplementation that we did so far ;-)
<ng_>(on kimsufi/ovh) like 3 sides: one voice on how cooperative they are, then many sys admins complaining their service is not existent, then another that they are good for seedboxes etc.
<lfam>Well, as long as do the checkout with the full hash, it's not a big deal in this case. Maybe as Nix and Guix grow in popularity, the shebang length will be revisited
<ng_>and then my gutfeeling which is akwardly strange when somebody wants to sell(rent) me a dedicated server starting at 5 euro/month
<davexunit>civodul: there's a project to reimplement coreutils in Rust, but it's expat licensed :(
<davexunit>the Rust community is, generally speaking, anti-copyleft, unfortunately.
<civodul>yeah i've seen that, all of Redox actually
<civodul>yeah :-/
<ng_>btw, we(i) can package rust with the next release :)
<davexunit>ACTION runs away before he gets into another compiler discussion
<davexunit>when you have Scheme, every other language just seems so much less appealing...
<lfam>I'm glad that there is a community that is at least trying to create an improvement on C. Time will tell whether or not they succeed.
<civodul>agreed
<civodul>i always wondered if it was/is the right idea for GNU to do C/Unix
<civodul>there's an obvious short-term benefit
<civodul>but it's been 30 years already ;-)
<davexunit>haha
<davexunit>I think it made sense
<davexunit>because otherwise, would we be using GNU today?
<civodul>dunno!
<civodul>it's not obvious to me
<lfam>I wasn't around at the time but, but it seems that the deep security problems of C have only really been discovered since GNU was started
<civodul>in the 80s/90s Windows was way more popular than Unix
<davexunit>it was a pretty pragmatic approach: take a proprietary UNIX system, and replace tool after tool until it was all free
<lfam>And also the pragmatism was a huge benefit it seems
<civodul>yeah i agree
<lfam>And here we are, still replacing one part at a time :)
<civodul>:-)
<davexunit>haha
<davexunit>I think projects like Guix are good steps away from traditional UNIX towards something perhaps a bit better
<lfam>My understanding is that GCC just killed the market for proprietary C compilers at the time
<lfam>davexunit: Yes, I think we are on our way :)
<davexunit>what a nice accomplishment :)
<paroneayea>back to the lisp machines! :)
<lfam>Not until it's in hardware ;)
<civodul>it used to be in hardware!
<lfam>I know!
<civodul>:-)
<lfam>Inspired by the metal :)
<paroneayea>plenty of lisps have compiled down to native code right? :)
<lfam>I wonder if anyone has a lisp machine on FPGA
<paroneayea>isn't that good enough?
<davexunit>Lisp/UNIX oscillator
<paroneayea>isn't that wingo's plans for the future of Guile? :)
<ng_>punching cards all the way
<davexunit>hardware accelerated GC would be nice :)
<paroneayea>slight tangent: I picked up a copy of the original 1960 Lisp 1.5 manual at the MIT Press store
<davexunit>as would a processor architecture that had an instruction set suitable for Lisp instead of things like C
<paroneayea>pretty cool: the eval/apply shown in there is mostly the same as SICP's
<paroneayea>I guess it's not surprising
<davexunit>I didn't realize they sold that there
<davexunit>guess I should grab a copy
<ng_>at this point nickcoloring is stupid, you are all blue.
<paroneayea>davexunit: yeah, it's a fun thing to thumb through
<davexunit>is it expensive?
<lfam>I wonder if the FSF has considering doing 'print-on-demand' for their manuals. I find paper books more useful for technical writing.
<paroneayea>davexunit: not bad, $20!
<lfam>I wonder if they could make that profitable
<paroneayea> https://mitpress.mit.edu/index.php?q=books/lisp-15-programmers-manual
<davexunit>paroneayea: sweet!
<paroneayea>davexunit: what I also like: the book gives 0 indication that it's a relic
<paroneayea>other than the copyright date
<davexunit>I'll have to check it out
<paroneayea>the preface is from 1962 :)
<paroneayea>you can probably find it in the MIT AI memos they have online
<paroneayea>but it's satisfying to have a physical copy
<paroneayea>the book also at great length tries to explain M-expressions
<paroneayea>and I find them much less readable than sexps
<paroneayea>familiarity, I guess?
<civodul>paroneayea: it's a reedition?
<paroneayea>civodul disappeared, but I think not, just a reprinting... nothing has changed, and no new preface since 1962
<lfam>I recommend all Guix hackers with more than one machine set up a caching mirror for themselves :) It's very nice
<lfam>Now I just have to figure out how to my local builds into that cache
<lfam>how to get my*
<davexunit> http://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/2016-March/002945.html
<davexunit>"Beware, this may be somewhat of a flame, but honestly right now I am quite a bit fed up with "either you support the new web app developers way of doing things or you will become obsolete except for running containers" argumentation crap."
<lfam>"
<lfam>I now found that Owncloud appears to be like a tamagotchi that messes up big
<lfam>time if I do not give it care and nudging and upgrades and stuff every half of
<lfam>a year at least."
<lfam>Lol
<lfam>I have to agree with that person. I think Owncloud's functionality is interesting but I'm not going to use it
<paroneayea>hm
<paroneayea>davexunit: ran in to my first fun experience of a service I'm running on guixsd failing to start because I didn't have my stuff upgraded to the program's new schemas
<paroneayea>postgres :)
<paroneayea>hoo, this seems complicated to do manually.
<paroneayea>luckily I don't need this database
<davexunit>paroneayea: what service are you running that uses postgres?
<paroneayea>davexunit: mediagoblin development
<davexunit>I don't know of any that we have
<davexunit>oh
<davexunit>so not a service, I see.
<paroneayea>I was running the postgres service, but not running another service that uses it, right
<davexunit>statelessness ends at the service layer
<paroneayea>davexunit: just makes me realize, oh right, we really will need that "upgrading users' state (ideally with easy backups) tools" you and I have discussed
<davexunit>I'd like a backup service that would trigger backups during service upgrades
<paroneayea>right
<davexunit>I have a 'user-files-service' patch hanging around that manages stateful files, too.
<davexunit>or rather, stateless files that get installed to stateful locations, such as your home directory
<bavier>that sounds nice
<davexunit>the main thing I want to use it for is dumping ssh public keys into home directories
<lfam>I read some of the upthread discussion, and linked discussions. Owncloud even offered to pay for Debian developers travel expenses to come to their meeting and discuss these issues. That's a real olive branch if you ask me
<paroneayea>yes, I have some empathy with people on all sides of the debian/ownclowd thing
<paroneayea>I understand why the OwnCloud people feel like they can't trust Debian to move fast enough to keep things updated (and currently, if you install OwnCloud from Debian, it's old enough to have a vulnerability backdoor in it)
<paroneayea>I also understand how Debian folks feel frustrated by being basically kicked around by some of the comments made by OwnCloud stuff
<davexunit>yeah, I see both sides.
<lfam>It seems like they need a new Debian maintainer who has a endless well of energy and optimism
<lfam>And a very thick skin
<davexunit>the "debian will be that thing you run Docker on and little more" comment really annoyed me though
<lfam>Well... considering that we don't really package any of that stuff either, I understand their point when they say that
<lfam>They are building software that is almost impossible to package with existing distro tools
<paroneayea>davexunit: right.. well it was interesting talking to Frank from owncloud, who didn't seem to know of the comment, but
<paroneayea>also felt similarly frustrated, and worried
<davexunit>Frank is cool!
<lfam>And those "great" Docker images will be equivalent to "old backdoored Debian package" in a year anyways
<lfam>I should clarify, the backdoor is not from Debian, but from some old software version in the package
<ng_>make backdoors great again
<lfam>Not even an intentional "backdoor", just a vulnerability
<lfam>If their upgrade path is unworkable, I don't see how Docker will solve the problem
<lfam>There is so much "self-hosted" software that is really not actually "self-hostable" by 99% of users
<paroneayea>we don't currently have any way to switch system profiles and services without a reboot, righ?
<paroneayea>right?
<davexunit>paroneayea: new services get started upon reconfigure
<davexunit>what we don't have yet is restarting of existing services
<lfam>Well, I hate to see the discord between those projects, anyways. I hope they can work it out.
<paroneayea>davexunit: got it... so is there also a way to switch back to a prior system without rebuilding it?
<paroneayea>or rebooting?
<paroneayea>eg I'd like to switch back to the previous profile that ran the previous version of postgres
<paroneayea>and start that up again
<paroneayea>that way I can dump, switch back, and reload
<paroneayea>it's not really critical that I do this right now, I'm just trying to figure out what workflows are currently possible in guix
<davexunit>reboot into the old generation
<davexunit>do what you need
<davexunit>reboot back into the new generation
<paroneayea>davexunit: got it
<paroneayea>davexunit: thanks for clarifying!
<davexunit>I could see us being able to do this without reboots in the future
<davexunit>but not until shepherd is smarter
<davexunit>with kexec, we could probably even do kernel upgrades
<davexunit>my current test of shepherd's readiness for production systems is to see if it can receive a new nginx service, one that uses a new nginx binary and config file, and can do a web server upgrade with 0 downtime
<davexunit>nginx itself can do this, so it's matter of making shepherd smart enough to trigger it when appropriate.
<davexunit>or rather, giving shepherd the means for us to write an nginx service that can do this specialized restart
<lfam>davexunit: Regarding the new binary, is that also covered by `nginx -s reload`?
<jmd>In GuixSD, confstr(_CS_PATH, ... doesn't return the correct value
<lfam>jmd: Can you send a report to bug-guix@gnu.org?
<davexunit>lfam: that's just for configuration
<davexunit>what I don't yet know is if you can tell nginx to reload config from a *different* file
<davexunit>because that will be necessary for us
<lfam>Good point.
<lfam>Maybe `nginx -s reload -c /gnu/store/...`?
<davexunit>lfam: that's what I'm hoping works, but I haven't tested :)
<lfam>Our nginx package doesn't include any man pages or similar, which I'd like to fix
<davexunit>oh, yeah that would be good.
<lfam>I'm not sure if they distribute a full manual in that way or not. The Debian man page is very basic
<lfam>Debian's man page appears to have an "out of tree" source
<jmarcian`>I have git cloned guix-web, but by instructions "guix web" is not working.
<lfam>I wonder if --fallback should be the default, if every build that uses texlive-texmf is going to fail.
<lfam>It would make the source / binary transparency a little more transparent
<lfam>Does anyone know how I could manually put the texlive-texmf source tarball in my nginx cache?
<jmarciano>I forgot to turn on environment
<jmarciano>but still...
<lfam>I guess I'd have to export the archive and then propagate this machine's signing key to all my other machines...
<lfam>jmarciano: guix-web's maintainer is in this channel ;) but perhaps he is busy with something else at the moment
<davexunit>jmarciano: 'guix web' is a *prototype* that I haven't touched in many months... perhaps there is bit rot.
<davexunit>but more likely is that you didn't use ./pre-inst-env to run it
<davexunit>the README forgot to mention that part
<jmarciano>OK i run pre-inst-env too
<jmarciano>I finished, configure, make all.
<jmarciano>but "guix web" - command not found
<jmarciano>aha pre-inst-env guix web...
<jmarciano>I guess?
<davexunit>./pre-inst-env guix web
<jmarciano>I got the web
<jmarciano>it works very well
<davexunit>pre-inst-env is a wrapper script that sets the right environment variables needed for guile to load the modules it needs
<davexunit>jmarciano: cool!
<davexunit>I need to revisit it some time, clean it up, and get it into guix proper.
<jmarciano>it shows public packages ? Does not touch my system?
<davexunit>it shows all the packages that are known to it
<jmarciano>from my computer or from servers?
<davexunit>your computer
<jmarciano>aha
<davexunit>guix doesn't use external servers
<davexunit>specifically, it uses packages that are on your guile load path
<davexunit>via fold-packages
<jmarciano>because it shows multiple packages that I don't have, not that I know
<davexunit>you must be mistaken.
<jmarciano>it shows 3248 packages
<davexunit>sounds about right
<jmarciano>but I don't have them installed
<jmarciano>I tried to search in /gnu/store, no there are no
<davexunit>it's showing you the full package list
<davexunit>not what you have installed
<jmarciano>yes
<davexunit>/gnu/store has nothing to do with the package list
<davexunit>packages are scheme objects
<jmarciano>ok it shows packages as objects, but not installed, and does not disturb, cannot update, remove nothing.
<jmarciano>very nice
<davexunit>I think you can install individual packages with it
<davexunit>I did that before I stopped hacking on it
<davexunit>it's not yet suitable for actual package management
<jmarciano>I just think in public terms, it could be nice feature to implement that for package searches
<jmarciano>it has some bugs, I write mutt, it says 6 results, below "No results"
<jmarciano>like "dico", 1 result above, below "No results", just that you know.
<jmarciano>but now suddenly showing
<davexunit>yeah it certainly has bugs
<davexunit>I wrote it as a proof-of-concept
<jmarciano>maybe it can be used for marketing of guixsd
<lfam>How can I make MPD run at boot on GuixSD? Can anyone give me a hint on where to start?
<davexunit>lfam: write a system service for it
<davexunit>I would use it. :)
<lfam>I'm currently looking through your guixsd.git repo for inspiration ;)
<davexunit>I don't have services in there
<davexunit>check (gnu services ...)
<davexunit>currently I run mpd with my user shepherd instance
<davexunit>which doesn't use any guix things at all
<davexunit>but a system service where you can pick the user to run mpd as would be nice
<lfam>I think that to start, the service will be very crude: Just start and stop actions.
<lfam>I find (gnu services ...) to be very dense for somebody with my level of Scheme knowledge (a low level).
<davexunit>lfam: writing services is a rewarding experience once you get it :)
<davexunit>we need more services! moar moar moar
<lfam>I really *want* to add a lot of services
<lfam>I wonder if `loginctl enable-linger` works with elogind
<jmarciano>let's say, I wish to distribute with guix package manager, postgresql, some software, plus the data. Is it possible to "package the data", like database with it? As only that way, I could tell to someone, please install my-software.scm and he would get the data included?
<rain1>I think you can have a package that simply copies data into the /gnu/store
<rain1>it might not be the best solution
<jmarciano>data part is important
<davexunit>jmarciano: in theory it is possible
<jmarciano>I guess users cannot change /gnu/store
<davexunit>you can put arbitrary files in the store
<davexunit>you could put, say a database dump there, and have a service that creates the database and imports that data if the db didn't exist
<jmarciano>aha
<davexunit>something like that is totally possible
<jmarciano>can I, delete database from /gnu/store once it was imported?
<jmarciano>as I read, /gnu/store was not changeable...
<davexunit>no
<davexunit>the store is immutable
<davexunit>why would you want to do thsi?
<davexunit>this*
<jmarciano>I think that guix allows somehting like docker...
<davexunit>it's important to understand that the store is only for *stateless* things
<jmarciano>because I don't need only software, I need database definition ready.
<jmarciano>there must be way to populate /var or other place
<davexunit>that's what I'm explaining
<davexunit>we have many services that create state directories in /var
<paroneayea>putting backups in the store is a curious idea
<paroneayea>I'm not sure it's the best thing or not but it's at least interesting
<rain1>but the store is for immutable stuff right?
<davexunit>not backups, but like an initial db snapshot
<paroneayea>ah
<davexunit>rain1: yes
<davexunit>I'm not talking about mutating the store
<paroneayea>(I wasn't talking about mutating the store either :))
<davexunit>GuixSD's service layer is the bridge between the stateless and the stateful
<jmarciano>like sandstorm.io, one installs full application at once
<davexunit>the services themselves are defined statelessly, but running a service is a stateful thing
<jmarciano>and I think to run software, separate from any distribution, and being able to move it easily.
<paroneayea>sandstorm.io does do something similar
<paroneayea>in terms of having an immutable application
<paroneayea>and having mutable data be carefully separate
<paroneayea>that's The Right Approach (TM)
<davexunit>well sure, you can do that with GuixSD, too. we just don't have a ready to use framework for that.
<paroneayea>ah
<davexunit>but you could hack something together like that
<jmarciano>I could do like: make my own package, pull the database from SSH server, by entering password, and run the script to load into database?
<davexunit>sure
<davexunit>the first part guix would handle
<davexunit>and for the rest of the steps you'd have your own script
<jmarciano>yes
<jmarciano>guix downloads also from ssh servers?
<davexunit>no
<davexunit>we are miscommunicating
<jmarciano>I got that I can make my own package, to download db definition, load it into database for example
<davexunit>a package wouldn't do that'
<davexunit>a package would build the software that you need to do something like that
<davexunit>it wouldn't actually do it
<jmarciano>package cannot run software?
<jmarciano>like in Debian, there are some scripts to run after installation
<davexunit>right, those do not exist in guix.
<davexunit>because those operations are inherently imperative
<jmarciano>that is like principle I guess
<jmarciano>but OK then I can run software to do it
<jmarciano>there are many applications waiting to be downloaded, and quickly run with Guix, so people will tend to do it by single mouse click later
<rain1>maybe guix could install a tool that makes installing these extra things easy
<rain1>then its 2 things you have to do.. but as long as they are both easy its not too bad
<jmarciano>Yes. And I am pushing some ISPs to offer GuixSD. Now I wonder about security. If I let ISP install GuixSD for me, is there way that I check for integrity of daemon and all software installed?
<mark_weaver>oh well, making the next release of guix free of grafts is not going to happen, I guess: https://lwn.net/Articles/681356/
<davexunit>darn
<mark_weaver>replacing expat without grafting will lead to about 7500 rebuilds
<mark_weaver>lfam: are you available to handle grafting expat? if not, I can deal with it in an hour or two.
<mark_weaver>ACTION goes afk for a while. ttyl!
<jmarciano>that is security issue, I hope there is way in GuixSD to handle that security issue fast.
<jmarciano>like for the local installation, or for -u (upgrade)
<rain1>what is?
<jmarciano>like in foreign distribution (Debian), when there is security stuff, package definitions are replaced, people upgrade and get quickly secure system.
<jmarciano>or better illusion of security
<bavier>jmarciano: guix has grafting
<jmarciano>I've read now "grafts"
<jmarciano>so we have the option, good
<mark_weaver>ACTION works on the expat security update
<lfam>mark_weaver: I'm back
<mark_weaver>lfam: okay, I'm almost done with this.
<mark_weaver>of course, icecat contains a bundled copy of expat. bla
<mark_weaver>just to make our lives "easier" :-/
<lfam>You should send a notification email to an upstream project every time you have to do something like this. I'm sure they'll "appreciate" all the mail ;)
<mark_weaver>:)
<mark_weaver>ACTION grafts a new epiphany for now
<mark_weaver>I just pushed the expat graft.
<mark_weaver>however, icecat is still vulnerable for now. I'll have to work on that a little later.
<mark_weaver>for now, I recommend using epiphany
<paroneayea>mark_weaver: yarg ;x
<kei_>noted
<paroneayea>mark_weaver: I wonder how long it'll be till we have an iceweasel fix :(
<ng0>I have a question. My theory is that this is true: If I write a setup.py and contribute it to a project because I want to make an "easier"[1] install in Guix and elsewhere, I feed the "one packagemanager per language" thing. [1]: I already figured out how I could be just faster in writing a Guix package rather than the ~60 lines of setup.py I already have.
<lfam>paroneayea: AFAICT, this bug was disclosed last August, and it was patched in mozilla-esr last April.
<lfam> <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1283>, <https://security-tracker.debian.org/tracker/CVE-2015-1283>, <https://hg.mozilla.org/releases/mozilla-esr31/rev/2f3e78643f5c>
<lfam>That might be of interest to mark_weaver too ^
<lfam>The mozilla link is from the Debian page
<mark_weaver>lfam: we already fixed that one a while ago. this is a different bug
<mark_weaver>oh wait, is it?
<mark_weaver>bah, now I'm not sure
<lfam>It seems to be that one
<mark_weaver>bah, I've made a fool of myself...
<lfam>That's harsh!
<lfam>I can't tell exactly why that bug has resurfaced. Maybe it's just this discussion about updating the CVE ID's metadata? https://sourceforge.net/p/expat/bugs/528/
<mark_weaver>this is what happens when I'm under time pressure. oh well
<mark_weaver>ACTION reverts
<mark_weaver>time to revert my email too...
<kei_>I have a question about defining a package.
<civodul>"guix lint -c cve expat" doesn't report anything, FWIW
<lfam>kei_: Go ahead
<kei_>What is necessary to build a package after I define it?
<kei_>I have the .scm file ready.
<ng0>could someone with more python knowledge comment on my theory, so I can revert a message I sent in a conversation?
<mark_weaver>I fixed this same bug over 6 months ago!
<mark_weaver>and arch is just fixing it now. unbelievable.
<lfam>kei_: I'm not exactly sure how Guile works under the hood. But I think that the .scm file is "just" source code, which must be compiled by Guile into the .go executable. I think that if you don't run `make`, that compilation happens anyways, but the results are not stored on disk.
<lfam>To clarify, the compilation would happen anyways when you actually try to do something with the package, such as build or install it.
<lfam>Happy to be corrected by somebody that knows more :)
<ajgrf>lfam: kei_: i think he's just asking for the guix command line. which would be either `guix build -f file.scm` or `guix build my-package`, depending on how he defined his package
<lfam>Oh, I misread the question as "Why is it necessary to build a package ..."
<lfam>Oops
<lfam>Yes, either `guix build -f`, or by setting the environment variable GUIX_PACKAGE_PATH to point to your package directory.
<rekado>if you use GUIX_PACKAGE_PATH you have to make sure that the location of the file matches the module name (if you chose to define a module)
<kei_>The .scm can be found here: http://paste.lisp.org/display/311412
<paroneayea>whew!
<rekado>kei_: the file would have to be in "$somewhere/gnu/packages/milkytracker" and GUIX_PACKAGE_PATH would have to be set to $somewhere.
<rekado>alternatively, you could add the package to Guix itself.
<lfam>+1 ^
<lfam>I'd love to play with that
<rekado>it could go to gnu/packages/music.scm
<kei_>How do I edit gnu/package/music.scm
<rekado>you'd just have to paste the package expression itself.
<rekado>do you have a git clone of the guix repo?
<kei_>I do not.
<rekado>then you should get one :)
<lfam>Everybody's got one ;)
<rekado>because then you can commit your change locally, produce a patch, and send it to our mailing list
<rekado>guix-devel@gnu.org
<kei_>Alright. Looking for the git URL now.
<rekado>ACTION has to go now
<ng0>reading about setup.py doesn't make it any easier to judge if what I think is right
<paroneayea>ACTION looks up
<paroneayea>is someone packaging milkytracker?
<paroneayea>I love milkytracker
<kei_>Attempting to, yes!
<paroneayea>I can't use it for crap but I find it thrilling
<paroneayea>not being able to use it is related to my own musical inabilities though :)
<paroneayea>also, wowee, over 2200 commits from last guix release
<kei_>Check out https://goblinrefuge.com/mediagoblin/u/kyamashita/ for some of my milkytracker investments.
<paroneayea>oh hey goblinrefuge <3
<kei_>Also, how do I use the Linux-libre 4.1.20 kernel for my system configuration, paroneayea?
<kei_>I saw on the mailing list that you resolved the issue, but I didn't quite get it
<kei_>My X200 is also resetting to 00:00 01-01-1970 on every boot
<paroneayea>kei_: http://pamrel.lu/be761/ the start of my system configuration file
<kei_>Is it the linux package module that makes the difference?
<lfam>Yes
<kei_>Okay.
<kei_>I tried the (kernel linux-libre-4.1) before but it didn't work.
<kei_>Also, while I'm here, how would I make WindowMaker my default desktop environment instead of XFCE?
<kei_>I've only ended up on it accidentally. I don't think WindowMaker has an xsession file.
<jmarciano>I remember, I just put wmaker in .xinitrc, and run with startx... but that is me
<kei_>Let's see...
<mark_weaver>kei_: (kernel linux-libre-4.1) should work. can you be more descriptive than "it didn't work" ?
<paroneayea>kei_: I like your music!
<paroneayea>fun stuff
<paroneayea>reminds me of all my fun days playing games on a c64
<kei_>mark_weaver: I didn't include "linux" in the list of package modules. It's working fine now.
<kei_>paroneayea: Thanks! I like GNU MediaGoblin! I also enjoy visiting your blog from time to time.
<paroneayea>kei_: :)
<kei_>jmarciano: xinit is complaining that the X binary isn't in the same folder as xinit. Did you install xorg-server in your user profile as well, or am I missing something?
<jmarciano>ehm... no
<jmarciano>but I will now
<mark_weaver>kei_: xinit/startx doesn't work on Guix. you need to use (slim-service) instead
<kei_>Okay, so how can I access WindowMaker from slim?
<mark_weaver>just add (slim-service) to your 'services' field and 'windowmaker' to the 'packages' field.
<mark_weaver>I don't see any utility to adding xorg-server to a user profile
<mark_weaver>in theory, xinit/startx could be made to work on Guix, but it's not trivial and no one has been motivated to do that work.
<kei_>Neither did I. I'm very much a newbie as far as Guile and Guix goes.
<mark_weaver>for one thing, slim-service takes care of crafting a suitable xorg configuration file, which is surely needed to deal with all the non-standard filesystem locations for things like fonts and X drivers. also, some things would need to be made into setuid programs.
<jmarciano>hmm, I have my $INFOPATH correct, I see guile.info.gz inside, but info guile gives me only "Guile config".
<kei_>I'll be back later...
<mark_weaver>jmarciano: for "info guile" to work, it is not enough for guile.info.gz to exist in INFOPATH. it needs to be listed in the 'dir' file
<mark_weaver>if guile is in your user profile, then the 'dir' in your user profile should include it.
<mark_weaver>and the INFOPATH should be set to include $HOME/.guix-profile/share/info
<mark_weaver>that's the best way to get this working properly... but also "info -f <filename>" should work, regardless of whether the 'dir' file includes the manual
<mark_weaver>(although I prefer to use the info reader in emacs)
<jmarciano> ok thanks, where is the dir file?
<alezost>jmarciano: I think it is generated during a profile creation, just install guile in your profile, and "info guile" will work
<jmarciano>that is exactly what I have done, but Guile is not in dir
<jmarciano>my dir is: /var/guix/profiles/per-user/admin/guix-profile/share/info/dir
<alezost>jmarciano: what's your INFOPATH?
<jmarciano>that one above
<jmarciano>but why dir was not generated with guile inside, I have inside charting and all others, but not guile
<mark_weaver>are you using GuixSD, or Guix on top of another system?
<jmarciano>on top
<jmarciano>maybe I need to get "info" but I don't know in which package
<alezost>jmarciano: "that one above", do you mean .../info/dir?
<jmarciano>yes
<alezost>it shouldn't be "dir"
<jmarciano>echo $INFOPATH/
<jmarciano>/var/guix/profiles/per-user/admin/guix-profile/share/info/
<jmarciano>without dir of course
<mark_weaver>jmarciano: so, 'guile' is in /var/guix/profiles/per-user/admin/guix-profile/manifest, but not in /var/guix/profiles/per-user/admin/guix-profile/share/info/dir ?
<jmarciano>I see it in manifest. But not in dir
<jmarciano>exactly
<mark_weaver>hmm, I don't understand how that could have happened.
<jmarciano>how is dir generated?
<mark_weaver>it's generated while the profile is built
<alezost>jmarciano: could you paste that "dir" file?
<mark_weaver>specifically, by 'info-dir-file' in guix/profiles.scm
<jmarciano>if I do info --all guile I can see 1. ..../info/guile.info.gz)Top, and 2. (*manpages*)Guile, if I do only: info guile, I get "Guile Config"
<jmarciano> http://paste.lisp.org/display/311417
<alezost>jmarciano: you have it!
<alezost>* Guile Reference: (guile). The Guile reference manual.
<alezost>jmarciano: it's just that "info guile" opens info of the "guile config"
<jmarciano>aha
<alezost>jmarciano: dunno, try "info guile reference"
<jmarciano>now I see also better when I pasted it... but then I need info "Guile Reference", complicated
<jmarciano>okok
<jmarciano>I am saved
<jmarciano>as recently it behaved different
<mark_weaver>I guess maybe "info guile" picks the first manual in 'dir' whose name starts with "guile", or something like that.
<jmarciano>I see yes
<mark_weaver>I have to go afk. happy hacking!
<jmarciano>thanks bye
<myglc2>Yo! For hacking do you do 'guix environment guix' or just install the requirements using guix?