<Jookia>davexunit: My pre-inst is based on a Git revision with one change- to have the Guix package use the same Git revision. Installing Guix should give it the same Git revision installed, minus the change
<Jookia>davexunit: What I'd expect to see when installing Guix using an installed Guix is a version downgrade, not a world rebuild
<davexunit>I don't know what you mean by "installed guix", though
<davexunit>you said you've only used guix from a git checkout
<Jookia>I've built Guix from a git checkout, then with the pre-inst-env, used that Guix to install Guix
<davexunit>that guix package is definitely built with localstatedir=/var/guix
<davexunit>so 'guix package -i guix' doesn't trigger a rebuild?
<davexunit>that version of guix should yell that it cannot connect to the build daemon
<Jookia>"./pre-inst-env guix package -i guix" doesn't trigger a rebuild, "guix package -i guix" with PATH set to the root profile does trigger a rebuild, both with their respective daemons running when run (not at the same time)
<Jookia>It does yell 'error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory' if I try to run the installed Guix with the pre-inst-env daemon
<davexunit>Jookia: respective daemons? only one daemon can be running!
<davexunit>because they will both be writing to /gnu/store, but each daemon that's using a different localstatedir will not know what stuff the other has built.
<Jookia>When I run the first command ("./pre-inst-env guix package -i guix") I run "./pre-inst-env guix-daemon ...", when I run "guix package -i guix" with the root profile in my PATH, I close the first daemon and run the second daemon using "guix-daemon ..."
<davexunit>Jookia: this explains exactly why you are rebuilding anything.
<davexunit>that second daemon has a completely different state directory
<jin_>OrangeShark, i will check again the nautilus dependences
<myglc2>I don't know. I have two identical physical servers. One has Debian 8 installed, the other guixSD. I ssh into both the same way, but the guixSD box has all these "?". Would guixSD be using a different default encoding than debian?
<lfam>myglc2: Do you have a unicode font in your guix profile?
<OrangeShark>jin_: good luck, I tried looking for any text files that has any instructions for dependencies and I can't seem to find any
<lfam>For example, font-gnu-unifont (make sure to select the right output, since the different font formats are split into different outputs)
<myglc2>lfam: I don't see any fonts in '/run/current-system/profile/share/info'. But would matter if I'm using tty (iTerm2 on a mac). I guess I could go over to the console in the other room and see if the '?' are there too?
<mark_weaver>is this within X or within a text console? what program?
<myglc2>So you think the problem is the font I am using in my terminal emulator (iTerm2)?
<lfam><myglc2> I don't know. I have two identical physical servers. One has Debian 8 installed, the other guixSD. I ssh into both the same way, but the guixSD box has all these "?". Would guixSD be using a different default encoding than debian?
<mark_weaver>yes, or maybe it's a problem with the terminal emulator itself.
<mark_weaver>I use gnome terminal, and that renders UTF-8 correctly.
<myglc2>Sorry, yeah a tty session running from my Mac desktop to the headless server.
<lfam><myglc2> any idea why all my guixSD emacs INFO pages have a "?" everywhere they should have a "'"?
<mark_weaver>myglc2: ah... so, within the iTerm2, while logged into the Guix server, "echo $LANG" from that shell on Guix says "en_US.UTF-8" ?
<mark_weaver>I'd also like to know what the output of "echo $LANG" is while logged into the Debian 8 server via iTerm2
<mark_weaver>well, I'm stumped. can you email email@example.com about it?
<myglc2>Sure, thanks. I just noticed that when I ssh to guixSD from the Debian box echo $LANG gives a blank line.
<mark_weaver>myglc2: one more question: in the emacs running on GuixSD, do you see "-UUU" on the left side of the modeline?
<mark_weaver>myglc2: wait, when you ssh from debian, LANG is unset/blank, but when you ssh from your Mac, LANG is "en_US.UTF-8" ?
<myglc2>Hmmm. On guixSD I see '-UUU:**-...', on Debian I see 'U:**-...'
<myglc2>Yeah. When I ssh from Mac to debian to guixSD, LANG is unset/blank. When I ssh from Mac directly to quixSD LANG is "en_US.UTF-8"
<mark_weaver>myglc2: when Emacs is run from a text terminal, it should show more characters than that before the ':'. when running it from Debian, is emacs actually running in text mode within the iTerm2, or is it opening a new window via X11 forwarding?
<mark_weaver>section 1.3 (The Mode Line) of the Emacs manual talks about what's in the mode line.
<myglc2>OOPS, I lied. I am sorry. I'm actuall in X11 on debian. Let me switch to tty.
<mark_weaver>run "emacs -nw" to force it to run in text mode. I'd be curious what happens if you run that on Debian from your iTerm2
<myglc2>OK now I have '-UUU:%%-...' on the mode line in Debian
<NiAsterisk>first time fosdem was interesting. brussels too, because I forgot for a moment it's dual language with french, good thing I refreshed french just enough to understand and have dialogues in french where I replied in english because after all these years forming sentences in french felt weird to me.
<efraim>anyone who reads this between now and when I update/fix wayland:
<efraim>dealers choice: add graphiz as a dependancy, or disable documentation?
<janneke>NiAsterisk: that helps...now to find how to set a sane PATH
<NiAsterisk>if it helps, my $PATH is: ~/.guix-profile/bin:~/.guix-profile/sbin:/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin where you should replace ~ with /home/your-username no idea what you are trying to do though.
<kqb>does guix JUST add a guile EDSL and different default system packages when used as an OS? Or is there more?
<NiAsterisk>most of it should be obvious through the website and documentation. for example nix has a more "relaxed" view on software whereas guixsd is a GNU faif distribution.
<kqb>I read the motivation/general-design part of the documentation, I am interested in an overview of the technical details underneath. There is an option - I believe it is "import" - that allows guix to use nix packages. Where can I find documentation on that?
<NiAsterisk>ACTION wonders why orangewebsite adds more than 100% to the price of .is domains. this seems so surreal, I have to get an reply from them
<NiAsterisk>oh, i just found a very demotivating post by cwebber about npm based software in guix :/
<mark_weaver>the first paper is a bit out of date, but a good overview of the rationale, design, and implementation of Guix
<mark_weaver>kqb: the entire client side of guix is written in pure guile scheme. I guess it would be difficult to write a common-lisp interface for it, because I'm not aware of any existing interfaces to allow calling guile procedures from common lisp.
<mark_weaver>also, unless the common lisp implementation in question used the BDW-GC garbage collector, they would be two separate garbage collectors in the same process, and that's likely to be a huge pain, to say the least.
<kqb>from what I gather guile has a c-interface; alternative: crank guix/guile out of common-lisp
<mark_weaver>the most likely approach would be to run guix in a separate process and talk over sockets.
<mark_weaver>it's true that guile has a nice C interface, though, so C could in theory be a bridge between the two worlds, if the garbage collection issues could be dealt with.
<mark_weaver>what is it that you wish to be able to do from common lisp?
<kqb>from what I read (I spent a year just reading) scheme traded macro-simplicity for namespace-simplicity (lisp-1 and lisp-2 being the two different approaches). Sadly Let over Lambda costs money. It gave me some insight into macro-programming
<mark_weaver>if the number of operations you need to expose to common lisp is limited, then it would be feasible to do it over a socket.
<kqb>maybe it is possible to just compile the guile-source with sbcl
<kqb>In the short term I just want to be able to use syntax-quote and macros to produce guix-packages
<mark_weaver>kqb: I don't understand. What do you think that Scheme traded away in the area of macros? Scheme has hygienic macros, and Guile has procedural hygienic macros with the ability to bypass hygiene where explicitly desired. I see them as strictly superior to CL macros.
<mark_weaver>kqb: running Guix, or any other non-trivial Guile code within a common lisp implementation is going to be a *major* project.
<kqb>I understand that point of view, but I consider that to be to much overhead for my *personal* code
<mark_weaver>kqb: Guile even has a 'defmacro' macro for those who don't want to deal with hygiene.
<mark_weaver>(although we strongly discourage its use, because of problems with unintended variable capture)
<mark_weaver>I also don't know what you mean by "Let over Lambda costs money". Can you explain?
<mark_weaver>kqb: can you tell me what you wish to do, and how your existing "personal code" fits into it? if I understood your goals, I might be able to suggest the easiest way forward.
<mark_weaver>"In the short term I just want to be able to use syntax-quote and macros to produce guix-packages" is too terse. Can you elaborate?
<kqb>I was unable to find a free copy of Doug Hoyte: Let over Lambda. I ended up going to a library.
<mark_weaver>in Guix, packages are first-class objects. they can be created programmatically using procedures or macros.
<mark_weaver>there are several examples of this already. we have several procedures that accept packages as arguments and use them to create new packages as return values.
<kqb>I am relatively new to lisp and some macros like Graham: On LISP "aif" sound interesting. They use intended variable capture. The way I learned to write code unintended variable capture was never a problem (I managed to write CLEAN "GOTO" code in a BASIC dialect). Most "features" to clean up code, just waste my time, because I do not need the constructs. When I give my code to others I put them in, because not everybody wants
<mark_weaver>guile uses the 'syntax-case' macro system, which allows variable capture where intended, while doing things hygienically by default.
<mark_weaver>if you want to write macros like that create guix packages, by *far* the easiest course of action is to learn the syntax-case system. all of the other solutions you're thinking of would be major projects.
<kqb>ok. I don't have a problem switching between LISPs, but if I have the option I prefer CL.
<mark_weaver>understood, but obviously the Guix project has chosen Scheme and written about 200 thousand lines of it.
<mark_weaver>I can explain how to write macros like 'aif' in syntax-case, but #guile would probably be a better place to discuss that.
<myglc2>mark_weaver: You remember the UTF-8 "?" for "'" problem I was having last night? Looking at this again this AM I noticed that '/run/current-system/locale/2.22' has en_US.utf8 and en_US.UTF-8. So I changed the line in my config.scm that reads '(locale "en_US.UTF-8")' (inherited from in bare-bones.scm) to read ... (locale "en_US.utf8") and the "?" in emacs info are fixed. So now I am a happy camper. However, ssh from debian box to guixSD
<myglc2>box and 'echo $LANG' returns blank line, which does not bother me but seems odd. Do you want me to email firstname.lastname@example.org re this discovery?
<mark_weaver>'datum->syntax' is used for intended variable capture. on that page, search for 'datum->syntax' and it will show a 'loop' macro that introduces a 'break' binding unhygienically.
<mark_weaver>myglc2: ah, that's interesting! thanks for the report.
<mark_weaver>I guess we should change our example configs. *.utf8 does seem to be the preferred form nowadays, but my system has (locale "en_US.UTF-8" and somehow I've not run into problems, so this is interesting.
<mark_weaver>myglc2: regarding ssh from debian to guixSD losing the LANG variable, that's interesting. probably worth an email to email@example.com, yes.
<myglc2>OK I will do that. Got to run out now, will be back later if there is anything else you need on this.
<mark_weaver>kqb: that binary install image is old, from the 0.9.0 release. since then, we've updated some core packages that forced the rest of the system to be rebuilt. assuming you ran 'guix pull' (which is a good idea, to get the latest updates, some of them security updates) then you're now downloading the new "versions" of those packages, even if the version number didn't change.
<kqb>I executed "guix pull" for root and for the unpriviledged user.
<mark_weaver>in cases where the version number of a given package didn't change and you need to download a new one, it's because some library that it uses (or some package that was needed to build it) was updated.
<kqb>I seems very unlikely - although not impossible - that such an update would occur while I was switching between users.
<mark_weaver>so, if you make ~root/.config/guix/latest a symlink to ~foo/.config/guix/latest, then running "guix pull" as user "foo" will effectively update guix for both root and foo. running "guix pull" as "root" would overwrite that symlink you made and now they'll be independent of each other again.
<mark_weaver>and if the symlink is pointing the other way, then you should "guix pull" as root to effectively update the guix packages for both foo and root.
<davexunit>NiAsterisk: we need to ford the npm river at some point. ;)
<davexunit>ain't gonna be easy, as cwebber's blog post has shown.
<NiAsterisk>I'm curious in all the wrong things to get an easy start :D maybe eventually I can contribute more when I figured out all the high level issues I experience and have to learn about.
<efraim>NiAsterisk: I started contributing by looking at the programs I used and updating them and their dependancies
<efraim>then from there I started attacking the packages that failed to build and somehow ended up trying to keep more of our python packages up to date
<NiAsterisk>I have a list of software I use and want to get into guix. but some of it is a bit complex for the beginning. lispf4 seems to work out, but that's the easiest package. everything was easy though when it was just ebuilds. I also want to see if I can bring up enough pro-arguments to get a vote on the test systems used with the EDN project, where I am not that much involved but it would make perfect sense to aim
<NiAsterisk>for an guixsd based system or at least guix as a package manager.
<mark_weaver>bah, the openssl security update has caused perl-io-socket-ssl's test suite to fail, and for someone like me who hasn't used perl for anything non-trivial in about 20 years, it's proving quite difficult to debug this :-(
<mark_weaver>it doesn't help that the problem only happens within the isolated build container
***ttuegel_ is now known as ttuegel
<janneke>how do i add an entries to grub.cfg and fstab (dual boot with ubuntu for now)
<mark_weaver>janneke: see the "GRUB Configuration" and "File Systems" sections of the Guix manual, both within GNU Distribution > System Configuration.
<NiAsterisk>does the hostlist accept things like mimageads*.googleadservices.com to capture 1,2,3,4,5,6,... for everything which could fit into the space behind mimageads? I started working on a proposal addition to the hosts service.
<NiAsterisk>the tl;dr will be: why stop at facebook with hostblocking options.
<mark_weaver>NiAsterisk: can you post to firstname.lastname@example.org about it?
<NiAsterisk>before I knew about dry-run.. i wondered, is this too intrusive? people who want the update will update and can review it with guix package -l afterwards. but what if they are low on bandwith, diskspace, time and just are curious about what's there to update?
<CompanionCube>NiAsterisk, or if they don't want to compile anything big without knowing
<lfam>I never noticed --dry-run. It seems to me a sufficient solution.
<NiAsterisk>does dry-run show size downloaded and disk space used?
<lfam>I'm working on a package for nmap. Overall the build system is very easy to use. However, it bundles all of its dependencies in case you don't provide them. And some of its dependencies bundle their dependencies...
<NiAsterisk>but, guix specific: don't you include the location of the file in the commit message? gnu/packages/file.scm seems to be more exact to me then just file.scm.. give it some more years and there could be a case where suddenly there's file.scm in n places. okay, commits with git solve this problem iirc, but is this okay?
<Jookia>Well, you can look at the actual commit to figure out what's going on
<lfam>See this commit for an example: 16414017f30f944cfe964f1d9141bdcbf56be857
<Jookia>"building of `/gnu/store/hsaqbkh9x95lpv0gyrwx4c8ccz59mv57-gdk-pixbuf-2.32.3.drv' timed out after 3600 seconds of silence" hmm- it seems the tests of gdk-pixbuf are either crashing my machine or timing out
<CompanionCube>because a set of gems spontaneously appeared in the stored ruby
<mark_weaver>alezost: myglc2 reported that when using (locale "en_US.UTF-8") in the OS config of his headless server, logging in remotely from a Mac running iTerm2 and running Emacs info, all of the directional apostrophe's showed up as question marks.
<mark_weaver>and he reported that by changing it to (locale "en_US.utf8"), the problem was fixed.
<lfam>Jookia: You can change the --max-silent-time of `guix build`. But that's probably not the real problem
<Jookia>lfam: Yeah :\\ I'm not sure what's happening, perhaps the system runs out of RAM.
<lfam>Jookia: Check the logs on hydra.gnu.org to see if its unique to you
<lfam>If it was out of RAM the kernel would kill the builder
<Jookia>Is there a command to grab the log from hydra.gnu.org?
<lfam>Jookia: I think there is in guix.el but I don't know how to use it. Usually I go to the web-based guix package list, find the package, and click on the architecture I'm interested in. It's stupid but it's faster than waiting for hydra.gnu.org's web interface which I don't really understand.
<lfam>Oh, in some cases `guix build --log-file` will download hydra's log
<alezost>mark_weaver: no idea why it happened; I just reacted to your phrase that you have no problems having (locale "en_US.UTF-8") in your system: any other "xx_XX.UTF-8" wouldn't work at all, but you know it apparently :-)
<lfam>Jookia: Is your machine reasonably powerful, or could hydra's 13 minutes turn into > 1 hour?
<Jookia>lfam: It's a T400, so perhaps it could. I'm not sure
<lfam>I don't know what hydra's x86_64 build machines are, so I can't say
<Jookia>I can't run the tests with the failed build either, it just gives me error messages :(
<lfam>Well, you could increase the max-silent-time and go to a movie ;)
<lfam>I would enter the failed build directory, source the environment-variables file, and run them manually. You may need to elevate your privileges if they want to write. I'm happy to hear a better suggestion!
<alezost>cajg: most likely there is an error in your config. If you paste it, people here may tell what's wrong
<lfam>alezost: cajg did share their config eventually
<Jookia>lfam: I'm not sure what I'm suppose to run though :( I've complained about the lack of debugging tools in Guix before so it's not that useful- sourcing the environment-variables and running 'make check' complains about missing test plans
<alezost>lfam: it had several (many) errors, and I don't know what was fixed and what left