<jjmarin>mark_weaver: great ! thanks for people who work on this ! :-) gnome 3 is my favorite environment <lfam>Unfortunately, I've never used GNOME so I'm not sure how much I can help beyond testing patches <NiAsterisk>I can't explain the technical background of guix that much, but maybe I want to do a short talk on getting started with guix packaging at a local hacker space when I have enough notes <mark_weaver>rekado: I gave up on trying to keep up on the ML a while ago. now I just skim <lfam>rekado: I saw that you said your workplace was switching to another packaging system? Did I understand that correctly? <lfam>My feeling about the ML is that if a message is more than a week old, it's stale and the sender should re-send if they care. <lfam>You have to advocate for your patches and bugs :) <NiAsterisk>is there a limit on mailinglists on gnu.org for a project? Could something be done to reduce the noise so that people don't have to skip through ~150 emails in 18 hours? <mark_weaver>jjmarin: GNOME 3 is also my preferred environment. I've lived with Xfce for quite a long time now because running Guix was more important to me. <lfam>I don't think the volume is 150 per 18 hours. <lfam>Oh, well I don't read guix-commits unless I need to <NiAsterisk>around 100 I counted coming in @gnu related to guix <jjmarin>NiAsterisk: maybe some of those videos can help you <jjmarin>mark_weaver: do you know if there is some for for making a guix backend for packagekit ? <NiAsterisk>jjmarin: if it's guix related talks, I've been there on saturday, and found the talks cweeber gave very good for short ones <davexunit>jjmarin: packagekit makes assumptions that don't work with guix <davexunit>so someone would have to heavily modify packagekit to make it work <davexunit>would be better for us to write our own gtk package application in pure guile. <mark_weaver>jjmarin: hmm, I don't know. I don't know much about packagekit. it might be that it's not flexible enough to handle the Guix model. <mark_weaver>for one thing, packagekit presumably assumes that all packages are system-wide, whereas in Guix packages are installed per-user. <davexunit>there's a packagekit issue about this somewhere... <jjmarin>davexunit: Do you know if there is any bug report or text where those assumptions are explained ? <jjmarin>the gnome people are working on xdg-apps, and xdg-apps also have the user and system installations <paroneayea>making the last adjustment related to the assword feedback. <paroneayea>there's still a bit of guilt that I never figured out *why* when I "git package -i assword", it doesn't run due to not importing gtk, and then I log out and log in again, and it works <mark_weaver>ah yes, I noticed the zero? thing. probably we should make a variant of 'system*' that raises an exception if the result code is non-zero. <paroneayea>it's also why I disabled the tests, the tests can't find how to import gt <paroneayea>pygtk seems pretty goofy in how it does import stuff. <mark_weaver>paroneayea: it's probably about environment variable settings <mark_weaver>when you log in, environment variables are automatically set for the set of packages you have installed at login time. <mark_weaver>but there's no way to modify the environment variables for most of your running processes. <paroneayea>I like that ludo said "environment variables are one of the hard problems in computer science" in one of his talks <mark_weaver>yeah, I have a love-hate relationship with things like environment variables and fluid variables / parameters in scheme. <pizzaiolo>mark_weaver: have you tried gnome shell yet in guixSD? <mark_weaver>they are deeply problematic, and yet for many things I don't know of any other solutions that aren't painful. <mark_weaver>pizzaiolo: I guess you missed my messages about this topic from a few minutes ago? <pizzaiolo>mark_weaver: I saw you saying that you use xfce despite enjoying gnome <pizzaiolo>I tried changing the icons to numix circle but that didn't work for some reason <calher>pizzaiolo: the only complete thing guixsd has is xfce right now <calher>but there's many window managers like openbox i3 etc <calher>pizzaiolo: idk how to make xfce not look like crap, but i have changed some themes <calher>i can't make anything that looks good <calher>pizzaiolo: i was trying to go for something classic, like Bluecurve <mordocai>In my standard environment (so not in a guix enviroment shell) I get http://lpaste.net/151818 when trying to install wine package with --no-substitutes. I have both guile and gnutls installed in my profile. Anyone know the fix? <calher>pizzaiolo: can't get gtk widgets to stoplooking like win95 <calher>also im trying to get tor to work so i can get on irc with tor <mordocai>How can I replace a locally build package with a hydra substitute for testing? I think sbcl is non-deterministic <mordocai>Well, build --check says it is but I think its behavior is as well <teythoon>how can i ask guix-daemon to use a different directory for the build than /tmp ? <teythoon>(i'm using it w/o isolation afaik, because currently that is not uspported on the Hurd) <teythoon>uh, it seems to be hardcoded in libstore... <janneke>teythoon: does the hurd have something like bind mounts? <teythoon>aiui the problem is that we don't provide a mount-like function, so the syscall module does not work <pizzaiolo>I hope manolis also makes hurd compatible with libreboot :) <teythoon>libre/coreboot already boots into grub, which is the preferred way to boot the hurd <teythoon>well, we require a multiboot-compliant bootloader <pizzaiolo>teythoon: I don't think the two are compatible <calher>If we call it GNU/Hurd, people are going to start calling it "the Hurd operating system" or "operating systems like Hurd". <pizzaiolo>teythoon: because no one knows if they work together <pizzaiolo>a friend of mine tried, and couldn't get it to boot <calher>It's a shame that the GNU project did a "Not Invented Here" thing and didn't quickly adopt Linux. <lfam>I'd say Linux quickly adopted GNU ;) <teythoon>calher: Linux was outdated the day it was conceived <teythoon>anyhow, i certanly didn't come here to talk about that... <mordocai>Is there a way to do guix pull with no-substitutes set? <mark_weaver>mordocai: guix pull doesn't use substitutes. it builds guix locally. <mark_weaver>oh, well, that's not necessarily true I guess. it needs to the compiler to build guix. <mark_weaver>mordocai: guix environment guix --no-substitutes should build what you need <mark_weaver>and then exit that spawned shell and run guix pull again <mark_weaver>fwiw, I'm told that the hardware that hydra runs on will be upgraded in the next two weeks or so. <mordocai>Yeah, i'm going to be setting up my own substitute server that builds things on my desktop soonish so then I shouldn't have to worry about it ***Sornaenst is now known as THE_LORD
***THE_LORD is now known as Sornaensis
<calher>pizzaiolo: I have a 32-bit machine but I need to fix it. <nextos2>hi, i've seen nftables is not packaged yet. Any particular reason? <calher>How do I run a random Python script if #!/bin/python does not work? <mordocai>At least that's what I do with ruby to make it work with rbenv <CompanionCube>ACTION is going to try out the shepherd as a userspace init thing <calher>mark_weaver: How does one do ./foo.py ? <mordocai>So if i'm sitting at a guix 0.9.0 binary release, I git pull, guix package -i sbcl (with substitutes), how can I then force guix to build sbcl? guix build sbcl doesn't work and guix build sbcl --check apparently doesn't exist. <calher>davexunit: I heard /usr/bin/env was also a hack, anyway <pizzaiolo>davexunit: is there a standard way to deal with programs that pressupose /usr/ ? <davexunit>we really need to add something to our manual about this because it's becoming tiresome to rehash this stuff over and over. <mordocai>davexunit: Idk, i'm going off of memory. I was using env somehow <calher>maybe shebangs in general are outdated and should be scratched? <janneke>davexunit: i heard mark_weaver say that too <davexunit>pizzaiolo: our build systems automatically patch shebangs to refer to the absolute path to the relevant binaries in the store. <mordocai>I take it no one knows how to force a build locally when a substitute is already downloaded? This seems like something that should be a core feature. <davexunit>pizzaiolo: guix compiles everything from sourc.e <pizzaiolo>really? I thought it fetched binaries from the server <davexunit>when using substitutes, those binaries were built elsewhere from source. <davexunit>the gnu-build-system has 2 phases of shebang patching <mordocai>davexunit: So I believe sbcl's behavior is currently different based on whether I use the hydra substitute or build locally. I have a machine with the substitute and have observed the behavior, what is my easiest path to building sbcl locally so that I can verify behavior? I don't want to change the build script at all. <mordocai>So far all the commands i've used to attempt to rebuild sbcl just don't do anything due to the substitute already being used. <davexunit>mordocai: you can't rebuild sbcl because the derivation is already built. <davexunit>if nothing is referring to it, you can garbage collect it. <davexunit>and then rebuild locally via 'guix build --no-substitutes' <davexunit>but you could force a rebuild by simply changing the name to 'sbcl-mordocai' or something <davexunit>because changing the name of a package changes its hash <calher>Also, I can't run the Tor Browser Bundle from the extracted archive. <mordocai>davexunit: Well i'm already doing the other. I might do the name change next time instead. <davexunit>mordocai: but I don't believe that what you see is correct. <mordocai>davexunit: It shouldn't be, but that doesn't mean something isn't broken <davexunit>*unless* sbcl's build is nondeterministic in such a way that the machine that built it really does something wrong. <mordocai>When I ran guix build sbcl --check on my desktop it got a different hash <davexunit>but that doesn't mean that what you see is because of this <mordocai>You can find it highly unlikely all you want, i'm getting proof one way or another instead of just talking about it :P <davexunit>but my hypothesis remains that your problem lies elsewhere. <mordocai>Yep, it'd be better if it turns out that the problem is elsewhere because it'll probably be less hard to solve <davexunit>but this will probably prove to be good work towards having nice support for common lisp. <mordocai>Yeah, after I get my sbcl woes figured out i'm moving on to ccl then stumpwm <davexunit>we need a build system for common lisp stuff <mordocai>Yeah, I figure stumpwm will take lots of discussion/work since that'll mean figuring out how to package common lisp libs <davexunit>I'm looking forward to having dto's games available. <davexunit>without me having to manually do a bunch of CL wizardry. <mordocai>Yeah, I love the CL wizardry when I'm doing development in the repl but not when I just want an application <CompanionCube>ACTION will have to try GuixSD when he can install it on btrfs <davexunit>mordocai: once there is a cl build system, we can write the quicklisp importer :) ***wilo_ is now known as wilo
<paroneayea>./devtools/update_extlib.sh: ./node_modules/.bin/bower: /usr/bin/env: bad interpreter: No such file or directory <paroneayea>yeah shoulda guessed that might happen I suppose. <paroneayea>I also feel guilty for mediagoblin's complicitness in the super sorry state of affairs of web application packaging <paroneayea>though honestly, if we hadn't adopted bower, which I did under general pressure <mordocai>Now everyone is moving back to pure npm. Not that npm is that much better <davexunit>paroneayea: it's hard to fight it, because mediagoblin would look like a stick in the mud to some. <paroneayea>davexunit: I'm determined to dig us out of the mud though <mordocai>I could install curl with substitute to get around it if necessary, but i'd rather build it myself <mordocai>Meh, i'll just use the substitute for now <davexunit>the guile bindings for gnutls, specifically. <mordocai>davexunit: Right, but shouldn't guix be doing that for me? <davexunit>the guix you are using *right now* needs gnutls <davexunit>it seems that you did not install guix using the standard method <davexunit>okay, so then your environment variables must not be correct. <mordocai>Very possible. Do you know which ones would affect that? <davexunit>well, "ERROR: missing interface for module (gnutls)" makes it seem like linking against the gnutls shared lib didn't work <davexunit>but our gnutls package hardcodes the absolute path to that library <iyzsong>mordocai: look your guix (eg: less $(which guix), does gnutls in the GUILE_LOAD_PATH? <davexunit>iyzsong: it seems like the gnutls scheme module is there. <mordocai>davexunit: Yeah, its in there and the directory it points to exists <iyzsong>then, I have no idea what's wrong :o <davexunit>mordocai: can you see if that module has a string that refers to the gnutls shared library? <iyzsong>yes, make sure guix use the guile in store, and gnutls.scm work with guile. try run the guile with GUILE_LOAD_PATH (as in the guix script), and ",use (gnutls)" in the REPL. <davexunit>yeah, there's a few impurities to check for when running on a foreign distro <marusich>Does the system installation of guix have a repo somewhere? On GuixSD. I just ran "find / -type d -name '.git'" to see if I could find it, but I found nothing. <marusich>I had assumed there was a git repo that gets updated when you do guix pull, but perhaps I'm mistaken. <davexunit>for one thing, the .git directory is non-deterministic. cloning it at 2 different points in time can yield different .git directories. <marusich>Hm. Hypothetically, if I wanted to pin my installation to a particular git commit (i.e., guix version), how would I do that? I don't want to; I'm just curious. <marusich>A related question: can you roll back a guix pull? <calher>How do I boot the Tor Browser Bundle? <mordocai>Verified I have the same problem on my other machine but considering I set them up almost identically that isn't really a suprise <iyzsong>mordocai: oh, that's because the url redirection of the 'curl' source, when it's 'http' in the recipe, gnutls won't be used, then it was redirected to 'https'.. <mark_weaver>marusich: "guix pull" cannot be rolled back. if you need that, run guix from a git checkout instead <mark_weaver>I find that running guix from a git checkout is by far a superior approach, but many people seem to dislike it for reasons I don't understand. <mark_weaver>mordocai: the problem you're having with (gnutls) is because the source URI is an 'http' URI, so Guix does not include gnutls in the build environment where the download occurs. but in this case, the site redirects you to an 'https' URI, and then gnutls is not available. <mark_weaver>mordocai: the fix is to change the source URI in the guix code to use https <mark_weaver>mordocai: I guess they started redirecting to https since we last updated that recipe. <iyzsong>yeah, I push the fix. mordocai, thanks! <mordocai>mark_weaver: cool, how do you have the guix from git checkout setup? I'd like to do that as well <mordocai>preferably for root and my normal user both <mark_weaver>mordocai: clone the guix repo, build it, make sure it works by building a package with "./pre-inst-env guix build netcat" or something like that, and then make both ~/.config/guix/latest and ~root/.config/guix/latest symlinks pointing to the top-level directory of the git checkout. <mark_weaver>mordocai: see the "Building from Git" section of the Guix manual. One important note: pass --localstatedir=/var to Guix's configure, to match the localstatedir of your existing Guix installation. <mark_weaver>(we use --localstatedir=/var for our binary installer and GuixSD) <mark_weaver>mordocai: no need to run the right daemon. an old daemon will work with a new guix client. <mark_weaver>but if you want to run the daemon from the git checkout, just run /path/to/git-checkout/pre-inst-env guix-daemon ... <mordocai>Yeah, apparently the build --check feature is only in the git checkout's daemon for instance <marusich>mark_weaver, what if you're running guix from a git checkout like you're talking about, but then you run guix pull from the checkout? ;) <mark_weaver>marusich: "guix pull" will overwrite that symlink, so then you won't be using the git checkout anymore. <mark_weaver>unless you explicitly prefix the commands with 'pre-inst-env'. <mark_weaver>to be honest, I've always thought that "guix pull" was an inferior method. IMO, it's only purpose is to lower the barrier of entry for people who don't want to deal with building from git. <mark_weaver>(and the only person who has more commits in Guix is Ludovic) <marusich>At a high level, what does guix pull do? The manual doesn't specify. I know I could dig into the source, but if you can explain it in 20 seconds, I'd be much obliged. <marusich>I had assumed it managed some git repo somewhere, but I was told that is not the case a few minutes ago. <mark_weaver>marusich: it downloads the latest guix sources from git (master branch), builds it, and then makes ~/.config/guix/latest a symlink pointing to it (in /gnu/store) <mark_weaver>actually, it doesn't use git to download, though. it downloads a tarball snapshot of the git repo that is automatically generated by savannah. <mark_weaver>at least that's what it does by default. you can specify an alternate URL. <marusich>when you say "build it" is that "build" like it would for any other package? <marusich>but conceptually it sounds like it just grabs a snapshot and updates a symlink <marusich>interesting that it is not modeled as its own package and upgraded with guix package <marusich>i guess that might have crazy dependency implications. <mark_weaver>it builds from scratch every time, though. whereas "git pull && make" is much more efficnet because it only recompiles the files that changed. <mark_weaver>(although very occasionally, "make" is not sufficient and "make clean-go && make" is needed) <mark_weaver>however, note that the 'guix' package within 'guix' is not the latest from the master branch. we need to update that package specifically, and only do so occasionally. <mark_weaver>so "guix pull" doesn't do the same thing as "guix build guix" <marusich>also omg i was finally able to send email from emacs. <marusich>Had to configure Gmail to allow connections from "less secure devices", tell emacs to use SSL, and spent hours trying to figure out why I was getting "no route to host" only to discover that my home network does not play well with IPv6. <mark_weaver>for example, right now our "guix" package is fixed at commit c3f29bc928d5900971f65965feaae59e1272a3f7 and will continue to be until we explicitly update it, like any other package. <mark_weaver>(see the 'guix-devel' binding in gnu/packages/package-management.scm) <mark_weaver>marusich: ah, I didn't know that emacs was behind the times in terms of TLS support. our openssl, gnutls, and nss libraries are cutting edge though. <marusich>it might be that emamcs uses tls by default, but I wanted to make absolutely sure before letting it send my credentials over the wire. You can force it to use TLS. It seems to use IPv6 for connections by default on GuixSD though, so I was surprised <marusich>I couldn't figure out for the life of me why netcat could connect just fine to smtp.gmail.com on port 465, but emacs could not. I didn't realize what was going on until I used tcpdump to get a packet capture. <marusich>But anyway. Now it's working, so that's good. I'll have to hunt down the devices on my network that don't like ipv6 and fix or r eplace them. <mark_weaver>my home network also have problems with IPv6. my ISP has IPv6 support, but its broken. <mark_weaver>I work around it for now by doing "sysctl -w net.ipv6.conf.all.disable_ipv6=1" but that's probably not the best approach. <marusich>So yeah, I think one of the reasons why I was having such a hard time w/email and emacs is because even if I had figured out (for the first time ever) how to set things up correctly, I still would have had to get IPv6 working and know to go tell Google to allow connections from "less secure" devices...so much stuff to configure! <mark_weaver>(and some packages fail to build from source while that's set, because their tests assume IPv6 support is available) <marusich>Ah. That would probably work, yeah. I hope I don't have to do that. I'll bet only a few devices in my network are misbehaving. I'm connected directly to my router now, and it works, so it must be something inbetween. <marusich>Anyways, gonna go mess with that. My battery is dying. See you later! <mark_weaver>if I reboot the router that my ISP mandates that I use, it works for a while, and then stops working at some point. <mordocai>It looks like kernel.org is also redirecting to https. <mordocai>Saw the error message fly by, but since there were backup places to get the download it worked anyway <phant0mas>mark_weaver: your patch needed some rebasing but it seems to work <phant0mas>and I have one question about the daemon, can I configure it to use /var/tmp instead of /tmp? <efraim>I believe for reproducibility it's currently hardcoded for /tmp <phant0mas>efraim: I know but this can be a nightmare if your tmp dir is a ramdisk on the Hurd:P <efraim>you could revert the change locally I guess <mark_weaver>I don't remember why it wasn't used. I think that Ludovic might have objected to this entire approach, but I don't remember clearly. <mark_weaver>phant0mas: if you set TMPDIR in the environment of the 'guix-daemon' process, it will do the builds there. <mark_weaver>however, at least on Linux, from within the build container, it always appears to be /tmp, for reproducibility. <phant0mas>mark_weaver: I will find the old mails and see why he did <calher>#bash recommends #!/usr/bin/env bash <yitz_>I'm trying to wrap my head around this, still <mordocai>calher: Not all of GNU cares about reproducibility <mordocai>FSF is a social cause not a technical one, after all <calher>mordocai: what does reproducibility have to do with no #!/usr/bin/env in Guix but yes #!/usr/bin/env in Bash <yitz_>I think you're confusing a shell and a file system layout <yitz_>What's the file system layout policy thingy called again? <mordocai>Who says that /usr/bin/env will be there? For complete reproducibility you should rely on nothing that is not under your control, and guix on a non-GuixSD system can't necessarily control whether or not env is in /usr/bin/ <mordocai>At least that's my opinion, but i've been using guix for two days so take it at face value <yitz_>bash doesn't determine/chose/pick where the env binary lives ... or where anything on the filesystem lives. <cehteh>Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH , ensuring that the returned pathname is an absolute pathname and not a shell built-in. <cehteh>.. not even /bin/sh is defined in posix <yitz_>What's your shell shebangs look like, cehteh? <cehteh>have no guix running yet :/ ... well installed somewhere but currently not used <yitz_>I'm not sure how you get around having a hard coded path in the shebang <cehteh>but i think it would be really nice to have some facility to ease this #!guix-env .... or something like that <yitz_>Actually, I'm not sure if you even need a full path <yitz_>cehteh: that'd be super compatible across systems <cehteh>relative paths are a bit prone to some errors and attacks, thats a bit problematic <cehteh>we had a discussion about that here some time ago <yitz_>They are, but you're already depending on the user having their PATH set up to be safe for them to run anything <yitz_>If someone can alter a user's PATH, things are already screwed before the shebang comes into play <yitz_>Right. And if the user wants to alter their own PATH, that's fine. Where's the issue there? <cehteh>but security is not about trusting only one defence line <cehteh>ideally it would be nice .. but some bad program/social engineering/whatever may trick the user in doing what he didnt want to do <yitz_>At which point we'd want the shebang to be safe via an absolute path. Fair enough. <cehteh>i really dont see a perfect solution <cehteh>i was thinking if its possible to build an user env with namespaces which is fhs conforming <cehteh>but i dont think people agree there <cehteh>otherwise a toplevel /guix may do the trick <cehteh>guix goes its own way, diverting from old standard ways to do/expect some things <cehteh>thats sometimes a bit uncomfotable, sometimes not completely solved. but time will show <yitz_>The whole idea of a GNU distro is still weird sounding to me <calher>yitz_: Why can't GNU distribute its own system? <calher>yitz_: GNU has been working for many years, trying to release a system. <Jookia>GNU distributing its own system is a weird idea <mordocai>I'm with calher as far as thinking that it is weird that people think it is weird <yitz_>GNU's always seemed like a standard toolset used widely across many systems. The idea of them having their own labeled system just feels weird to me <mordocai>The point of GNU from the beginning was to write a completely free system though. <mordocai>From a historical background it makes perfect sense <Jookia>And we have completely free systems now <Jookia>Yes, but what's the point of a completely GNU one <mordocai>That seems like a strange question to me. What's the point of anything? <Jookia>If you start writing a free system as there's no other free systems around and people start making tools that work with it that are also free, why not use those <Jookia>What could be gained besides having the name 'GNU' on it <yitz_>Yeah. If that was the goal all along, then everything done would fit nicely with that goal. I never viewed GNU through the perspective of that goal. <Jookia>If you look at most GNU tools, there are things that seem like duplicates when compared to other tools (Linux/Hurd) but actually further GNU ideas <yitz_>Don't we already have completely free distros, though? Is there value to having yet one more? <Jookia>What's GNU going to do to innovate on say, Ardour <Jookia>There's always value for having more distros <mordocai>Meh, I find your whole argument silly and unconvincing personally. Why does it have to have a purpose? It's a cool new system with cool new ideas and happens to make it possible to have a completely GNU system. <yitz_>I didn't say it shouldn't exist or that it's a bad idea. I just said I found it weird <rekado>"GNU's always seemed like a standard toolset" <-- that's a common misconception. <rekado>GNU is more than just GCC + bash + coreutils. <rekado>as far as free distributions go, I found the choice to be rather limited. <rekado>see how many of them are "based on $distro". <rekado>Guix enables "practical software freedom", as it lowers the barrier of entry to distro hacking. <rekado>it is trivial to get the sources of a programme you want to patch, and then install a patched version. <rekado>that's very much in the spirit of GNU. <rekado>same goes for making root less important, which is also a very GNU idea. <phant0mas>currently I am helping Justus to set it up and running on his box <pizzaiolo>phant0mas: I was thinking of testing hurd + libreboot today <phant0mas>currently only the package manager run on top of hurd <phant0mas>pizzaiolo: when the time comes we will look into it as well <phant0mas>but for now we have other problems to look into :P <pizzaiolo>phant0mas: FYI, I spoke to a dev yesterday, working on reviving Arch Hurd <phant0mas>would love to see it up and running again :-) <phant0mas>pizzaiolo: anyhow if you have any questions about the port or want to run it yourself on a hurd machine feel free to contact me directly :-) <pizzaiolo>phant0mas: what issues are you looking up into at the moment? <phant0mas>pizzaiolo: right now I am solving some problems with building packages on the hurd <phant0mas>libunistring has a test failing when built through guix <phant0mas>debian glibc has some patches not in our glibc which I have to chery pick each time to find which one we need <phant0mas>anyhow I got to study for tomorrow's linear algebra exam <alezost>nextos2: the reason nftables (or any other free program) is not packaged is because no one has packaged it yet. You are very welcome to do it :-) <taylan>mordocai: I can run the SBCL REPL just fine, by running /gnu/store/sbcl-<hash>-1.2.8/bin/sbcl directly or by installing it into my profile <taylan>mordocai: do you have SBCL_HOME set? (if so, make sure it's correct, or just unset it) <janneke>how hard would it be to share our [local] builds in a trustable way? <davexunit>janneke: well, people will have to decide who they trust, but you can just run 'guix publish' <janneke>i'm in the process of setting that up for myself... <janneke>it would be nice if there was a way to trust everyone <wingo>ACTION does a big --no-subtitutes build :P <janneke>ACTION is tempted to trust wingo :-D <fhmgufs>Do I have the same environment as in GuixSD in a foreign distro if I do 'source ~/.guix-profile/etc/profile'? <iyzsong>not same, things from the host distro are still available. <nextos2>is there a plan to support systemd unit files in dmd? <nextos2>they are purely declarative so it shouldnt be hard. <nextos2>im asking because im planning to transition a few servers i have from nix to guix <civodul>nextos2: would be nice indeed; this was a GSoC idea last year <civodul>it's still not trivial to get all the semantics right, though <nextos2>civodul: ok, yes. i think its quite important, loads of stuff ships with service files. <Steap|Devconf>ACTION needs a "I write \\nOpenSour^W\\nFree Software" t-shirt for the next devconf <wingo>fhmgufs: i think there are few missing vars still, like the GUIX_LOCPATH stuff maybe <sneek>fhmgufs, you have 1 message. <sneek>fhmgufs, fhmgufs says: Hello <wingo>fhmgufs: not sure, i think so tho <wingo>you might need some extra packages in your profile tho for that to work <wingo>sorry for not being more precise :) <fhmgufs>lxappearance onlx shows the default raleigh theme. <fhmgufs>Although I have installed gnome-themes-standard and some other themes. <fhmgufs>I don't know, I thought that it's just looking to share/themes for themes. <mark_weaver>fhmgufs: it might be that gnome-themes-standard is what you need <fhmgufs>What's the mechanism for Gtk+ to search for themes? <fhmgufs>Is there a cache needed or sth like this? <mark_weaver>wild guess: XDG_DATA_DIRS is involved, but I'm rather ignorant in this area. iyzsong is a good person to ask, maybe on the mailing list. <iyzsong>I think themes should be symlinked to ~/.themes <fhmgufs>But "normal" distros have them in share/themes and that's where they are in the profile. <fhmgufs>Is Gtk+ not listening to the XDG_DATA_DIRS variable? <fhmgufs>iyzsong: You're right - it works within the ~/.themes directory. But that's no good solution. Themes should work out of the box. <mark_weaver>fhmgufs: it would be good if you could help us investigate and improve things. <rekado>I suppose we could use some environment variables to point it at ~/.guix-profile/share/themes <mark_weaver>maybe run gtk+ programs within strace and see what it's trying to do, and look at the source code. <rekado>(that's what we do to find input method modules) <rekado>ACTION has to make some pizza now <fhmgufs>rekado: Yes, but that's only for modules. And the engines are working. ***ghost1 is now known as arianvp
<myglc2>mark_weaver: last night you said "so the git method is a *lot* faster". So are there reasons why I would want to use "guix pull"? <myglc2>Is it a bootstrapping thing, for, e.g. when I don't have git yet? <efraim>you don't need to worry about being behind master, and every time you issue a guix command you don't have to start with ./pre[tab] in the right directory <NiAsterisk>I have to say, with no years long exposure to workflow in gitbut only basic functions, getting it right for guix is a challenge. But I like learning new things :) <a_e>NiAsterisk: No, it is easy! I would do this: <a_e>(If master changed in the meantime: git fetch; git rebase origin/master) <a_e>git format-patch HEAD^ (for one patch or) <a_e>git format-patch HEAD~2 (for two patches and so on) <NiAsterisk>or: git checkout master; git pull; git merge wip-branch; git soft-reset HEAD~2; git commit <a_e>I try to avoid merges. It creates a separate commit with the merge and destroys linear history. I think rebasing is better. <NiAsterisk>git format-patch -1 origin/master gnu/packages/file.scm for one file <a_e>Anyway, there are usually several ways in git. <a_e>And I know only a tiny fraction of them, but they work easily for developing guix. <NiAsterisk>and created some local issue which will just get fixed with the next pull.. I hope. <a_e>Anyway, you do not even need to merge your changes back to master. <efraim>i normally rebase back on master <a_e>Once the patch gets applied, it appears magically in master. And then you just delete your development branch. <NiAsterisk>the problem was an old way behind branch I think.. next time I know better :) <davexunit>efraim: you don't need ./pre-inst-env if you symlink ~/.config/guix/latest to the root directory of your git repo <davexunit>which is what all of us that work from git all the time do <a_e>NiAsterisk: Yes, always do a "git fetch; git rebase origin/master" on your development branch and test that things still work. <NiAsterisk>hm.. I still separate things.. maybe when I get it more, I'll do it with the symlink. I used to switch computers often.. <efraim>davexunit: I know, but this way I can leave git on a branch and guix nearish head <fhmgufs>Is it enough to just add (search-path-specification (variable "GTK_DATA_PREFIX") (files '("."))) or sth like this to native-search-paths of the gtk package definition? <fhmgufs>Oh, not the share subdirectories, but the store directories itself. <fhmgufs>But I think the profile variant is easier. <mark_weaver>fhmgufs: it's probably better to add it to /etc/profile in 'operating-system-etc-service' in gnu/system.scm <mark_weaver>fhmgufs: in theory, what you suggested is superior, but there's a problem: if gtk+ is not in the profile, you won't get the reminder. <mark_weaver>and also it would require rebuilding everything that depends on gtk, which is a lot. <mark_weaver>fhmgufs: oh, and there's another problem. I guess GTK_DATA_PREFIX can only contain one directory, so it can't include both the user profile and the system profile. <mark_weaver>maybe post to guix-devel@gnu.org to share what you've learned, and asking for suggestions? <fhmgufs>Ok, I'll mail. But before I look, if there's sth different. <mark_weaver>if there's no other way, maybe we'll want to patch gtk+ to look for themes in more than one directory. <mark_weaver>although in general, we try to avoid non-trivial patches like that. <wingo>a local build of gpg 2.1.11 failed <mark_weaver>it did eventually build on hydra, but only after 8 failed attempts <efraim>are we sure that after 8 failed attempts that the one that did build isn't the bug? ;) <mark_weaver>wingo: it seems to depend on the machine. civodul built it on his laptop three times, and it succeeded every time. <wingo>i got the '14 errors' thing twice in a row <mark_weaver>and on hydra, it succeeded on all other platforms on the first try (i686, armhf, mips64el) <efraim>I got the 14 errors both times I tried <wingo>i suspect it's a race condition with the pinentry package, like it says in the upstream bug <wingo>ACTION installs gnupg from hydra, then :) <NiAsterisk>is the failing gnunet-gtk still relevant, ie not worked on? I would like to give it another try soon to see if I can spot some corrections I can make <NiAsterisk>don't you "love" 1 word replies with no reference to your message? I asked if I could do sometime in the first half of this year a short talk "an beginners introduction to guix packaging" for really really beginners, no coding experience whatsoever, first reply I get "Mh, I just just started with Nix/NixOS" .... okay? <efraim>so... they're learning something else so they're not even interested? <NiAsterisk>possibly. but it was a proposal/question to one of the hackerspaces in city next to me. I even specifically said that I don't want to get into the projects history and all the technical details other people have given better talks about. Sometimes I want to get my own email server, just for the purpose to have an auto-reply like rms, and it would include a line like "please respond on topic or expect no <NiAsterisk>response.".. seriously, what's the point of "hey, I like cars I want to talk about this one special really cool car!" random person: "oh, i like ducks." <NiAsterisk>I wrote an reply where people hopefully don't read things between the lines which aren't there. I dislike pointless discussions of things I did not imply, I can't read everones minds and feelings. <myglc2>I am finding it difficult to understand and use both "guix pull" <myglc2>and "git pull"? Last night mark_weaver said "so the git method <myglc2>is a *lot* faster". So, should I use only "git pull" to simplify <myglc2>my life? Is there any downside to that? PS: I am running guixSD. <mark_weaver>myglc2: using git won't *simplify* your life. it is somewhat more complex. but it is more flexible and updates will be faster. <fhmgufs>mark_weaver: Couldn't there be sth like the gtk-icon-themes derivation when building a profile for gtk themes, too? <fhmgufs>... creating a store directory which could be set as GTK_DATA_PREFIX? <NiAsterisk>cool. they recommended me to wait for the call for papers for the annual LaborTage convention at their space.. for a first talk that's a bit bigger and later in the year (autumn), but it gives me more pratice and more time to maybe let my slides and notes be checked for factual errors. <mark_weaver>fhmgufs: we could, but it would still only unify the themes from a single profile. there would still be the user profile and the system profile. <myglc2>mark_weaver: You said, 'I've *never* run "guix pull"', and 'to be honest, I've always thought that "guix pull" was an inferior method.' Based on my experience with guixSD, it seems like at least one "guix pull" is required to bootstrap into git. <mark_weaver>you can build from git using the older packages available in guix before the guix pull. <myglc2>But how do I get git, I don't think I saw it on the ISO. <mark_weaver>however, I admit that it might be preferable to do the 'guix pull' first, because maybe hydra no longer has the substitutes for the older versions of packages in guix before the guix pull. <NiAsterisk>guix package -i after you did guix pull in the installation medium <mark_weaver>and also, the older software might have unpatched security holes. <mark_weaver>so sure, it might be a good idea for someone to run "guix pull" after installing GuixSD in order to get what they need to build from git. <myglc2>Right, so the reco fo a contributor to get up to speed is, 1 guix pull during the installation, and git thereafter? <myglc2>Or maybe, guix pull during install, guix package -i git, and git thereafter? <civodul>sneek: later tell alezost make sure to close #22550 if it's done <wingo>how do I get totem to play an mp4 in guix? <wingo>i have totem and gst-plugins-ugly installed in my profile. <wingo>hoo, totem is a dog on this laptop. must be missing the fast video sinks or something <wingo>it's using an opengl video sink but somehow opengl does not seem to be accelerated here <wingo>i wonder what the deal is; it's intel graphics <mark_weaver>and I'm sure your laptop is much more capable than my X60 :) <wingo>indeed "OpenGL renderer string: Gallium 0.4 on softpipe" <wingo>i think that means software opengl <wingo>mark_weaver: glxinfo | grep renderer <wingo>guix makes it really easy to find that out :) <mark_weaver>yeah, I found the answer about the same time you wrote it <mark_weaver>my laptop is also very busy now building guile master <mark_weaver>OpenGL renderer string: Mesa DRI Intel(R) 945GM x86/MMX/SSE2 <wingo>mark_weaver: do you add xf86-video-intel to your packages in your os configuration? <jchmrt>Hey everyone, when i boot up my laptop running guixsd it ends with the message "root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY" and drops me into a guile repl. I am not quite sure how to run fsck in the guile repl, does anyone here have any idea? <mark_weaver>wingo: no. that's irrelevant, because x86-video-intel is in the xorg configuration in gnu/services/xorg.scm <mark_weaver>jchmrt: ah, I've been there once before myself. sorry it's not so nice. can you try: (system* "e2fsck" "/dev/xxx") ? <mark_weaver>I don't remember exactly what was needed, but we can work through it <jchmrt>mark_weaver: it says "In execvp of e2fsck: No such file or directory" <wingo>mark_weaver: am looking, will let you know if i find something <wingo>apparently my laptop is too new for whatever intel driver i am running <wingo>it's a broadwell laptop, from 9 months ago but maybe i haven't rebuilt the os in a while <mark_weaver>jchmrt: I'm sorry this is so terrible, but these commands should work: <mark_weaver>(define dirs (scandir "/gnu/store" (cut string-suffix? "e2fsprogs-1.42.13" <>))) <mark_weaver>(define e2fsck (string-append "/gnu/store/" (car dirs) "/sbin/e2fsck")) <mark_weaver>we should probably arrange to have PATH set reasonably at this point <jchmrt>mark_weaver: there isnt a directory ending in e2sfprogs-1.42.13 in /gnu/store so dirs is evaluated to '() for me. There is however a directory ending in e2fsck-static-1.42.13, should I use that one instead? <jchmrt>mark_weaver: there is no e2fsck in the sbin of e2fsck-static-1.42.13, it contains fsck.ext2, fsck.ext3, fsck.ext4, and fsck.ext4dev according to scandir <jchmrt>which one should i use? or should i use another directory entirely? <lfam>jchmrt: I missed the beginning of your conversation but if you want to fsck your filesystem, use the one that corresponds to the filesystem type <mark_weaver>huh, I wonder if PATH was already set correctly but I suggested running the wrong program name. <jchmrt>nah, i tried fsck.ext4 myself before <jchmrt>It boots again. Thanks for your help mark_weaver! <jchmrt>hmm, i ran (system "fsck.ext4") at least <mark_weaver>civodul: should PATH be set in that emergency REPL if fsck fails? <jchmrt>oh wait of course, i didnt specify an argument then, maybe that was the problem <mark_weaver>I see no occurrence of PATH in linux-boot.scm, so I guess not <mark_weaver>I wonder how much bigger our initramfs would be if we added readline <lfam>Does anyone have any ideas about how to rebuild a package (python-2) that is alive in the store, so that I can investigate reproducibility? Can I save the results of `guix build --check` somewhere? <davexunit>though I'm afraid I don't understand what manolis meant about building a "second stage" of avr-gcc <lfam>The total size of readline's closure is about 67 MB, but readline itself is only 1.2 MB <civodul>mark_weaver: would be a good idea, yes <civodul>lfam: you can rebuild it with 'guix build --check -K' but i think the result is lost <lfam>civodul: I'm trying to look at bug#22010: Python 2.7.10 not deterministic <lfam>I may just use another machine <lfam>Although that machine will build it much more slowly than this one. <mark_weaver>civodul: if the result is lost, how does one compare the old and new versions to debug non-deterministic builds? <civodul>lfam, mark_weaver: if the thing is still live, you can add a noop to one of the phases to make it different and rebuild it several times <civodul>stash the result of the first build with "cp -a" and remove it <lfam>That's what I've been doing, but the other packages have all lacked referents that kept them alive. <lfam>Is there a Scheme no-op I should use? <mark_weaver>civodul: but that will change the hash in the output directory name, which will usually end up changing the files within because of self-references, no? <lfam>Perhaps, but depending on the problems, it may be easy to "filter" those differences out by eye <lfam>According to the bug report, the only difference is the 5th byte of the bytecode, which sounds similar the python-3 non-reproducibility issues <lfam>Our python-2 package creates a broken link at share/man/man1/python.1 that makes diffoscope and rsync crash :( <lfam>I'm just going to delete it and keep going <civodul>maybe it's the man page compression phase that's breaking things <lfam>Perhaps. It's the beginning of a botched symlink chain <lfam>It doesn't crash `cp -a` BTW <lfam>python.1 -> python2.1.gz, python2.1 -> python2.7.1.gz, python2.7.1.gz