<dannym>lfam: I used the pre-inst-env anyway in order to extract the (claws-mail) source. I then adapted it. And now? <lfam>The bug, is it related to using claws-mail in Guix or should it go upstream? <dannym>lfam: probably upstream. The calendar doesn't show boxes in the week overview because they use colors wrong :P <lfam>dannym: If the bug is not fixed or filed upstream, here is what I would do: Make a patch of the changes against the claws-mail source tarball we distribute. Apply it to our package definition as in commit 6f74aecdb30d. Finally, file a bug report upstream, and provide the patch. If the patch doesn't apply to upstream's HEAD, adapt it to do so. <lfam>If it's not a bug but rather working around something Guix specific, then we usually do the patching while building, as in f5a8491b69830 <lfam>The difference is that the former is applied to the source tarball provided by `guix build --source`, and the latter is not. So, real bugs are fixed for someone who may use Guix to get the source code but does not want to build with Guix. But Guix-specific things are only applied while building with Guix. <lfam>And when fixing upstream bugs in our packaging, I always include a link to the upstream bug report in the package definition. <lfam>Hm, I have gnupg-2.0 in my profile. If I do `guix package -u`, it wants to upgrade it to gnupg-2.1. This seems wrong. <lfam>Steap: I just saw this reposted on #reproducible-builds on irc.oftc.net. It's really the core of why I think it's worth the effort <paroneayea>guess I'd better get a release out and package for guix... <mordocai>So i've found a number of bad source links due to https redirection and gnutls not being autoloaded, but pkg-config seems to break when I update it. This patch http://lpaste.net/151987 results in this result http://lpaste.net/151988. Any ideas? I can't download/build pkg config due to this error. <mordocai>In case anyone is curious, so far by doing guix environment guix --no-substitutes i've found libpcap, pkg-config, libva, and libdrm all needed their urls updated to be https or it fails. <mordocai>But as above, pkg-config doesn't like being updated apparently <mordocai>The url that should result from that works fine so... <mordocai>The only thing I can think of is that with this pkg-config depends on gnutls and gnutls depends on pkg-config. <mordocai>I'll send an email on the dev list and download pkgconfig from hydra for now <Jookia>Though my definition of bug is liberal ;) <calher>I can't do basic stuff because of this whacky system. <calher>The packaging guide in the manual doesn't help. <mordocai>I have no experience with it yet, but the people who write packages all the time seem to think it is quite nice once you get used to it. <mordocai>Idk how you are supposed to learn it though <Jookia>calher: What're you trying to package mate? <mordocai>davexunit: Hey, do you happen to know why this patch http://lpaste.net/151987 results in this result http://lpaste.net/151988? My guess is it causes a circular dependency between pkg-config and gnutls but not sure. In any case, I can't build pkg-config because it is now redirecting to that https url so I downloaded it via hydra for now. <calher>Jookia: I was originally going to package Mumble, but that sounded too hard. Now I'm thinking about packaging guile-irc, but that may also be too hard. I think I should just stick to something simple, like MCWM. <calher>Unfortunately, the hacker who wrote it is now a macfag. <sneek>dmarinoj, you have 1 message. <sneek>dmarinoj, lfam says: I think you need a working installation of the Nix package manager in order to use the nix importer. I've used it a couple times. It can only do the basic stuff. For complicated Nix package expressions you have to do the complicated stuff yourself. <davexunit>mordocai: perhaps it is. needs some investigation. <davexunit>mordocai: pkg-config is indeed a native-input to gnutls <davexunit>better inform the mailing list so we can sort it out. <davexunit>there could be a way to break this chain by building a minimal gnutls that doesn't need pkg-config at build time, and use that for these https downloads. <Jookia>davexunit: Speaking of circular chains, how does git-downloader (might not be the right module name) use the 'git' package without importing it and creating a circular dependency due to packages in the vcs module using git-fetch? I wish to do some tweaks to add socat to the git builder for proxy support, but I run in to that issue <davexunit>Jookia: none of gits inputs may use git-fetch for their source. <mordocai>I swear I need my own bug tracker. Anyone know what's up with this and clisp build? I think it is due to my /tmp being a partition maybe? http://lpaste.net/151989 <Jookia>davexunit: Ah, but when I do #use-module some code in the module unrelated to git would use git-ftech, yes? <Jookia>Sorry, I'll have to come back in a few days with some code showing my issue <davexunit>#:use-module may cause a module dependency cycle <davexunit>which in some cases is OK, some cases is an error. <Jookia>Yes, that's kind of what I mean- I assume to specify a package in a gexp you have to import the module it's in, yes? <davexunit>yes, because you are specifying a *variable* <calher_>Where's the git-fetch code for package defs? <calher_>How do I get that weird base32 hash? <calher_>How do I get the weird base32 hash thing for the tarball/ git repo? <xd1le>calher_: from the error message when you try to build it with an incorrect one (apparently) <calher_>xd1le: error message? but i want the correct one <xd1le>calher_: yeah same. as in, in the error message, it fails because it doesn't have the correct hash <xd1le>and it tells you what correct hash it expects <xd1le>so you just copy paste it from there <xd1le>or at least that's what i do <xd1le>i asked about this a while back, and iirc there wasn't any better way <xd1le>iirc, it might also work for a git repo, if you remove the .git directory <xd1le>and hash that resulting directory <xd1le>ofc, you lose all your git history by doing that, so make sure it's a fresh clone <xd1le>i guess remove the .git directory, and everything that a .gitignore would match.. <xd1le>in which case, i'd say copy pasting from the error message might be easier <calher_>xd1le: Could I tarball it and then base32 it? <xd1le>maybe, the problem is it's hard to predict what guix keep/remove (in the case of a git repo), i think <xd1le>calher_: anyway i'd also suggest waiting for someone more knowledgable to answer <xd1le>s/keep\\/remove/keeps\\/removes <xd1le>i'm also not exactly sure whether a tarball would give the same hash and hashing a directory.. <xd1le>(even with the same exact contents) <lfam>Probably the most "proper" way to get the hash of a source is to download it with wget or curl, check the signature or checksum if one is provided, and then use `guix hash`. <lfam>For git sources, I don't know how to do it except to put a garbage hash in the package definition and then copy the hash out of the error message. <lfam>And I'd bet that's how most people do it for any source. <xd1le>calher_: try `guix hash` or `guix hash -r` ? <calher_>OMG! OMG! There's a window manager written in Guile! <xd1le>that's more like a 'toolkit' isn't it? <calher_>And it's in a REPL, so you can modify the WM while it's running by just evaling some Lisp in Emacs! <calher_>xd1le: They said they've implemented a Stump clone with it. <xd1le>time to add it to the todo list <calher_>xd1le: Yeah, but that's written in Elisp :( <xd1le>yeah i know, but as in i guess you should be able to eval elisp in emacs to change it whilst it runs <xd1le>calher_: did you manage to hash a directory? <xd1le>ooh is it packaged for guix? <xd1le>calher_: i don't have access to guix right now either... otherwise i would <xd1le>have tried to remember how to do it myself.. :/ <xd1le>(because i was going to ask you how you did it if you did) <xd1le>btw i get a 403 forbidden on that link <xd1le>calher_: cloning seems to not work (i.e. hang), are you sure that's the right git url? <lfam>I checked, and you can get the hash of a git source by cloning, checking out the desired commit, removing .git, and using `guix hash -r` on the result <calher_>xd1le: I don't have to 'checkout the desired commit' if I'm just wanting what's in master, right? <xd1le>as in you don't need to check it out if you want what's in master <xd1le>it's because when you checkout a branch, HEAD points to the tip of that branch, *i think* <xd1le>so if you do `git show HEAD`, you'll see HEAD is at the latest commit on master, if you're on master <xd1le>calher_: how big is the repository, maybe it's huge? <xd1le>which is why it's taking long perhaps <xd1le>as in, i'm seeing network activity, but git isn't telling me anything, not sure if it's supposed to, but git usually says "Receiving objects: ..." and stuff <xd1le>calher_: nvm, took a while, but it worked <xd1le>so yes, what lfam said is correct <xd1le>calher_: so the hash i'm getting is: <xd1le>0yv28rr45x36nkm4r8fw7jcqzak1gaakwm84ly66p53cil1d9a9a <xd1le>calher_: which btw means that to hash a directory, you just `guix hash -r <directory>` <cbaines>Is there any documentation around on transforming a public ssh key generated with lsh, such that you can use it to login to a server running OpenSSH? <cbaines>(trying to get Guix to talk to Gitolite (which is using OpenSSH), and its telling me "FATAL: fingerprinting failed" at the moment) <alezost>calher_: it's absolutely OK (and the right thing) to have a description breaken into multiple lines <calher_>alezost: Will the line breaks show up when it's not appropriate? <alezost>calher_: no, the description will be formatted properly as it is passed through texinfo <alezost>it should be @url{http...} instead of @url{a lot of features http...} <alezost>don't use git-fetch, method; use a tarball instead <calher_>I mean, I guess there's... yeah, that. <Jookia2>alezost: should tarballs be used over git-fetch? <alezost>Jookia2: yes, if there is no good reason for git-fetch (like no releases, or maybe crucial fixes) <Jookia2>alezost: is this documented somewhere <alezost>I don't know; I thought it's a natural thing <calher_>I can see why. Git is more complicated. Tarballs are more 'official'. <alezost>a developper makes releases for a reason <Jookia2>i wouldn't really do tarball releases that aren't git archive tag snapshots <Jookia2>calher_, dependencies go in inputs maybe <calher_>(plain-file "torrc" ;; Will this generate a torrc? <calher_>Having to reboot to test configs is really making me not want to config stuff. <rekado>calher_: you could use "guix system vm" to test without a host reboot, but I agree that this could be made simpler <calher_>rekado: Does the X200 have enough power to VM? <civodul>calher: user 'tor' has no home and doesn't need one <calher>I don't see any info in the manual about VMs. ***francis7 is now known as fchmmr
***fchmmr is now known as francis8
***francis8 is now known as francis
***francis is now known as francis7
<rekado>calher: re power to VM: I don't know. I think that with libreboot hardware virtualisation does not work, because that seems to depend on microcode updates to the chip. <civodul>sneek later tell calher the 'tor' user is automatically created when using 'tor-service' <phant0mas>hey civodul if package A inherits package B, doesn't it also inherits the arguments field from package B? <phant0mas>which in our case gnumach inherits gnumach-headers with a modified #:phases field <phant0mas>that's why I did (arguments `(#:phases %standard-phases)) <civodul>usually we do it the other way around <civodul>that is, foo-headers inherits from foo <phant0mas>civodul: but is it possible to declare a package before the declaration of its dependencies? <NiAsterisk>I'll be flashing libreboot on friday evening.. how was the grub problem solved? does the patch Jookia submitted work, or does it work temporarily in some other way to boot into guixsd? <random-nick>will guix continue to support using it as a package manager on another distribution <xd1le>random-nick: it's a pretty major use case <civodul>petter: i'm looking at your doc patch, lots of stuff in there! :-) <petter>civodul: cool. Yeah, it turned out to be a full step-by-step guide. <petter>If you like it i want to add description for encrypted root with unencrypted boot. <petter>Also, i think it would be good to have description for encrypted home. Maybe someone already has one, or want to share home with another distro. <petter>oh, with regard to the booting chapter. Mark wasn't sure if this belonged in the Guix manual and proposed this as an addendum. But i don't know how to make addendums so i just made chapter. <civodul>petter: i was expecting only things related to encryption, but there's much more <civodul>so i'm trying to split it into several parts <petter>ok. I look forward to see what you do with it. And i'd be happy to help further. <a_e>which points to there: <petter>ACTION wonders how affected his Icecat is which don't allow pages to choose their own font <a_e>There is a new version 1.3.5 with a "security bugfix". <mark_weaver>oh, this seems to indicate the upstream 1.3.5 is fixed <a_e>There is a discussion there: <a_e>which seems to indicate that all four of them are fixed, but I did not find definite information. <a_e>The debian page seems to imply that one of them is not. <a_e>If you update, you should also modify the web page, which points to github now. <mark_weaver>looking at the upstream git repo, it doesn't look like there have been any recent commits addressing these bugs <mark_weaver>the relevant code mentioned in the blog entry I linked above has not been touched since September <a_e>They mention directmachine.cpp. <a_e>But also "If the opcode in particular is a cntxt_item". <a_e>There is git commit 2fc07f868146f924621307925b92a5161b7bd571: Disallow nested cntxt_item <a_e>This is in 1.3.5. But as a non-specialist of the code, how should one know if this is a fix? <mark_weaver>but we need updates for graphite2, libsndfile, and libgcrypt in the next security-updates branch <mark_weaver>if someone wants to take care of making this happen, that would be much appreciated. <civodul>Graphite is basically a VM for a language akin to PostScript it seems ***S is now known as Guest54337
<civodul>fakeroot is the Debian thing that makes it looks like you're running as UID 0 IIRC ***marxistvegan is now known as marxistvegan_
***marxistvegan_ is now known as marxistvegan
<lfam>Thanks for taking on that challenge! <Steap>Truth be told, we cannot have something that works as well as virtualenv (for now) <Steap>but it would be nice if the tox devs could let us have "beta" backends <Steap>I hope the Nix people will be interested in this as well <lfam>Can anyone help me understand the role of "glib:bin"? What does that binary *do*? <lfam>I'm reviewing that patch adding the notmuch address book tool, but I really don't know what to say about glib as an input. <lfam>Steap: I'm curious, what are the current advantages of tox over guix-tox? <Steap>lfam: they are the exact same, but virtualenv+pip is replaced with tox <Steap>you get the ability to install packages not written in Python (think of the C libs needed by Python packages) <Steap>completely isolated environments (with virtualenv, you have access to the whole filesystem, the env variables are not reset...) <lfam>Ah, I thought that tox was just a test framework. I didn't realize it could resolve dependencies as well. <lfam>I see all the advantages of Guix over upstream Tox, but not too many disadvantages ;) <paroneayea>is how to replace the commands that are normally set up via "python setup.py develop" <paroneayea>which normally dump some commands, like a "gmg" command in mediagoblin's case, with something I can run which links to mediagoblin's (or whatever's) source <paroneayea>I've thought of some solutions but they all do relatively evil things by linking to things outside of the store <paroneayea>davexunit: yes, the trouble is how to reproduce pre-inst-env in python environments <davexunit>just set PYTHON_PATH to include your source tree <paroneayea>davexunit: maybe it is that easty... I guess it's also not hard to reproduce the "entry points" into launching scripts <lfam>Do we have a standard answer to whether the contents of (arguments) should be quoted or backquoted? I've read the difference between the two, and I think I understand it. Of course there are many cases where backquotes are used although nothing is unquoted. Advice? <paroneayea>since they're usually pretty simply "import this module, run this function" <davexunit>lfam: don't use quasiquote unless you are unquoting <lfam>Okay, and the only mechanism for unquoting is the comma, correct? <davexunit>in those cases where you don't unquote, I mean. <davexunit>likewise, `foo is short for (quasiquote foo), and 'foo is short for (quote foo) <lfam>I'd say it would be very bitter without <lfam>It's a whole lot of sugar <civodul>Steap: good that you've submitted the proposal to upstream tox! <Steap>civodul: yeah, though I don't think it will be a priority for them :D <davexunit>it could be a burden to maintain multiple backends <davexunit>the choices seem to be: 1) add such backends to tox itself or 2) add backend API, only ship virtualenv backend, but have to maintain API compatibility for third-party backends <civodul>it could be that maintaining a backend API would be cheap enough <Steap>the whole thing is currently virtualenv-centric <Steap>not sure how easy it would to make it backend-agnostic <davexunit>hopefully easy-enough if you submit some patches ;) <paroneayea>all tests but 2 passing with using mediagoblin on guixsd for hacking <paroneayea>but I had to set up the bower stuff on debian ;p <dannym>lfam: (for what it's worth, I tested a postgresql #:config-file including the end quote by now and it works) <lfam>Hey dannym! Okay, thanks for the feedback! I'll push the fix. <lfam>I wanted to ask since it wouldn't be practical for me to test it myself <dannym>lfam: Yeah, I'm currently connected to the template instance and creating a new database works. Goood. <lfam>Awesome :) I'm very glad you tried it and reported the bug. <lfam>I was just typing in the SSH key password ;) <dannym>I ran into another (workaroundable) bug when trying to use #:config-file, though, but the report seems to have been... not copied to the mailing list. <civodul>lfam: BTW, ahem, don't look at what git blame says on this file <dannym>So just in case: There's this guix system reconfigure functionality that checks the service list and starts new services (that previously were not in config.scm), stops services that are now not in the config.scm; it seems it doesn't notice when the call parameter list changes. In any case, it doesn't replace the postgresql call. <lfam>dannym: Do you know the number of the bug? <civodul>dannym: right, it doesn't do that yet <civodul>dannym: but, if you run "herd stop postgresql" right before "reconfigure", it'll remove the old one and start the new one <dannym>lfam: 22619. Although I misattributed the cause there... <dannym>civodul: yeah, I found out. However since my service was respawning without being able to run, I forgot at first that I had to do that. <pecg>Hello. So far I've been 'playing' around with guix, and I certainly love it. <pecg>Although I'm still far from building the whole system together, I want to know if: guix-daemon --no-substitutes is set permanently <pecg>I'm willing to wait the time it takes the system to compile all the packages. <davexunit>pecg: each client can choose whether or not to use substitutes <davexunit>to make sure no substitutes are used, de-authorize hydra <pecg>davexunit: And that's by removing the hydra.gnu.org pub key from the ACL, right? <pecg>Guix is growing strong on me. All of its features seem like obvious needs for package management programs, I still wonder why functional methods for package management didn't happen earlier. <pecg>We should give Eelco Dostra some kind of award for this advancement in free software, and in computer software innovation, or something <pecg>I know prizes are not the goal for some people. <lfam>There are many people who deserve a beverage :) <pecg>The work done with Nix and Guix is going to same countless of hours of fail attempts on trying to reproduce complete operating system environments <pecg>Althought, I've learnt a lot in the process. <lfam>I think that one reason it did not happen sooner is that other package management projects, like dpkg or yum, are part of huge community projects. And as any communities grow, they "ossify" and become rigid as a way of handling complexity. I think this is unavoidable. So, there is a huge burst of innovation at the beginning, and then it soon becomes almost impossible to change things in a serious way. <pecg>lfam: That could happen to guixsd and nixos also <lfam>I picture the growth of a coral reef. At the beginning, anything is possible. But as the reef grows, it turns rigid and the landscape is more or less permanent. <pecg>Although not necessarily bad <pecg>Eelco's work is a big mind changing thing <lfam>pecg: Indeed. It's one reason I resisted a feature suggestion that I saw as overly bureaucratic a few months ago (allowing people to put their names on packages as maintainers) <lfam>The longer we can resist the creation of bureaucratic structures, the better. <davexunit>lfam: now, I wonder, could Guix grow and still be able to change better than the others? <pecg>I think that for those big changes to happen, one would have to build things from scratch, almost completely <pecg>davexunit: That will depend on what new ideas the community can come up with <calher>linux panicked when i did guix system vm <lfam>davexunit: Who knows? So far, the project is organized very loosely, and, from my beginner's perspective, I think that is very valuable. <davexunit>if we can last as long as Emacs, that will be great. <calher>yeah lfam . everything froze and i had to hard-poweroff <lfam>What is the host system? <lfam>What operating system are you using? <lfam>Well, that's not a good result! <a_e>Do other people also often get <a_e>ssl_error_unsafe_negotiation <davexunit>our icecat is awfully strict about ssl. I had to use a different browser (epiphany) to register to vote last night. <a_e>I suppose this is due to a security update :-) <lfam>calher: I think that's worth a bug report. I'd include any output from `guix system vm` that you can include, and the system configuration you gave to `guix system vm`. <calher>ACTION is happy guile-wm has an info manual <davexunit>calher: not in quite some time. I have a few small patches in the code base. <a_e>So I end up using iceweasel all the time. Together with https-everywhere it becomes annoying. <calher>lfam: is there a record somewhere? do i just email it? <NiAsterisk>why does `guix environment --ad-hoc --container --pure guix git guile make gcc-toolchain sed autobuild perl m4 gettext texinfo graphviz help2man automake` not want to run make clean in the git checkout? <lfam>calher: I'm not sure. Normally I'd scrape it from the terminal emulator but if the system froze and you had to hard reboot, of course that is lost. <lfam>NiAsterisk: What happens when you try it? <calher>davexunit: i tried to run it after reading the manual. I guess Guix put a sample config in ~, but it doesn't work when I put `exec guile-wm -i $HOME/.guile-wm' in my ~/.xsession and log in. <calher>lfam: Why does all the important stuff show up where you can't save it? <calher>I need a digital camera or something to take screenshots. <lfam>calher: It's hard to do much useful stuff when the system freezes :) <pecg>What's really exciting about guix is that it uses scheme, considering nix own syntax that's a big improvement, and gives the hacker a whole new world with endless possibilities and programming <lfam>calher: If you can reproduce it against a specific version of Guix by using `./pre-inst-env guix system vm`, that would make it easier. <davexunit>NiAsterisk: --pure is redundant when using --container <pecg>calher: guile-wm needs some maintainance, or a rewrite, maybe? <NiAsterisk>I need to paste... which is not working so good. <calher>I don't like StumpWM and Sawfish because I don't want a foreign Lisp on my system. <pecg>calher: But you can learn, if you want to <mark_weaver>davexunit: regarding icecat ssl strictness, are you running icecat since guix commit 08cb746f08c679a95047f1ee0d1fb70915b10f96 ? <pecg>calher: programming with scheme is easier <mark_weaver>basically, upstream icecat disabled some important cipher suites <davexunit>mark_weaver: no, I haven't updated icecat in a bit because it wasn't built on hydra. <mark_weaver>to work around the Logjam attack, but NSS was fixed for that over 8 months ago, so... <calher>pecg: I guess there's more motivation to learn Scheme, since my OS is written in it. <davexunit>mark_weaver: ah, so the problem will be gone, eh? awesome :) <pecg>calher: I used to use StumpWM, but it was too slow for my tastes, then I switch to bspwm, and promised to use guile-wm when I had the time to contribute <mark_weaver>davexunit: the quick fix is to go into about:config and enable security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha <pecg>calher: I also prefered scheme over Common Lisp, since it is more elegant <calher>But they intentionally fragment Scheme so you have to stay on one implementation. <mark_weaver>davexunit: I'd be curious to hear whether it fixes the problem you had. <davexunit>calher: it's best to view Scheme as a family of closely related languages, not as a single language. <calher>I don't speak of "the Scheme language". I speak of "the Guile language". This is why I'm not on Scheme, because Scheme just isn't a real programming language. <pecg>calher: Most of the implementations have mostly the same features. <pecg>calher: how dare you? That's it. <calher>pecg: Good luck saying "I wrote a Scheme program; run it in your Scheme interpreter." <calher>I don't know why people don't say "forget efficiency!" and write everything in R6RS only. <pecg>calher: That's because every implementation has its own features. Guile was written for a lisp-ish way to extend GNU <pecg>calher: I'm still waiting for a direct compiler for guile, that will make a more powerful implementation <calher>When people write programs, they should be copatible rather than using stupid extras. <a_e>mark_weaver: I still have the connection problem with the latest icecat in master. <a_e>With gnupg, it was a question of "not matching ciphersuites". <pecg>calher: But in the end that's a developer choice <a_e>I often get "unsafe ssl negotiation". <mark_weaver>upstream icecat changes a bunch of the default crypto settings to be more strict <davexunit>NiAsterisk: why not use 'guix environment guix' ? <mark_weaver>I can't test now, because I won't use icecat with a buggy graphite2 <NiAsterisk>and test in an environment not as changed as mine <a_e>It happens quite often with different sites. <davexunit>NiAsterisk: okay, well just add autoconf to what you have there. <a_e>mark_weaver: So do you think that the new graphite2 version fixes the bugs? <NiAsterisk>why does `guix environment --ad-hoc --container --pure guix git guile make gcc-toolchain sed autobuild perl m4 gettext texinfo graphviz help2man automake` not want to run make clean in the git checkout? <-- <pecg>calher: Compiles R5RS to x86_64 assembler <mark_weaver>a_e: dunno. I'm skeptical but someone at Debian seems to think so, so I guess I need to look deeper. <calher>What's the command to start xfce? <a_e>Well, it definitely cannot hurt to update. <NiAsterisk>this is not really very forward playing the guessing game with apllications needed. idk.. I have some values in my .bashrc, but none which should prevent or alter software building. <calher>Does Guix index and manage ELPA Emacs packages? <davexunit>mark_weaver: I actually get the same error on the new icecat. maybe mass.gov really just needs to fix their TLS setup. <calher>Trying to put pastebin support into my Emacs. <davexunit>calher: we have an emacs build system and an importer for elisp packages <calher>meh i'll just use the separate emacs package manager <mark_weaver>davexunit: did you check those settings in about:config? <mark_weaver>Here are two other settings that icecat turns on: security.ssl.require_safe_negotiation, security.ssl.treat_unsafe_negotiation_as_broken <dannym>calher: startxfce4. You can also just choose it at the login window. <dannym>calher: (If X is already running, xfce4-session) <civodul>ACTION .oO we need more reviewers! :-) <lfam>civodul: I'm trying! At my level of ability anyways... <rekado>it's all been a little too much for me lately. ***ringst_ is now known as ringst
***bmpvieira_ is now known as bmpvieira
<NiAsterisk>and how would I deal with this in guix environment guix --container --network 'long list with packages' ... with this error when I ran make; ./bootstrap; ./configure --localstatedir=/var .... guix build: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory <NiAsterisk>guix is so much more to re-learn than I expected <NiAsterisk>and not found as a command, but it was included in the list of applications <rekado>I only just tuned in, so I don't know what you're trying to achieve <NiAsterisk>because I need to isolate it from what I have, to be sure of what I do <lfam>NiAsterisk: the daemon is usually allow in root's environment <NiAsterisk>what would I pass to container if I want/need guix as a daemon? more than just guix I guess.. <rekado>NiAsterisk: if you just want to test a package in isolation then "guix environment --container --ad-hoc the-package -- the-command" is sufficient <rekado>using "guix environment guix" for testing *other* packages seems wrong. <lfam>Yes, `guix environment $1` is only for getting the environment to build $1 <NiAsterisk>hm. is it? why? maybe I have some wrong expectations / ways to do things I assumed would be like this.. I did all the testing of packages so far in guix environment guix as I needed something interactive. I thought container would work as well.. <rekado>"guix environment guix" gives you a shell session in which all the packages for hacking on guix are available. <rekado>that doesn't help you when you want to test lispf4, for example <lfam>For lispf4, you'd do `guix environment lispf4` <rekado>to get an isolated environment containing only lispf4 you would do: guix environment --pure lispf4 <rekado>and then "exit" or ^D when you're done. <rekado>instead of --pure you can use --container for even stricter isolation. <lfam>It took me a while to grok. `guix environment foo` puts you in a shell where you have everything you need to build foo. If you do `--ad-hoc foo`, then you have foo itself and can run it. <lfam>I often use `guix environment --ad-hoc foo` when I just need to use foo once and don't care if it gets garbage collected later. <lfam>I did what you are doing for a little while, too <rekado>erm, sorry, I forgot to add "--ad-hoc" above. <NiAsterisk>I did *all* the testing inside guix environment guix <lfam>You only need to do that when you are building Guix itself <lfam>If you want to to try to build something else interactively (that is, not by calling `guix build foo` but rather by calling `make`), you would then use `guix environment foo`, because it would make sure you have the dependencies, environment variables, etc <NiAsterisk>ACTION thinks the documentation really needs a beginners "my first package" section <lfam>NiAsterisk: It's not a bad idea. A tutorial from picking a package to working with reviewers on the ML. <NiAsterisk>hm. okay... not a day without learning something new. I like guix <lfam>Does it make sense? Feel free to ask questions. <NiAsterisk>lfam: sort of.. I make notes and try to process them tomorrow, the last days weren't good to me with stress from my health insurance.. I intend to do such a thing, "guix packaging for starters" or something at Labor Tage 2016, a small annual convention at a hackerspace here. some hundred people coming, idk.. somebody on their list seems to know ludo from way back, I started talking about guix and the person <NiAsterisk>mentioned nix and how he still doesn't get the difference and motivation of guix <lfam>health insurance: It really sucks that as a species this is still a problem for people. I feel it all the time here in the USA. <lfam>We have the resources to provide health care for everyone and we don't do it. I hope your problem gets resolved. <NiAsterisk>I feel it in germany.. system sucks everywhere, people as products. <lfam>That's too bad. I always thought Germany would do it much better than us. <lfam>It can't be worse than our system from 3 years ago. <NiAsterisk>some aspects are better.. but in general I would pick iceland if I have to leave. <lfam>Heh, maybe I'll see you there someday <paroneayea>time to figure out how to get postgres working on guix... <lfam>paroneayea: We fixed a bug in the postgres service only a couple hours ago! <NiAsterisk>I try to compare countries by things which suck... and germany is getting to the point where the things which suck possibly canÄt be changed anymore and might get lifethreating from one day to the next for all kinds of people.. iceland is the rational best at the moment. other things suck, but they don't suck as much as they do here. I wouldn't feel safe in the USA for example. <civodul>lfam: i agree with rekado, your help on reviews is appreciated! <paroneayea>. o O (also time to figure out how to write out a postgres config file that does mostly what I want...) <lfam>NiAsterisk: I think feelings of safety are relative. My city is famous for violent crime and yet I feel safe. Of course we should improve it. <NiAsterisk>thanks for all the welcoming help so far, it's really amazing how much I have to understand and how patient and friendly the community is. I experienced others in the past which weren't. really a positive note for Guix :) <lfam>NiAsterisk: I agree. It made a huge difference to me getting started here. <NiAsterisk>lfam: I feel safe living in the street with most drug dealers, unorganized smalltown crime and much more here.. the way 'germans' (in average) "handle" situations like we have currently (again) in this country is nothing you will probably ever fix. I spend some years trying to figure out why, and I have no ultimate answer, but I could fill a rather long speech with rants on the political unorganized left, <NiAsterisk>anarchism in germany historicaly and now, and different subtopics. my safety is politically and to other often so-called minority groups I belong. if I can choose safety over unproductive trying to change a deeply rooted authority obedience, and there's a country where politics are relative okay and they treat people mostly like people, the decision is easy. <paroneayea>NiAsterisk: I'm glad you've found the community so welcoming, and I agree <NiAsterisk>it's sad that this has to be stressed though, that other projects have these issues. <paroneayea>wingo: I wonder if some of this can be generalized so that other packages can do some stuff like it <paroneayea>eg, the <configuration-field> stuff seems nice, and like something a lot of services might be able to be used <NiAsterisk>okay, I do have a question. using guix environment guix is only for building guix itself. this would imply for me, that this is the way to do the [make clean-recursive; ./configure --localstatedir=/var; make] thing in. or maybe it isn't. it's not really very clear but I can't point right now where in the docs it isn't clear. <NiAsterisk>I'm half understanding and half trying to wrap my mind around this new concept. <mark_weaver>NiAsterisk: "guix environment guix" provides everything you need to build either a guix tarball release or the sources from git <mark_weaver>GuixSD is just the name of the complete system that Guix can build. there's no separate repo for GuixSD <NiAsterisk>thanks! I almost feel like this is because I get so much input and read so much that obvious things become not so obvious anymore. <mark_weaver>yeah, it takes some time to learn your way around Guix and GuixSD <NiAsterisk>it's not worse than Gentoo :) when I just installed guixsd, I did not spend 3 days trying to install an encrypted system with initramfs and make sure everything works before rebooting :D <paroneayea>so, the right way to declare config files for ostgres <mark_weaver>paroneayea: I don't think that's the right approach. the config file should be passed to the postgresql service as an argument. <paroneayea>I was looking at daatabase.scm and was guessing that I could only pass in a path <paroneayea>mark_weaver: yeah, I'm not trying to figure out how to write it, but how to work with it <mark_weaver>paroneayea: see the 'config-file' field of the <postgresql-configuration> record in gnu/services/databases.scm <mark_weaver>paroneayea: well, more to the point, note the #:config-file keyword argument accepted by 'postgresql-service' at the bottom of that file <mark_weaver>paroneayea: I guess you could use local-file, plain-file, computed-file, etc <paroneayea>I am yak-shaving down guix service land instead of fixing mediagoblin bugs! but hopefully that'll pay off :) <mark_weaver>paroneayea: something like (postgresql-service #:config-file (plain-file "postgresql-config" "<contents>")) I guess <mark_weaver>to make it a bit nicer, you might put (define postgresql-config (plain-file "postgresql-config" "<contents>")) earlier in the OS config file and then refer to that variable in the service call <paroneayea>so if I install this, and I do "guix system reconfigure", I can probably loaad through shepherd the newly defined service without a reboot... right?