IRC channel logs


back to list of logs

<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 looks
<lfam>Was it just stopped like that, waiting on the (read)?
<rie>it's still there, btw
<lfam>Something's broken :(
<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 <> if you find the time
<rie>yes I will do that! Glad to contribute something (even if it is just more work)
<lfam>We appreciate it :)
<xelxebar>Threw this question into the void yesterday, but how exactly does the install iso at get generated?
<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
<vits-test>.xz ha-he-huh. In one thread, for sure.
<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?
<vits-test>sneek: botsnack
<vits-test>boys, It returned.
<vits-test>sneek: seen sneek?
<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_>why is it happening?
<ani_>I added new variable r-decon and now trying to build it.
<ani_>it worked with
<ani_>./pre-inst-env guix build -K r-decon
<ani_> this command
<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>and then run emacs from that shell
<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>hmm, EMACSLOADPATH is set that way
<wleslie>ah, hmm
<wleslie>GUIX_PROFILE must be set before sourcing the profile
<wleslie>I did those in the reverse order
<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'
<ani_>efraim: Yup.
<ani_>I got it now.
<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>Trial by CTF
<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.
<shoxy>okay cool thank you
<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
<leoprikler>We have 11.6, 10.13 and 9.6.16
<leoprikler>So yeah, 12 and 13 are currently missing
<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
<cbaines>shoxy, the PostgreSQL service configuration has recently changed, and there's no longer a default package for the service
<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
<leoprikler>Which emacs bug are you referring to?
<jmarciano>the trush stuff
<shoxy>ok, ty, sounds good ;)
<leoprikler>trush? you mean trash?
<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> is a decent resource, but if you want to go "full Stallman" you can also stick to RYF everywhere
<shoxy>RYF isnt necessary. 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.
<jmarciano>leoprikler: yes trash
<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
<shoxy>ok ty ;)
<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 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
<jmarciano>that is why I ask how it is in Guix
<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.
<leoprikler>sneek seen sneek
<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).
<leoprikler>meh good enough
<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
<vits-test>ani_: from that page:
<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_: msgid "Contributing"
<vits-test>msgstr "Содействие"
<ani_>I see.
<ani_>will look into that.
<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.
<ani_>I will look into it.
<vits-test>sneek: botsnack
***stikonas_ is now known as stikonas
<civodul`>sneek is back!
***civodul` is now known as civodul
<civodul>sneek: botsnack
<leoprikler>botsnack sneek so they don't hunger
<leoprikler>sneek: botsnack
<vits-test>sneek: no more It, U're They from now.
<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>er, require 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/ 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?
<jsoo>sneek: botsnack
<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
<janneke>sneek: botsnack
<lfam>Since I am always crowing about the lack of free drivers for wireless hardware, here is a neat challenge about writing free drivers for a wifi/bluetooth implementation:
<samplet>Hi #guix!
<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>yes, I think that's to be expected
<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.)
<samplet>Also, thanks cbaines !
<cbaines>hmm, that's maybe worth trying
<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.
<cbaines>makes sense
<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>No, it gets put into your ~/.guix-profile.
<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>I assume there is a semicolon after pull
<Bumblehorse>yes sorry
<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...
<zimoun>“guix fetch“ what?
<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
<lispmacs[work]>PET, BBC Micro, and such like
<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 instead of :( )
<zimoun>‘guix build’ already does some work. Is it not enough?
<maav>ipfs sounds good, and gnunet is on my radar too...
<apteryx>maav: OK, no worries :-)
<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)
<joshuaBP`>hello guix!
<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?