IRC channel logs

2021-04-10.log

back to list of logs

<Noisytoot> ;; If configure existed it would fail due to tap being missing,
<Noisytoot> ;; as we do not have tap packaged yet, tap is used for tests.
<Noisytoot> ;; This package still works as a dependency of glob and inflight,
<Noisytoot> ;; which are being packaged.
<Noisytoot>Is that good?
<lfam>Yes, that's perfect
<sss2> https://bpa.st/FICA - so it's adding my cxxflags, but it have overrided later by inherited ?
<apteryx>civodul: I've created a ticket about udev to remember about it
<Noisytoot>lfam, I've sent it, although I accidentally sent it to guix-patches@gnu.org, rather than to 47680@debbugs.gnu.org: https://issues.guix.gnu.org/47682
<lfam>Noisytoot: Okay, you can "merge" the two tickets by sending a message that contains "merge 47680 47682" to <control@debbugs.gnu.org>.
<lfam>This control interface is described here: https://debbugs.gnu.org/server-control.html
<Noisytoot>done
<lfam>Thanks!
<lfam>Now you are a debbugs master :)
<PotentialUser-43>hi
<kozo[m]>Yo
<simmon>hi...
<Frosku>Hi
<kozo[m]>Yo
<simmon>join in simmon
<simmon>I'm guix translation.....progress...
<simmon>Is it possible to restart the web service part so that the translated part can be applied?
<simmon> https://guix.gnu.org/ko
*raghavgururajan fell sick 🤒️
<lfam>Oh no! I hope you feel better soon
<raghavgururajan>thanks
<nij>I believe 3.3 of the manual is out of date -- https://guix.gnu.org/manual/en/guix.html#Copying-to-a-USB-Stick
<nij> https://bpa.st/K64A
<lfam>Weird. That sv.gnu.org URL works fo rme
<lfam>For me
<lfam>I guess it's the unquoted question mark being interpreted by the shell
<lfam>I'm surprised it ever worked
<nij>OH indeed
<nij>sorry for my stupid call :-(
<nij>and thanks for testing!
<lfam>It's a mistake in the manual
<lfam>I'm going to push a fix now
<lfam>nij: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b685337c9453ef76e27685ced2ab6b1f31d75395
<lfam>It should appear in your local manual, I think after `guix pull`?
<lfam>And in a few minutes on the "devel" version of the manual, which tracks the master branch: https://guix.gnu.org/manual/devel/en/
<lfam>Thanks for reporting it!
<link2xt>is anyone maintaining kde-frameworks? current version of extra-cmake-modules and kirigami is 5.80.0, but guix contains 5.70.0
<link2xt>I tried building with a new source, but there is a failing test
<link2xt>everything else is 5.80 too: https://ftp.icm.edu.pl/pub/unix/kde/stable/frameworks/5.80/
<lfam>link2xt: There are some WIP branches for plasma and "KDE education":
<lfam> https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-kde-education
<lfam> https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-kde-plasma
<lfam>I don't see any recent activity on the mailing lists that suggests anyone is working on an upgrade
<lfam>It could be as simple as setting up a Guix development environment and doing `guix refresh --type=kde`
<lfam> https://guix.gnu.org/manual/devel/en/html_node/Building-from-Git.html
<lfam>`guix refresh --type=kde --update`, or something like that
<link2xt>interesting, didn't know about guix refresh
<link2xt>I have guix cloned, but tried to update versions manually
<lfam>So, you run it in the directory of the source code, and it tries fetching updates and rewrites the source code for you :)
<lfam>There may be some more work to do before all the packages build and everything works right, but at least it automates a lot of the work
<link2xt>does it make sense to always use ./pre-inst-env like the manual says?
<link2xt>I run basically the same version of guix anyway
<lfam>pre-inst-env is for using the changes in the source code directory
<lfam>So, I would not use it to run `guix refresh`
<lfam>But, then I would test the changed packages with `./pre-inst-env guix build --no-grafts my-packages`
<lfam>Does that help?
<link2xt>hmm, I think pre-inst-env is needed for refresh too
<link2xt>otherwise it fails with "read-only filesystem" error
<link2xt>probably tries to update the other tree, which is used by the system
<link2xt>is there any way to use these updated packages in my system if it works?
<link2xt>should I guix pull from my local tree?
<lfam>Oh, okay
<lfam>link2xt: You can pull from the tree, or you can do `./pre-inst-env guix system reconfigure ...`
<lfam>They will both work, but the pre-inst-env is a little more ad-hoc
<link2xt>I'm running Guix on top of Debian, so `guix system` is not an option. Will pull from the tree then, thanks.
<lfam>link2xt: Oh, you can also do `./pre-inst-env guix install`, or similar with any `guix package` command
<apteryx>lfam: do you have an opinion about making the inputs propagated by default for the go importer?
<apteryx>it seems more useful that way for go libraries
<lfam>Hm, not really
<lfam>If it seems like the right choice, it probably is :)
<apteryx>OK :-) I'm asking, because I'm about to push this: https://issues.guix.gnu.org/47310
<lfam>I looked at some packages to jog my memory and, yes, propagated-inputs seem right. Because, Go "packages" as we conceive of them are basically a bunch of source trees, since dependencies are bundled-by-default
<lfam>I see one that propagates pkg-config... maybe that should be adjusted
***terpri_ is now known as terpri
<Jdaco>Hello, I haven't been able to do a guix pull for a few weeks now. When I try I get a "error: corrupt input while restoring archive". https://pastebin.com/VTJ9Ur0k. Does anyone know how to resolve this?
<lfam>Jdaco: I think this is a bug we fixed a week or two ago
<lfam>Since the bug causes downloads to fail, you'll have to try and try again until it completes, or add the --fallback option
<lfam>After it completes, you need to restart the guix-daemon
<Jdaco>It fails even with --fallback. You're saying if I try over and over that it will eventually go through?
<lfam>I was afraid of that. This type of failure is not considered "fallback-able" in the code
<lfam>Yes
<lfam>For example, you could do `while true; do guix pull && break; done && systemctl restart guix-daemon`
<lfam>Or, however you run the daemon
<Jdaco>Alright, I'll get that going. Thank you
<lfam>Sorry about this!
<lfam>Your errors look like these: <https://bugs.gnu.org/47578>
<apteryx>lfam yeah that's one place where propagated don't make sense (native-inputs); I'm not aware that Go as a way to mark the build only dependencies as such.
<lfam>Well, all dependencies are build-only in Go :) At least the way we use it
<apteryx>so human review of the inputs will still be needed anyway, but at least if the default choice is sane it's a bit less work
<lfam>Yeah
<lfam>Go for it
<apteryx>OK; I'll see how far I can get through generating an RC
<apteryx>lfam: by the way, any reason we release this as 1.2.1 rather than 1.3.0? I'm sure we've added functionality since the last release (I have to go through the release notes, but the go importer is one on top of my head)
<lfam>I don't remember where the actual number came from
<lfam>If I had to come up with a reason, it would be that we haven't done a core-updates cycle since the last release
<lfam>But I don't have a strong opinion about the number
<apteryx>I'm trying to understand the origin of the wip-next-release branch; it was branched off master when?
<lfam>apteryx: Like, when did the branch first exist? Or what's the history of the commits that landed on master?
<lfam>It didn't really use a branching workflow. It was just a few commits that kept being rebased on master until they were done
<apteryx>OK! This was done as the ungrafting efforts, correct?
<apteryx>as part of*
<lfam>No, all it ended up being was time zone updates and removing Qt 4
<lfam>We didn't ungraft yet
<lfam>It was too much to do before April 18, so I guess it will happen as part of core-updates
<apteryx>fine
<apteryx>yes, next we should aim for a core-updates merge
<apteryx>it's long due
<lfam>Yes, definitely
<lfam>Right after the release we should start working on it in earnest
<apteryx>I'm really bad at inspecting branches history with git for some reason
<apteryx>how they relate to one another
<lfam>I think the CI is ready. We'll have better tools than we have in a long time
<lfam>Yeah, it can be hard to understand
<lfam>I think there must be tools that make it easier
<apteryx>OK, so the base is 45dfcdba86 * gnu: diffoscope: Update to 170. (March 22)
<apteryx>and there are 4 commits above that
<apteryx>but these have also been cherry-picked to master it seems
<lfam>Yeah
<lfam>That's how I "merged" the work
<lfam>(I assume you're talking about wip-next-release)
<apteryx>yes; so it's basically a 2/3 weeks old snapshot of master
<lfam>Are you trying to do something with the branch?
<apteryx>I'm thinking if we want it as it is, or if we'll want to cherry pick the various security fixes done on master, or outright reset it to master?
<apteryx>I think there have also been a couple fixes done to master w.r.t. to the bugs marked as blocking the release
<apteryx>I think the QEMU perf warning was one
<lfam>Oh, I don't mean for wip-next-release to be the thing we release. It was just a place to work on these updates, to take advantage of the CI
<lfam>I would take a snapshot of current master
<lfam>I even deleted wip-next-release from Savannah
<apteryx>OK, thanks for clearing that up. I thought that's what I had to work with for prepping the RC
<lfam>Sorry for the misunderstanding
<lfam>I think that there's a few more bugs we want to fix for the final release: <https://bugs.gnu.org/47297>. I'm going to work on those over the weekend
<apteryx>no worries, I haven't followed very well the guix-devel list as of late.
<lfam>mothacehe announced some new features on ci.guix.gnu.org that may help us
<lfam> https://ci.guix.gnu.org/
<lfam>There are jobs for images and tarballs
<lfam>Looking at them, I guess there are still some rough edges
<lfam>I don't see the results for the tarball job, for example
<lfam>So, people can start testing the images now
<apteryx>I clicked on dashboard, it brought me to this page: https://ci.guix.gnu.org/eval/19463/dashboard
<apteryx>if you click that colored circle it brings you to a page with the tarball archive to download
<lfam>We should add the installer image to 'gnu/system/images'. Then I guess CI will build it
<lfam>Ah :) I didn't realize I was supposed to click the dot
<lfam>Oh, the usb and iso9660 images are the installer
<apteryx>cool!
<lfam>qtwebkit: #:parallel-build? #f
<lfam>😭
<apteryx>yikes
<cbaines>morning :)
<Frosku>Morning
<cbaines>o/
<wxie2>Hi
<wxie2>In guix, how can I make script like '/bin/bash' work?
<iyzsong>Hello, Guix!
<cbaines>wxie2, there's a special files service that can create things like /bin/bash https://guix.gnu.org/manual/en/html_node/Base-Services.html#index-special_002dfiles_002dservice_002dtype
<cbaines>wxie2, you can just run it with bash from your profile, and not use the shebang
<cbaines>hey iyzsong o/
<wxie2>Let me check. Thanks.
<iyzsong>yeah, starting build patches..
<raghavgururajan>iyzsong: Thanks for working on gtk4.
<iyzsong>raghavgururajan: yeah, I need more work for GTK4, I'll try and review some your patches for gstreamer first.
<raghavgururajan>iyzsong: That'd be great. Thanks!
<iyzsong>glad to help :)
<raghavgururajan>Looks like leoprikler have sent some cleaned-up patches, for staging.
<iyzsong>yes, I'll build upon staging
<iyzsong>i have some concern about the adding inputs (eg: gtk+ for gsteamer), i'd like to check out what them for and if they're "necessary"..
<leoprikler>Oh yeah, I'll greatly appreciate that you do.
<raghavgururajan>gst has depedency for gtk+, but was missed as it was sliently propagated by some other inputs. So I added them directly.
<raghavgururajan>*it
<iyzsong>I believed that gstreamer shouldn't depends on gtk+, though its plugin is, but let me check now..
<iyzsong>raghavgururajan: turn out gstreamer have an test example depends on gtk+, I think we better skip it, I'll send a update patch for it latter.
<leoprikler>do the examples even do a thing in our tests?
<leoprikler>hmm, looking at the source code it seems they do
<raghavgururajan>I see `Run-time dependency gtk+-3.0 found: YES 3.24.27` during configure phase.
<leoprikler>just because you see it during configure doesn't mean it's a hard dependency
<leoprikler>in particular, it seems it's only used to build that one test example
<wxie2>cbaines The bash method works.
<wxie2>iyzsong I will study the special file service later.
<cbaines>wxie2, cool :)
<iyzsong>yes, by default we have special files for '/bin/sh' and '/usr/bin/env'.
<raghavgururajan>I see.
<WorthListeningTo> https://invidious.xyz/Uun2YhnUNGc
<rekado_>rms spam
<davidl>Hi, Im trying to optionally include #:environment-variables <service-config-option> to the make-fork-constructor in the mysql service. My attempts so far (many) fails. Is there an example somewhere I can look at?
<cbaines>davidl, what environment variables are you trying to optionally set?
<davidl>PATH and some ssl vars
<davidl>PATH needs set to the bin-dir of mysql to be able to run some wsrep_sst_rsync etc.
<cbaines>Is it mysqld running those things?
<davidl>yes
<davidl>You can test making it work by for example starting mysqld with PATH=<path-to-mysqld-bin-dir> mysqld --defaults-file=/tmp/my.cnf
<cbaines>Have you considered wrapping mysqld so that it always has it's bin directory on the PATH ?
<cbaines>or there might be some way of patching this in the code
<davidl>No I haven't, but I wanted to add extra option so that user can set the environment themselves as needed.
<cbaines>Ok
<cbaines>As for the SSL related environment variables, I'm not sure how that fits in with Guix system
<cbaines>Anyway, can you share your latest attempt davidl ?
<davidl>cbaines: yes
<davidl>cbaines: here https://paste.debian.net/1193051/
<davidl>I am running this in separate module renamed to galera so that I can reconfigure with: guix system -L /tmp/galera-mod config.scm
<cbaines>davidl, rather than `(#$@extra-env) I'd put (list #$@extra-env)
<yoctocell>Hi civodul!
<yoctocell>I have some questions regarding downloading and authenticating git repos
<davidl>cbaines: ok, thx Im trying that now
<cbaines>davidl, cool, do say how you get on
<davidl>cbaines: guix system: warning: exception caught while executing 'start' on service 'galera':
<davidl>Wrong type (expecting string): "#<procedure list _>"
<cbaines>davidl, OK, and what is extra-environment set to when you're getting that error?
<brown121407>I like what y'all did with the output of Guix when it's downloading stuff, it's a lot easier to read for normal people now.
<davidl>cbaines: it was set to (extra-environment #~(list (string-append "PATH=/usr/bin:/bin:" #$rsync "/bin:" #$coreutils "/bin:" #$gawk "/bin:" #$grep "/bin:" #$mariadb "/bin:" #$iproute "/sbin:" "/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin" ) "SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt" "SSL_CERT_DIR=/run/current-system/profile/etc/ssl/certs"))
<davidl>cbaines: don't ask me why I had all those things there, please! xD
<cbaines>davidl, Ok, first thing, I think it should be a list of gexpressions that end up as strings, rather than a gexpression that ends up as a list
<davidl>cbaines: mhmm, and how would above thing look like? That is set inside my config.scm
<cbaines>something like (list #$(string-append "FOO=" #$bar) "BAZ=foo")
<cbaines>that'll work properly with the (list #$@extra-env) bit
<davidl>and what would I set the default value to then?
<davidl>just empty list?
<davidl>or would I still do #~'() for default value?
<cbaines>davidl, hmm, I think '() (the empty list) will work
<davidl>cbaines: ok trying that now
<davidl>cbaines: that gives me error: ungexp: unbound variable
<davidl>cbaines: sry, I made a typo!
<davidl>cbaines: Ill try again
<davidl>cbaines: same - error: ungexp: unbound variable
<civodul>yoctocell: tell me :-)
<cbaines>davidl, ah, wrong symbols in my example, it should be #~(string-append
<yoctocell>civodul: I can use 'git verify-tag --raw TAG' to try to verify a tag, and the output it produces is the same as running 'gpgv --status-fd=1 SIG FILE' which 'gnupg-verify' does in (guix gnupg).
<yoctocell>'gnupg-verify' has a 'status-line->sexp' procedure which parses the status, maybe we could move that procedure to the toplevel and create a 'git-verify-tag' procedure which will use it?
<civodul>yoctocell: ideally, you would use update-cached-checkout from (guix git) to fetch stuff, and then Guile-Git and (guix openpgp) to verify signatures (you still need (guix gnupg) to fetch keys)
<yoctocell>civodul: Looking at Guile-Git, there doesn't seem to be a way to get the signature of a tag.
<civodul>yoctocell: see commit-signing-key in (guix git-authenticate)
<yoctocell>civodul: Ok, will take a look :)
<civodul>hmm the difficulty is that you need a keyring
<civodul>well, take a look at tell me how it goes :-)
<davidl>cbaines: samme error I think
<cbaines>davidl, right, have you got a #$ that's not within a #~ ? maybe share the value you're using again
<civodul>we could probably make the ungexp error clearer
<yoctocell>civodul: Why would a keyring be difficult to get? Won't 'current-keyring' in (guix gnupg) get it?
***rekado_ is now known as rekado
<davidl>cbaines: I mean this works, now Im back to one of the old errors that in /var/lib/log_error.log (configured in my.cnf), the galera service just stops abruptly after herd start galera. https://paste.debian.net/1193056/
<cbaines>davidl, I don't know anything about galera, but maybe look at the #:log-file option to make-forkexec-constructor, as that might help gather more information
<yoctocell>oh wait, it needs a <openpgp-keyring> record...
<jlicht>Is it me, or are there several emails on guix-devel that are missing In-Reply-To?
<roptat>just pushed korean now at 100% (-1 string)
<roptat>(for the website)
<nij>Hello! How do I find out what %base-packages evaluate to in my config.scm?
<roptat>you can run a guix repl to find out, give me a minute
<roptat>run guix repl, and inside it type (use-modules (gnu system) (guix packages)) and at the next line ,pp (map package-name %base-packages)
<roptat>nij, ^
<nij>oh yeay thanks :)
<nij>I'm trying to install guix system on an UEFI based machine. My understanding is poor, so fiddling around fails me so far.
<nij>I haven't succeeded in installing archlinux on it before, which explains my lack of understanding.
<nij>Following the manual, I put (bootloader-configuration (bootloader grub-efi-bootloader) (target "/boot/efi")) in my config.scm under (bootloader..
<nij>But there's still an error.. (I have to type it out, just a sec)
<nij>guix system: error: ...-grub-efi-2.04/sbin/grub-install --boot-directory /mnt/boot .. /mnt-boot/efi' exited with status 1: output follows:
<nij>/gnu/store/0jf....grub-efi-2.04/sbin/grub-install: error: /gnu/.../i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory.
<iyzsong>raghavgururajan: hello, i have done a round of review for the gstreamer patches, mail sent..
<nij>Manually typed. I ignored details. If it's needed, please let me know :)
<roptat>nij, weird, I've seen that before, but have never been able to diagnose the issue
<roptat>are you using the installer for 1.2.0, or latest?
<nij>lemme guix pull first..
<nij>hmm not sure. I made my usb disk from the manual.
<roptat>oh, ok, tat should be more or less latest
<nij>It's guix pulling - lemme find out which installer I'm using later.
<nij>Oh, maybe I should disable legacy boot.
<roptat>ah right, if you booted in legacy, grub might be confused
<roptat>did you create (and declare) a partition for /boot/efi?
<nij>mm... no either.
<nij>I created three paritions. sda1~3
<nij>One for swap, one for root, and another for boot.
<roptat>that might also explain it
<roptat>instead of /boot, make it a partition of /boot/efi
<roptat>the kernel is in the store anyway, so there's no point in having a separate /boot
<nij>lemme try :) it's still guix pulling.. taking a long time.
<roptat>yeah, it can take time when the build farm doesn't have substitutes yet
<nij>In the meanwhile, could I maybe ask another question?
<nij>I'm curious how GUIX works, in the example of emacs packages.
<nij>I understand that I can pull emacs packages that are packaged by guix contributors.
<nij>But what if package B and C both require package A, but with different versions?
<nij>Unlike other programs, emacs packages got loaded into emacs memory.
<nij>So different versions of A being load at the same time doesn't sound legit to me.
<nij>Without that, how do B and C work at the same time?
<roptat>no idea for emacs, it probably won't work
<nij>:O some people do use guix to manage emacs packages.. i just can't imagine how.
<roptat>in general though, you can have B and C on your system (profile), because guix doesn't put A on your profile with them
<roptat>B and C refer to A1 and A2 with their full paths which are different
<roptat>I don't use emacs, so I have no idea, maybe someone else will know
<nij>Ay! After turning off legacy boot it seems working (so far!) nicely pulling down stuff ;) Thanks roptat
<apteryx>nij: yeah, Emacs doesn't support multiple versions of a package in the same EMACSLOADPATH; Guix can't do much about it. What you can do is setup different profiles with different versions of Emacs and or its packages.
<nij>apteryx: ah :-( I see!
<nij>Another error from installing guix system.. -
<nij>"Installing for x86_64-efi platform. \n /gnu/store/8j..grub-efi-2.04/sbin/grub-install: error: /mnt/boot/efi doesn't look like an EFI partition."
<roptat>nij, the partition should be a vfat partition, not ext*
<nij>However, in `cfdisk`, /dev/sda1 (which /mnt/boot/efi mounts to) is indeed of type "EFI System".
<nij>Oh
<nij>Lemme try again :) thanks!
<nij>Oh deer it werks <3!
<nij>Hmm.. I created a user in config.scm while I installed. Now it's indeed there, but there's no password for it, so I cannot log in :(
<nij>Unlike root, which happily allowed me log in without a password the first time.
<rhou[m]>I'm creating a package only for guix, what build system shall I use? As guix has me covered in dependency resolution and build environment, but I missing a guix native build system...
<roptat>nij, you'd create a password for root and your user now, with passwd
<nij>roptat: ah yeah!
<nij>Hmm.. running `guix pull` in root returns the error: Git error: the SSL certificate is invalid.
<roptat>do you have nss-certs in your system profile? and is GIT_SSL_CAINFO set?
<roptat>it should be set to GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt, and the file should exist
<la_snesne>wow, I didn't knew korean translation has been done. Its nice to hear, but it's quality looks bad to me(e.g Trasnlating free software to free price software, transaction to connection..) And even made my few translation worse. Maybe i should spend my time to fix those thing.
<roptat>la_snesne, please do :)
<roptat>la_snesne, https://translate.fedoraproject.org/projects/guix/website/ko/
<la_snesne> I'm already working on it. ^^
<roptat>you might want to use the glossary to make sure other translators pay attention to these terms :)
<roptat>(and if you manage to translate the guix component after that, it would be awesome!)
<nij>roptat: I see. The bare-bone config is more bare-bone than I thought..
<roptat>nij, nss-certs should be part of %base-packages
<nij>I've added package nss-certs to my config.scm.
<roptat>oh no, it's not
<nij>Err.. then that's weird.
<nij>Oh ok
<roptat>sorry ^^'
<nij>How do I "enable" config.scm then?
<nij>No worries :)
<roptat>you "reconfigure" (guix system reconfigure /etc/config.scm)
<roptat>it's documented here if you want to read more: https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-system.html#Invoking-guix-system
<nij>I probably go through the manual for a few times.. but I never remember them, and cannot remember where they are located :-(
<nij>I come back to guix this time trying to install "from scratch" ;)
<roptat>well, you managed to do it, so congratulations :)
<roptat>la_snesne, ping me when you're done, I'll update the website (countrary to other translations, it doesn't commit directly to the repo because it could break things, and we don't want to give commit access to an external tool)
<la_snesne>roptat, ok, I'll do that.
<nij>Hmm.. upon `guix system reconfigure`, I kept getting the following error:
<nij>guix system: error: symlink: Permission denied "/var/guix/profiles/system-3-link.new"
<roptat>nij, are you running it as root?
<nij>I tried both normal user and root.
<nij>Oh, when I run that as root, I got another error:
<roptat>you should reconfigure as root, you can't change the system as a simple user :)
<nij> > command: `sudo guix system reconfigure /etc/config.scm`
<nij>guix system error .. //boot/efi doesn't look like an EFI partition
<nij>But I didn't put any "//" in config.scm
<roptat>is it mounted?
<roptat>if not, mount /boot/efi manually, and add it to your config.scm
<nij>Oh.. another noob mistake :(
<lubrito>Hi, I'm an Outreachy applicant. My setup is ready and I would like to know what are the initial tasks for Guix Data Service project, and see what I can do to help.
<cbaines>hi lubrito, good to hear from you
<cbaines>lubrito, the first suggestion I've got is to look at implementing a basic JSON output for the derivation comparison page
<cbaines>lubrito, this is one example of the page, and you can click the View JSON button to see the current behaviour http://data.guix.gnu.org/compare/derivation?base_derivation=/gnu/store/hb1j5p8za9qsn646zbw2gnmp24syhjz3-akonadi-20.04.1.drv&target_derivation=/gnu/store/kr9i9dvp0mxjqjz74gf5p6if8xkbsbrn-akonadi-20.04.1.drv
<cbaines>the relevant controller procedure is here https://git.savannah.gnu.org/cgit/guix/data-service.git/tree/guix-data-service/web/compare/controller.scm#n564
<lubrito>cbaines ok, I'll be looking for that now, thanks
<cbaines>lubrito, great :)
<nij>How to let /dev/sdaX to be mounted automatically in config.scm?
<davidl>cbaines: I found the error now! I had accidentally switched to :user mysql instead of :user galera in the test module's make-forkexec-constructor procedure. Now Im just running a final test, then Ill submit a patch
<cbaines>davidl, OK, glad you figured it out
<roptat>nij, you declare it in the file-systems field
<davidl>cbaines: it was thanks to you, I used the :log-file thing. Thank you!
<cbaines>davidl, you're welcome :)
<roptat>nij, here's an example: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/examples/desktop.tmpl
<roptat>nij, see line 39
<nij>Hmm. I can check the UUID from `cfdisk`. But it's tedious to write them down. Can I label, for example my boot partition, as my root partition?
<nij>I used `mkfs.ext4 -L my-root /dev/sda2` to label my root. However, my boot partition is not of ext4 fs.
<roptat>not sure
<roptat>it's only 8 characters though, not so hard, is it?
<nij>swap's is longer
<nij>I'm also thinking of making a config that will work right away on all of my machines.
<nij>So I don't have to type in its UUID manually everytime.
<roptat>mh... not sure, but I think you can simply say (device "/dev/sda2")
<bdju>just had a friend try gajim on guix and he hit the same issue as me ( #47611 ). are some people not having the problem?
<bdju>not sure how many guix gajim users there even are
<nij>I followed line #69 to setup xorg, but there's an error - https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/examples/desktop.tmpl#n69
<nij>ice-9/boot-9.scm:1669:16: In procedure raise-exception:
<nij>In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #<procedure keyboard-layout (name ..)>
<roptat>nij, that's because the last keyboard-layout on that line refers to the keyboard-layout field on line 16
<nij>Ah oh yay indeed!
<BlackMug>hi there
<BlackMug>roptat finally i have installed guix on qubesos, man i needed to work on the config.csm the default one is just crazy for MBR installation.
<BlackMug>i have installed ungoogle-chromium but i cant see it in the menu xfce , nor i can run it from terminal
<roptat>BlackMug, you probably need to reload something, or even reboot
<roptat>oh not even from the terminal?
<roptat>how did you install it?
***PotentialUser-67 is now known as constfun
<constfun>Hello. It appears I have the same issue as this user when trying to configure xmonad: https://issues.guix.gnu.org/issue/47335 and get 'module import XMonad not found' xmonad works similar to dwm in that it recompiles the config file. I don't think xmonad doesn't recompile the binary, but only the config file which it then loads dynamically. I don't
<constfun> know this for a fact.
<constfun>Are we doing something wrong or is this a bug?
<nij>`startx` fails to run X, as "/gnu/store/w2rms..xinit-1.4.1/bin/X": no such file or directory.
<nij>It wants me to make sure that "...1.4.1/bin" is in the path. Should I add that into the path? Or there's a more suitable way?
<roptat>nij, does xinit work better?
<nij>Yeah.. I remember there's a hack in the mail group that works with this.. am still trying it
***bonz060_ is now known as bonz060
***iyzsong- is now known as iyzsong
<lubrito>cbaines hi, how do I get to Compare Derivations page through my local server? I can't find it.
<cbaines>lubrito, I'd suggest finding a link from the package derivations comparison page.
<cbaines>So look at the revisions for the master branch, and click Compare, then click Compare package derivations
<lubrito>i tried, but i got this error: wrong-type-arg
<lubrito>string-splitWrong type argument in position ~A (expecting ~A): ~S1string#f#f
<cbaines>there might not be any package derivation changes between those two revisions, so you might need to try a few different revision comparisons until you find one that works
<cbaines>lubrito, also, does the following path work for you locally? /compare/derivation?base_derivation=/gnu/store/kjpvrv5xwwb4g0f8zsj8z40b85fapvqz-perl-net-patricia-1.22.drv&target_derivation=/gnu/store/wq5p9jyvdwhwvqigh7rz3l2wshmkg3l0-perl-net-patricia-1.22.drv
<lubrito>ok, I got one that works
<cbaines>great :)
***beckett.freenode.net sets mode: +o ChanServ
***sneek_ is now known as sneek
<lfam>`git describe` gives me a weird value for recent commits
<lfam>E.g. `git describe 94f03125463ee0dba2f7916fcd43fd19d4b6c892` gives bootstrap-20190815-28936-g94f0312546
<lfam>It would be nice to have a reference that included the most recent version tag
<lfam>Does anyone how to make one?
<lfam>Oh, I learn about the --candidate option
<lfam>`git describe --candidate 1` from that commit gives `v1.2.0-75109-g94f0312546`, which is perfect
<eriklovlie>when iterating on a new package definition that has a lengthy compilation step, what's the usual way to speed that up? ccache? or perhaps just making a branch in the source repo and hack the makefile to produce some dummy files? Anything more clever (i.e. easier)?
<eriklovlie>or I could add the dummy files in the package definition (since it's just guile after all)
<eriklovlie>in a temporarily replaced build phase
<lfam>eriklovlie: There's no magic bullet here :)
<lfam>Depending on what you're trying to iterate on, you could build the package with the --keep-failed option, and then go to the build directory, source the environment variables file, and attempt whatever you want to try "by hand"
<lfam>The execution environment won't be identical to what exists in the Guix build container, but it's similar
<eriklovlie>yes, I found that section in the manual, and that is super helpful to debug the actual build. However now the build works but my guile doesn't :p
<eriklovlie>but I can have this kludge temporarily in the package definition I guess:
<eriklovlie>(eh, well, pastebin error... anyway, (modify-phases blabla copy some mocked files from my home dir to the source dir to pretend the build completed)
<lfam>We recommend <https://paste.debian.net>
<lfam>Is it the Guile package you're working on?
<eriklovlie>yes, it is a package for a tool that takes ages to build, and it is my first guix package
<lfam>I meant to ask eriklovlie, were they working on the package that provides `guile` itself
<lfam>Anyways, seems not
<nij>Hello! Anyone had luck using stumpwm with Guix System? I successfully started X and stumpwm, and saw the first message of stumpwm. And then my machine hangs.. I cannot even switch tty by C-A-F2..
<lfam>I see some recent bug reports about stumpwm
<lfam>It may be that it doesn't work, idk
<nij>lfam thanks for that info!
<nij>I should find a backup wm to safely fall back on.
<lfam>Well, I guess the reports were on help-guix, and not technically bug reports
<lfam>Nevertheless
<nij>Hmm so now I'm stuck with the tty without a working wm. The font size is very small. Before I start fixing other issues, can I make the font size larger?
<lfam>I hope someone has an answer! I have no clue
<nij>Hmm.. I just tried dwm, and encountered the same thing.
<nij>I started X and dwm successfully. I can the workspace indicators.
<nij>I can see the cursor centered.
<nij>But I cannot move anything. I cannot go to another tty by C-M-F2.
<nij>Something must be wrong about my X.. I'd guess, on my new machine.
<marusich>Hello, Guix!
<marusich>cbaines, the guix-build-coordinator built successfully on my powerpc64le-linux machine!
<marusich>I'm not sure what the next steps are. I think it would be nice to set up my machine to automatically build things. It doesn't have to be part of the build farm, though.
<nckx>nij: Not your main issue, but to set a larger console font, you can use ‘setfont sun12x22’ (that's an ugly one, but it's short and easy to remember :) More fonts in /run/current-system/profile/share/consolefonts/.
<nckx>+ Morning, Guix.
<marusich>morning!
<nij>nckx: Oh yay that saves my eyes :)
<nij>But it's indeed ugly. Is the default font terminus? Why isn't it there in the folder?
<nckx>The default is just... the default (IBM?) VGA font? I guess? Not sure if it has a name.
<nij>Oh terminus is called Lat2-Terminus16 <3
<nckx>nij: Terminus isn't the default and I don't think it's built into our linux-libre kernel. If you install font-terminus it provides more psf fonts in .../share/consolefonts.
<nij>But it's very small
<nij>Oooops.. my sin has been disclosed.
<nckx>Bigger ones shipped separately ☝ :)
<nckx>Meh, I build my own kernel too, yet I don't use any naughty bits. It's no sin.
<lfam>Software freedom gives us the freedom to use whatever software we prefer
<nij>I thought it's considered a sin on #guix and we should not talk about it ;) I'll keep quiet.
<lfam>nckx: If you hadn't noticed, I scrounged up a CVE ID for us
<nckx>And Guix makes it feasible to do so. Killer combo.
<lfam>nij: We should not recommend non-free software here :)
<nij>nope, there are absolutely bad
<nij>they*
<Noisytoot>When I load the prism.py script from WeeChat from Guix it fails with: ModuleNotFoundError: No module named 'math'
<nckx>lfam: I just did. Sweet, thank you. I wish I cared more/at all, but that's no diss of your effort.
<nckx>I'm just dun.
<lfam>That's fair
<lfam>Most projects like ours gave up after they stopped assigning CVE IDs via oss-sec
<nij>Font size issue resolved. Lesson learned. Thanks :-)
<nckx>Happy I could help with one thing.
<nckx>I don't recognise your main issue.
<nij>Now I should really resolve this - when I start x, stumpwm and dwm both started correctly. But then my whole system freezes - I cannot even switch console by C-M-F2.
<nckx>That one.
<nckx>Noisytoot: Sounds like a missing {propagated,} input. Is that script part of our weechat package proper?
<nckx>(OTOH something called ‘math’ may be a built-in thing, and it's a sign of a badly broken Python -- I don't speak it.)
<cbaines>marusich, that's good :) are you looking to just build things to populate your own store, or to serve substitutes somewhere?
<Noisytoot>nckx, It isn't part of the package, and "math" is in the standard library
<Noisytoot> https://weechat.org/scripts/source/prism.py.html/
<nckx>Shows how much Python I know.
<nij>O right. I will come back later and ask. Basically stuck here ;)
<nij>Not even the num lock is working.
<nij>I put in `~/.xinitrc`: `exec stumpwm \n sleep 10 \n pkill -9 stumpwm`.. and still nothing happens. It starts stumpwm, and freezes.
<BlackMug>roptat guix install ungoogle-chromium
<BlackMug>lfam thanks, manual installation worked but needs scheme work for the default config.scm to make it work
<roptat>arg, my server doesn't boot :/
<roptat>I'm trying older generations (even one from more than a year ago that I know used to boot), but they're all stuck at "starting kernel..."
<lfam>BlackMug: I'm glad to hear something worked, although I don't remember the context...
<nij>I now suspect my keyboard inputs are all ignored by xorg after starting.....
<BlackMug>lfam no need to remember just thanks :0
<BlackMug>:) *
<BlackMug>roptat ah yes i needed to reboot guix to make ungoogled-chromium readable from the distro
<BlackMug>i can assure that after installation i cant even run from terminal
<BlackMug>this is normal behavior?
<nckx>What does ‘readable’ mean here, exactly?
<nij>OH! How do I load %default-xorg-modules?
<nij>
<nckx>Well, they're used by default, where used means that they're ‘present’ for Xorg to load them if it thinks it needs to. So unless you're overriding the default you shouldn't need to care. Can you share your system configuration file?
<nckx>As is tradition I will now go AFK after asking a question :) But I'll return.
<nij>Lemme see.. this time I used the barebone template.. so perhaps it's really missing.
<nij>How do I share a file in a bare console :O...
<nckx>nij: Try ‘guix install wgetpaste’.
<nckx>o/
<BlackMug>nckx installed ungoogled-chromium
<BlackMug>nothing showing in the icons nor in the terminal
<BlackMug>i mean when i type ungoogled-chromium in the terminal
<BlackMug>but after restarting the system it showed up
<nij> https://bpa.st/XGOA
<nij>nckx (sin fully disclosed)
<lfam>BlackMug: I guess the icon thing is expected, although not desired. It would be available from the terminal immediately, but maybe something isn't set up right
<lfam>I mean, not set up right on your system.
<lfam>When I install packages, they are available immediately in my terminals
<BlackMug>i think installing guix with xfce using manual installation path is a mess
<BlackMug>i have more worst bug than this
<lfam>What else went wrong?
<BlackMug> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=47687
<BlackMug>this is until this moment happening
<lfam>We are going to make a new release next week. It would be great to fix problems...
<BlackMug>oh thats great, would be happy to see improvements fixing manual installation i have already opened tickets about that
<lfam>I advise you to share your config.scm in the bug report. Otherwise, it's unlikely anyone will try to reproduce the bug
<lfam>You should also include the output of `guix describe`
<BlackMug>ok just normally i copy thing from the config or special commands needed to generate a report about the machine
<BlackMug>in qubes for example simple command will generate a report about the machine info, not sure if something similar available for guix
<nckx>nij: OK, I'll build it here. You should remove ‘xorg-server xf86-input-libinput xf86-video-fbdev xf86-video-nouveau’ (perhaps also xinit) from your packages, though. They are at best useless there, at worst they complicate or even break things.
<nij>nckx: thanks for helping out!! I will give a try :)
<lfam>BlackMug: Well, that is what `guix describe` is. Along with config.scm, it should be enough to reproduce your system
<nckx>BlackMug: The two things lfam listed are that.
<lfam>"You should do A and B". "No, I prefer to do B and A"
<lfam>We should advertise `guix describe and config.scm` more prominently, somehow
<lfam>It's a nice feature of software "forges" that you can make templates for bug reports
<nij>WAT?! guix describe + config.scm = whol esystem?!?!
<lfam>More or less nij. It's not really possible to recreate partitioning
<lfam>s/possible/feasible
<lfam>There is also /run/current-system/provenance, which is supposed to help aggregate this info
<nckx>BlackMug: ‘guix package --list-installed’ can also be useful, although it's usually not. It really depends on the nature of the bug.
<lfam>That stuff also doesn't take into account what users do. It's just the system level
<BlackMug>nckx i will provide as well no problem, anything that might help issues specially like this one
<nckx>Stupid users, ruining perfectly good systems by trying to use them.
<lfam>Heh
<lfam>I prefer "unruly"
<lfam>Installing Guix from 1.2.0 feels excruciatingly slow, since substitution was pipelined
<nckx>That's not how you'd expect a sentence ending like that to start. I missed the news though.
<nckx>What does pipelining do and what was the aim?
<lfam>Substitution has sped up *a lot* since 1.2.0
<nij>I'm typing lots of "GUIX_PROFILE=... . "$GUIX_PROFILE..." now.. is there any reliable way to save the work?
<nckx>Ooh, got you.
<lfam>nij: Can you explain why you are doing that?
<lfam>Like, what are you trying to save?
<nij>I don't want to keep typing that..
<lfam>But why are you typing it?
<nij>Well.. I have a <unspoken>-channel
<nckx>nij: Type it once and use C-r to yank it from your history the next time?
<nij>and whenever I `guix pull` without that, it says there's no code for that <unspoken>channel
<lfam>Huh, I figured this was all handled automatically
<lfam>Isn't that the point?
<nij>nckx: OH! Didn't know that trick before :)
<nckx>Welcome to this half of your shell-using life.
<vagrantc>armhf substitutes are still pretty much not happening?
<lfam>Not at all vagrantc
<lfam>We stopped building them several months ago
*vagrantc is trying to upgrade an armhf system that hasn't been updated since october
<lfam>Unless someone steps up to provide enough build machines, I don't think it will come back
<nij>nckx: wait.. that's just on guix right?
<nckx>C-r? No.
<nckx>It's a standard bash thing.
<lfam>vagrantc: At this point, there are probably substitutes only for core packages. Almost everything else has changed
<lfam>After the next core-updates cycle, armhf on Guix will be done
<nckx>Well, inspired by emacs, I guess.
<vagrantc>lfam: ok, somewhere on my back-but-not-backmost burner i'll set something up for armhf :)
<lfam>Maybe we can get some powerful armv8 machines that support aarch32, but it's extremely low priority
<vagrantc>maybe start by providing substitutes for myself, at least, and then make them publicly available
<lfam>Like I said, someone will have to volunteer to handle it
<lfam>Yeah, that will be breat
<lfam>great
<nij>nckx: o i see, my zsh didn't have that by default
<lfam>It doesn't seem like many people were using Guix on armhf, since there have been hardly any complaints. And there's no powerful armv7 hardware coming in the future...
<lfam>I'd say the platform is dead for a build-from-source distro
<vagrantc>yeah, i managed to get Guix System installed on an apm mustang (8-cores, 16GB of ram), which is also 32-bit capable, and i'm running some 32-bit virtual machines for debian's reproducible build infrastructure on the same hardware
<lfam>That's great
<lfam>Hopefully ALTRA can do aarch32, but I don't know
<vagrantc>so i could probably set it up to at least build the packages i care about and through some wirdguard VPN set up a caching proxy
<vagrantc>lfam: highly doubtful
<lfam>Yeah, I doubt it too
<vagrantc>lfam: basically all the new chips don't
<nckx>nij: I always forget some people haven't upgaded to bash yet. (Weird, I've always considered zsh a maximalist grab-bag and assumed it would have grabbed that feature from bash. Erps.)
<lfam>And the market for capable hardware is still extremely tight
<nckx>nij: Eh, how do you start X?
<lfam>I'm not sure that anything is actually available for sale
<lfam>Zsh definitely includes C-r
<nij>nckx: I removed x related stuff in config.scm, reconfigured, and rebooted. Still the same problem.
<lfam>I use it constantly
<vagrantc>every once and a while i toy with "fish" and eventually come back to "bash" because decades-old habits are hard to break
<nij>nckx: This is how I start x: https://lists.gnu.org/archive/html/help-guix/2018-07/msg00080.html
<nij>It worked for me a few months ago. Life got busy, and I haven't touched guix for a while.
<lfam>I don't even see used hardware that is considered obsolete for sale, like the mustangs
<lfam>Maybe we still have several years to go, or maybe it won't ever happen
<lfam>Maybe the future is 100% cloud
<vagrantc>lfam: well, i've got ~4 mustang boards, but i don't think i have the bandwidth or power to host all of them for guix
<nij>nckx: so tldr, I run this script after logging in: https://bpa.st/YA5A
<nckx>nij: Oh, right, hm. I guess I'd need at least your ~/.xinitrc file, but this is not the quick ‘guix system vm nij.scm’ I'd budgeted for.
<nij>with my ~/.xinitrc having "exec xterm"
<nckx>OK.
<vagrantc>lfam: not including ones i already have in service :)
<lfam>Riht
<lfam>Right
<nij>I've tried xterm, stumpwm, and dwm.
<lfam>If we can't get the hardware I had in mind, I could host a mustang
<nij>All of them behave the same.. so I think my keyboard lost connection to my machine while X starts.
<lfam>I'd rather host something newer, but I'm not sure they actually exist
<vagrantc>right
<vagrantc>i *think* the synquacer *might* be a purchaseable newish option that can do 32-bit
<nckx>nij: It surprises some people but ‘startx’ and similar on Guix is not something that's well-supported at all. It's not the baseline low-risk try-this it is elsewhere. Now I'm a lot less surprised you're seeing weird bugs.
<vagrantc>slow cores, but 24 of them :)
<lfam>Can it actually work as a builder though? It's 24 A53 cores with a TDP of *5 watts*
<lfam>It seems... extraordinarily slow
<lfam>I'd guess that 4 x A72 from e.g. Marvell would run in circles around it
<vagrantc>lfam: one of the debian arm folks rebuilt all of debian with one in a few weeks ...
<lfam>Oof
<Noisytoot>24 is lots
<Noisytoot>I only have 2 cores
<lfam>It's like 24 toy cars, instead of 1 real car
<lfam>It's not that much
<lfam>You can't carry your groceries on the toy cars
<nckx>nij: I still think ‘guix package -i xinit xorg-server xf86-input-libinput xf86-video-fbdev xf86-video-nouveau’ is... odd. We have a procedure that creates a startx script ‘properly’ with those.
<lfam>I'm wary of adding more weak machines to our distributed build farm, because the strategy of "host a bunch of weak machines in developers' homes" has never been effective for us
<lfam>The uptime is maybe 50%
<nckx>But I'll defer to someone who got it to work.
<lfam>We really need to focus on getting a small number of powerful machines
*nckx forgot what that procedure's called.
<nij>nckx: what's the
<nij>o never mind
<lfam>The aarch64 machines have an uptime of ~33%, since we were given 3 of them, and only one of them is used in the build farm
*nij thinks: HMMM if not startx, what do GUIXers use to start x?
<lfam>If somebody donated the Synquacer boxes, we could try it, but it's probably not a great use of funds
<vagrantc>lfam: guess it wasn't just on the synquacer, but: https://lists.debian.org/debian-arm/2019/01/msg00000.html
<lfam>That makes sense, vagrantc
<lfam>I'd guess the Synquacer contributed very little :/
<lfam>Do you know what the "Seattle" is?
<vagrantc>lfam: that wasn't the impresion i got talking to steve about it was ... said they were actually pretty capable
<vagrantc>lfam: i think seattle is the same processor in the overdrive's y'all have
<lfam>Okay, I shouldn't second guess you. It's just surprising that a 5 watt SOC could offer much performance
<vagrantc>you have to schedule your builds to be very parallel ... e.g. more builds with fewer cores rather than fewer builds with lots of corew
<lfam>By the way, if you ever want to get rid of some of your machines, I might be interested in buying. There's not much of a used market...
<vagrantc>lfam: they're not for sale, have to go to support free software projects :)
<lfam>Yeah, compilation has long and slow single-threaded parts like ./configure, so you also need to run multiple jobs
<lfam>Well, that's why I'd want them
<vagrantc>those were the terms that they landed in my hands :)
<lfam>There's almost nothing available at retail and these machines almost never hit ebay
<lfam>It seems like you have to have connections to the hardware companies or be connected to the Linux Foundation to get them
<nij>nckx - OK I'm burnt out with guix today (many hours). Thanks for all your help :) I will come back next time.
<cbaines>I've got the machines behind guix.cbaines.net building armhf-linux stuff as well as aarch64-linux stuff now, there's still a way to go, but the substitute availability is creeping up
<lfam>And, it doesn't seem like the situation will improve soon, since the semiconductor market has imploded
<cbaines>I want to work out if there's any big blockers to using aarch64 + x86_64 hardware for armhf-linux builds, and I haven't found one yet
<vagrantc>yeah :/
<lfam>So... if you have anything sitting idle, I could take over the work of integrating it into our build farm
<vagrantc>cbaines: apparently the x86_64 emulation really crashes hard
<vagrantc>lfam: yeah, i don't think i can use all these boards
<lfam>cbaines: I spent some time yesterday retrying emulated aarch64 build failures on real hardware for ci.guix.gnu.org
<lfam>For example, qemu-minimal failed its test suite under emulation
<lfam>But, it worked on an Overdrive
<vagrantc>which becomes a nasty issue, as substitutes don't get re-tried
<lfam>Yup
<cbaines>that's the thing with the Guix Build Coordinator, as automatic retries on native hardware can be enforced
<vagrantc>if there was a "build first on x86_64, fall back to aarch64 on any failure" that might be interesting
<lfam>It's interesting that you don't have trouble in your farm
<lfam>It would be amazing to have "retry on real hardware", especially once we have more machines
<cbaines>when there's a armhf-linux or aarch64-linux build failure, some retries happen automatically, and some of those are targeted at real hardware
<marusich>cbaines, I guess I'd like to know how to do both, but for now it would be nice just to be able to automatically build things and keep an eye on what breaks.
<vagrantc>lfam: i'll try to get a couple of these boards roughly tested with an eye towards sending them your way sometime
<lfam>Okay
<cbaines>lfam, vagrantc excuse the quote escaping, as this is from a bash script, but this is the fancy code to get some retries to always happen on native hardware https://paste.debian.net/plain/1193135
<lfam>I'm thinking about buying this: https://www.ebay.com/itm/Solidrun-Marvell-Macchiatobin-1-3/124671484700?hash=item1d06ffe31c:g:2MIAAOSwhjlgbhMZ
<vagrantc>lfam: it'd just be boards with CPU and ram, takes atx power supply, mini-itx form-factor
<lfam>It's the "single shot" variant, which runs at 1.6 GHz instead of 2.0 GHz, but it could be a good deal if the price stays low
<lfam>Okay vagrantc
<lfam>We'd be able to buy enclosures and power supplies
<vagrantc>i'll also try to get the firmware all upgraded, as i just figured out how
<lfam>Another thing to test is to boot with linux-libre (like with the Guix installer) and check if the network ports are operational
<lfam>As long as we can do USB -> ethernet, it's okay, but still good to know about
<lfam>Some of the high-end aarch64 networking SOCs have special networking drivers
<vagrantc>lfam: have Guix System running linux-libre on at least one of them and ethernet works
<lfam>Alright
<vagrantc>lfam: pxe boot seems to require several retries sometimes ... and haven't consistently tested all three ethernet ports, though have occasionally used multiple
<lfam>Would only need one
<vagrantc>figured :)
<cbaines>marusich, the easy way of doing that would be to connect to an existing coordinator instance, maybe my test one at guix.cbaines.net or the one now running on bayfront? You could also run your own coordinator instance, but that would require additional work
<lfam>Like, I'm not sure if the Honeycomb's networking is supported at all on linux-libre, but I'm still interested in acquiring them as build machines. We really only need the CPU and storage to work out of the box
<marusich>cbaines, would an existing coordinator instance build things for powerpc64le-linux?
<lfam>Do you have any idea about that cbaines? If any of the ethernet ports on the Honeycomb will work with linux-libre?
<cbaines>marusich, it's just a matter of submitting those builds, which isn't that hard
<marusich>I know basically nothing about the guix build coordinator. What should I read first to get an idea of what to do? How do you "submit those builds"?
<cbaines>lfam, nope, no idea, I still haven't had any news, but hopefully I'll be able to find that out at some point
<lfam>Alright
<lfam>Thinkpenguin sells USB -> ethernet adapters, which will suffice
<cbaines>marusich, the Guix Days video is quite detailed, I'm not sure if that's what you're looking for though https://xana.lepiller.eu/guix-days-2020/guix-days-2020-christopher-baines-guix-build-coordinator.mp4
<lfam>This email summarizes the state of aarch32 support on 64-bit CPUs
<lfam> https://lists.debian.org/debian-arm/2018/06/msg00062.html
<marusich>thanks! i'll take a look
<lfam>Very helpful
<cbaines>marusich, the Guix Build Coordinator pairs nicely with the Guix Data Service, which can provide information and substitutes for derivations, and there's an included script to submit builds from a Guix Data Service instance, so it looks something like: guix-build-coordinator-queue-builds-from-guix-data-service --system=x86_64-linux --system=i686-linux --system=aarch64-linux --system=armhf-linux --system=i586-gnu ...
<cbaines>doing builds for powerpc is just a matter of adding --system=powerpc64le-linux
<vagrantc>lfam: i've also heard good things about macchiatobin, so i'd say go for it, fwiw :)
<lfam>It definitely depends on the price for me
<lfam>This would be something I buy for myself, not on behalf of Guix
*vagrantc nods
*vagrantc has been fighting with an riscv64 board ... because arm is getting too straightforward
<lfam>Which one do you have?
<lfam>I tried getting some BeagleV machines for Guix but they didn't select my application
<Noisytoot>Does Guix support RISC-V?
<vagrantc>not yet
<Noisytoot>What about armhf?
<lfam>Technically, but we don't build substitutes for it anymore
<BlackMug>lfam nckx ok check now https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47687
<vagrantc>lfam: polarfire icicle kit ... will have a hifive unmatched w/ 16GB of ram if ... they ever get produced
<Noisytoot>lfam, Why?
<vagrantc>Noisytoot: don't have working infrastructure
<lfam>Noisytoot: A combination of lack of suitable hardware and lack of anybody trying to make it happen
<vagrantc>and that
<lfam>And, lack of users, from what I have seen
<Noisytoot>I have an armhf computer!
<lfam>I count 3 users :)
<vagrantc>guix is not a exactly a great distro for slow computers
<lfam>Yeah, that too
<lfam>Plus, the architecture is not being developed anymore, as far as I can tell. So, no future
<Noisytoot>What about the ThinkPad X200?
<Noisytoot>lfam, Lots of computers still use it
<vagrantc>though weirdly i was partly drawn to guix because it allowed for more flexible packaging around core firmware, kernel, bootloader, etc.
<lfam>Yeah, but already 64-bit ARM is more widely available and cheaper than 32-bit
<vagrantc>yeah, 32-bit arm is not even really on life support in upstream linux
<Noisytoot>Then you have to get a new computer
<lfam>Guix isn't ever going to run on the 32-bit co-processors that are scattered across a motherboard
<vagrantc>lfam: let's not forget more performant :)
<lfam>The X200, despite being 13 years old, is still faster than almost any 32-bit ARM computer
<pkill9>not as power efficient though
<lfam>It's a shame to abandon all the 32-bit SBCs that people own, but somebody needs to actually try to maintain the platform in Guix
<lfam>Yes, and also much heavier pkill9
<lfam>On the other hand, saving a few watts during operation will never ever overcome the energy spent producing the new computers
<lfam>It's always better to keep an old computer running than to chase power-efficiency gains every few years
<lfam>I mean, from the perspective of saving the earth
<lfam>These disposable SBCs are an environmental disaster
<BlackMug>lfam so you think supporting 32bit should be kept?
<lfam>Yes, it *should* be kept. But if nobody does the work to keep it, it will go away
<vagrantc>it would be good if someone could do the work of keeping the 32-bit architectures working...
<BlackMug>lfam better to go away and to be honest i hope no body waste his time on supporting them
<lfam>Well, you're in luck. Nobody is spending his or her time on it
<vagrantc>heh
<vagrantc>other than when i get the foolish urge to boot one of my armhf systems :/
<vagrantc>but that's not the kind of work needed
<lfam>I mean, we welcome the help :)
<BlackMug>lfam nice lol
<vagrantc>although, getting guix system on the mustangs, and figuring out how to run 32-bit VMs on those ... did make me think about it :)
<lfam>We could keep it going for a couple years more at least, if we were building for it
<pkill9>yea
<lfam>I think that upstream software support will wither away quickly though
<pkill9>so much e waste
<vagrantc>indeed
<lfam>It seems like upstreams only actually test on 64-bit
<pkill9>it's mostly for phones anyway
<BlackMug>32bit announced to be deprecated from many distro/projects long time ago
<pkill9>and smartphones are just bad for your mind
<pkill9>they have their benefits but, meh
<lfam>Are any phones still being produced on 32-bit SOCs?
<pkill9>ok i changed my mind about them being bad for the mind, i'm just being miserable lol
<lfam>I can relate
<lfam>They are the dominant computing platform, so it's important that the free software movement pay attention to them
<pkill9>like most consumer computing, they are terrible in terms of waste
<lfam>Definitely
<lfam>My phone's NAND has gotten super slow after only 18 months. It's really disappointing
<lfam>I was hoping to keep it for 3 years
<BlackMug>android or linux phone?
<lfam>It's a Nokia
<lfam>Android
<lfam>On the other hand, everyone I know with an iPhone can keep using it for at least 5 years, no problem
<BlackMug>replicant or grapheneos or which one?
<lfam>Regular Android
<lfam>I need it to just work
<lfam>It's part of the Android One program, so it actually gets updates
<vagrantc>hrm. something in one of the test suites needed to run guix pull on my veyron-speedy ... triggers a kernel panic. yes, armhf ... poor armhf. not worth trying anymore :/
<lfam>Oof
<lfam>That's a shame
<BlackMug>lfam you are still considered sinner
<lfam>That's suppposed to be a really good platform for software freedom, right?
<lfam>From a christian perspective, we are all sinners BlackMug.
<lfam>It's a really weird thing to say, though
<BlackMug>lfam thats why im happy to be semitic (literally descended from Abraham pbuh))
<lfam>What luck!
<BlackMug>i dont know the sin in the church of emacs how it will be forgivable
<BlackMug>using free software shower system lol
***theruran_ is now known as theruran
<vagrantc>so, i was meaning to upgrade u-boot to 2021.04 soonish ... should i wait till after the next release?
<lfam>I don't know vagrantc, should you? :)
<lfam>What are the trade-offs?
<vagrantc>newer version is shinier! ... but also odds it might break a platform or two, given history
<vagrantc>or might just work fine
<nckx>I considered it but lacked bcourage.
<nckx>-b
<lfam>Maybe it also adds some new platforms? :)
<vagrantc>might also fix a platform or two that nobody noticed was broken
<lfam>Sounds like a wash