<rie>i did: guix pull -v 2 but i'm not seeing any debug output (did i need to pipe stderr to a file?) the command is still running (over 7 hours) and hasn't moved past the git update and i'm worried its stuck. ***midnight is now known as midnight_
<lfam>rie: 7 hours sounds way too long <lfam>rie: What kind of computer are you using? And what is the output of `guix describe` and `guix --version`? <rie>it's an asus eee-pc netbook. describe: error: failed to determine origin. version 1.1.0 <rie>describe also said hint: perhaps this guix command wasn't obtained with guix pull <bavier[m]1>pull on eee-pc is fairly slow if substitutes are unavailable <rie>the guix real process is using 0% cpu. top shows nothing going on at all it seems <bavier[m]1>I think pull needs to substitute/build a git before it can do the local checkout, which requires several other packages be available, etc. On an eee-pc that may take a while esp. if ram is low and disk-swapping is going on <bavier[m]1>if there's no builds happening, it should be safe to cancel and restart the operation without any "work" being lost <rie>i have, restarting it leads to the same result. doesn't seem like anything happens at all. <lfam>That output of `guix describe` is expected if you haven't done `guix pull` yet <lfam>I would install the strace package (`guix install strace`) and then trace the main guix-daemon process with it, using the -f option to it <lfam>It would be interesting to know what it's doing, or if it's totally stuck <lfam>So, something like `strace -f $(pgrep guix-daemon)`, but make sure it selects the parent guix-daemon process (lowest PID number) if there is more than one <lfam>Was it just stopped like that, waiting on the (read)? <rie>it's still there, btw <rie>ouchie. well, i don't really have any more time right now but I appreciate your help. Thanks :) <lfam>Sorry it doesn't work for you :( It would be nice to get a bug report at <bug-guix@gnu.org> if you find the time <rie>yes I will do that! Glad to contribute something (even if it is just more work) <xelxebar>That image is ~500MB, but guix system disk-image gnu/system/install.scm generates a ~3GB one. <vits-test>xelxebar: Manual in 3.9 claims it was with `guix system disk-image --file-system-type=iso9660 gnu/system/install.scm`. <lfam>xelxebar: Check the release target of the Makefile <lfam>I'd guess the difference is due to compression <lfam>I checked and it doesn't account for the whole difference <lfam>Did you try it from the release tag, xelxebar? <vits-test>xelxebar: "You can specify the root file system type by using the ‘--file-system-type’ option. It defaults to ‘ext4’." <vits-test>probably read-only iso9660 is easier to zip? <sneek>s34n was in #guix 4 months ago, saying: (I think. I can't look at history right now and I'm brand-new to guix). <xelxebar>Hrm. I might just be showing my ignorance here, but how would choice of filesystem make such a huge difference in size? <ani_>[ani@thinkpad guix]$ ./pre-inst-env guix build decon <ani_>;;; note: source file /home/ani/guix/gnu/packages/cran.scm <ani_>;;; newer than compiled /home/ani/guix/gnu/packages/cran.go <ani_>guix build: error: decon: unknown package <ani_>I added new variable r-decon and now trying to build it. <ani_>./pre-inst-env guix build -K r-decon <wleslie>just thought I'd try getting a more recent emacs using guix, and specifically configured for working with my current employer, so I installed into a new profile: <wleslie>guix install --profile=/home/wleslie/.guix-extra-profiles/tsa-dev emacs emacs-go-mode emacs-tide emacs-toml-mode emacs-lsp-mode <wleslie>I opened up a new terminal and set `GUIX_PROFILE=/home/wleslie/.guix-extra-profiles/tsa-dev ; source $GUIX_PROFILE/etc/profile` <wleslie>however I get this error: Warning: Lisp directory `/home/wleslie/.guix-profile/share/emacs/site-lisp': No such file or directory <wleslie>it's pointing at the wrong profile, somehow <wleslie>I start it with `emacs --no-desktop` since I still have my host emacs running <wleslie>GUIX_PROFILE must be set before sourcing the profile <wleslie>how do people handle `.emacs` in guix? <efraim>ani_: Looks like you typo'd. your paste says it doesn't know about 'decon' but you successfully built 'r-decon' <efraim>wleslie: not sure about emacs at all, but to switch profiles I think you need to source ~/.guix-extra-profiles/etc/profile <wleslie>not quite, you need to set GUIX_PROFILE first, as the sourced file depends on its current value <wleslie>hmm. it doesn't read my ~/.emacs, but Custom writes to ~/.emacs.d/early-init.el <wleslie>ah, figured it out; if it fails during site load (in my case due to invalid entries in EMACSLOADPATH) it doesn't get to .emacs <vits-test>xelxebar: iso9660 vs ext4 zip-ability: IDK how, but chances are. <xelxebar>vits-test: Maybe the ext4 image contains a lot of free space (i.e. zeroes)? <xelxebar>vits-test: Interestingly, I build the image on a remote machine and ncat'd it to my local machine through a reverse ssh forward with compression (ssh -C -R). That the receive side was reporting something like 15 MB/s throughput, which is well above my puny internet link's capabilities. So you're probably right about the compression. <shoxy>hi everyone! guix is great! i would like to use it for my servers, but i am worried that e.g. postgres is not maintained. I myself am not (yet) able to support maintaining. How do you handle such (famous/important) packages at guix? <vits-test>shoxy: One need to challenge a developer for hand-to-hand fight. Loser become a package maintainer. <leoprikler>Jokes aside, upgrades are usually trivial unless they're major. <leoprikler>As such, you don't really have to fear postgres getting outdated. <leoprikler>If it does become a concern, e.g. as in the node case, you could [temporarily] package them in your own channel. <leoprikler>I assume businesses that use Guix will already do so, as companies dislike the thought of sharing internal resources with anyone very much. <shoxy>I only found the postgres major version to be 10 <shoxy>its not a big business, but i like the config/controlly way of guix <shoxy>but isnt there a "main" package? I looks like it is the v10 <leoprikler>`guix build postgresql` will build v11, but the variable postgresql refers to v10, yeah <leoprikler>you might want to prefer postgresql-N, where N is the version you want <jmarciano>is Guix following freedesktop specifications and to which degree? I am not interested that it follows personally, just researching to compare it for one specific bug in Emacs <shoxy>ah ok, ty! I know - maybe its a little picky, but for server I prefer the most maintained version, and as "guix-noob" having difficulties to get these info <cbaines>the rationale being that someone using PostgreSQL should be explicit about the major version they're using <cbaines>I'm hoping this change will also help in supporting upgrading from one major version to the next. At the moment it's possible to do, but just not documented <leoprikler>jmarciano: Guix does honor XDG to some extent with the big outlier being ~/.guix-profile <shoxy>thanks everyone for the help! <shoxy>Oh, and of course I just remembered another question I had: How do you handle hardware? So how do you know which hardware is suitable for Guix before you buy it or before you put it together? <leoprikler>h-node.org is a decent resource, but if you want to go "full Stallman" you can also stick to RYF everywhere <shoxy>RYF isnt necessary. h-node.org feels outdated. Isnt there some kind of guide, e.g., "with this brand or with this available device you are good"? <leoprikler>Not really, because it's not so much a brand thing as an age/feature set thing. <leoprikler>In that case Guix won't put anything into your trashcan, but programs should have access to it. <MSavoritias[m]1>you can also see what specs purism has. their distro is only free software as far as i know <jmarciano>leoprikler: I have Guix on image, not on one of computers as we cannot allow spending bandwidth. <jmarciano>leoprikler: so currently I am not using it, only when in Europe. But you say that when you delete file, that file does not end by default in Trash can, is that so? <jmarciano>MSavoritias[m]1: not that I refer to any freedom issue, I refer to Tramp accessing remote files and variable delete-by-moving-to-trash causing Tramp to attempt trashing remote files, which is all bound to Freedesktop.org but it is no standard just popular adoption <jmarciano>and Tramp accesses many remote systems, definitely not only desktops as in "freedesktop", mostly servers <jmarciano>I know in Hyperbola GNU/Linux-libre much of stuff from Freedesktop is not followed blindly <leoprikler>sneek: later tell jmarciano Guix (the package manager/OS) deletes files [upon gc] using rm, so nothing is trashed. Applications on Guix, e.g. GNOME, may or may not honor XDG trash, as they do in other distros. <sneek>s34n?, pretty sure was seen in #guix 4 months ago, saying: (I think. I can't look at history right now and I'm brand-new to guix). <ani_>How do I translate guix docs? <vits-test>seem that there are .po files that contains msgid + msgstr pairs. <ani_>vits-test: I don't know a lot about translation <ani_>my only experience of translating free software was with mozilla <ani_>where they have some translating strings which we can translate. <vits-test>ani_: try search the git log for "translation" (or f||F rench), then use magit or git diff to see how it was done. ***stikonas_ is now known as stikonas
***civodul` is now known as civodul
<vagrantc>in guix/tests/* there are a lot of tests that check for network ... would it be acceptible to disable the check for network with an environment variable, or some other flag passed to make? <vagrantc>maybe this is a question more appropriate for the list <cbaines>vagrantc, if it's helpful, I'd say go for it. It looks like network-reachable? in (guix tests) is the opportune place to check <vagrantc>and i was also thinking of patching all the tests/*.sh to source common functions, as many of those also import a network test <vagrantc>the context is packaging for Debian, as running network tests during a build are not permitted by policy, but might not be blocked technically during build <vagrantc>although there's also an option to run tests during runtime, in which network may be allowed <cbaines>I see tests/guix-build-branch.sh does a test for DNS, simplifying that and having it work with an environment variable seems fine <cbaines>although, I'm not a big user of the test suite <vagrantc>i'll see if i can't come up with a patch and submit it through the usual channels <jsoo>sneek: later tell lfam: i am sorry it's taking so long to test 5.9 with bpf. If it fails I can send a patch. Might as well do the update and fix bpf later? <lfam>jsoo: I actually updated it already :) It built successfully <sneek>Welcome back lfam, you have 1 message! <sneek>lfam, jsoo says: i am sorry it's taking so long to test 5.9 with bpf. If it fails I can send a patch. Might as well do the update and fix bpf later? <lfam>If it's broken, then we'll fix it <samplet>I’m setting up some build machines, and I’m confused about offloading. <samplet>I have two machines, one offloading to the other, but it seems like the main machine is not doing any builds locally. Is that normal? <cbaines>I think there are ways to not offload things, guix build --no-offload for example <samplet>What happens if I put both machines in “machines.scm”? Will the main machine offload to itself? <samplet>(I would like both machines to be working.) <cbaines>I'm not sure if it would work though, or whether it would get stuck in a loop trying to re-offload the build to itself <cbaines>samplet, out of interest, what are you trying to do with your build machines? <samplet>I think that may have happened. I did see a loop before. I’m trying again now. <samplet>I have a handful of armhf computers, and I would like to use some of them to support the others. <samplet>That is, use a few as PCs and the others as build machines. <samplet>Right now, there are very few Web browsers available for armhf-linux. <cbaines>unfortunately I'm not that familiar with offloading, but maybe someone else can help <samplet>Hmm.... It doesn’t lock up with itself in “machines.scm”, but it doesn’t seem to be building either. <samplet>I tried bumping “max-jobs” and “parallel-builds”, but still no luck. <samplet>I’ll have to try again later. Thanks again! ***midnight_ is now known as midnight
<Bumblehorse>When I install a package as a user, does that information get updated into the operating-systme declaration file? <leoprikler>Guix separates between user-local and system-wide packages like a few other package managers (and non-package-managers) out there. <Bumblehorse>I see so when people describe having completely reproducible systems they have one system wide file and then another for their own application software for the user? <leoprikler>Your system.scm is somewhat different from your profile manifest. <leoprikler>The latter only needs to list packages, while the former also has services, a bootloader, etc. <leoprikler>That said, this plus your channels.scm [the list of Guix channels you used to build your system and profile] are all you need to "copy" your entire state on another machine. <Bumblehorse>Well thank you, the ability to copy a system state so easily is what made me want to try guix <Bumblehorse>But there seems to be a lack of information as to how for those who aren't familiar with it yet <leoprikler>You should find all the information I just told you in the manual, although admittedly it's a bit scattered if exactly that is your use case. <Bumblehorse>One last thing, I just typed "guix pull sudo guix system reconfigure /etc/config.scm" and have been waiting for atleast half an hour for this to finish. Is this normal? <leoprikler>Half an hour doesn't sound too bad for a system upgrade. Remember, that Guix is a source-based distro with substitutions, so you can get your Gentoo "10 years compiling" sweater out of the closet if you still have that ;) <jonsger>it depends on your machine and whether you get substitutes or not, Bumblehorse <leoprikler>There are some performance issues, specifically on HDDs, but trust me, I've seen worse. *jonsger hopes that Miguel and Ludos patches on `guix publish` improve the situation... <maav>jonsger: for small packages you should already see an improvement, but you can always pull a commit from master that hasn't been built yet... and I really need improvements, as half an hour would be delightful sometimes with my machine :) <maav>i want to try some kind of "wait unless nobody is going to build that" option... <maav>saying it out loud I realized that maybe a "guix fetch" command could be a good idea... <lispmacs[work]>hi, I was just wondering if anybody is working on any packages for retro computer emulators (e.g., commodore 64) <zimoun>maav: and the distribution of substitutes via IPFS could be really awesone. The patch set is waiting some love. :-) <lispmacs[work]>I see there are a lot of console editors like the NES, Sega, etc., but was thinking more along the lines of the 70s, early 80 PCs like the commodore 64 <leoprikler>There should be some c64 emulator in emulators.scm, but I can't speak for their qualities since I've so far only used ppsspp on Guix. <simonsouth>lispmacs[work]: I'll be looking soon into adding one of the free TRS-80 emulators. I can't speak for the rest however. <simonsouth>Of course you're always welcome to contribute yourself; adding a package definition isn't that hard and there are plenty of people to help. <maav>zimoun: thanks for the pointer, be sure I'll check it up soon :) <maav>(i was afk), "guix fetch" substitutions from a server/server list <apteryx>maav: great patch set for isssues found when the store is on a btrfs subvolumes! I'll try commenting on it soon. <zimoun>maav: we’ve tried to share all the love about the IPSF via the Outreachy program, but the applicants do not seem interested. <maav>apteryx: thanks a lot, i have to send an update for the locale part, because it has some issues (as using guix.mo instead of grub.mo :( ) <zimoun>‘guix build’ already does some work. Is it not enough? <maav>ipfs sounds good, and gnunet is on my radar too... <maav>zimoun: sure build already is complete, i was thinking out loud to interface only the retrieval from the servers from a command <maav>apteryx: i'm sending it in 5 minutes, and also have a minor change for the patch allowing /boot in a separate partition with / encrypted <maav>(just generated a system with it to do some tests, hehe) <Bumblehorse>What would be the easiest way to install dwm with my custom config.h file? I'm thinking it is with "guix build --with-source=" but what would you guys do?