<brendyn>Because what `giux build` really does is return the location in the store of the build package. If that requires actually building it, then it will, if it's already there, then it'll just return it
<Corin>Hey, question. Are any other distros utilizing Guix and Shepherd besides GuixSD?
<DoublePlusGood23>Corin: GNU/hurd uses Shepherd, and I think ng0 has an OS in dev that uses guix. You've probably heard of NixOS which GuixSD takes a lot of inspiration from and uses a similar package manager.
<Corin>DoublePlusGood23: What's GNU/Hurd? You mean GNU?
<lfam>Basically, debbugs doesn't handle multi-email patch series well. To keep all the patches in one "bug", one would have to send a dummy email, get a bug number, and then mail the patch series to that bug number.
<DoublePlusGood23>Corin: I wouldn't recommend switching full time, it's still pretty unstable. You can install it on top of another distro and it will function in tandem, but I've had issues with that as well.
<lfam>DoublePlusGood23: If so, I can make that change locally; no need to send a new patch. I had already split that patch into two commits
<DoublePlusGood23>lfam: agreed :-) One python lib used pythonhosted which seemed more offical.
<Corin>Oh, hm. I've dealt with similar before though. It's pretty funny finding workarounds for bugs and making a usable system out of an unusable one.
<DoublePlusGood23>lfam: How would I send different changes to the same file as separate commits? I opted for just the one, but useful info
<DoublePlusGood23>Corin: If you have the computer to test on it's always worth a shot. Sending in bug rps and patches is nice to.
<lfam>DoublePlusGood23: There are a million ways :) I like to use `git add --patch`, which offers an interactive interface for staging changes
<lfam>I "used" Git for a year or two before I really started it using it heavily. That's when I started to need a better workflow
<DoublePlusGood23>lfam: I don't really program that often either, I just know enough to cause damage :p
<brendyn>I just dump everything into commits, then when I'm done I update master, make a new branch and remake all the commits manually
<DoublePlusGood23>brendyn: at least with these commits, I pulled, made a separate branch, edited my files, then added and commited per file. Seem to work mostly OK - the --patch flag should especially help with package expressions.
<lfam>It's hard to say until you start. I would start by checking if that package's built output includes the missing program. If not, I'd poke around in the source code and search the internet for mentions of the program, to see where it is supposed to come from
<lfam>I remember looking for a new libaio source when fedorahosted shut down. It's a bit disturbing to see things disappear like that!
<DoublePlusGood23>lfam: Yeah, I'm surprised they shut it down and how many projects haven't migrated.
<marusich>I have noticed that, somehow, when I log in, gnome-session seems to be sourcing (perhaps indirectly) my ~/.bashrc file.
<marusich>Does anyone know how that might happen? I can't see anything in /etc/profile, /etc/bashrc, or my home directory's dot files that would cause this
<marusich>To answer my own question: on GuixSD, we have implemented (in (gnu services xorg)) a slim-service (see 'info (guix) X Window') that runs a command like the following to start the graphical session: $SHELL --login -c $SESSION, where $SHELL is the user's login shell, and $SESSION is the session chosen at login (e.g., GNOME on X11).
<marusich>Therefore, in my case, when I log in, slim actually executes something like: 'bash --login -c gnome-session'
<marusich>That is a non-interactive login shell, which causes (accoring to 'info (bash) Bash Startup Files') the following files on my system to be sourced: /etc/profile, then ~/.bash_profile. My ~/.bash_profile in turn sources ~/.bashrc. QED.
<marusich>The upshot of all this is that, even though it is not (yet?) documented in the Guix manual (as far as I can tell), this means that it's easy to set environment variables for both terminals and graphical sessions in GuixSD, which is nice.
<marusich>Such is the price of building from source without substitutes.
<reepca>also, it turns out that applications only search the "assumed" info page locations if INFOPATH is either empty or ends with a colon. So if you install texinfo and source ~/.guix-profile/etc/profile in your .bashrc like you should, then you end up unable to find any of the non-guix info pages (in /usr/share/info or /usr/local/share/info, for example). ¯\\_(ツ)_/¯
<rekado>since ‘git add --patch’ was mentioned: magit (the Emacs UI for git) makes this even nicer by showing you the changes and allowing you to stage individual hunks right there.
<rekado>brendyn: instead of remaking all commits manually you can do this in the same branch: git fetch origin; git rebase origin/master
<rekado>brendyn: this will try to apply your commits on top of the latest version of master.
<brendyn>surely I don't want to mess with origin/master?
<Apteryx>brendyn: the git rebase thing means rebase *onto* origin/master, essentially rewriting your commits on top of current master.
<Apteryx>reepca: Interesting. I didn't know about INFOPATH values needs to end by ":" if I want the standard locations to be looked up.
<rekado>brendyn: you cannot mess with origin/master as you don’t have permission to push there.
<efraim>git rebase also takes the '-i' flag for interactive, if you want to drop or rearrange or edit commits first
<efraim>I do that when regular rebase fails from one of my branches
<efraim>or 'git rebase origin/master' if I haven't pulled on my local master copy yet
<rekado>it also makes it easy to amend commits that are a few commits back
<rekado>you just make a new commit ‘tmp java’, then interactively rebase, move the commit right after the one it modifies, then mark it as a fixup commit
<rekado>interactive rebase is very convenient in magit
<rekado>it’s a bit rough without (e.g. you have to cut and paste lines to move commits and you have to manually change ‘pick’ to other commands)
<reepca>Apteryx: yeah, I couldn't find any documentation of it in the man page for info or in the info pages for info. Only C-h v actually mentioned it (and now that I look, some people on stackexchange), but both emacs and the standalone info reader seem to behave the same way in that regard
<efraim>I use it also when working on packages where I also have to package a dependency, which should be commited first
<marusich>Does anyone know what the following line means in doc/local.mk?
<marusich>What I don't understand is the stuff after it.
<marusich>What feature of make is that, where you can do $(DOT_FILES=%.dot=$(top_srcdir)/%.png) ?
<marusich>Since it involves two equals signs, it does not seem to be what is described in (make) Substitution Refs, since that involves a colon and an equals sign.......
<brendyn>reepca: Do you know how to do that in Magit? I think it might be broken for me since I tried something like that with it's rebase feature and M-j but it didn't not respond to those key presses.
<rekado>we offer the software also as a Guix package for R, and it’s on bioconductor too.
<rekado>(though there’s no need for the web interface when you use it directly in R)
<efraim>for anyone interested, i ran `guix pull' on my aarch64 board, built guix with firstname.lastname@example.org, and then ran `guix pull' a second time and now it's building guix2.2-ssh, presumably to build guix with email@example.com
<efraim>namely, i created the filesystem on /gnu with a newer version of coreutils than the board has, so every now and then when it fails to mount I need to transfer it to a different system to fsck it, but it hasn't been a real problem yet
<rekado>civodul: I don’t know yet. I need to try to build ecj next and then use that to build GNU classpath 0.99, rebuild jamvm with that version of GNU classpath, and then … maybe that’s enough to build icedtea already (i.e. jamvm + classpath 0.99 + ecj).
<rekado>then we could cut GCJ loose and also get rid of the ecj bootstrap jar.
<brendyn>I had to rebuild my whole git repo since I got all these funny errors ;;; ERROR: In procedure make_objcode_from_file: bad header on object file: "\\x7fELF\\x02\\x01\\x01???\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00"
<civodul>brendyn: that's a sign you're almost on 2.2 :-)
<civodul>brendyn: it's 2.0 complaining about 2.2 .go files
<efraim>hmmm, infernal wants vmx or sse for parallel instructions
<brendyn>;;; Failed to autoload make-page-map in (charting):
<efraim>civodul: another issue, the guix-package.sh test fails on aarch64
<brendyn>I guess it's a bit bumpy is the Guix starship engages warp drive
<civodul>efraim: that's no good, could you investigate or report details to bug-guix?
<civodul>efraim: you can run "make check TESTS=tests/guix-package.sh" to run just this one
<brendyn>civodul: Another thing that I find odd is that the order in which guix chooses to build packages seems inconsistent. when I `guix system init ~..' again guix will start building another package usually, rather than the last one that just failed
<brendyn>It's not exactly a bug, but it makes guix unpredictable
<brendyn>But the thing that concerns me is for example it may be useful to support other solutions in the mean time. the wait for GNUnet means proposals to use things like IPFS get rejected immediately
<ng0___>brendyn: I hope to finish the documentation export soon, and dvn will start soon working on the new website for gnunet.org .. those are steps which are less obvious and not programming
<rekado>looks like the class loader in jamvm doesn’t quite work when built with GNU classpath 0.93.
<rekado>I need to find a faster way to get to a later version of GNU classpath.
<ng0___>I don't want to reject GNUnet. You can add whatever you want for the system, I know I am working on solutions which will require GNUnet in the end, so if someone comes up with something as a middlepath for the time being, okay.
<rekado>(actually, ‘frozen’ is a really poor term considering how hot this plastic case gets)
<brendyn>ng0___: I'm not rejecting it, but I have a line of reasoning I wanted to discuss. I think the difficulty with switching to a GNU internet is that one cannot simply take someone elses HTTP site and magic it on to GNUnet or IPFS, atleast not easily. That is, part of the challenge is moving away from HTTP
<brendyn>But if the internet largely used something like IPFS, it seems one could link it up with GNUnet much more easily
<ng0___>wel lactually gnunet is ready for use. it just depends on getting towards a more reasonable release model, something which is on the roadmap.
<brendyn>How can it be ready for use? I have the latest git version. I cannot even download a copy of the GPL via file sharing, memory leaks and cpu usage cause me to have to kill GNUnet after 1 hour. Maybe this is just my build or config is broken and so my opinion is wrong
<ng0___>part of why I'm so stuck on GuixSD and learning shepherd is so that I can create some kind of easiest, dead simple solutions cookbook where you can see usecases for servers etc.. right now it's terrible to setup
<ng0___>it helps to report bugs if you think what you experience are bugs.
<ng0___>so I guess no one knows why lvm2/static fails.
<ng0___>brendyn: probably also depends on where you use gnunet, dgolle helps to maintain it for embeded hardware like OpenWRT routers. but it's relatively common for certain types of software to use lots of resources ime. pybitmessage tends to do the same.
<rekado>ng0___: maybe send an email to help-guix? I don’t think 20 mins is enough time to wait for something like this on IRC.
<ng0___>it's not good, but in the end mobile devices with limited resources will not use the full build of gnunet
<reepca>Well, over the course of the past week I got moved in back at home, got guix set up on my laptop, got my desktop set up, got guix updated on it, learned how INFOPATH works, learned that installing "hello" on a weak i686 laptop without substitutes takes several hours, and read various documentation.
<ng0>no it's not an expression of being annoyed. I'm just not so motivated to update the site. I knew about prep and think I will settle on moving most of it to prep and drop my attempt at writting something similar for now
<efraim>sneek: later tell civodul 9 hours for make with guile2.2 on aarch64
<ng0>there are multiple use cases, if you tell me what you understood, it helps to refine the description. I have my view, but I can't talk about everything. There are features which are rough plans for now
<ng0>a usecase is a base for 0, an application I'm currently designing.
<ng0>do you know texinfo? there's a very boring task mostly done by myself to fix the gnunet documentat. that is not developer centric
<ng0>I will try to make it more clear then over the next couple of months. I'm just running multiple approaches at once, and one of them involves that I can't talk about everything which is attached to this system
<ng0>but I can make it in general more clear who will use it, etc
<ng0>talking about it would be cool :) which would require that I finish the writing tasks. I have a clear vision, but I'm not terribly motivated to write in documents. I prefer paper. Once the university applications are done I can do it I hope
<reepca>"if that comand fails because you do not have the required public key..." - right underneath the key-verifying part. Maybe we should instead assume that most people don't have rekado's public key and put that before it.