<lfam>I'm not sure. If you search the guix-devel archives you will find some discussion <davexunit>kristofer: your system doesn't trust letsencrypt certs <lfam>davexunit, kristofer: Let's Encrypt is cross-signed by an older, established CA (IdenTrust) <lfam>So, I wonder if kristofer's client has other issue. kristofer, can you clone from some other site of HTTPS? <kristofer>lol, I actually have sly cloned from the same server <kristofer>it's actually a different method git:// not https <lfam>kristofer: I don't think the git:// method uses TLS at all, but I could be wrong <lfam>From the git-clone man page: The native transport (i.e. git:// URL) does no authentication and should be used with caution on unsecured networks. <lfam>Of course, if HTTPS isn't working, that doesn't help you too much <kristofer>I have confirmed I can clone from github over https <kristofer>davexunit: yeah, I got it situated :) thank you <dannym>Does anyone have a hplip printer configured in some GNU/Linux distribution that is not guix? I'd like to know where the hplip ppds went when in use... <rain1>How do you make an environment where #!/bin/bash works? <quiliro>just finished installation but failed on reboot <quiliro>frustrating after 6 hours of installation <lfam>quiliro: What do you mean by "failed on reboot"? <rain1>it doesn't let any failed tests slide <rain1>it is so frustrating and takes long, I have had similar trouble during install <quiliro>on reboot it said something about io.... (not disk) i know i should have written it down <quiliro>is there any way i can download the packages and make an offline installation <quiliro>worst is not the 6 hours but the lack of internet connection to try again <lfam>Unfortunately my experience installing GuixSD is not that deep... <quiliro>lfam: it is not so much the remote speed..it is the local bandwidth <lfam>quiliro: Does it take 6 hours because your connection is slow, you have to compile a lot, or because your OS configuration includes a lot of packages, or some combination? <lfam>Yes, I've never installed it a few times on hardware. It's not the easiest OS install yet <quiliro>perhaps that is what makes compilation solong <lfam>If you decide to start over, I recommend using the bare-bones config for the initial installation. Then, once that works, use the desktop config and reconfigure <quiliro>lfam: you have done it on virtual machine? <lfam>I have used `guix system vm-image` to create GuixSD virtual machines, but I haven't actually installed in a virtual machine yet <lfam>quiliro: The only thing about the bare bones config is that it is *really* bare bones. It comes with the editors zile and nano. If you prefer another editor, you should add to the config so that you are comfortable <lfam>And I do think it's a good idea to test using something like `guix system vm-image` first, because it's much faster than installing to bare metal, and you can cache the binary substitutes between runs <lfam>That would require you to install Guix on some other GNU / Linux system <lfam>But, that's another (smaller) can of worms <lfam>It's too bad you don't remember what the error message was <lfam>quiliro: I mean to say above "I've instaled it a few times on hardware". I don't know why I typed "never" <quiliro>i checked the /mnt partition and it only has /tmp and /etc <lfam>quiliro: Sorry, I don't know exactly what should be in there. Something is wrong if it doesn't even boot. If you ask again in a little while, there will probably be somebody who can give you better help <quiliro>the package download was only 1 hour, 3 hours of compilation, the rest was restarting the installation because the installation broke because of server not online for about 1 or 2 seconds <lfam>jmarcian`: You should edit it! It is wikipedia after all :) <quiliro>lfam: wikipedia librarians are very rude and impositive....must read the rules because they will ban you and the change will not be accepted <lfam>Who is going to argue with you? It's not a very big page <dannym>I've guixsd installed right now. There's /gnu which contains the store. /boot should contain grub (and nothing else). I have a tiny /etc and a tiny /var . /root and /home should exist as usual (if you actually had a "users" form in your config, that is) <dannym>If there's no /gnu , it didn't work at all <quiliro>i have nothing of that but configured config.scm correctly....read it 10 times to be sure <jmarcian`>lfam: if somebody has already put "Linux" and on that page there are so many bias, changing that would incite new arguments and leads nowhere. If someone is editing it already from GNU or GuixSD people, they might make it better, then me who is new to them <quiliro>a solution is to remove linux from guix <lfam>That way I can't be banned <quiliro>then they cannot possibly call it linux ...jaja <lfam>I do it all the time. I haven't had any problems <lfam>Or maybe I just don't notice the problems <quiliro>lfam: have you done it with an issue like linux vs GNU-Linux? <lfam>No. But, this is a GNU project. I don't foresee a problem <quiliro>Pikolas (talk) - it is still a Linux distro. If you disagree then discuss on the talk page to gain consensus, but do not edit war. <rain1>"the term GNU?Linux is not used on Wikipedia" oh.... :( <quiliro>you must use their rules to outrule them <lfam>That's a shame. The sign of a dead project, in my opinion. <jmarcian`>I will stop using GNU/Linux, but: GNU operating system... (and if anyone is unclear, then I continue) with the Linux kernel <rain1>at least guix can explain things in their own words on their home page <quiliro>rain1: you can reffer to gnu/linux or something like that to see the controversy <quiliro>i still wonder how to install by downloading the packages <quiliro>gota go.... thanks for your input lfam <woodrad>paroneayea: that's true, even java projects with maven builds might just be a wonderland of blobs <woodrad>davexunit: i second that. maybe i can help out on the more important packages <woodrad>well, that post is a lot to think about. perhaps someone here can point me to a high-profile (but not too complex!) java project to cut my teeth on <rekado>woodrad: "not too complex" ... well, that's where things usually fail. <rekado>roelj and I have been trying to package maven <rekado>but maven has dependencies of its own. <rekado>I packaged a couple of them but then noticed that they bundle some jars that we should build from source. <rekado>the next library I should package when I temporarily gave up is qdox. <rekado>It is a little more difficult to package because it's not just Java code but requires yacc and some other unpackaged libraries. <rekado>with that we can build hamcrest-core and other core libraries all the way up to some basic version of junit, which is needed by many Java packages, including the dependencies of maven. <efraim>debian has a newer version of graphite, that might be related to their DSA-without-CVE that they had this week where they disabled graphite entirely <efraim>the release message doesn't make it sound like there's any major issue, the DSA doesn't have any new information, but it's still bothering me ***kelsoo1 is now known as kelsoo
<ng_>is it possible that boost build is broken in cache or something? updates since yesterdayy fail with "bzip2: Compressed file end unexpectedly" <efraim>other people also said they built boost locally <efraim>alezost: do you have access to clear the cache of broken items? <efraim>seems there's some growing pains with the caching server <alezost>efraim: do you mean access to hydra? No, I don't <rekado>trying to package nhc98 now, a compiler for Haskell98. <rekado>it can be bootstrapped from generated C sources. <rekado>I think that's still better than the big binary bootstrap GHC. <civodul>yeah, though generated C is still not source code :-/ <rekado>true, but it's surprisingly readable. <civodul>anyway that'll give us concrete data on the feasibility and pitfalls of the approach <efraim>civodul: ng_ is having errors with downloading boost and the file ending suddenly <rekado>it's also a simpler compiler than GHC, so it might be easier to use hugs (a Haskell interpreter) during the build. <ng_>out of current guix pull <ng_>I can pastebin the full error <rekado>ACTION sees "pastebin" as a verb like "google" instead of "web-search" <civodul>rekado: right, i had that feeling too :-) <ng_>idk, is there a paste service named pastebin? <ng_>i don't use google is a verb though <ng_>"i can paste the output" would imply paste-flooding the channel for me. <ng_>what I use is a commandline paste <jmarciano`>some companies like google, pastebin, influence the language way too much, it is part of mind manipulation <ng_>like i said, i had no idea that a company like pastebin existed <ng_>and i rarely if ever use a sentence like i did. <ng_>whn guix gc -C gets no min, does it delete all failures and dead files? <efraim>i've been using the pastee.py from pastee.org/pastee.py, but it has no license <rekado>ACTION looks at yale haskell now, written in Common Lisp (but also contains Scheme) <ng_>pb, the software running ptpb.pw is gpl2 or 3 iirc. <ng_>is it safe to just run "guix gc -C" ? or is there some piping like guix gc --list-dead | guix -gc -d <civodul>ng_: "guix gc -C" alone is not meant to work; it's either "guix gc", or "guix gc -C123M" <ng_>then I misread the doc <civodul>ah no, "guix gc -C" is OK but it's equivalent to "guix gc" <civodul>well it says that, but not explicitly <ng_>selfmemo: run gc more often <ng_>i think this is deleting over 30GB <fhmgufs>I'm currently studying the Guix sources: What are the specifications of package inputs in Scheme? Lists of lists containing two or three elements? Or sth else? <fhmgufs>I mean for example `(("glib:bin" ,glib "bin")) <efraim>glib "bin" means the "bin" output from glib, instead of the "out" output <efraim>if there's nothing, then the "out" is implied <fhmgufs>Yes, that's clear. But what Scheme type has that? <fhmgufs>Probably yes. I just wanted to be sure. <fhmgufs>And (sorry for asking this again): What's the difference between `() and '()? <alezost>it's a backquote, see (info "(guile) Expression Syntax") <alezost>sometimes it's a convenient way to construct a list, for example, try this: `("foo" 3 ,(string->number "28") ,@(iota 3)) <fhmgufs>Yes, thank you, now I've understood these things :) <df_>I'm trying to install guix-binary-0.9.0.i686-linux on a debian system and the daemon isn't creating build users <df_>strace says it's in the middle of an accept() call so I'm guessing it's skipped that step for some reason <roelj>df_: Shouldn't build users be created separately? <df_>oh crap I totally misread the manual ***kelsoo1 is now known as kelsoo
<ng_>texmf.tar.xz gives a 404 error <ng_>well texlive-20150523-texmf.tar.xz <rekado>ng_: I think that was done to avoid overloading hydra. You should still be able to build it from source, though. <ng_>possibly. yes I am building it from source, slowing down testing and building some other update <ng_>it's bad that I still need to write some lines, otherwise I could leave for a while <ng_>hrm. I download the new libressl, I run guix hash on it, I paste it to the file with the changed version, and the hash of the downloaded file when running ./pre-inst-env guix build libressl then is different? <ng_>it's not even a checkout of anything, just the .tar.gz <ajgrf>ng_: that happens quite often with github-generated tarballs <ng_>shouldn't it be the same? <ng_>well it's a plain tarball <ng_>some moments and I can paste it <ajgrf>ok, i saw that libressl existed on github and assumed you used that to download <ajgrf>but it looks like the tarballs that libressl releases are hashed and signed <rekado>ng_: I usually just do "guix download", which downloads and prints the hash. <ajgrf>so it should not be difficult to determine which hash is correct <ng_>i forget about guix download <ng_>well that is different. but the same like the pre-inst-env gives me <rain1>would you like to post the hash and we could verify? <efraim>I try not to use `guix download` to make sure I don't mess up the url in the package description <rain1>what is the situation about pthread? <rain1>I see a libpthread-stubs package <ng_>rain1: done. will submit the patch in the next minutes <ng_>but it's strange why guix download gives another hash than manual download and then guix hash on the file <rain1>i added pthread-stubs and glibc <ng_>I've sent the patch, should arrive from gmane soon. <rain1>I don't know if anyone is interested in ring? I have put a lot of work in packaging it but failed, if anyone wants to continue it but I think I should stop <roelj>rain1: What is the problem you run into? <rain1>a lot :P ... many I got past <rain1>a test fails because of something about pthread, I can turn off that test but it installs the headers to a weird location /gnu/store/*-libdbus-c++-*/include/dbus-c++-1/dbus-c++ <rain1>so ring-daemon cannot find it <rain1>ring-daemon needs dbus-c++ to build the actual daemon, apart from that it seems like every piece is in place <roelj>rain1: You have probably already tried, but maybe you could simple install the header files in a normal place with a custom install phase. But heck, it's probably not the last thing that needs to be fixed before it works. <efraim>/gnu/store/*libdbus-c++-*/ is the prefix <rain1>basically "dbus-c++-1" shouldn't be there, ring daemon doesn't expect it <rain1>dbus-c++ puts a pkgconfig file and ring daemon is using that, it should work.. <rain1>that's really strange, pkg-config --cflags dbus-c++-1 points to the right include path <rain1>I heard about that, such a mean thing to do <rain1>pushing people around because they think they own 3 letters in a row, it is terrible <kristofer>if I modify my nginx configuration, must I reconfigure the system? <davexunit>rain1: it's funny because a lot of people are mad at azerbike! <davexunit>but all I see is terrible, terrible npm with it's terrible, terrible implementation <davexunit>I mean really, a centralized system that everyone depends on in which anyone can just delete what's been put there at any time? <davexunit>I can't believe that the system wasn't append-only <rain1>I don't know npm enough to understand that but it definitely sounds like they need a replacement that gives people choice <davexunit>the sadistic side of me is so happy to see this happen because I've been told time and time again how awesome NPM is and how the problems I see are actually features. <rain1>sometimes things have to go wrong a bit before they get fixed <df_>is it overkill to use gnu-build-system if all you really want to do is unpack? (then add a symlink in the user's profile) <rain1>if it has a configure and makefile then no reason not to use it <rain1>if it doesn't you'd just have to delete from phases, so you might as well use trivial-build-system <davexunit>df_: if that's *really* all you want to do, then yes. <davexunit>try using trivial-build-system as rain1 suggests <df_>ok, will have to figure out how to unpack then <df_>I'll look at some examples <davexunit>check out the 'unpack' procedure in (guix build gnu-build-system) <rain1>I use searches like this a lot to find example code: grep -r trivial-build ~/.config/guix/latest/ --include=*.scm <df_>I assume I have to declare that I want tar available? <rekado>davexunit: I just read your response to the npm+guix GSoC proposal. <rekado>you mention recursive importers there <rekado>I wanted to extend the cran importer to do recursive imports <davexunit>rekado: I want to do the same to the Ruby importer. <rekado>but wouldn't that require to create full package definitions, i.e. with variable bindings etc? <rekado>just checking, because I wasn't sure if there's any other big picture idea there that I didn't see. <davexunit>also, should the importer try to identify if an *existing* package already satisfies a dependency and use that instead? <davexunit>and maybe spit out the appropriate (use-modules ...) code at the top? <davexunit>I think we need a framework for this that all importers can share. <davexunit>GuixSD will never be a solution for all node programmers. maybe Guix could be a solution for the subset of node programmers that use GNU/Linux, but that still leaves out a ton of people. npm should be better than it is. <rekado>jmarciano`: isn't that old news? <rekado>I thought this break in happened about a month ago? <rekado>if I remember correctly this spawned a discussion about signing more, and triggered some criticisms of "guix pull" (which doesn't try to verify what it downloads). <rain1>So the problem is that, even though I have dbus-c++ as an input to ring-daemon, and it installs a correct pkgconfig thing which I've tested, its ./configure just doesn't find dbus-c++ <rain1>I can't imagine why, pkg-config is there everything seems to be set up correctly <davexunit>civodul: didn't get a chance to reply to this in time, but it looks good to me! :0 <davexunit>as I share this around, I am reminded of something: reddit won't change r/GUIX to r/guix <davexunit>so I'm thinking of declaring it as obsolete and creating r/guixsd instead <davexunit>yeah I was surprised that it wasn't mentioned <rekado>civodul: thanks for the new pam extension feature! Looks like this will also be useful for making pam respect limits. <rain1>I'll give up on ring now, if anyone wants the packages work I did so far feel free to ask <bavier>cloudflare ruins much of my w3m browsing <civodul>same here, those damn companies don't want us to have privacy <rain1>it's funny gnu social uses it for DNS <davexunit>civodul: I think /gnu/store/g70195d256g0nllq75r6zphdf38d9zmr-boost-1.60.0 may be corrupt <civodul>yeah i started looking at it this morning <civodul>but i don't fully understand what's going on <davexunit>okay. just wanted to make sure it was reported. :) <davexunit>thankfully guix is awesome and I can just build boost myself and press onward <civodul>davexunit: you're getting a hash mismatch, right? <rekado>for boost it's just a truncated archive <civodul>but that translates to a hash mismatch, no? <davexunit>so I did the ol' 'guix environment boost -- true && guix build --no-substitutes boost' trick <davexunit>(wishlist: add a flag to 'guix build' to do this trick more easily) <rekado>the hard part here is to find a good flag name :) <davexunit>--build-only-the-things-i-specify-but-use-substitutes-for-everything-else-please <efraim>another one I want is --use-upstream-substitutes for when I have to download source <davexunit>so the full thing would look like: 'guix build --requisites boost && guix build --no-substitutes boost' ? <bavier>make it singular, to suggest that it applies to only the named package <davexunit>it removes the abuse of 'guix environment' ;) <rekado>"--no-substitute" makes me uncomfortable -- I'll always double-check the end to see if I forgot the "s" <bavier>civodul: I was able to reproduce the guile vm.c failure with -Os, it fails with gcc@4.9.3, but works with gcc@5.3.0; unfortunately the reduced test-case isn't trivial so doesn't suggest a workaround <civodul>bavier: oh, ok; so you got a test case generated by c-reduce? <bavier>civodul: yes, but it's still 7097 bytes in size <bavier>and since it's not an issue in 5.3.0 it doesn't seem worth a bug report <civodul>could you paste it? i'm curious to see what it looks like <ng_>davexunit: about npm, yeah last thing I read yesterday before going to sleep, I just thought: hey, i hope guix can replace that one day soon. <ng_>civodul: I consider using 1984hosting for patches test (and more), given that Guix is still young 200GB/month is still realistic, right? Every low traffic service I ran used less than that. <rekado>for tests I'd be okay with offering some space on elephly.net as well. You wouldn't need to pay for hosting then. <ng_>well I had a waiting period on my domains to resettle, and I consider running other low traffic services again there until GuixSD is in a state where I can run it on a dedicated server here. <ng_>so it wouldn't be exclusive to that one service. <ng_>but maybe it's easier if we use elephly.net as it's already functional. <rekado>what software did you want to evaluate? <ng_>no, i was talking about the software "patches" <ng_>like civodul mentioned in the thread about patch management <rekado>ah, good. I'll see if I can create a little set up over the coming free days. <civodul>ng_: for testing purposes, it could be hosted anywhere <civodul>we can host it on bigger machines when the test is conclusive <civodul>but i wouldn't worry about those details for now <rekado>reading the README --- this is meant to be used by developers on a local machine, no? <ng_>there's a server readme <ng_>oh, i think I maybe pick advania as a new temporary hoster/dc. I'm just waiting for GuixSD to get where I want it to be, so I can use IN-Berlin with my own server and not worry about bandwidth for the service I used to run. <rain1>II thought id try gnome but system reconfigure failed <ng_>(gnome-desktop-service) ? <ng_>is this the complete error? <rain1>no just the part i thought was relevant <ng_>could you paste your system config? <rain1>I would have to remake it, I had just deleted the gnome stuff to do a clean reconfigure <ng_>i could push my current working config so you could compare? <rain1>I'll hake a look over it to see I didn't do anything wrong <rain1>I don't really want to use gnome, just reporting the error in case it's helpful <ng_>url might be different, for me it's origin git@notabug.org:niasterisk/guixsd_niasterisk-configs.git <ng_>file you want to look at is config-t.scm <rain1>onl/y difference is you don't have gnome listed inpackages <ng_>because i have (gnome-desktop-service) <ng_>with it in packages it breaks <paroneayea>looks like I'm not the only one hitting the boost issue! <anthk_>it's possible to install gnome from "guix system init" by placing it in the config.scm file? <davexunit>ugh, I learned that in ruby you can specify, at runtime, what the allowable versions of a library are. <rain1>does that mean i can literally make a ruby library that choses to install or not based on the phase of the moon? :) <davexunit>so if you upgrade a library that the developer of another library says is not supported *directly in the code*, your application dies. <rain1>I tried this a sec ago and it didn't work.. but I might have made a mistake in my config <davexunit>rain1: it doesn't install, but the ruby runtime apparently knows about the versions of things <rain1>system reconfigure always installs what's needed <ng_>rain1: it is because you have gnome in packages <ng_>remove it and put gnome-desktop-service in services <paroneayea>civodul`: is there any way to embed a scaled down copy of the screenshot *in the blogpost* about gnome? <anthk_>(services gnome-desktop-service %desktop-services) ? <rain1>(services (gnome-desktop-service) %desktop-services) <rain1>thanks ng, might try overnight since the install took so long <anthk_> # /mnt/config.scm:8:0 source expression failed to match any pattern <rain1>if you like you can paste your config? maybe can spot the error <rain1>its a syntax error, a field or something is wrong <anthk_>does the guixsd installer provice SSH? <lfam>davexunit: You don't have to use `true` in that trick. Remember that you can do `guix environment boost -- guix build --no-substitutes boost` ;) <rain1>(services (cons* (gnome-desktop-service) %desktop-services)) <rain1>services wants a list of services, cons* makes it <anthk_>(services (cons* (gnome-desktop-service) %desktop-services))) ? <rain1>don't put gnome in there, that's the mistake I made <anthk_>I don't need xfce, if I delete it, I get the same error <rain1>I wonder how to find packages that Id on't need anymore, guix gc --list-live lists way too many things to sort through <anthk_>unbound variable: gnome-desktop-service <rain1>try adding gnome to use-package-modules at the top <ng_>anthk_: take a look at my config. <ng_>gnome-server requires desktop <davexunit>probably the most annoying thing about all of this is all the people seeing "this is why you should bundle all the source for your dependencies!" <rekado>anthk_: the indentation is confusing. <anthk_>I know, but I needed to fit in the screen <rekado>anthk_: swap-devices has no closing paren. <anthk_>now after fixing it, "Unbound variable: gnome-desktop-service" <davexunit>you must import the symbols you wish to use in your program <rekado>davexunit: isn't it already there? <anthk_>davexunit, I have (use-service-modules desktop networking) <davexunit>anthk_: you must be using an old version of guix <rekado>anthk_: did you run "guix pull"? <anthk_>davexunit, I am running the one from the installer, can I do a guix pull from it? <lfam>Oh man, I think we really need to do a better job communicating that <davexunit>IIRC someone patched the manual/motd so that we tell people to 'guix pull' first <lfam>Okay, so from the next release hopefully more users won't get tripped up this way <Jookia>It should also run dhclient automatically] <lfam>I think our new users are tired of dealing with it too <lfam>It wastes so much time for them <Jookia>fwiw not having dhclient run automatically tripped up many virtualbox users <davexunit>we can't possibly know what network device people want to use <Jookia>this is true, maybe note it? a lot of distros run it automatically <rekado> Jookia: the instructions do mention that networking needs to be configured first. <rekado>FWIW the CentOS installer doesn't unless you tell it to. <rekado>by default networking is not enabled. <Jookia>oh! i was remembering it wrong, davexunit was there too so nevermind ***Basstard1 is now known as Basstard`
<davexunit>since we don't have a fancy installer, and our target audience is *experienced* GNU/Linux users currently, I think we're okay as long as we make the directions clear. <davexunit>the manual didn't say to 'guix pull' and that sucked, so we fixed it (I think so anyway) <davexunit>but the manual already says to configure the network interface <paroneayea>might this be the watershed moment where people realize that npm style design is a real problem? :) <rain1>why not put info about setting up networking in the guix live usb MOTD? <lfam>sneek: later tell efraim: I tried building Syncthing against your Go package (from your GitHub) repo, but unfortunately it failed with "[...]libgcc_s.so.1: cannot open shared object file[...] <rain1>that maykes it really easy to see <davexunit>rain1: because the MOTD is insufficient for documentation <sneek>Welcome back efraim, you have 1 message. <sneek>efraim, lfam says: I tried building Syncthing against your Go package (from your GitHub) repo, but unfortunately it failed with "[...]libgcc_s.so.1: cannot open shared object file[...] <Jookia>Luckily Guix has proper documentation so it's all in info <Jookia>Guile and Guix have documentation I aspire to have for my own tools :) <davexunit>I believe the MOTD already directs users to the manual on whichever TTY it's on <lfam>I see that codemacs hsa recent work on his own Go package. I wonder if it's working yet? <rain1>I'm not saying delete the information <davexunit>so we just need to make sure the instructions in the manual is *complete* <lfam>efraim: I also wonder if we should ask upstream Go people for help? Do you know if anyone from Guix has done that yet? <efraim>ludo pointed me at the libgcc_s in base?.scm <lfam>Another take on packaging Go for Guix ^^ <ng_>the binary installation at step 2.1 on the documentation at gnu.org might be improved too.. i just tried to use the link I asumed and got a deadend <davexunit>oh boy I'm being downvoted on HN for suggesting that bundling dependencies isn't the answer to the NPM debacle. <lfam>efraim: Do you understand what that part of base.scm / glibc means? I don't get it on first glance <ng_>lfam: wget ftp://alpha.gnu.org/gnu/guix/guix-binary-0.9.0.x86_64.tar.xz is what not thinking much about details you would use when you download guix. <fuzzyhorns>has anyone suggested a blockchain dept manager on HN yet? :d im curious on that <efraim>when i was working on gccgo-5 i got an error about that <efraim>so the clue was to see how it was dealt with elsewhere in that file <lfam>fuzzyhorns: What do you mean by "dept manager"? <fuzzyhorns>davexunit: it is odd that people downvote that as it's p reasonable strategy <fuzzyhorns>lfam: typo, meant just dep manager, iow dependency manager <davexunit>fuzzyhorns: bundling is a reasonable strategy? maybe you've misread me. <ng_>oh. need to append -linux <fuzzyhorns>davexunit: oh i did! oh i am curious to hear more <ng_>we should append that to the example, i just tried it from the pov of someone not thinkig about these details <fuzzyhorns>i dont have strong feel on this, more just want to learn :) <rain1>suspiciously close name to 'guix' <davexunit>Qt is a wonderful example of bundling gone wrong <lfam>fuzzyhorns: When bundling the library foo, then every upstream developer must issue updates when there is a security update to foo <rain1>building qt took me awhole day <lfam>But in practice, that doesn't happen <ng_>i have no clue about how to edit the manual, so whoever can, it should be reflected that $arch needs an appended -linux <rekado>it's plain text with a little bit of markup. <lfam>ng_: If you want to then look at your changes in a web browser, you can build the web pages with `make doc/guix.html` <davexunit>fuzzyhorns: the problem with bundling is that it makes your users dependent on you for critical updates to software that you didn't even write. <davexunit>it increases the surface area of any given software vulnerability <ng_>lfam: okay, will edit it later <fuzzyhorns>true, in some sense though i wonder how to avoid that as if it's mixed in with your code, it's not truly sep either <lfam>fuzzyhorns: Avoiding that *is* the traditional way that most distros are built on <davexunit>instead of updating the *one* problem package and moving on, users now have to figure out what things bundle the vulnerable package <lfam>You link against the external library <davexunit>particularly when the application has used static linking <davexunit>inspecting your package manager *won't* tell you about the bundled stuff <davexunit>because to the package manager that application *didn't* depend on those things <davexunit>because it bundled, which is opaque to the package manager <lfam>What was the link to the rant about hadoop? Remember that? That was a *great* explanation of our point of view on this topic <davexunit>bundling defeats convenient forms of auditing. <lfam>The hadoop catastrophe... <davexunit>lfam: "the sad state of sysadmin in the age of containers" <fuzzyhorns>what do yall make of something like GX? something like that i think is very neat on the face of it:x <lfam>I hate that Google does that <lfam>Even sharing a link feeds their AI <davexunit>which is why I never share google links when I have my head on straight <lfam>I started using DDG a few months ago and it really is good enough <lfam>Once in a while I'll try Google to see if I'm missing something <ng_>and if not you can always go bang google <fuzzyhorns>do you all have thoughts on a good source to read about the "better" way to do this? <lfam>It's not a panacea but it does give some diversity <fuzzyhorns>lfam: to your point, the way distros do it, i mean <lfam>fuzzyhorns: Well, we are biased towards our way :) The Nix paper by Eelco Dolstra is a good introduction to the fundamentals of our system. We are a fork of Nix, although we share very little code. <davexunit>there's fun stuff like that for a variety of programming languages <fuzzyhorns>yeah ive read a bit about nix, i should go back and read that paper <rekado>I don't think Guix can be called "a fork of Nix". <rekado>it's not like Guix started from the same repository/tarball <rekado>we just use one component of Nix: the daemon. <fuzzyhorns>if it's not impolite to ask, do you all have thoughts on "why" guix vis nix? <rekado>all the build code itself is written in Scheme. <fuzzyhorns>for context, i do find the gnu stamp appealing so i'm sold there :) <lfam>fuzzyhorns: For me, I chose to get involved with Guix because of GNU / 100% free software and because of Scheme <rekado>fuzzyhorns: Guix is quite different from Nix. I really like about it that it's pretty much all written in Guile Scheme. <ng_>somebody I spoke to dumbed it down to "civodul likes languages" <Jookia>Guix focuses on freedom politically <rain1>I read that civodul was a Nix developer <rain1>and created guix because there was some things which are too difficult in nix, that guix redesigned and solved <lfam>Indeed. We actually do share patches on the Nix daemon back and forth with Nix <fuzzyhorns>oh rain1 do you have material to read on that? im def curious. i havent watched the video on the guix page yet though, perhaps that will answer my questions <lfam>The homoiconicity of Scheme (meaning, code is data and vice versa) allows us to inspect and transform our code base easily, without text scraping. <fuzzyhorns>lfam: ive never used a scheme "in anger". i should prob try that. i do like having a type system though :x <lfam>civodul was here only a little while ago. Too bad he left :) <lfam>fuzzyhorns: I'm pretty new to Scheme, so I don't have a strong or educated opinion on topics like that. I find the Guix codebase to be a pleasant place to work <lfam>And I am really impressed by the speed and brevity of the solutions that more experienced Guix developers are able to implement <lfam>By speed I mean speed of writing the code, not necessarily speed of execution <anthk_>next I would like to try the sly package for Guile :) <lfam>The sly developer is in this channel! <Jookia>Sly's a really cool piece of software <lfam>You should ask davexunit ;) <Jookia>It's one of the reasons I'm looking seriously at learning Scheme :P <lfam>Wow, that's pretty cool! <rekado>FRP without the laziness trap of similar Haskell offerings <davexunit>Sly 0.1. is getting a bit old. I'd like to get 0.2 out soon, hopefully before the next Lisp game jam. <davexunit>I borrowed lots of ideas and terminology from Elm <davexunit>it's basically the usual dynamic vs. static feud <Jookia>I'm still skeptical of lack of laziness but eh <Jookia>Also is there a reason Sly uses ticks in the FRP abstraction? <davexunit>the FRP implementation itself doesn't care about that stuff, but for the purposes of a game I use a scheduler that integrates by "ticks", where by default there are 60 ticks in a second <davexunit>so naturally there are signals that hook into the scheduler and change their values based on that <davexunit>if/when any of you folks wants to talk more about sly or get help, there is a #sly channel <Jookia>Joined to kinda move this discussion <anthk_>mmm another package manager with xdg-app :| <davexunit>well, GNOME is behind xdg-app so it makes sense <davexunit>AFAIK it's *the* package manager using xdg-app <anthk_>I know, but GNOME is too much binded to RH <lfam>I need to share my WIP GNOME Maps package. I got stuck and distracted but I suspect the issues are easy to fix <anthk_>btw you have a gnome updater for GUIX? <ng_>It's right that I assume for guix.texi to also add my name to the @copying section, is it? <lfam>ng_: Yes. Just be sure to add the '@*' to the name above yours <anthk_>just by using guix system reconfigure ? <lfam>Otherwise, certain output formats will not have correct formatting (I learned the hard way) <ng_>lfam: yes, i see the patern. thanks <anthk_>ok, I've seen it's a metapackage <ng_>okay this is weird. in the checkout it's fixed, on the website it's not. <ng_>and on the website also <ng_>it just escaped my eyes <civodul>paroneayea: re shiny blog posts, we'd need to use a different tool :-/ <aeva>how do I install i386 versions of libraries? <Jookia>I'd imagine you'd select a target to bulid it for but I'm not sure. I'm interested too <mark_weaver>aeva: pass --system=i686-linux to "guix build" or "guix environment". <mark_weaver>aeva: guix environment --pure is probably what you need, and the spawned subshell will contain exclusively 32-bit software <davexunit>it may have access to more if this is Guix on a foreign distro with /usr :) <davexunit>I don't think we have a way to specify that some packages in a profile should be built for a different arch than the rest <mark_weaver>aeva: guix doesn't use traditional multilib. instead, you'll be using the exact same store items that someone on a 32-bit computer would be using. <jmd>I want to define two outputs for a package. How do I do it? <mark_weaver>jmd: add an 'outputs' field to the package definition, e.g. (outputs '("out" "doc")) <lfam>jmd: I think the transmission package is a good example. <Digit>ACTION just checked in to see what condition guix distribution was in... well well well, there be talk links up there again. :) <lfam>The condition is improving! :) <lfam>tyngdekraften: I think the interesting stuff is above the first line. Is it possible to show that output? Also, how are you trying this? <lfam>How are you trying to do this? Are you using `guix system vm` or some tool like that? <lfam>If so, can you share the command-line you sed? <efraim>bah zerobin needs javascript, can't use it from links ;p <aeva>I'm using guix on fedora at the moment; I did the envirenment --pure thing with the i686 flag as well, now I got a different error, "wineg++ not found" - tried running "guix package -i wine" to reinstall it but said it was already installed? <lfam>You really see the reach of javascript from the console browsers. So many sites don't work atll <lfam>tyngdekraften: In what kind of virtual environment? <aeva>lfam I could use a non least-authority pastebin if privacy is less important than not running js :P <aeva>(if you have a good recommendation) <anthk_>mm so in the near future we will have a Synaptic like front-end for Guix <mark_weaver>aeva: add "--ad-hoc wine" to the "guix environment" command line <lfam>aeva: I just use paste.lisp.org. I don't know how that works in a console browser because I don't spend much time in those <mark_weaver>aeva: "guix package -i wine" would try to install wine compiled for a 64-bit system <efraim>i use links mostly for code snippets, downloading source packages and opening articles from newsbeuter <lfam>tyngdekraften: Okay, I've never tried that but I have a few recommendations <mark_weaver>aeva: to be clear, the way this works is that within the "guix environment", every piece of software you use, including the toolchain, will be running in 32-bit mode, e.g. the exact same software I'd run on my 32-bit Thinkpad X60. <mark_weaver>aeva: since you're running on top of Fedora, there's a danger that ./configure will end up finding 64-bit things from /usr <lfam>tyngdekraften: First, be sure to run `guix pull` before you start the `guix system init`. This will update you to the latest package definitions. We have garbage collected the binary substitutes for 0.9.0, so you will have to build almost *everything* from source, and you will not get a bunch of critical security fixes. <aeva>mark_weaver fedora's version of winemaker just segfaults, yeah, I should probably avoid their build all together <efraim>hackernews works in links, just missing the formatting for who's replying to who <tyngdekraften>lfam: Yes, it took almost three hours to compile eveything and the hydra servers were very slow <lfam>tyngdekraften: Second, we have some very good built-in tools for virtualizing GuixSD in QEMU, under the `guix system` command. For this, you will need to install the Guix package manager on your GNU / Linux distro. This is not hard and does not effect the host distro. <mark_weaver>aeva: all of the packages you'll need should be included in the 'guix environment' command. guix environment <pkgs1>... --ad-hoc <pkgs2>... will include everything needed to *build* <pkgs1> ..., and will also include <pkgs2>... <lfam>I really recommend you go that route instead. I do think some users have successfully installed GuixSD in VirtualBox, but I don't have any experience with it <tyngdekraften>lfam: I can try to built it from in a real system, I just wanted to try it first <mark_weaver>aeva: you might indeed need to pass --container as well, in order to ensure that things from /usr won't get picked up <mark_weaver>aeva: davexunit is the best person to ask about this, I've not done this myself. <tyngdekraften>lfam: Thanks for the recommendations, I will try it tomorrow and tell you the result <davexunit>Digit: the guix video from libreplanet isn't up yet <mark_weaver>aeva: but if you can find some package in guix that cover most of your build dependencies, then you could include that in <pkgs1>... <davexunit>it will probably be a few weeks before we see it <mark_weaver>aeva: and that will include the usual utilities like grep, etc <lfam>tyngdekraften: If you choose to continue trying your current method, you should at least do `guix pull` and pass '--substitute-urls=http://mirror.hydra.gnu.org' to `guix system init`, because that mirror should be much faster. <lfam>Please come back if you more problems! <aeva>mark_weaver well, its downloading a bunch of stuff now <anthk_>can I ctrl-C the guix system init? <lfam>I wonder if we should apply that <lfam>anthk_: The mirror is the default in the current version of Guix, but not the old 0.9.0 release. <aeva>mark_weaver hopefully that is all going somewhere into my home partition instead of my very full root partition XD <lfam>anthk_: Did you know that you can easily make your own USB installer with `guix system disk-image`? <aeva>mark_weaver well butts xD <lfam>Anyways, just a hint. You could also set the substitute url in the old copy of the installer <lfam>I don't know whether or not it will be successful to interrupt the initialization process. Some other users may know <lfam>One nice thing about doing it from the current Git master is that then you will be able to fetch over HTTPS, which is obviously better than HTTP <efraim>so 2.48.0 should be repoducable? <lfam>efraim: I'm not sure yet, I just saw it the headline in #reproducible-builds on irc.oftc.net <anthk_>lfam, I did a guix pull, don't worry <davexunit>hmm I'm getting complains from a shared library I'm trying to load: <efraim>i saw it in the debian bug thread <lfam>anthk_: Okay, I'm worried that installing GuixSD is too hard and finicky :) <lfam>efraim: I read the (short) thread. That's promising! They say they will release soon, so I guess we should just wait <anthk_>I think the GUI for BTRFS snapshots at OpenSUSE would be nice as an example layout <efraim>guix refresh -l glib: 705 dependent packages are rebuilt <lfam>efraim: Yeah, so no hurry ;) <davexunit>I don't understand how this code could have compiled but then can't run <lfam>anthk_: That's a great interface considering what it enables otherwise "non-technical" users to do. <lfam>Backups are still out of reach for most of those people, in my experience. Filesystem snapshots are a good component of a solution for them <ng_>where are the licenses listed again? <ng_>or short question: do we already have " GNU LIBRARY GENERAL PUBLIC LICENSE" ? <Digitteknohippie>i've long had an idea of gui that teaches commandline/code. are there moves towards interfaces for guix that have this principle that it's easy-for-newbies low bar entry, and without the typical opaque plastic wrap that keeps them ignorant? it seems an idea that fits with the guix philosophy of empowerment, sneaking in code learning through use. <ng_>was this recently rebranded in lesser gpl? ***Digitteknohippie is now known as Digit
<Jookia>ng_: Not recently I don't think, but I think it was <Jookia>BUT I'm not sure if it's okay to say it's the lesser GPL if it says library GPL <Jookia>Maybe it could signify author's intentions if they delibertaly chose library GPL, idk <ng_>it's a library.. I could also ask the authors later <Jookia>mark_weaver: Have you thought about having some Lisp code that users compile using paper and pen to get to machine code somehow? ;) <jmd>So if I want to make a non-standard output "foo" are there any special things I need to do? <bavier>then arrange for the build to put things there <jmd>And does the install directory get created automatically, or do I have to create it? <mark_weaver>jmd: note that gnu-build-system automatically handles some output names, e.g. "bin" "lib" "include" "doc". search for "assoc-ref outputs" in guix/build/gnu-build-system.scm <janneke>do we have something like apt-file search in guix already? <rain1>I got your email about gensym twice <rain1>I wrote about half a reply but I'm not sure if it matters <ng_>can I make the gnu-build-system do a "cd src/" at the very beginning? <bavier>ng_: you'll need to add a new phase, with modify-phases that does a (chdir "foo") <ng_>is an add-before valid for that? <bavier>search for "chdir" in the package modules for examples <ng_>libtocc is an example <rain1>I think the bug can be closed since people are ok with the current <ng_>this npm situation gets even better.. kik released the email thread for whatever reason.. breach of secrecy of correspondence, woo \\o/ <ng_>well cut te last part of my sentence, but it's still pointless medium post <ng_>tl;dr sorry for not being sorry <ng_>checking for yacc / <malloc.h> / -DSGI_SOURCE / afree name clash... /tmp/guix-build-psyclpc-20160211.drv-0/psyclpc/src/configure-do: line 14285: yacc: command not found <ng_>where do I get yacc binary in guix? <ng_>thanks :) and thanks for reminding me that the gentoo ebuild has its point <efraim>i'll have to checkout the ebuilds, I've been looking at the pkgbuilds from arch and the ocassional build script from the BSDs ports <rekado>yale-haskell looks interesting. It contains some common lisp glue code to provide a more scheme-like environment on different lisp implementations. Much of the code looks a lot like regular scheme code. <rekado>last release was in the early 90s <rekado>this looks fun and unproductive, so I think I'll play with this and try to make it work with Guile. <rekado>would be nice to have a(n early) Haskell on Guile. <bavier>rekado: that's the best kind of hacking :) <Jookia>Oh man that NPM disaster is some quality schadenfreude <ng_>set the world on fire through patent laws \\o/ <civodul`>rekado: that sounds like a nice project :-) <ng_>this is in src/autoconf/configure.in which creates the configure-do which is run in the process of configure. however gnu-build-systems seems to not touch line 2885 which includes "CONFIG_SHELL='/bin/sh' " which then causes the build to fail as it produces a #! /bin/sh in configure-do (or -go? idk) <ng_>if test -z "${CONFIG_SHELL}"; then <ng_> CONFIG_SHELL='/bin/sh' <rekado>CONFIG_SHELL is passed to ./configure <ng_>for the build yes. or maybe not, I'm trying to find the file which sets #! /bin/sh and does not get changed by the scripts <ng_>maybe I post the error log <rekado>heh, the scheme-like layer on top of common lisp in yale-haskell is called "mumble". <ng_>i see people discussing fixes around npm which include npm as a base for a new kind of npm. nowords. <bavier>ng_: that psyclpc code does silly stuff <ng_>but if I figure out where this comes from I can simply tell the devs and it gets an update <bavier>they really shouldn't be running autoreconf during build <ng_>maybe i just look at that again <bavier>their configure script ultimately ignores any arguments passed to it <ng_>i don't know enough to fix this <bavier>ng_: do like the ebuild and run settings/psyced directly, because it also generates the configure-do script <bavier>but patch settings/psyced so that is does "exec ${CONFIG_SHELL} ./configure-do" instead <bavier>I think that should work, the shebang will remain unpatched, but it will be ignored <ng_>okay, i'll try that. thanks <rain1>this has some good analysis of the security situation, which may be relevant to guix <civodul>why so much fuss about these npm packages? <civodul>after all, there's a million packages on npm no? :-) <rain1>one security issue is that if author deletes their package, then someone can swipe the name <rain1>and the package manager doesn't mine - just installs that new persons new code in anything that depended on it <rain1>(of course guix is secure against this thanks to the hashes in package definitions) <rain1>there has been discussion of including npm in guix on the MLs... <Jookia>Yes, koz_ wrote that ;) He's not here but I'm setting him up with Guix <Jookia>Right now from what I know his T400 is in Francis' hands, but who knows ***Basstard1 is now known as Basstard`
<Jookia>I think what we can learn from npm is that we need a p2p source hosting system + pinning versions of packages using hashes <ng_>p2p source hosting is one of my further ideas for gnunet (or even secushare).. some p2p git, to discuss. <ng_>eh hosting/working system/thing/just a scrap of an idea <ng_>someone should name an npm package microsoftwindows and wait for the real patent trolls <ng_>sorry, staring at too much text right now. of course i know patents =/= trademarks <Jookia>Part bullying, part the fact you can do this at all <ng_>i hope they get the reaction back they deserve when they publicly lie and pretend to "love open source" <civodul>"open source" is not something i care about <ng_>open source was in their words, i don't care too 
