IRC channel logs


back to list of logs

<drakonis>trisquel is very sane next to parabola and hyperbola
<drakonis>truly impressive
<drakonis>this is a pleasant sight
<nckx>dstolfa: Best-effort is fine. And your effort so far sounds very best indeed.
<civodul>apteryx: yay!
<solene>hyperola has plans to move to OpenBSD, I'm curious to see how it will go
<dstolfa>nckx: alright, i'll wait to see their response and keep poking around. if things seem fine i'll order one of the dongles and try it out on my laptop when it arrives (approx 1 month from now, hopefully). i'll try building it by adding _Static_assert to everywhere that blobs might be included to see if the compiler hits it or if it really is compiled out
<solene>(it's old news )
<dstolfa>if so, i'll see how it could be packaged up for guix
<drakonis>that was disappointing.
<nckx>dstolfa: The other main thing is whether the hardware actually works without giving it firmware. I don't think it makes sense to add it untested anyway.
<drakonis>they posted pacman to it and called hyperman
<dstolfa>nckx: agreed
<drakonis>its like doing debian/kbsd
<drakonis>grub is blacklisted too
<dstolfa>no way
<nckx>Does anyone here use the kernel framebuffer penguin logo at boot?
<nckx>‘GRUB can be used to load non-free operating systems’?
<drakonis>this is grub2
<nckx>‘Hyperbola endorses secure boot™’
<drakonis>they blacklisted grub2
<nckx>drakonis: Does it say why?
<drakonis>grub:grub:::[branding], [technical] Arch version uses version control system (VCS) sources
<drakonis>am i expected to use the version released a decade ago?
<drakonis>i'll just reiterate, this is not grub legacy, its the modern day version
<drakonis>this is all kinds of fucked up
<nckx>GRUB 2.04 is not a decade old, it only feels that way.
<pineapples>I like what I see - a lot of faces and topics that pertain to usability
<nckx>It does probably predate Btrfs+zstd, I'm not sure.
<pineapples>(not a perfect timing on my side with this one but well)
<drakonis>there are things getting blacklisted for not using sha-512 hashes lol
<dstolfa>aaaaaalrighty then
<vagrantc>drakonis: so, while many of us probably share the shock and disbelief ... at some point it might be worth dropping the topic :)
<drakonis>i'll stop now
<drakonis>there's a limit to how much disbelief i can acquire here
<vagrantc>heh :)
<ix>drakonis: basically, everything's blacklisted
<dstolfa>why is vte3 and vte-common blacklisted
<ix>If you wanted to use software, wrong place
<dstolfa>WHY QEMU
<vagrantc> /o\
<dstolfa>"haha you want VMs. too bad"
<dstolfa>okay uh
<dstolfa>now it's getting really weird
<dstolfa>ffmpeg and dkms??????
<pineapples>Well. Speaking of which, libvirt in Guix has been brokem for a while
<dstolfa>why would you blacklist ffmpeg and dkms
<drakonis>you can find out why if you click at the commit :V
<dstolfa>qt5-base is blacklisted because it depends on openssl and libpulse
<dstolfa>and because it doesn't use SHA512
<dstolfa>these people won't have xorg by the end of this
<drakonis>they dont
<drakonis>that's the joke
<vagrantc>i guess i have no authority on the matter, but please let's take discussions of the *bola blacklists elsewhere? please? :)
<nckx>ix: lol.
<dstolfa>vagrantc: sorry, i just remain baffled and confused
<nckx>I don't want to use authority but I agree with vagrantc. It was fun :)
<vagrantc>it is understandable, but at this point more examples don't really change the clear message :)
<nckx>So... anyone here use the kernel framebuffer penguin logo at boot? This little buddy:
<lfam>I'd like to!
<drakonis>gimme those goods
<dstolfa>i'd like to as well
<drakonis>its a staple
<dstolfa>can we also get a gnu face somewhere
<drakonis>i wonder how it looks like when someone has 24 threads
<drakonis>linux libre has freedo, no/
<drakonis>i swear i saw that it used freedo instead of tux
<nckx>Well, I can't get it to appear.
<nckx>drakonis: Possible, this is just a random image from the old Internets.
<drakonis>linux libre on linux doesnt have it enabled on boot
<drakonis>guess its time to patch... the kernel...
<pineapples>Any cmus users here? The app's D-Bus integration seems broken, without which mpris (the thing that allows to control audio playback from anywhere on the desktop) doesnt work
<dstolfa>roptat[m]: i see you managed to connect :)
<roptat>eh, but I have no idea how
*nckx tries disabling CONFIG_FB_DEFERRED_IO
<nckx>drakonis: Patch the kernel?
<pineapples>Ah, it's an easy fix. Adding elogind to its inputs and updating Cmus to the newest stable release does the trick
<roptat>althouh my messages don't appear
<drakonis>its just a kernel config you have to turn on when building i think?
<drakonis>gentoo might have it explained somewhere
<nckx>drakonis: Ah, but my complaint is: it doesn't.
<roptat[m]>indeed, here I am
<Bumblehorse>I noticed that my service "swap-/dev/sda1" has been stopped, but when I try to restart it, it says "In procedure swapon: "/dev/sda1": Invalid argument". Does anyone know why this is the case?
<nckx>CONFIG_LOGO=y, CONFIG_LOGO_LINUX_CLUT224=y (which I've replaced with a full-screen Guix logo — what, you thought I was asking because I wanted 4 penguins?)
<drakonis>i see
<nckx>CONFIG_FB_EFI=y (which is probably not needed), CONFIG_FB=y (which is), i915 built-in just in case...
<nckx>The fbcon itself works fine. Custom font & all. But no logo. Very strange.
<pineapples>Speaking of kernel configs, I like the idea in here:
<vagrantc>there it is again!
<Bumblehorse>Incase anyone was wondering I fixed my problem. For some reason, when I call swapon myself, it just works.
<nckx>Bumblehorse: The executable or the Guile procedure?
<Bumblehorse>the executable
<Bumblehorse>I then called the swapoff executable and the service now succesfully restarts
<nckx>So no debugging that anymore...
<nckx>It would be interesting to know if (swapon "/dev/sda2") works.
<nckx>In the state where the service refuses to start.
<Bumblehorse>well, thats the rest of my harddrive. Is that a wise thing to execute?
<lfam>It doesn't sound like it
<nckx>Please, substitute your own swap device.
<nckx>Or don't, it's your data.
<lfam>How do I get rid of these ";;; In procedure load-thunk-from-memory: incompatible bytecode version" warnings from my source tree
<lfam>I updated from a checkout that was a couple weeks old
<lfam>Rebuilt, and now it does this
<cbaines>do you have a guile executable at the top level of the Guix Git repository lfam ?
<leoprikler>lfam delete guile (the file inside guix git tree) and reconfigure
<lfam>That sounds right
<lfam>I always forget about this guile
<leoprikler>is there a particular reason to have it (other than to cause headaches)?
<ix>Ah uh
<ix>wait, `guix search` searches nonguix too right?
<lfam>I suppose it would, if you were using that channel
<ix>Was checking my apps are all about
<ix>Ok, can't ask my real question
<ix>But damn
***iskarian is now known as Guest536
<leoprikler>guix search searches all the evil channels you have installed and can't talk about, that's freedom 0 :P
***iskarian is now known as Guest402
<ix>"evil" hah
<Rooks>Is the lack of KDE stuff more of a "bug" or a "feature"?
<rekado>it’s difficult to package it all
<rekado>Hartmut has made a lot of progress packaging the base libraries, but higher tiers still need work.
<dstolfa>someone said libvirt doesn't work on guix... what exactly is broken?
<roptat>last time I tried, it work well
<dstolfa>22:17 < pineapples> Well. Speaking of which, libvirt in Guix has been brokem for a while
<roptat>mh... I might be on an older guix then...
<bdju>looks like I hit a build failure on emacs-evil-magit earlier
<bdju> log here
<bdju>and it's a troublesome one to skip over since a lot of other stuff is kinda tied to it
<apteryx>dstolfa: works for me as well
<apteryx>I'm using it with GNOME Boxes, sometimes virt-manager
<lfam>I'm working on the OS declaration for the macchiatiobin
<lfam>It's using linux-libre-arm64-generic@5.10.40
<lfam>`guix system build` fails when it can't build the linux-modules derivation:
<lfam>Do I need to add some modules to the initrd?
<lfam>I see that the overdrives use the "regular" kernel and add some modules to the initrd:
<apteryx>lfam: the error suggests you should add some modules to the initrd yes, I think!
<lfam>Okay (I'm new at this)
<lfam>Hm, adding it to initrd-modules doesn't change the situation
<lfam>I may try the regular kernel
<RE5007>Hello! Just a Parabola GNU/Linux user passing by. I see that some of you are suprised by the "blacklist.txt", but that file is just for documenting problems in Free Software. Most programs are patched and available in the repos If you want to see the real black-list it's here: This can be easily uninstalled if you really wish to install a conflictig package.
<lfam>Oh, thanks for the clarification
<drakonis>parabola's blacklist is mild, really.
<drakonis>but this topic was beaten to death now
<ix>RE5007: good way of doing things.
<ix>Very easy to opt out
<apteryx>RE5007: thanks for the clarifications!
<dissoc>when trying to use recent guix-system-install my system would hang at "Please wait while gathering entropy to generate the key pair"
<dissoc>going back to 1.1.0 worked fine. any idea why this might be happening?
<dissoc>maybe it's unrelated to the key gen. im thinking it might be video card. i will try again tomorrow
***micro is now known as micro_
***micro_ is now known as _micro
***_micro is now known as rprimus
***rprimus is now known as rprimus_
***rprimus_ is now known as _rprimus
***_rprimus is now known as golgotha
***golgotha is now known as micro
<drakonis>dissoc: try 1.3.0?
<civodul>Hello Guix!
*raghavgururajan 's device is having freezing issues again
<raghavgururajan>not sure if its RAM
<danderson>memtest86 overnight time?
<danderson>if some ram is bad, IME memtest86 lights it up like a xmas tree
<tissevert>hi guix
<projectmoon>If I'm storing my guix configs in a repo or something for backups, the user profiles are separate files from the system config right? Basically I'm wondering how to deploy a system in full, including its user profiles, using guix magic
<projectmoon>Everything I find so far is for the system config only
***lukedashjr is now known as luke-jr
<civodul>oooh, a CHICKEN importer!
<tissevert>🐔 ?
<leoprikler>chicken, the scheme implementation
<tissevert>discovering that reading the issue
<wingo>will guix implement proper veterinary controls, is the question
<munksgaard>Does anyone know what the guix equivalent of wamerican-insane from eg. Debian is? I need it for a project, but it doesn't seem to be part of the guix package repository.
***Kimapr7 is now known as Kimapr
<civodul>wingo: re veterinary controls on imported eggs, good question :-)
<avalenn>Hello guix!
<avalenn>cidovul: I want to reply to disagree with you about Rust, Linux, Cargo and co. But did not took the time yet.
<civodul>avalenn: oh, you want to disagree with me? :-)
<civodul>don't get me wrong, there are good things to be had with such a move
<civodul>it's just that i fail to be enthusiastic
***rekado_ is now known as rekado
<avalenn>Conflating Rust (the language) with Cargo (the build tool and package manager) is easy but not correct, especially in the Linux context.
<avalenn>And I really thin
<avalenn>And I really think Rust hit a sweet spot in terms of usability, performances and safety.
<civodul>it sure did
<civodul>it's not the only one, but a good one in its category
<leoprikler>I agree, that Rust the language is not necessarily Cargo, the build system and package manager, but those two are very much interwoven to the point that Rust without Cargo is next to useless (and certainly not used in practise).
<qyliss>it's about to be in both Linux and Android!
<avalenn>It is not much more interwoven than Python and pip. In practice no one does Python today without pip.
<leoprikler>Similar to how you can very well code Javascript without npm (and many do), but pure Javascript projects or projects with a significant Javascript portion often rely on npm.
<avalenn>And in Linux, Rust will certainly be used without Cargo.
<leoprikler>I hope you are right about that, but other problems with Rust remain.
<leoprikler>Particularly the thing about static linking.
<munksgaard>leoprikler: What thing?
<leoprikler>IIUC Rust (like Go) only produces statically linked binaries.
<avalenn>Rust (unlike Go IIUC) can do dynamic linking. Cargo have strong opinion in favour of static linking.
<qyliss>the reason dynamic linking is usually avoided with Rust is that the ABI isn't stable between compiler versions
<qyliss>(and that it's not really doable with Cargo)
<qyliss>but the ABI thing wouldn't be an issue for Guix
<projectmoon>Are they finally adding it to the kernel?
<avalenn>not yet, but I think it will be added this year
<mario-goulart>Hi (I'm a CHICKEN contributor). Someone showed in #chicken. Nice job! Thanks for that. Regarding licensing, we are aware of the problem and are discussing ways to improve it (e.g., ).
<mario-goulart>Just wanted to point out that a better value for %eggs-home-page would be "", which is the canonical base URL for egg documentation.
<civodul>hi mario-goulart! thanks for chiming in!
<civodul>i haven't looked in detail at the importer yet but it's nice to make eggs easily available on Guix
<mario-goulart>Yeah, very cool!
<munksgaard>mario-goulart: When I go to "", I get redirected to "", which is a 404?
<mario-goulart>munksgaard: that's actually the base URL to be concatenated to the egg name. E.g.,
<mario-goulart>You can also use for no redirects (that's "hardcoded" to eggs for major version 5 of CHICKEN).
<munksgaard>mario-goulart: But still, is a 404 for me.
<mario-goulart>Yeah, that's expected. It's just the base URL and also requires an egg name.
<mario-goulart>I'm refering to
<efraim>Oooh, got guile-final to build on powerpc-linux
<mario-goulart>+ (define egg-home-page
<mario-goulart>+ (string-append (%eggs-home-page) "/" name))
<munksgaard>Aaaah, okay! Yes, that makes sense. Sorry, I misunderstood what you mean :)
<mario-goulart>No worries. :-)
<mario-goulart>Maybe it makes more sense to use, actually (to be explicit about the version).
<dstolfa>roptat: apteryx: hm, okay. guess i'll find out soon :). thanks
<thecatster>Has anyone tried running Cuirass on a Pi cluster? I’m wondering if I could get away with cross-compiling with it, if not I’ll continue to use my big server. Thought it would be cool to offload that many cores but not fast CI/CD to the cluster.
<civodul>thecatster: hi! you could run the core service on a biffy x86 machine and have it offload builds to RPis
<civodul>you could also run Cuirass itself on a Pi, but it may be too slow
<flatwhatson>getting a weird message from guix upgrade: "warning: missing arguments, nothing to do"
<flatwhatson>i think "guix upgrade" with no arguments shouldn't warn?
<thecatster>civodul: That sounds great, I think I’ll try that.
<civodul>flatwhatson: oh, my bad
<civodul>lemme see
<civodul>flatwhatson: i can't reproduce it, neither with "./pre-inst-env guix upgrade" nor with "guix time-machine -- upgrade"
<civodul>perhaps you're running it on an empty profile?
<flatwhatson>civodul: not an empty profile, "guix package -I" shows plenty of stuff installed
<flatwhatson>this is not a guix system, not sure if that would make a difference?
<civodul>hmm weird
<civodul>flatwhatson: are you passing -p or similar?
<civodul>does ~/.guix-profile exist?
<flatwhatson>civodul: no flags, just "guix upgrade"; ~/.guix-profile -> /var/guix/profiles/per-user/flat/guix-profile
<flatwhatson>is it just because there are no packages which require upgrade?
<civodul>flatwhatson: no; the condition in (guix scripts package) is:
<civodul>(and (null? files) (manifest-transaction-null? trans))
<civodul>meaning: no -m flags, and an empty transaction
<civodul>when you do "guix upgrade", the transaction is populated by all the installed packages
<civodul>so it's not empty
<civodul>at least that's my current understanding :-)
<flatwhatson>thanks, i'll have a poke at it
<projectmoon>is there a way one can create user guix profiles from the system configuration? or should i just make those separately and copy them to a new system?
<flatwhatson>civodul: i don't get the warning if it upgrades something
<civodul>flatwhatson: could you add a pk call around "trans" in the condition above?
<civodul>projectmoon: hi! currently user profiles have to be created separately from the system config
<projectmoon>ok, thanks
<projectmoon>i think that would be a cool ability to have. one file (or set of files?) for the system, and it poofs even the user's setup into existence
<civodul>yes, i agree it could be useful
<flatwhatson>civodul: ;;; (#<<manifest-transaction> install: () remove: ()>)
<civodul>so what does this profile contain?
<projectmoon>also where can i follow gnome 40 progress?
<civodul>flatwhatson: the transaction can't be empty in this case, can it?
<apteryx>civodul: I think the Xfce keyboard switching thing may require localed as you had found for GNOME.
<apteryx>I tested in a Debian 10 VM with Xfce and it was working, but localed is present in this environment (haven't investigated deeply though)
<flatwhatson>civodul: but it is! i put the pk back:
<ytc>hello. i want to boot my guix system with different kernel arguments. i checked "Bootloader Configuration" section in guix manual but i didn't find anything. could you guys please help me?
<civodul>flatwhatson: oh i see, it can be null when it can determine that nothing needs to be upgraded
<civodul>so i think we mostly need to change the message to just "nothing to do"
<elb>Hi all, I have installed and updated guix per the directions on (I believe) on a debian buster foreign distribution, and I have used guix package to install mutt; my terminal (via debian) is kitty, and mutt reports 'Error opening terminal: xterm-kitty.'. I used guix to install kitty, but I still get the same error. How do I get mutt in guix to find _either_ my foreign distro terminfo _or_ the
<elb>guix terminfo?
<flatwhatson>civodul: sounds reasonable to me, it is friendlier than previous behaviour of no output
<civodul>ytc: hi! see 'kernel-arguments' at
<civodul>flatwhatson: yeah; i'll push a fix, thank you!
<elb>(NB that both /usr/share/terminfo/x/xterm-kitty and ~/.guix-profile/share/terminfo/x/xterm-kitty exist)
<flatwhatson>civodul: and thank you!
<elb>it looks like mutt is looking only in the ncurses-shipped terminfo in /gnu/store/zzkly5rbfvahwqgcs7crz0ilpi7x5g5p-ncurses-6.2/share/terminfo/ and ~/.terminfo
<ytc>civodul: thank you.
<civodul>elb: does setting TERMINFO_DIRS=$HOME/.guix-profile/share/terminfo help?
<elb>civodul: it does, as does infocmp xterm-kitty | tic -
<elb>what I want, however, is for _all_ guix apps to use the installed terminfo database in its entirety
<civodul>(terminfo has always been somewhat of a mystery to me)
<elb>like, for all users, not for users who know the magic incantations
<civodul>TERMINFO_DIRS should work for all ncurses-using apps (both Guix- and non-Guix-installed)
<elb>agreed, I think but guix should be handling this somehow
<elb>but I think, rather
<balbi>hey guys, how to install an aarch64 cross-toolchain with guix?
<civodul>elb: yeah, i'm not sure how to have it DTRT automatically; suggestions welcome!
<elb>do guix programs generally know nothing about the installed guix profile at all?
<civodul>balbi: surprisingly, there's no convenient way to install it in a profile, but you can use it easily with "guix build --target=aarch64-linux-gnu ..."
<civodul>elb: no, not at all
<civodul>generally they don't know about Guix
<flatwhatson>~/.guix-profile/etc/profile sets a bunch of envs
<elb>(I'm brand new to this; so far my experience has been: guix is unusably terrible without substituions; guix pull fails and asks me to report a bug report; guix locales and terminfo are both broken without manual intervention)
<balbi>civodul: interesting... guess it would be hard to rely on guix for linux kernel dev, then (?)
<elb>(I don't say this to be harsh, I think guix does something I very much want, which is a stable way to deploy non-distro packages to a variety of machines, but I'm a Unix user and Linux user with 25+ years of experience and several degrees in computer science ,and I'm still finding this ... frustrating)
<elb>flatwhatson: mine sets _only_ the path
<civodul>balbi: there's a way to do that with 'guix environment -m' though; ekaitz has a manifest that does that
<elb>but I agree that it seems reasonable for this sort of thing to be handled there
<flatwhatson>elb: sure, it depends which packages you have installed in the profile
<elb>perhaps your comment wasn't directed to my woes, apologies
<ekaitz>the arm toolchain does have a package, doesn't it?
<ekaitz>but as civodul says, you can also make a fancy manifest with `cross-gcc` function from `cross-base`
<civodul>elb: that Guix is "unusable" without substitutes isn't a surprise; but yeah, the other pain points you mention for foreign distro usage are frustrating
<flatwhatson>perhaps ncurses needs TERMINFO_DIRS added to its native-search-paths? are those propagated to dependees?
<civodul>elb: documents some of the pitfalls and necessary steps, but the install script could do more
<elb>civodul: I would expect it to at least be able to update itself even without substitutes; but I think m yreal surprise there was that the instructions say "oh by teh way you might want to install substitutes" in passing, not "you'll need to install substitutes if yo uwant to be able to install the most trivial of packages before the heat death of the universe on your 12-core Xeon with 56 GB of RAM"
<civodul>elb: did you use the install script?
<elb>I was fully prepared for slow installs, but on the like fourth build of gcc I was like ... this is unsustainable
<elb>I did not, I followed the binary install instructions
<civodul> mentions the install script at the top
<elb>it does, and I don't wget | sh shell scripts
<civodul>me neither, but that's not what it suggests :-)
<elb>so it was either read the shell script and run it one line at a time, or run the install instructions one line at a time
<civodul>yeah, sure
<elb>it says exactly that, yeah
<apteryx>elb: you can expect even more building using Guix compared to a source based distro such as Gentoo when not using substitutes, as Guix goes a longer way to cleanly bootstrap things.
<elb>I mean I realize at some point this is academic because once I run the `guix` command it does what it does
<elb>apteryx: understood, I read the bootstrap documentation as well, but it was still ... more than I expected
<elb>I guess I didn't expect `guix pull` to go all the way back to ground zero _even once I had a bootstrapped distro_
<civodul>the binary tarball does not include gcc, etc.
<elb>which is, whatever, neither here nor there -- I suppose my constructive criticism here is that the docs should be a bit more firm about saying "no really, you need substitutions" :-)
<civodul>makes sense :-)
<civodul>note that some people knowingly choose to avoid substitutes
<elb>yeah, and I understand that and I might do it in any number of situations
<elb>but for this particular use case, I'm OK with binary packages
<elb>I basically want a known-static-independently-configurable package set that i can deploy to machines running somewhat different underlying core distros
<elb>which, as I said, looks like a perfect case for guix
<elb>I'm just encountering more friction than a first read of the docs led me to expect ;-)
<flatwhatson>i've used "guix pack" for this with great success
<elb>I'm under the impression that `guix pack` would still have this terminfo problem
<elb>and yes, `guix pack` is on my list of things to explore if I get to the "next steps" part of this journey ;-)
<flatwhatson>yes, likewise FONTCONFIG_PATH can be annoying on non-guix systems
<elb>years and years ago I used checkinstall (I think?) for this purpose, but I was never entirely happy with it
<elb>I think I may be able to converge on guix pack plus a script to be dropped into /etc/profile.d or whatever, but that script is feeling a little bit like whack-a-mole right at hte moment, since the _very first package I installed_ ran aground on this ;-)
<elb>perhaps I just had bad luck out of the gate
<elb>(although to be clear, the fact that an out-of-the-box binary install of 1.30 cannot successfully `guix pull` is more concerning)
<apteryx>elb: what was the error? something failed to build?
<elb>guile, yeah, I filed a bug; searching through the mailing list (which I should have done first, but I just followed the thing where it said "file a bug" first) it looks not uncommon
<elb>it hasn't hit the archive yet, let me toss up a nopaste
<elb>some sort of guile self-test failure
<apteryx>mthis was without substitutes, right?
*apteryx tries
<apteryx>are you building on a small spec machine?
<apteryx>how much ram, for instance?
<cbaines>civodul, with the knowledge that I can't use GnuTLS in Guile with the garbage collector enabled, I think I've managed to hack around it
<cbaines>I still haven't done a lot of testing, or looked if the throughput is reasonable, but I think the hacky gc disabling port is helping
<elb>apteryx: 12 core Xeon, 56 GB RAM
***mskrisprolls is now known as mrkrisprolls
<flatwhatson>cbaines: isn't --enable-mini-gmp sufficient to prevent gnutls problems?
<cbaines>flatwhatson, a problem/some problems, but not any and all problems to do with gnutls (as far as I'm aware)
<flatwhatson>cbaines: are there some relevant bug reports? i've been hacking around gc and gnutls in recent months, i guess the adventure continues :)
<cbaines>flatwhatson, these changes might help
<civodul>cbaines: "can't use GnuTLS with GC enabled" is a bit strong :-)
<civodul>Guix commit 02d62978f46fcc2793608bb57a2c20a30555dbba catched EAGAIN/EINTR and tries again
<taeaad>Hi, I was just wondering about guix and trying to understand the organisation behind it better. Is it maintained by the GNU Project? And is that the same as the FSF. I know Stallman vs. the World seems to be a thing these days, but I just want to know specifics a bit better.
<civodul>when that happens, it does a bit more work, but it's rather unusual
<civodul>cbaines: ↑
<civodul>taeaad: hi! the GNU Project is loosely organized; Guix governance is independent of the FSF and RMS in practice, if that's what you're asking
<taeaad>OK, yes, I didn't want to sound political.
<cbaines>civodul, with the Guix Build Coordinator, especially when it's performing multiple builds, it can often be trying to upload a large output, while the GC is firing all the time. I think this changes it from an unusual event to something that simply prevents making non-trivial TLS requests.
<taeaad>It's cool that there is GuixHPC, sounds interesting.
<civodul>cbaines: are there other threads "doing things" while it's uploading?
<civodul>in a single-threaded program there's no GC activity while transfering data over GnuTLS
<civodul>but yeah, in a multi-threaded context there could definitely be something
<civodul>if the GnuTLS patch doesn't land in a timely fashion we can add it locally
<cbaines>civodul, yeah, the model I'm currently using is that one thread takes care of one build. So on a large machine, there can be 32 threads all going at once.
<civodul>ok, i see
<cbaines>I'm not quite sure what is the biggest causes of garbage, but I wonder if the build logs streaming back (and going to to a void port) lead to garbage
<civodul>yeah, writing to a port typically triggers allocations
<cbaines>anyway, I'm happy that there's a workaround :)
<cbaines>that means I can get on with fixing and improving other things
<rovanion>I'm failing at packaging again. This time its a modern program called Lingot. It seems easy enough, but I can't seem to provide GLIB_COMPILE_RESOURCES to its configure script to put in the Makefile. Atleast that's my read of it. I've pasted my package definition here if anyone want so give it a shot:
<nckx>rovanion: ("glib" ,glib "bin")
<nckx>...and good beautiful morning, Guix.
<daviwil>Good morning!
<nckx>rovanion: That's the way to ask for the glib:bin output (glib is the library, :bin contains the tool you need) in packages for now, until civodul ruins everything by improving it greatly -- again.
<apteryx>nckx: Likewise.
*apteryx forgot to turn their GNU changelog style mode off
<rovanion>nckx: That worked. And it even runs!
*nckx signs off on apteryx's greeting.
<nckx>Come for the packages, stay for the bureaucracy.
<nckx>rovanion: Awesome sauce.
<rovanion>Oddly running the program, which should only listen since its an istrument tuner, makes my computer hiss.
<nckx>...try to gain its trust slowly? That is weird.
<nckx>rovanion: Have you perchance tried FMIT on the same hardware? (No, it's not in Guix yet.)
<rovanion>nckx: Sorry, have not.
<rovanion>But my Lingot patch is off to guix-patches!
<nckx>leoprikler: Puns are allowed if they make me snort coffee 👍
<rovanion>Its coil whine of some sort I think.
<rovanion>And I also want to pimp my error message patch which hopefully still applies:
<rovanion>Now I'm off to do some biking!
<nckx>Have fun :)
<emad-guix>Hi, I'm new to guix system I'm wondering why most Gstreamer test config are disabled for building it in Gstreamer.scm ?
<nckx>emad-guix: Where do you see ‘most’? For gstreamer itself I only see 2 tests disabled, and then only on 32-bit Intel, with a link to <>.
<nckx>In fact I see lots of patching going on to enable tests, not disable them. Only exception to that seems to be gst-editing-services.
<emad-guix>I tried to build gst-rtsp-server package with tests but it failed
<emad-guix>for 64-bit
<nckx>We're missing some info here. (1) gstreamer tests aren't disabled but for 2 on i686 and (2) gst-rtsp-server isn't in Guix, are you packaging it?
<emad-guix>I'm following the way to package gst-rtsp-server because it's missing in Guix
<nckx>Thank you very much. And what do you mean by ‘most Gstreamer test config are disabled for building it in Gstreamer.scm’?
<emad-guix>T (build-system meson-build-system)
<emad-guix> (arguments
<emad-guix> `(#:tests? #f
<emad-guix> #:phases (modify-phases %standard-phases
<emad-guix> ,@%common-gstreamer-phases)))
<emad-guix>Does this mean it's disabled ?
<nckx>As I said, gst-editing-services is the exception.
<emad-guix>Ah ok
<nckx>It disables tests with the comment ‘FIXME: 16/22 failing tests’ which means the author was fed up and gave up, I know as much as you 😉
<nckx>We discourage doing that, though, please try to get tests to pass before disabling them.
<nckx>+ we might be able to help with that.
<nckx>gstreamer itself and the gst-plugins-* packages do run the test suite.
<emad-guix>Currently I'm trying to build the missing package without test but unfortunately it failed
<emad-guix>I'm new to scm config :-)
<emad-guix>sorry I mean with tests
<nckx>It really helps if you can share more information than the above, like your work so far & *how* they fail (the log). You can use for that, pasting multiple lines into IRC isn't ‘done’.
<nckx>emad-guix: I'll be back in ~30mins.
<emad-guix>nckx Ok
<emad-guix>nckx I'm getting something like : Unexpected critical/warning: failed to create element 'rtpbin', check your installation
<elb>as a specific suggestion, on this page, step 7, I would move the < to the second line of the command before the file being input, for clarity:
<civodul>nckx: howdy! thoughts on the activation issue ss2 reported a few days ago?
<civodul>i'd like to get to the bottom of it
<dstolfa>lfam: how are you today
<lfam>I think I've almost got the macchiatobin working with Guix System, but not quite. And now I've borked the existing Debian installation
<lfam>I'd rather re-try `guix system init` from a "live CD" thing
<civodul>hey lfam!
<civodul>ah the ARM thing?
<lfam>(A weird name, for sure)
<civodul>i imagined a fashionable Rust package :-)
<dstolfa>someone liked macchiatos i guess
<lfam>They were building on the espressobin name
***Kimapr1 is now known as Kimapr
<dstolfa>ah :)
<dstolfa>i guess the next step is cappuccinobin
<lfam>So, I wonder if I can attach its storage to my x86_64 Debian laptop and do it from there somehow. Maybe with QEMU?
<lfam>Or maybe directly on the macchiatobin, from the Debian installer on a USB flash drive?
<lfam>It would be nice to avoid installing Debian onto it again, just as a host for installing Guix System
<civodul>lfam: you could set up offloading + qemu, and try "guix system init --target=... config.scm /mnt"
<civodul>would that work?
<civodul>i guess it should
<civodul>otherwise you could cross-compile a basic system and dd it to the storage device
<efraim>`in the past I've just built a disk-image and used dd to get it onto a flash card
<lfam>I don't have a "working" aarch64 machine now, so offloading will be tricky
<lfam>I know I could offload to QEMU but it will be pretty slow
<lfam>Could I use disk-image instead of init, and get the same result after I dd it to the SSD?
<lfam>I'd guess the bootloader stuff might be tricky
<lfam>The way it failed was that it totally lacked the ability to load the storage. I think I have to add the ahci module to the initrd
<lfam>At least, the overdrives do that
<lfam>I tried to find a decent aarch64 live image but I had trouble finding good candidates
<lfam>Debian seems to only have the installer
<civodul>yeah, you can use "guix system image -t arm64-raw" maybe, which would cross-compile the thing i believe
*lfam learns about arm64-raw
<civodul>"guix system image --list-image-types" is not as helpful as it could be
<lfam>I didn't mean to put it down
<lfam>I'm going to try again using the Debian installer's shell, installing Guix there, and doing `guix system init`
<lfam>Maybe it can work
<lfam>I worry about using `guix system image` and then later struggling with changed storage UUIDs
*nckx ret.
<lfam>We will see if the Debian live image with the ash shell is up to the task
<nckx>Are unicodically-correct apostrophes (’) fine in package Texinfo? Or should I use an ASCII replacement and let the renderer fix it up later?
<lfam>Europeans are really into apostrophes and quotations marks :)
<lfam>Quotation marks
<lfam>Where do these descriptions go? The Guix UI, the website, anywhere else?
<nckx>americuns dont bother or wut
<civodul>nckx: ideally the renderer would DTRT, but in fact it doesn't
<lfam>USAmericans do not bother
<civodul>thing is, if we use Unicode apostrophes, "guix show" & co. will fail when running in a non-Unicode-capable locale
<nckx>How can that be, you can't even spell y'all without one.
<civodul>though that too can be worked around
<lfam>I guess it's a consequence of never having to explore "outside of the default keyboard"
<lfam>With y'all we just use the basic '
<lfam>Ain't a problem
<nckx>civodul: OK, ' it is!
<nckx>Nobody ever got fired for buying ASCII.
<lfam>Heh, I think that time has past
<nckx>Thanks y'both.
<lfam>I was just joking around. You should use the right thing
<lfam>Even here, we are long past ASCII "being enough"
<nckx>Well, apparently not in this specific case, but in general I agree.
<lfam>As you see fit :)
<nckx>Except stuff *still* breaks.
<lfam>Heh, depends on Bash which is not present in the Debian installer's shell
<lfam>So I am back to square one
<lfam>Maybe I will just install Debian and then retry `guix system init`
<lfam>I can install Debian to an SD card and then `guix system init` to the SSD
<drakonis>is #guix the only channel?
<lfam>It's the only channel named #guix!
<lfam>Hey vagrantc
<lfam>You're asking if there are other official Guix channels?
<civodul>nckx: in theory, Texinfo expects `like this' (because that's also what TeX expects)
<Noisytoot>drakonis, There used to be #guix on freenode, but a bot closed it because the topic contained "libera"
<projectmoon>That happened to any channel
<projectmoon>"how to kill an IRC network in one week"
<bavier>and I think they kicked everyone out of the channel first, too.
<lfam>I was banned from some channels that happened to
<lfam>I think somebody didn't really know how to IRC
<dstolfa>lfam: friend of mine got banned on the channel he was +f on
<dstolfa>so yeah, someone didn't know how to irc at all
<Noisytoot>dstolfa, +f or +F?
<dstolfa>Noisytoot: +F, forgot to capitalize
<dstolfa>as in, founder
<Noisytoot>The bot didn't unset +I, so some users could still join
<nckx>drakonis: There are also, for example, #guix-hpc and #guix-risc-v.
<nckx>Anyone could create #guix-ponies just by joining it.
<nckx>I closed #guix on Freenode btw. I mean, the bot thing totally happened and they did all that, but the noobs also forgot to revoke access flags. I undid their sabotage & made #guix invite-only.
<nckx>I never wanted that, but if that's the network Freenode wants...
<lfam>I'm not sure they know what they want
<nckx>They didn't get what they wanted to steal. Now they're trying all kinds of weird things with the ashes.
<nckx>Anyway. What's past.
<lfam>The transition was relatively seamless for us. Thank you for getting ahead of it
<nckx>Thanks, appreciated.
<nckx>It was ‘fun’ in that sense that I never want to do it again :)
<stikonas>and it fractured overall community a bit... Some projects moved to other IRC networks, e.g. oftc...
<nckx>The only hiccough was the Matrix bridge but that's not something we could help with.
<nckx>stikonas: Oh, certainly, I was talking only about #guix here.
<nckx>It was certainly a net loss overall.
<nckx>OFTC uses (used?) non-free captchas last time I checked.
<lfam>I guess that some IRC clients make it hard to join more than one network. In Hexchat it's not a big deal
<nckx>Free as in free labour training AIs, not as in beer.
<lfam>I see people complaining about it
<nckx>I've only heard that about ERC specifically.
<lfam>Alright, I'm trying `guix system init` again. Fingers crossed
<nckx>#guix bias of course...
<nckx>Good luck!
<emad-guix>lfam Hi, I'm still trying to build gst-rtsp-server 1.8.2 package for guix the issue is that the tests failed
<lfam>Okay emad-guix
<lfam>If you'd like, you could try sharing the error messages and your work-in-progress package definition on <>
<taeaad>nckx: That's pretty funny RE: Freenode.
<taeaad>nckx: It may be difficult since you're still in Emacs and everything is in a buffer. So if you want it all in the same Emacs instance, then I guess it can be confusing.
<taeaad>But configuring different networks isn't difficult if you are already an Emacs user.
<nckx>emad-guix: Please share more info... ‘the tests failed’ is not useful, nor is ‘ I'm getting something like : Unexpected critical/warning: failed to create element 'rtpbin', check your installation’. Just paste your current package, and the log (although we can recreate the latter if you give us the former).
<emad-guix>nckx sure I will
<leoprikler>nckx I apologize for all the hardware damage, that you've had to endure due to the snorted coffee, but I'm afraid I won't be able to pay for any of them :(
<nckx>You can use the pastebin lfam & I suggested.
<nckx>We can't really help otherwise.
<nckx>leoprikler: You contribute to GNU; we know. 's Okay.
<leoprikler>rovanion Please respect the 80 (or is it 79?) character limit
<dstolfa>i assume 80
<nckx>I just sent a mail to rovanion.
<leoprikler>okay, I wasn't off-by-one then :)
<nckx>Better 79 than 81.
<nckx>That would be troll.
<dstolfa>nckx: i hate when people go >80col, especially because i default to 80col everywhere and if i need to edit it in non-gui mode it's a serious pain
<vagrantc>heya guix! :)
<nckx>Hi vagrantc.
*nckx nods @ dstolfa.
<bavier>our dir-locals.el sets the fill-column to 78, and I think the linter doesn't complain until 90.
<emad-guix>nckx here you are
<nckx>I consider that an allowance for common-sense exceptions. I suspect it's an arbitrary number (even more arbitrary than 80, I mean).
<bavier>right, "wiggle room".
<nckx>OK, 50% pass already, not bad ;-) <>
<emad-guix>nckx haha I tried that in Fedora 34 it worked perfectly ;-)
<nckx>Well, it was designed to work there, not in Guix. OK, so rtpbin is provided by gst-plugins-good... I wonder why it's not found...
<nckx>Does *our* gst-plugins-good provide it? I'm not sure...
<emad-guix>nckx I also tried to read the meson build log file /tmp/guix-build-gst-rtsp-server-1.18.2.drv-0/build/meson-logs/testlog.txt it's not found!
<nckx> yes it does.
<lfam>You would need to run the `guix build` command with --keep-failed, emad-guix
<lfam>Otherwise, the build directory is deleted afterwards
<emad-guix>lfam Aha make sense
<drakonis>i have a suggestion for a blog post for driving some eyeballs to guix
<emad-guix>nckx Are there any skipped packages for license reasons in Gstreamer in general ?
<drakonis>talking a little bit about guix's goals
<drakonis> i certainly like the software freedom section here
*nckx really needs to re-slather their CPU in fresh paste :-/ 99°C building this thing because it's mildly warm out.
<nckx>Unfortunately that log file doesn't seem to contain any shocking news. Disappointingly, GST_PLUGIN_SYSTEM_PATH looks correct...
<apteryx>for Shepherd actions, is the modules field of a service sufficient to have extra Guile module (e.g., (srfi srfi-26)) in scope ?
<nckx>emad-guix: You mean in Guix's packaging of gst-plugins-bad? Not that I'm aware. I'm not an expert on Gstreamer by any means (I once installed it to make the baseball men go, the end) but my understanding was that ‘bad’ did not include ‘straightforwardly non-free’. It's more about patents &c.
<drakonis>nckx: wait what.
<lfam>The bad plugins have low code quality. It's the ugly plugins that are patented
<nckx>Eh, that, then. Use the sed in your head.
<nckx>I can never keep the two straight.
<avalenn>nckx: matrix bridge is there now. I think it will be announced in the next 24h.
<lfam>You need to watch that old movie 5 more times. Then you'll remember :)
<nckx>avalenn: Little birdies had told me but thank you! Soon things will be as they were in the old days, and we can laugh at matsplats instead of at netsplits.
<nckx>lfam: I have watched it, and it said disappointingly little about media codec patent freedom.
<nckx>Maybe I need to watch the director's cut.
<lfam>Yeah, that's the one ;)
<emad-guix>nckx did try to build it? it seems everything is correct but the test issue probably from network config or something like that I'm not sure to be honest
<lfam>There's no network access in the build environment, emad-guix
<nckx>It just has 34 minutes of an rms interview awkwardly spliced in.
<lfam>emad-guix: You could test if this is the problem by going to the failed build directory, sourcing the environment variables file, and then running whatever command is used to start the test suite
<emad-guix>lfam I mean during the test casese
<nckx>emad-guix: I tried a few times & a few things (someone said setting GST_PLUGIN_PATH fixed it, so I tried that in addition to our GST_PLUGIN_SYSTEM_PATH), but no progress.
<lfam>emad-guix: Build or test, the network is not available. It's all part of "building a package"
<nckx>I am really clueless about gstreamer/gstuff in general, sorry.
<emad-guix>nckx Aha
*lfam curses that QEMU was not built for aarch64
<lfam>I'm building it now
<lfam>Every time I find something like this, it's another hour or two of waiting
<lfam>Soon, that problem will past us, however.
<lfam>Mathieu fixed that bug
<lfam>Be past us
<apteryx>lfam: it is on overdrive1
<lfam>But we'll have to find and rebuild affected derivations for a while
<apteryx>but I don't see it as a worker anymore; not sure what's going on
<lfam>Interesting apteryx. Yeah, I was about to ask about that
<lfam>It disappeared yesterday, I think
<apteryx>(I had to build it manually yesterday to run 'guix system reconfigure' on it)
<kreved>hello, guix
<nckx>I built something on berlin y'day that successfully offloaded to an overdrive.
<lfam>I think that offloading often continues to work when the Cuirass worker system goes down
<apteryx>offloading is not the same as CI workers
<lfam>Howdy kreved
<emad-guix>nckx Thanks for your help at least you give some effort to investigate
<nckx>I wish I could do more, but I'm really not a media person.
<Noisytoot>nckx, There's a Matrix bridge now:
<emad-guix>nckx I really appreciate that :-)
<nckx>Could someone announce that in the non-bridged Guix room? I might have never memorised my Matrix password and have it in a text file in ~ on another machine :)
<drakonis>i'm still there
<Noisytoot>I can't access Matrix currently
<Noisytoot>What is the other room?
<Noisytoot>It may be possible to plumb it
<emad-guix>Unfortunately, when I tried to "guix refresh" I got "rate limit exceeded" for example HTTP download failed: 403 ("rate limit exceeded")
<nckx>drakonis: Let me know if it still has the favicon & all the metadata, or if I have to copy that too.
<drakonis>it has the topic but not the icon
<drakonis>high latency too
<drakonis>8 seconds delay, yowza.
<nckx>emad-guix: GitHub limits users by default, nothing we can fix without user action. See ‘GUIX_GITHUB_TOKEN’ in
<Noisytoot>emad-guix, Can you do it via Tor (to get another IP)?
<nckx>drakonis: OK, thanks.
<emad-guix>Noisytoot "I'm new to guix" how ?
<nckx>Noisytoot: There's a ‘native’ Matrix room, I think it's called ‘Guix System’, not owned of operated by the project.
<apteryx>lfam: I think the wireguard link had been lost following my reconfiguration
<apteryx>I've fixed that by restarting wireguard-wg0 on overdrive1 and pinging
<roptat>so close, I'm trying to make the first real package that uses the maven-build-system, it passes the build phase \o/
<lfam>I got the qemu-minimal derivation registered on berlin and now it's baking
<drakonis>oho maven build system?
<drakonis>that's good to hear
<roptat>but the test phase fails as it fails to find the wrong version of the maven-install-plugin
<roptat>now I need to investigate why it thinks that's the version it wants
<nckx>drakonis: <> is that the non-IRC one?
<drakonis>the non official one hosted on the matrix instance
<nckx>Is ‘#’ just a nod to IRC?
<drakonis>the bridge is at
<roptat> is not bridged, is the matrix bridge
<nckx>That's less complicated than I thought. Great.
<apteryx>is a GC running on berlin? I get waiting for locks or build slots...
<drakonis>its pretty much the same thing as irc in a way
<roptat[m]>Hello :)
<lfam>Hm, it's not that time of day apteryx
<lfam>I just restarted the ungrafting jobset, so maybe there are no build slots available
<nckx>apteryx: What are you building?
<drakonis>how terrible is the latency on your side? is it only me or it takes 8 seconds to get the matrix message across?
<lfam>There were a few thousand spurious failures in that jobset because the derivations had been garbage collected
<apteryx>nckx: trying to repatriate the qemu aarch64 build that should be on overdrive1 via: guix build qemu --system=aarch64-linux
<lfam>That's been fixed in Cuirass and I hope the installation has been updated
<apteryx>(running this on berlin)
<lfam>apteryx: I think it's done
<roptat>I get the irc messages instantly, but sending a message is not instantanous
<nckx>apteryx: Yeah, that's the exact same command I'm running on berlin 😉
<nckx>You're waiting for me.
<lfam>I already "built" and registered that derivaiton
<roptat>it was about 3 minutes yesterday :p
<Drakonis[m]>ah it sped up now, good.
<nckx>Then why's it building here.
<Drakonis[m]>instant, finally.
<lfam>I don't know nckx
<lfam>This is /gnu/store/zh7mppjq41pz1h21wx5vn8yssc11y077-qemu-minimal-5.2.0.drv
<apteryx>ah, minimal
<lfam>Right. Sorry for the confusion
<Noisytoot>emad-guix, You could try running it with torsocks
<nckx>OK, so both apteryx & I are building the same thing, and neither is what lfam needs. Teamwork! Imma let it finish, no point in having the cycles so far have gone to waste.
<lfam>The full QEMU needs to be built anyways
<nckx>It's not repatriating anything, though, it's currently building Spice.
<apteryx>so I guess there's no more problem building QEMU on aarch64, it's built twice so far
<roptat>oh, it's failing the install phase, not the test phase, I was confused by guix coloring
<roptat>it colors the end of the phase, not the beginning
*dstolfa is really itching to install guix on his desktop but must resist because $WORK needs to be done
<drakonis>gosh why not do it now
<roptat>although, it only builds the parent pom, meaning it does nothing interesting apart from running the enforcer plugin
<roptat>not sure how to make it build the various modules in that package
<dstolfa>drakonis: well i need to deal with strongswan first, i literally can't work without it
<drakonis>what kind of work do you still have to do?
<dstolfa>still waiting for someone to review it who actually uses strongswan
<lfam>dstolfa: You may be the expert
<drakonis>why not make a channel and add strongswan there then install that?
<lfam>If nobody reviews it, and you are using it successfully, then it's good
<roptat>I might have done something wrong when adjusting the pom file
<dstolfa>alright guess i'll just do it tomorrow and get some "production" testing in :)
<roptat>arg, I made a mistake in a shared module, now rebuilding all of java :/
<nckx>I told dstolfa to wait ~2 weeks for someone who actually uses it (not an expert) to chime in, otherwise the changes LGTM.
<lfam>Sounds god
<nckx>It's... ‘interesting’ that a usable/modern/secure/whatever StrongSwan configuration is apparently adding 30 switches to ./configure, but I've seen weirder.
<dstolfa>yeah, their default configuration is basically strongswan, but without almost any auth working
<dstolfa>everything else is built as a plugin that defaults to no
<lfam>That kind of thing was a big factor in the design of wireguard
<nckx>‘Secure by default’ it certainly is if nobody can log in!
<nckx>Someone went to OpenBSD skool.
***katco[m] is now known as katco
<nckx>lfam: My thoughts similarly :)
<dstolfa>lfam: yeah i'm not opposed to wireguard, it's just that i can't use wireguard to connect to my work network since it's all strongswan
<lfam>Yeah, it will be with us for a long time dstolfa
<katco>hey all, quick sanity check for this matrix bridge: is my nick `katco`?
<katco>or `katco[m]`?
<katco>ok, thanks friends!
***iskarian is now known as Guest3539
*dstolfa prepares his backups to move to guix
<solene>lfam: I sent a patch for gnutls
<dstolfa>where can i see the status for gnome40 in guix again?
<dstolfa>i recall someone mentioning it, but i can't seem to find it
<lfam>I'm seeing a lot of "no arguments specified, nothing to build", even when there is an argument and something is returned
<lfam>Pushed, solene!
<solene>cool :)
<lfam>Did you find that thing I wrote helpful at all?
<civodul>lfam: that must be me; could you send details to reproduce it?
<lfam>civodul: It occurs when I ask `guix build` to build something that is already built (maybe that's on purpose?)
<lfam>So, for example, `guix build gnutls && guix build gnutls`
<solene>lfam: it was absolutely helpful
<lfam>I expect it to be printed for the second iteration, civodul
<solene>the graft thing is smart
<lfam>Hm, my attempt to `guix system init` from Debian on an SD card to an SSD appears to have broken the Debian on the SD card
<dstolfa>uh oh
<lfam>Rather frustrating
<nckx>dstolfa: There's a wip-gnome branch to which raghavgururajan has been pushing updates towards ~. I don't think there's a useful up-to-date metadocument, just the work itself.
<dstolfa>nckx: ah okay, thanks.
<roptat>obviously, I keep making typos, forgetting unquotes, and all that...
<roptat>and everytime I have to fix (guix build maven pom) and rebuild most of java again
<lfam>I'm unsure of what to mount for `guix system init`
<lfam>There is the boot partition, the partition that contains /, a partition that contains /home, and swap partition
<lfam>I mounted the / partition
<lfam>What about the boot partition? Will the system installer correctly target the Guix boot partition by UUID, or will it instead write to /boot/efi?
<lfam>(I suspect it wrote to /boot/efi, since the existing Debian installation was unbootable afterwards)
<nckx>lfam: You mount everything under /mnt that will be part of the new system. /boot at /mnt/boot, etc.
<lfam>I see
<lfam>Time to try agian
<nckx>l/home probably doesn't matter but why not.
<lfam>I'm going to make it a priority to have an aarch64 / UEFI live image or installer image for the next release
<lfam>It's painful to do this through another distro
*dstolfa has a bootable USB now.
<dstolfa>see you all on the other side
<nckx>dstolfa: o/
<vagrantc>lfam: you'll want to mount all the partitions
<nckx>It's not as fun but I don't remember it being painful, only suspenseful.
<vagrantc>lfam: yay!
<lfam>Waiting is painful
<lfam>Alright, I have a solid list of things I did wrong
<lfam>That's good
<nckx>How do you think I found out that emacs contains a Tetris.
<lfam>It's not an operating system if it doesn't have tetris
<lfam>I feel like a live image shouldn't be too hard, assuming we limit it to EFI systems
<nckx>Oh sure. That's very reasonable.
<drakonis>my evangelizing seems to work...
<Noisytoot>Does Guix include a Tetris?
<nckx>Noisytoot: Several.
<vagrantc>and most modern u-boot's can actually boot EFI
<nckx>Noisytoot: But emacs is on the installer ISO so Tetris is technically pre-installed.
<vagrantc>if you leave the first 16MB unpartitioned on your EFI image, you should also be able to install u-boot onto the image
<lfam>Our installer image includes tetris 😭
<vagrantc>at least for most major u-boot platforms
<vagrantc>e.g. rockchip, allwinner
<nckx>emad-guix: I'll respond here, since it was Guix-specific: That's fine! It's better to have a patch without tests than no patch at all. It's just important to try first.
<emad-guix>nckx sorry wrong channel
<emad-guix>nckx I will do that by tomorrow and thanks for your effort again!
<nckx>emad-guix: Least I could do. Look forward to seeing your patch.
<nckx>Does the programme actually work fine when installed?
<emad-guix>nckx I did not try that I have simple app using it to run simple rtsp server locally to streame Video/Audio
<nckx>lfam: It also comes with a bundled Eliza therapist bot that might be more relevant 25 minutes into an installation.
<emad-guix>nckx I'm using with Gstreamer
<nckx>It's tolerable if the tests fail but the result works fine, not so if it doesn't. So testing (by a human) is still needed.
*nckx AFK.
<emad-guix>nckx Well, I'm not sure aboout this kind of restriction for local network tests but I will try to make reasonable analysis
<roptat>progress, now it's trying to build submodules, but fails to do so
<leoprikler>how do you even enable "networking, but only local plz thanxkbye"
<solene>leoprikler: do not set a gateway?
<leoprikler>not sure, there's probably some bypass for whatever clever trick one might come up with
<emad-guix>nckx is it possible to disable certain test in scm for meson build system ?
<leoprikler>substitute* is your friend
<roptat>ok, progress: it's building the parent again, and fails building the first module
<roptat>it wants to use the wrong version of the maven-jar-plugin
<drakonis>dstolfa: success yet?
<apteryx>where in the sources would I organize a module that supports a service?
<apteryx>(guix build something) ? (gnu services name utils) ? something better?
<civodul>apteryx: (gnu build something) maybe?
<civodul>i don't think there's a precedent for a service-specific helper module though
<apteryx>yeah, that's what I realized
***lukedashjr is now known as luke-jr
<roptat>progress: it uses the right version for maven-jar-plugin (and all other plugins) by default now
<roptat>but build fails in a compilation error: /tmp/guix-build-java-jmh-1.31.drv-0/source/jmh-core/src/main/java/org/openjdk/jmh/runner/options/[70,41] error: incompatible types: Class<CAP#1> cannot be converted to Class<Integer>
<roptat>any ideas?
<roptat>mh, that must be an issue with maven, because guix build java-jmh --with-git-url=java-jmh= --with-branch=java-jmh=master, which uses the ant-build-system, works
<solene>how do you put a computer in suspend mode? I can't find pm-utils
<pkill9>solene: loginctl suspend
<solene>pkill9: thanks!
<projectmoon[m]>i guess this thing is online
<projectmoon[m]>with the bridge
<projectmoon[m]>i was connected via heisenbridge before
<projectmoon[m]>it seems they're bringing the bridge online
*dstolfa waves from the other side
<dstolfa>yep, got everything running with full config on wayland
<dstolfa>(on btrfs)
<dstolfa>the compression is really nice with guix
<dstolfa>also wayland is so buggy in some ways, but it's miles ahead of xorg for multi-screen setup
<drakonis>as expected, really.
<projectmoon[m]>i use wayland at work, because multi-DPI
<dstolfa>if you have variable refresh rate screens, it's so obvious when you switch from screen to screen
<dstolfa>projectmoon[m]: yeah, that's why i use it too
<projectmoon[m]>at home i don't really care because i've connected my laptop to a monitor all of 1 time
<dstolfa>i have 4K and 1080p
***projectmoon[m] is now known as projectmoon
<projectmoon>multi-DPI is a pretty huge thing that linux isn't really doing well. it's catching up fast though
***iskarian is now known as Guest4412
<drakonis>hmm, has anyone here done containers for non guix distributions?
<drakonis>without docker, that is.