<jsgrant>Yeah, I've seen that one via the Debian 'expert install' a few times. loool
<nckx>jsgrant: It's configurable in that it was written from scratch (newt-set-color COLORSET-ROOT "white" "blue"), it's not based on an existing installer, but the author was obviously inspired.
*nckx wonders if KMScon supports more than the usual pseudo-16 colours allowing for a more Guixy theme.
<nckx>The default ANSI ‘orange’/brown is utter ralph.
<jsgrant>I know like NOTHING about TUI programs, but wonder how much is trying to just to stay 'as compatible as possible' between devices in a tty. Like intuitively I'd think "oh just make the framebuffer render everything" and shove like actual gui elements if-possible lool
<Noisytoot>guix system: bootloader successfully installed on '#f'
<nckx>jsgrant: Some ‘text mode’ programmes in the 80s/90s used passed a custom font to the hardware with unused characters replaced with (parts) of GUI symbols like arrows, checkboxes & c. It was all monochrome but it could look quite convincing. Unfortunately, yes, hardly portable.
<mroh>nckx: thx for refactoring the neural network revision! That was fast ;)
<iskarian>another quick packaging question: is "lib/pkg", "lib/pkg-X.Y", or "lib/pkg/X.Y" preferred when the package is installed in /usr/lib/pkg or /usr/lib/pkg-X.Y on other distros?
<nckx>I'd follow the same pattern, since other software might rely on either. But I'd expect the package's own build system to handle this, e.g., with a Makefile or pkg-config or… Why is it your problem?
<Guest14>nckx: Hi, I’m following up on the VMD driver from earlier today. The install image boots, but the install fails while trying to build the kernel-modules derivation. Is there further configuration that needs to be done?
<Guest14>nckx: The vmd module loads in the installer and the NVMe drive is detected. So that part is fine.
<nckx>Could you share (ideally as text but a photo is OK) the actual error?
<nckx>I might think I know what's going on (perhaps).
<Guest14>Will do. Please give me a couple of minutes.
<iskarian>nckx: the package name; I was trying to be generic. This is the go compiler, which expects everything to be under one directory (/usr/lib/go by default); with libraries and commands under 'pkg', source under 'src', binaries under 'bin'. The current package has these dirs directly in the main output, so they are appearing directly in ~/.guix-profile. With the exception of 'bin', I figured we would rather have these in a 'lib/go' subdirectory
<nckx>OK, so src definitely belongs in /share/go. misc also looks like architecture-independent text, is that correct? So also /share/go. With only pkg in /lib/go, which BTW sounds like the right choice.
<nckx>I'd not include the version anywhere for simplicity.
<nckx>OTH, /src is also ‘correct’, since $prefix/src (/usr/src) is a thing.
<dstolfa>i would say sorry, but if this results in you getting a pizza, i'd call that a win
<iskarian>Cool. The other elephant in the Go room is that the tests are currently in a separate "tests" output, but to actually use them you have to construct a symlinked directory so that Go thinks they are still in its main directory...
<nckx>No, substitutes are content-addressed and always guaranteed to be (at least functionally, but usually bit-by-bit) identical. The issue is with how Guix works in general and how we build the image in particular: packages definitions are ‘part of’ guix (e.g., unlike Debian there's no apt executable + separate repo)
<nckx>So whilst the CD booted with the new kernel, and the installer is clever enough to add currently loaded modules that look important to your new system configuration, the guix command contained on that same CD would still install the old one, which lacked the module.
<nckx>Guest14: You probably could have worked around it by switching to another VT and running ‘guix pull’ while the installer's running, but I've been told by people who actually grok the installer that it's not recommended 🤷
<nckx>raghavgururajan: What's the actual problem? I went to that bug and saw a boatload of patches, but no question.
<nckx>Re: http://issues.guix.gnu.org/48729#186 I agree with Maxime. I'd really rather not add things to profiles like that. You say that upstream is ‘planning’ on dropping the polkit requirement. How concrete is that plan?
<nckx>I'd like to here ‘very concrete and happening very soon’ so this is just a temporary wart in Guix, not something that will end up sticking around for 5 years while upstream ‘plans’ ☺
<Guest14>nckx: Works perfectly. Install done and I’m rebooted into my shiny new Guix. Thanks very much.
<nckx>Welcome! Don't worry, plenty of other cool shiny bugs to keep you company.
<Guest14>Lol, look forward to sorting them all out. Cheers.
<raghavgururajan>nckx: Bitmask's lead dev told me that polkit is a hindrance on some distros, as they got complaints. So they are gonna remove the dependency. I am not sure when.
<raghavgururajan>To load the polkit policy of bitmask, I have to extend the polkit-service-type. For that I need the package the to be in system profile, as it provides the policy. Is there any other way you could think of to make this work but not adding package to system profile?
<raghavgururajan>Actually, just extending the polkit-service-type is enought to load the policy. I think I added to profile to avoid mismatch betwen versions.
<raghavgururajan>Like policy is loaded from one version, when a user using app from diff version.
<zacchae[m]>Is it possible to just start x servers as a user with startx, or do you need to use one of the system X services?
<iskarian>nckx, another thing our Go package does currently is bake in a gcc for cgo support. Do you think this is more or less reasonable than allowing it to use whatever is accessible in PATH at runtime, for example a gcc-toolchain in the same profile?
<char>pkill9: I installed guix package manager on pinephone
<kitzman>is there a way to instruct emacs in .dir-locals.el, to run geiser as a custom command? (i.e: guix environment ...). i tried setting geiser-guile-binary but that one tries to run the command with arguments as a single binary..
<kitzman>this is emacs-related, but this might be the best channel to ask
<dstolfa>is there an example somewhere on how to access a jupyter notebook run from `guix environment --container`?
<ajarara>I'm trying to get my yubikey to work w/ udev: I've tried modifying the udev-service-type config to have the rules I need, but I'm not seeing them in the dir returned by `herd rules udev`
<Noisytoot>I have added (bluetooth-service #:auto-enable? #t) to config.scm, when I restart, I get a popup saying "g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.blueman.Mechanism was not provided by any .service files (2)". How can I fix it?
<dstolfa>hmm, the guix jupyter kernel seems to crash on me for some reason every time i run it
<dstolfa>i just get Nudge: attempt ... on kernel <HASH> until it just shuts down
<dstolfa>all i'm trying to run is `;;guix environment matplotlib-env <- python-matplotlib python-numpy python-ipykernel`
<dstolfa>the way i've run the kernel is `guix environment --pure --ad-hoc guix-jupyter jupyter -- jupyter notebook
<dstolfa>i'm really not sure what's causing the issue, it just keeps timing out
<ajarara>Ah, just had to restart, otherwise following the man pages for udev-rules-service worked to get rules under `herd rules udev` (and it's reading the rules too)
<podiki[m]>irfus: trying now. I do see that libepoxy had a version bump and change to propagated-inputs for mesa in origin-updates
<podiki[m]>irfus: that patch wasn't applying cleanly for me on top of the previous one (some changes I had, and then mesa complained about removing the libglvnd input); could you do one patch with all the changes from origin-updates?
<civodul>first i'd like to understand why ci.guix is not building core-updates for ARM
<maximed>and ‘cross-base: Fix cross-compiler for i686-linux-gnu’ isn't all that useful, more a hack to test meson when aarch64-linux-gnu didn't work and probably not worth the complexity
<dstolfa>civodul: i've ruled out docker and the likes from being the culprit by disabling them, still hitting the issue, so it might be relatively easy to reproduce with a pretty basic setup. the only "variable" in my setup and something pretty stock is that i use btrfs. could that be causing it?
<Akawama[m]>I keep coming across this error when I run `guix system reconfigure`:
<Akawama[m]>`guix substitute: error: TLS error in procedure 'write_to_session_record_port': Error in the push function.`
<civodul>dstolfa: could you email firstname.lastname@example.org with all the info: how are you running the jupyter and guix-jupyter, what do you see on the console, etc.?
<Akawama[m]>I looked up but can't find anything like it so I'm thinking to submit a bug report. Is there any guideline for it? Other bug reports seems very detailed and I haven't done something like it before
<civodul>Akawama[m]: hi! is that with a recent installation? (1.3.0ish)
<nckx>raghavgururajan: On which commit are you developing the bitmask patch series? I'm still unable to actually build it, with the same error reported by others for unrelated packages: no code for module (guix build qt-utils)
<dstolfa>nckx: are there qt tests for check-system?
<dstolfa>or something that would cover buliding it?
<dstolfa>and i guess you can't make it asynchronous since if it takes a while to build, you might run into merge conflicts
<dstolfa>and all the other goodness of race conditions
<nckx>The place to gate this is on the CI end, with a separation between ‘the branch to which we push’ and ‘the branch from which users pull’, with automation to sync the latter with the former when all tests pass. And send sternly worded e-emails if not :)
<nckx>civodul: Some tests fail when run with a non-UTF-8 locale. OK, that's ‘by design’, but are there any drawbacks to forcing an UTF-8 locale when running tests? Is there a reliable way to do so? Is there a reason we don't? We're not testing the user ☺
<na2th>Hello everyone! Here am I again trying to upgrade texlive.
<na2th>With the help of nckx I was able to compile texlive-bin, so I am quite happy about that.
<na2th>On the other hand, I noticed that *the whole file tex.scm* uses two variables %texlive-version and %texlive-revision to select a given version of the tex scripts they download
<na2th>of course I want to bump these versions, but that seems to imply that I have to recalculate *every* hash in tex.scm
<na2th>is this the way to go? Of course, to "scratch my own itch" I can only recalculate the hashs that I use, but this seems to completely rule out my attempt of producing a patch in the end
<na2th>the variable %texlive-revision has 150 occurences, and there are 293 define-public's
<na2th>so it seems that bumping this version implies recomputing hash for half of the 300 packages in tex.scm
<maximed>na2th: what about defining a %next-texlive-revision, and updating the texlive packages to the next version one-by-one?
<na2th>maximed: that seems reasonable; is this what is done in other Guix packages?
<maximed>and at the end of the series, when %texlive-revision is unused, rename %next-texlive-revision to %texlive-revision
<nckx>Could someone run guix environment guix -- make check TESTS="tests/cpio.scm" ?
<na2th>because this really looks like something that comes up in other places
<maximed>The hardcoded value %texlive-revision is the same as the default value %texlive-revision. With this change, %texlive-revision can now serve guix better, so that seems positive for %texlive-revision?
<maximed>If/when all texlive packages are upgraded to some common version, then %texlive-revision can be updated again
<maximed>So %texlive-revision will ococcasionally be granted a vacation (-:, which seems positive for %texlive-revision?
<na2th>maximed: I see why you demanded a bikeshed, you are good at it
<maximed>Actually, if this change is made, it is quite possible eventually %texlive-revision will disappear. I suppose you could call that ‘negative’ for %texlive-revision
<tisquel9-pm-user>I am using the Guix package manager on Trisquel 9 and would like to know if I can use 'install-info' or some other method to get Emacs (installed with Guix) to see the custom .info file I made or do I have to create a Guix pacakge and install it that way.
<tisquel9-pm-user>So far I've had no luck by adding the directory path to INFOPATH, up to and including creating a dir file for that directory and using 'install-info' on Trisquel...where it works but still can't be seen by Emacs.
<bricewge>nckx: I managed to unveil the mystery of the mouse-keyboard, xorg-configuration force evdev driver on keyboard
<bricewge>When removed, libinput driver identify the keyboard as a keyboard and not only a mouse!
<TheAsdfMan>Hello, I have problems starting the libvirtd service, it used to work but after it got updated to 7.5.0 it doesn't, i think the problem is in the config file it reads, it writes 'auth_tcp: unsupported auth sasl:'
<nckx>‘Pulling guixes’ and doing the drugs no doubt.
<nckx>Successfully running ‘guix pull’ twice without a channels.scm on two independent machines has reassured me that no post-mortems will be written today, so that's nice. I wonder what *is* up then.
<Noisytoot>After I added bluetooth-service to config.scm (with #:auto-enable? #t), when I start my computer, I get a popup saying "g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.blueman.Mechanism was not provided by any .service files (2)" (and bluetooth doesn't work)
<drakonis>something that an ill timed pull may have caused
<dstolfa>drakonis: maybe you just forgot you used wip-gnome?
<nckx>Noisytoot: I have the same code and last reconfigured on 49dc5bb7d22af9019b71be67bd8e43f15c41cf23 and BT works fine. I don't use anything that could display a pop-up though, only bluetoothctl directly. Have you tried that? Maybe the problem is with your DE?
<nckx>Folk: how the *hell* do I get Meson to tell me why it's failing to find a library right in front of it? There's something called meson-log.txt but it contains nothing of value. Where's the real log?
<raghavgururajan>nckx: On my local bitmask branch, guix describe is bd67ba445a386ba95a7b9b5bfc0803e46d8af5e7. In v9 patch-set, I imported (guix build qt-utils) inside bitmask definition, to overcome the error.
<dstolfa>e.g. you link ZFS (CDDL) into linux (GPL) and you need to distribute ZFS as a part of linux under the GPL and thus the source under the GPL. but if we're just distributing ZFS as a standalone thing, this isn't really the same thing that the FSF discusses here right?
*dstolfa hopes that someone will have some experience with the law on the mailing list
<dstolfa>would be really nice to get an actual professional take on this
<nckx>I don't think your source-binary parallel holds, since the rules for either aren't the same, complicated by the fact that there are 2 licences to discuss and not just the GPL. But I am indeed no more a lawyer than Sweaty Joe down the street who lives in a box and sells expired cough syrup to children.
<dstolfa>nckx: the thing i struggle with is where the line is. it's easy to go through the ZFS on linux code and find a bunch of includes of linux headers, which are GPL'd. the thing i want to know is... why is that okay, but building it and giving it to thy neighbor is not
<dstolfa>and i fear that the only way to know the answer to that is court, which i doubt is in anyone's interest
<nckx>We really need an opinion on what *Guix* does. Our #:substitutable? #f hack is clever and fun and very clever. Do organisations like the SFC answer questions like ‘but does it actually work’ for free?
<nckx>Finding people to give free legal advice: hard.
<dstolfa>FWIW, regarding guix i think it's perfectly acceptable to say: "we don't want any part of this, brr scary"
<sneek>civodul, maximed says: I forgot importing (gnu ... bash) in (gnu ... xdisorg) in the ‘Add input for 'wrap-program'.’ series
<dstolfa>civodul: it doesn't answer my question unfortunately :( i've read through it a few times but never could reconcile why it's okay to include linux headers from CDDL'd code and redistribute that, but not building it as a standalone module which is modprobe'd and redistributing that
<nckx>It's not a bad link. And I'm sure there are good reasons for it not even explicitly mentioning the CDDL except in the background section.
***TheCreeper1 is now known as TheCreeper
<dstolfa>yeah, that article definitely answered a lot of the questions as to why it's a problem to put it in linux itself (and not assuming things is good civodul! i appreciate the link. if i didn't read it before, i would have learned something)
<dstolfa>alas... lawyer things are hard. sorry for starting a bikeshed (it wasn't intentional, i promise)
<vagrantc>ok, so *maybe* could work on the pinebook pro (4gb ram)
<vagrantc>any other resources it tends to consume? e.g. cpu?
<nckx>Noisytoot: ZFS is more mature and reliable than current Btrfs, although I don't know if that applies to the Linux port. It has more and more complete features that btrfs lacks, than btrfs has features over ZFS. These features do matter ‘at scale’ and in ‘the enterprise’. ZFS is still the only credible option there.
<vagrantc>oh, u-boot doesn't support btrfs ... so would have to fix the bug for a split /boot partition
<nckx>Btrfs is still struggling to reimplement RAID5/6 after they vastly underestimated it and designed a system that didn't work :-/
<vagrantc>bricewge: i haven't even tried in ages, to be honest :)
<vagrantc>oh, actually there is some support for btrfs in u-boot ... though it might not be enabled for pinebook-pro ... hrm.
<nckx>vagrantc: It provides system calls to deduplicate files you tell it are duplicates. It's more efficient than hard links but it's not native as in transparent. It would vastly speed up the final GC phase (deleting links) because you don't have to stat() the world.
<bricewge>vagrantc: Now there is a pcscd-service-type, that should the issues you had. Do you think it can be closed?
<vagrantc>bricewge: i suppose, i can always reopen or open another bug if i use it again and it doesn't work :)