<vagrantc>oooh, luks2 support for rootfs ... i might need to reinstall my original guix machine from scratch! :) *rekado_ fixes python2-numpy and related things on c-u-f <vagrantc>interesting... don't really have anything of great importance on there, other than dozens of old guix git repository worktrees of ancient branches ... so maybe a good candidate <jgart>Is anyone working on upgrading python-pandas? <bdju>oh god, lotta join/quit spam. <bdju>has anyone run into pavucontrol resetting their microphone volume? I'm trying to lower mine and watching it jump back up mid-talking <bdju>once to 100%, and another time oddly to 98% <bdju>nevermind, I think I figured it out. I was testing with vocaroo and it's apparently capable of changing my mic sensitivity system-wide. scary. <apteryx>SrainUser: can you patch its reference to libGL.so.1 (it's provided by mesa). <apteryx>it's trying to figure out the sweet signal/noise ratio spot or something <apteryx>there's probably an option to turn this off in its config if you don't like it <SrainUser>apteryx: It uses ctypes.util to find and load the desired libraries. Is there an example package that fixes this? <bdju>apteryx: well, after unchecking the box on vocaroo it stopped changing my volume anyway. not sure if other programs will try the same, though. <apteryx>SrainUser: I think it you substitutes libGL.so.1 by its full path it'll work <apteryx>that's the usual solution to these dlopen problems <apteryx>perhaps grep ctypes.util.load_library to see if it was fixed that way <apteryx>we have ctypes.util.find_library though <apteryx>SrainUser: never existed; are you sure it's not find_library? <SrainUser>apteryx: ctypes.cdll.LoadLibrary and ctypes.util.find_library <apteryx>so for find_library patch it absolutely <apteryx>the ctypes code is a bit of a mess, but for posix it seems to resolve to a dlopen call <apteryx>and dlopen accepts an absolute path (as well as a file name to be searched via ld.so) <apteryx>so yes, absolutely patch the refs in both instances *apteryx has some terrible idea try try with the cross-built rust <lilyp>Why do we let icedove still refer to "thunderbird"? (52cb5cf5b852117b5151a67af187d80764849ad3) <the_tubular>What do I add to my config,scm to solve "libvritd daemon is not working" ? <cehteh>libvritd << did you mean 'libvirtd' ? <cehteh>i mean do you have a typo in your config? <the_tubular>It probably is something like (service libvirtd-service-type) <cehteh>i have virtd on my laptop, but sitting on the desktop now <cehteh>yeah .. sometimes things are a bit hard to figure out unfortunally <the_tubular>config.scm:100:21: error: libvirtd-service-type: unbound variable <apteryx>the_tubular: try 'info info', learn the bases, then try 'info guix' <cehteh>its more the way the docs are written when you dont know guile and the parts guix adds <cehteh>has too much expectation on the user imo <cehteh>the_tubular: note that you need virtlogd as well <the_tubular>Umm, added : (use-modules (gnu services virtualization)) <mala>does a remote machine acting as an offloaded builder need access to the same channels as the machine whose store it's building? <mala>I'm getting an error https://pastebin.com/ZUQhWnS2 when i try to offload the build, even though guix offload test works. Not sure where to look for more detailed error or log messages, either... <the_tubular>Nvm got it, about to go to bed, doing too much typo ... <efraim>sneek: later tell civodul I'll narrow it. It only narrows the tests which are known upstream to have not working "sandbox 1" type support with glibc-2.33, so an actual tor configuration with 'sandbox 1' will fail on aarch64 and powerpc32. I was uncertain between leaving it broken (since it is) or disabling the test <efraim>sneek: later tell zimoun I'll let you know if I start working on updating julia. I was planning on waiting until at least 1.7.1 <sneek>civodul, you have 1 message! <sneek>civodul, efraim says: I'll narrow it. It only narrows the tests which are known upstream to have not working "sandbox 1" type support with glibc-2.33, so an actual tor configuration with 'sandbox 1' will fail on aarch64 and powerpc32. I was uncertain between leaving it broken (since it is) or disabling the test <civodul>oh beautiful, Unicode is so rich :-) <civodul>efraim: i think it's okay to remove "Sandbox 1" on those arches, but only on those, since otherwise the test is just not testing the same thing <civodul>you've dedicated a key to SNOWMAN WITHOUT SNOW? :-) <vivien>No, it is a default for altgr shift F on the BÉPO ANFOR keyboard ^.^ <efraim>I'll push the patch after I finish building on aarch64 <civodul>vivien: woow, the AFNOR normalization folks are having fun! <sneek>zimoun, efraim says: I'll let you know if I start working on updating julia. I was planning on waiting until at least 1.7.1 <zimoun>mothacehe: kudoo! This is awesome! It is becomi <zimoun>Debugging is becoming a game :-) <civodul>mothacehe: very cool! nicer than looking for the right dot :-) <mothacehe>thanks! it would also be nice to be able to switch between dot view and a new list view <civodul>great that you fixed ghc on i686, BTW! <civodul>mothacehe: yes a plain list would be nice too <zimoun>civodul: now, the c-u-f seems in good shape, no? What is missing for a merge? <rekado>so, my laptop battery ran out of juice, so I was forced to reboot into my most recent c-u-f system. <rekado>there are a bunch of problems stil <zimoun>rekado: laptop on x86_64 or i686? <rekado>2) I’m using wayland now, and I see that xorg-configuration has no effect, so my trackball won’t work as configured <rekado>even with “--migration” I can’t get it to start. The much older icecat works. <efraim>python-dbusmock is still broken IIRC <jpoiret>i didn't really think of it when adding support for wayland, but it's true that we'll need another way to specify configuration for GNOME/KDE/etc... under wayland <efraim>oh, it *only* fails on my computer, there are substitutes <zimoun>The question is thus: is it possible to make a Cuirass feature? <efraim>damnit, the rust crate rename patch I just pushed touched librsvg <zimoun>mothacehe: Or is it better to write something as a manifest etc/sources-git.scm? <zimoun>and last what is the specification ’source’? <rekado>icecat also corrupted my huge session state file. Had to restore my uncountable tabs from backup. <jpoiret>rekado: there is no universal way to configure libinput under Wayland using configuration files, it depends on the compositor. Sway has direct configuration of many things in its config, but for gnome you have to use the control center <mothacehe>zimoun: source is related to etc/source-manifest.scm. This specification builds the origin derivations of all packages. <rekado>perhaps we could configure this through the gnome service? <jpoiret>yes, I agree. Unfortunately that's GNOME's fault <rekado>or have a dconf service or something like that? <jpoiret>well, those settings must be stored using dconf, so we could use that <jpoiret>but i don't think it's a public API so there might be breakage in the future <jpoiret>in any case, existing Xorg configurations will not work under Wayland, so that's quite annoying <civodul>rekado: ah, so there are more usability problems than i thought on c-u-f, right? <civodul>to me the main problem left was librsvg on non-x86_64, which i'll work on ASAP starting from the patch i posted a couple of days ago <efraim>rust inputs are still a problem on x86_64 librsvg, I'm going to revert the crate source rename patch <efraim>the ~200 crates which are hidden inputs for librsvg <rekado>civodul: no, not yet, but I can give it a try on this system today <civodul>in particular, if we can just remove the LD_LIBRARY_PATH wrapper in GNOME, that's great <rekado>I’ll remove it, reconfigure, reboot, and report back <civodul>efraim: hidden inputs? and what's the problem, what are the symptoms? :-) <civodul>AFAIK librsvg basically works on x86_64 <efraim>on core-updates-frozen build librsvg and then drop the revert I just pushed and build it again <efraim>any changes to those ~200 crates rebuilds librsvg <jpoiret>i have looked at GJS source as well, if just removing the patch doesn't work i could look at it <efraim>we still need to tag them so they don't change *efraim goes AFK for a bit <jpoiret>that means for GNOME and friends that we need a whole new configuration system *rekado reconfigures without LD_LIBRARY_PATH now <rekado>jpoiret: I spawned a shell (in Emacs) and ran “dbus-update-activation-environment WAYLAND_DISPLAY” followed by “gnome-terminal”. <rekado>it still fails with: # Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: Process org.gnome.Terminal exited with status 9 <abrenon>if you distribute a guix.scm with a project, do you configure it so that it builds: <jpoiret>ah, that's a different error then, my bad (i think takes care to update the dbus env itself) <jpoiret>that's _EXIT_FAILURE_UNSUPPORTED_LOCALE <abrenon>1) the content of current folder, no matter its state (url ".") because you want to hack on your particular folder <ns12>Why doesn't Guix add binary releases of software to the official channel? Why does everything need to be built from source? <abrenon>2) the current branch, so that cloning the project lets anyone build the version they choose <rekado>jpoiret: indeed! dbus-update-activation-environment LANG fixes it. <rekado>no idea why LANG would be wrong, though <abrenon>3) main (or master) only, because it's supposed to be clean enough to be included as-is in guix' repos ? <rekado>could be the difference between en_US.UTF-8 and en_US.utf8 <abrenon>is there a recommended best practice ? <rekado>ah, this reconfigure will take forever: gotta build librsvg/inkscape/gtkmm first <jpoiret>rekado: I don't even know when LANG is supposed to be set, not in /etc/profile or .bash_profile <rekado>I set it in .bash_profile to en_US.utf8 <jpoiret>mothacehe: i see you've added support for swap-space in the installer, thanks! completely forgot about it <rekado>and LANG=en_US.UTF-8 after login. <jpoiret>i remember having problems on arch years ago with utf8 *rekado fetches the revert commit <mothacehe>jpoiret: no worries, gnu/system/installer.scm was also missing the swap-space record, breaking system tests evaluations *rekado removes sanity-check from python2-matplotlib <jpoiret>mothacehe: yes, that's because d48b404cf577cbfcd29b294e193a4db0c3e580b1 has not been merged into c-u-f yet <jpoiret>(stupid omission on my part, but testing with `guix system vm` didn't complain so maybe it removes the swap-space fields?) <jpoiret>rekado: I can launch gnome-terminal just fine with (locale "en_US.UTF-8") <rekado>jpoiret: having removed en_US.utf8 from .bash_profile I can start gnome-terminal fine now. <rekado>civodul: I rebooted into the LD_LIBRARY_PATH-deprived Gnome: it works fine. <rekado>I also started the gnome weather tool and it works <rekado>so I'll remove the LD_LIBRARY_PATH wrapping and close the bug <rekado>bah, *every* time I reboot Emacs behaves differently <rekado>I got a new color scheme now (it looks fine, it's just not what I used to have), and magit no longer works... <jpoiret>i think having a proper configuration interface for gnome is going to be messy <jpoiret>(configuring manually through the control center is still going to work though) <mothacehe>jpoiret: did you ever try the gnome recorder? i'm trying to use a screen recorder working on gnome/wayland <mothacehe>tries obs + xdg-desktop-portal-gtk without success <jpoiret>heh, i don't personally use gnome :) <jpoiret>xdg-desktop-portals are still kind of a mystery to me, haven't managed to make it work under sway <rekado>mothacehe: I successfully used peek <jpoiret>mothacehe: let me try obs + xdg-desktop-portal-gtk (can't find gnome recorder anywhere) <civodul>rekado: re LD_LIBRARY_PATH, nice! let's remove that wrapper :-) <jonsger>mothacehe: screenrecording on wayland is for the hard trying folks :) <civodul>i think it would have been enough to test in a VM, no? <mothacehe>the pipewire input source appears, let me select a screen but nothing happens then <mothacehe>jonsger: heh, gnome 40 + wayland works fine though :) <jpoiret>it's for desktop-portal-wlr but it should be the same for -gtk mostly <jpoiret>there might be a pipewire-media-session issue <rekado>mothacehe: oh, you're right! peek records my soul, but not the desktop. <civodul>efraim: re crates that librsvg depends on, yes, i'm not surprised, and i guess it'll be tricky to have "/fixed" variants of each of those crates <civodul>having the system depend on Rust doesn't make me happy <civodul>it's just too much of a sloppy foundation <rekado>another problem on c-u-f: shutting down from the Gnome menu doesn't do anything. In the logs I see that gnome-shell segfaulted... <rekado>(that's before I removed LD_LIBRARY_PATH) <dhruvin>(if you're a paying user) do try the guix image out. feel free to ask questions/report bugs/request features there :) <ss2>I'm not very familiar with writing tests myself, and can't come up with where to start at. <civodul>ss2: you can look at the SSH tests, where we basically ensure that we can connect over SSH to a VM that uses, say, openssh-service-type <mbakke>there are also NFS tests in gnu/tests/nfs.scm which may be interesting <rekado>I'm trying to build all packages in the bioinformatics module like this: ./pre-inst-env guix build --keep-going -e "(begin (import (gnu))(fold-packages cons '() (list (resolve-interface '(gnu packages bioinformatics)))))" <rekado>all I get is an error, though: guix build: error: integer expected from stream <civodul>c'mon, why didn't you give it an integer? <civodul>it may be that one of the packages has a substitute >= 2^31 B <civodul>to my knowledge, there are two such packages: flightgear, and repeat-masker <ss2>okay, thanks. It makes a little more sense now. :) <rekado>I'll remove repeat-masker from the list and see what happens <mothacehe> mbakke: both ganeti tests are failing on c-u-f, it would be great if you could have a small look :) <ns12>Hello, when using the gnu-build-system, how do I change the name of the makefile target used in the install phase? By default, gnu-build-system runs "make install". Is there a way to change it to "make install-full" instead? <rekado>ns12: you can override the 'install phase <ns12>rekado: Okay. Thanks. I just wanted to make sure that there isn't some build system parameter/argument that I could have used. <attila_lendvai>so, i cannot use a macro defined in the current module inside a gexp, right? <rekado>ns12: there's also #:make-flags where you can pass anything to the make invocation, but I don't know how you could use that to override just the install target. <attila_lendvai>maybe with a define-gexp-compiler? or is that a forest i don't want to walk into...? <mbakke>mothacehe: timely! I just upgraded my ganeti cluster overnight and discovered the same thing; it seems commit 1ed567c8721ec2810fdb70f1c6fc8396a705d503 accidentally omitted the output directory from GUIX_PYTHONPATH <mbakke>will fix later, I also have fixes for all the Django packages on c-u-f that I need to sort out <mothacehe>oh that awesome, it will probably fix the patchwork test that is failing because of a django package <mothacehe>then i'll have a look to the docker and nfs test so that we can finally have a 100% system test coverage <mbakke>civodul: I think mrustc works on AArch64, ref e765ad091d861c9 <rekado>we're still at ipython 7.9; 7.20 fixes the problem <efraim>mbakke, civodul: I'll test mrustc, and more importantly the rust version after it on aarch64. hopefully I have enough RAM&swap <rekado>7.20 builds fine; will try building related packages <rekado>(on c-u-f we're at 7.27, so no need to fix it there) <efraim>ok, attempting to build rust-1.40 on c-u-f on aarch64 <ns12>What happens when two packages place two binaries with the same name in bin/ ? <civodul>mbakke: so a different mrustc revision than the one we're currently using, right? <mbakke>civodul: I don't think so, it works on 'master' too with a much older mrustc; although some of the later rusts fails to build (IIRC). <efraim>huh, I noticed that %qemu-platforms is missing x86_64 <efraim>interesting that I removed i486 from %qemu-platforms but it's still listed in qemu <civodul>mbakke, efraim: ok, so concretely what's the status of Rust/librsvg on aarch64 on c-u-f? <civodul>i thought it was x86_64-only, and ci.guix seemed to agree, but maybe it was just lagging behind? <efraim>I think I ran out of ram building rust-1.39 (with mrustc) on aarch64, and when I built it using emulation on x86_64 I segfaulted while trying to build 1.40 <efraim>I'll add more swap to my aarch64 board, but it'll likely be hours before we find out if it works <rekado>still need to fix a lot of bioinfo packages for c-u-f <mbakke>civodul: mrustc itself builds, but some of the later rusts fail, efraim will tell us which :) *mbakke restarted a bunch of transient failures for aarch64 on ci.guix <rekado>so many of them use %build-inputs <efraim>zimoun: I'm also testing the i686 julia patches, currently building julia for i686, then I'll try all the julia-* package patches <efraim>gsl fails on powerpc32, i'll add that to my for-later list <civodul`>efraim: so Rust might be buildable in theory on aarch64, but not in practice, is that correct? <zimoun>efraim, cool! thanks. Are you trying on real hardware or ’-s i686’? <zimoun>and I have tried to improve the scalability of the precompile phase… hum, not working as expected. <efraim>civodul`: I think most people with aarch64 won't turn off substitutes, so if the build machines can do it once then it should be fne <zimoun>ok, I hope to have catch all the non-deterministic failure. <efraim>IIRC the overdrive machines had 8 GB of ram? <zimoun>jbv1[m]: do you use PackageCompiler? And SystemImage? I mean, if yes, do you have concrete numbers for 1) the time to build this SysImg and 2) the size of SysImg? :-) <rekado>how can I replace (assoc-ref %outputs "python") in a gexp? <rekado>this is in #:configure-flags or #:make-flags <rekado>for (assoc-ref %outputs "out") the replacement is just #$output <mbakke>rekado: I think you can use #$output:python or at least (ungexp output "python") <jpoiret>rekado: I'll try looking at the gnome-shell shutdown error <civodul`>efraim: have we seen a real aarch64 machine build Rust once? :-) <mbakke>hard to tell how it does on new 'core-updates-frozen' bootstrap as the CI thinks Rust is unsupported for aarch64 (which is probably the case, but still) :) <dhruvin>how do i add a (program-file "name" #~(gexp)) to manifest.scm? is it even possible? <dhruvin>i think we have specifications->manifest and packages->manifest, is there something for (program-file)? <apteryx>efraim, civodul`` : the problem with rust on non-x86_64 is not bound to rust itself but mrustc, which we used for bootstrapping <apteryx>civodul``: if we had a --wrapper-target argument, perhaps we could tarball a dynamically linked rustc (and its closure) as `guix pack -RR rust-i686-linux-cross --wrapper-target=i686-linux-gnu`, and unpack this into an i686-linux package ? <jpoiret>rekado: re the gnome-shell shutdown, it works for me in a vm as well <rekado>jpoiret: I'll have to try this later again. I saw a segfault reported on the first VT. <mbakke>dhruvin: it's not very ergonomic, but you can place a "computed-file" in your manifest with (manifest (append (list (manifest-entry (item (computed-file "foo" gexp)))) (manifest-entries (packages->manifest ...)))) <efraim>that looks like the error I just got <mbakke>a program-file won't work because it will be placed in the top-level of the manifest, which breaks some assumption somewhere...but a "computed-file" in e.g. $output/bin should work <mbakke>I wonder how to make gexps in manifests easier to use ... perhaps a gexps->manifest procedure? <ns12>attila_lendvai: Thank you for the link. <attila_lendvai>ns12, i made the patch to be able to have multiple idris packages with a bin/idris binary, and deterministically put the newest one in the profile after the union. but AFIAU, the union logic that i changed is used much more broadly than just the user-facing profiles and their bin/ dir. so, the latest version of my patchset is just a cleanup that adds more flexibility, but it doesn't change behavior. <PotentialUser-8>Should guix pull && ...reconfigure... be run as normal user or root? Or both? Does running it as root upgrade user package? <attila_lendvai>PotentialUser-8, guix system reconfigure will only work as root. and guix pull is separate for all users. <PotentialUser-8>Thanks. Does guixsd not use substitutes by default? The installation was too quick to be from source, but now I'm trying to upgrade and my CPUs are all 100% loaded and fans are spinning like crazy <dhruvin>mbakke: thanks for the links and advice <jpoiret>PotentialUser-8: note, when you `sudo guix system recofigure`, it uses the guix generation from your own user, not that of root <jpoiret>so you don't need to do `sudo guix pull` as well <jlicht>dhruvin: RE: the sr.ht stuff: amazing, thank you! <kwjc>I am so confused. How do I add more window managers to the cog wheel on the GDM sign in page. I tried following the video guide by distrotube (he followed the documentation) and it just resulted in not having a desktop environment at all. <rekado>I'll push a bunch of %build-inputs fixes later tonight <roptat>rekado, does that include things in maven-parent-pom.scm? <roptat>otherwise, I can take care of it myself tonight too :) <roptat>ok, then I'll take care of it :) <rekado>roptat: I'm building all the changed packages in bioinformatics; but we have even more in java*.scm <rekado>I'm having a problem with a package that uses python2-statsmodles <rekado>statsmodels comes with statsmodels/compat/numpy.py which does "import numpy as np", but it here "numpy" appears to refer to the *current* module and not the top-level module provided by python2-numpy <rekado>any ideas how to work around this in Python 2? <rekado>same with statsmodels/compat/pandas.py, which includes the line "from pandas.util._decorators import ..." --- this fails with ImportError: No module named util._decorators <roptat>oh I see we use that a lot in the java bootstrap... how come ci is able to evaluate some java packages then? <civodul>mbakke: the reference to Guix suggest they may think it's "just" a Guile syntax of the same underlying language <rekado>this fork-of-nix meme has to end <jpoiret>also, they want to use OCI for builds instead of their own compartimentalization <roptat>so should we fix all uses of %build-inputs? <vivien>Oh evolution fails to start on core-updates-frozen, because of a bad libsoup mix <jpoiret>mothacehe: iiuc we don't even have a session manager for pipewire packaged (not even the example one), so things shouldn't work very well for video <civodul>roptat: %build-inputs is still bound for instance in gnu-build-system <civodul>i maliciously let it unbound in a few fringe build systems to give people an incentive to switch :-) <roptat>civodul, ha, so that's why it's not always an issue <civodul>for which build system did you experience the issue? <roptat>I only found out about it by looking at a log file on ci though <civodul>and many packages rely on %build-inputs? <vivien>The debugging is easy: go through all inputs for evolution, find those that need libsoup 2, and make -with-libsoup2 variants out of them <roptat>civodul, probably not, it looks like most of the ones that use it in java.scm use the gnu-build-system <vivien>Actually it might be easier than that <roptat>I see 6 ant-build-system packages that use %build-inputs <vivien>Who is Maxim Cournoyer? I’d like to know if it’s safe to partially undo acd827be09a5d15734be9a09a88e1892d54f8dc4 to build with webkit with libsoup 2 (what about the CVE patch?) <jpoiret>that should be apteryx from my own understanding :) <jpoiret>we're still using pulseaudio, rather than pipewire, right? <jlicht>rekado: can you try 'from __future__ import absolute_import'? <jlicht>in python > 2.5, <3, this should give similar import effects as python3 <jpoiret>xdg-desktop-portals requires pipewire for its transport protocol <jpoiret>i'll work on this in a separate branch i think. has anyone successfully used xdg-desktop-portal in the past? <jackhill>I've determined that the audio piece is not as simple as running pipewire-puseaudio from a guix shell. I think I saw something that the rde folks were doing for pipewire <jpoiret>well, pipewire-pulseaudio needs to start the pipewire daemon too, and there might be some hidden things as well <jackhill>yeah, I figured I would need to get them installed in my default profile so dbus can find everthing :) <jpoiret>also, we're using system-wide pulseaudio, and most likely will need system-wide pipewire since we don't have an easy user shepherd integration with guix system <jpoiret>systemd binding sockets to autospawn the servers <jpoiret>other distros and upstream recommend user-wide servers rather than system-wide <jackhill>If we can manage it, that sounds like a good idea <podiki[m]>jpoiret: I use xcd-desktop-portal all the time (flatpak), but I'm not on wayland <podiki[m]>err xdg-desktop-portal rather, in particular the -gtk variant <podiki[m]>I had made a bunch of updates for them, but since I don't use wayland maybe that needed updates too <zimoun>samplet: thanks for the link. Using that, you do have rate limit, right? <podiki[m]>jpoiret: I can later today (not on my guix machine this morning); I do screen sharing with Zoom that has worked fine <jpoiret>oh, but you're using the zoom binary, right? on gnome? <podiki[m]>for that link it would need to be through eg a flatpak browser? <samplet>zimoun: Yes, but you can process 1K SWHIDs per call. <jpoiret>xdg-desktop-portal does more than just flatpaks <podiki[m]>yes the zoom (flatpak) binary, but just on a bare WM <podiki[m]>I have to make sure I launch my WM with dbus to get portals working <jpoiret>yes, that's normal. Weird then, I could swear that the communication between xdg-desktop-portal and xdg-desktop-portal-gtk happens through pipewire <podiki[m]>there were also bugs with an env variable for portals, which I fixed for the -gtk portal <zimoun>samplet, what do you mean “per call”? <podiki[m]>I think you can see pipewire being started in debug output <podiki[m]>if this is with pipewire updates, could be I haven't updated in a couple of days; I'll try later today <jpoiret>no, thanks for your info! i think it should be enough <jpoiret>i'll try making xdg-desktop-portal-wlr work on my machine first, then try with -gtk and obs in a VM <samplet>zimoun: You can check up to 1K SWHIDs in a single HTTP request. Therefore, if you are limited to 100 requests per hour, you can check 100K SWHIDs every hour. <podiki[m]>jpoiret: -gtk now propagates xdg-desktop-portal, I didn't look at the -wlr backend though <podiki[m]>so it should ("should") work just install xdg-desktop-portal-gtk and then the magic of dbus <jpoiret>i have installed in my profile anyway. I'm not sure if we should propagate it, since xdg-desktop-portal-... are plugins to xdg-desktop-portal <podiki[m]>I did that for -gtk to work around an env variable getting multiple variables, which is not supported upstream (my bug report has gone unanswered) <podiki[m]>so it would mysteriously fail since xdg_portal_dir (or whatever it was) had the (same!) value with a : in between <podiki[m]>and -gtk at least won't work without xdg-desktop-portal available (probably due to dbus, needs to be in the profile?) <jackhill>at leas with ungoogled-chromium (I think the x11 version as ungoogled-chromium-wayland was crashing sway, need to test some mroe there) with sway on core-updates-frozen and xdg-dekstop-portal and xdg-desktop-portal-wlr, I can't share non x11 monitors <jpoiret>when using manifests, with package transformations and such, can you use `guix package -u`? <civodul>jpoiret: yes, and transformations are preserved! <civodul>you can see that they're recorded in ~/.guix-profile/manifest <civodul>or if you do "guix package --export-manifest" <jpoiret>(by package transformations, i meant rewriting inputs programatically) <civodul>what's fun is when you use --with-latest <jpoiret>jackhill: it's very possible that on x11, chrome simply records windows itself rather than use xdg-desktop-portal <zimoun>jpoiret, and it is really cool! because if you do “guix pack --save-provenance -f docker -m manifest.scm” using transformations; and you share that image, it is still possible to get back the manifest and the transformations from this very same Docker image <rekado>jlicht: heh, that's what I'm doing already. Waited for the long build... <rekado>python-pandas is broken on the master branch <apteryx>rekado: perhaps just merge core-updates-frozen into master (if it works there) and be done with it? ;-) <jackhill>jpoiret: yeah, I definitely need to try again with the wayland varient and to see if the core-updates-frozen versions fixed the crashing issue. <jackhill>wf-recorder works, but I don't think that's going through the portals <jackhill>cool, thanks again for working on all of this :) <vivien>I sent the patch as 52246, apteryx you might be interested <vivien>I have another solution, we could upgrade evolution-data-server to libsoup 3, create a evolution-data-server-with-libsoup2 variant and use this variant everywhere except for the few packages that are fully libsoup 3 ***paren is now known as unmatched-paren
***jonsger1 is now known as jonsger
<unmatched-paren>is there a way i can apply patches to st while still keeping it installed through guix? preferably without creating some kind of `custom-st` package in my channel <unmatched-paren>i'm trying to find a decent terminal emulator that has all the features i want, and ironically st seems to have them all through patches <rekado>unmatched-paren: see guix build --help-transform <jpoiret>the declarative counterpart is with manifests: you don't need to create a whole channel for those <unmatched-paren>the only reason i use the eovim gui is to have both 1) true colour support and 2) ligature support/correct font rendering. for some reason, most terminals are either one or the other, except st <rekado>this libsoup 2 vs 3 thing is pretty annoying. Would it make sense to default to libsoup 2? <rekado>it seems like the vast majority of packages is still on libsoup 2 <rekado>this statsmodels business is such a drag <rekado>clearly this won't work with Python 2 without a whole bunch of patches. Why do they still declare that this version works with Python 2, then? <unmatched-paren>...and after a quick glance at suckless.org, it seems like st DOESN'T have a true colours patch :| <vivien>rekado, I agree, we should default to libsoup 2 at least until most of GNOME has migrated <unmatched-paren>anyone have any recommendations for terminals that fit the above criteria? even if they aren't in guix? <unmatched-paren>(kitty has true colours and ligatures but renders fonts really thin and it looks strange) <unmatched-paren>actually there's wezterm but that needs a newer version of rust than guix has (which is one reason why i submitted a patch to update it) <zimoun>samplet: do you think that when you check ’%swh-known’, is it possible to send a save request if the package is not there? <unmatched-paren>konsole also has everything i want but it depends on basically 50% of KDE <rekado>I'll downgrade python2-statsmodels and then move it to Guix Past. <florhizome[m]>unmatched-paren: alacritty? i've been using kitty so far, but you are kind of right with the fonts <unmatched-paren>florhizome: alacritty purposely leaves out ligatures because they slow down the rendering process <unmatched-paren>i, personally, do not understand why they are so obsessed with making a block of text in a window run at 1982938 fps <florhizome[m]>what about the default one on enlightenment, i heard good things... or do we have foot (wayland only though)? <unmatched-paren>florhizome: yeah, i use the jet brains mono nerd font, which i like because it's really thick and readable, but in kitty it looks really low quality <unmatched-paren>(foot, as far as i can tell, doesn't support true colours, only 256, and I use GNOME, which on Guix currently only supports wayland) <unmatched-paren>i like how the enlightenment things can be run without installing the entire desktop environment :) <unmatched-paren>hmm it has this strange fancy flashing cursor, and the text is absolutely miniscule... <florhizome[m]>yeah wayland on guix is kinda tough. i guess c-u-f will help. you should google carbonOS. its a project that substitutes mutter with wayfire (i can send you the build recipe for wayfire) <dstolfa>unmatched-paren: i used GNOME wayland happily on guix before i got tired of GNOME, what exactly are you having problems with? <dstolfa>the only thing i needed to change is to use SDDM instead of GDM <unmatched-paren>i've looked into wayfire, it looks really nice if you want something light, but i quite like gnome, especially the newer versions <jab>florhizome[m], I didn't know you could substitute mutter with something else in gnome! That's cool. Also, in my opinion sway works the best (as far as wayland is concerned) in Guix System. <dstolfa>there is some missing plumbing with gdm in guix to make it launch wayland GNOME. someone was looking at it a while ago, but i don't know what happened with it <jab>unmatched-paren, now that I think about it, I was using gnome on guix system for a bit. I think I disabled the DM, and just logged into gnome from the console. <unmatched-paren>jab: i've used sway before, but i switched back to gnome after failing to get sway to work on guix and then realized that minimalist is not always best <jab>unmatched-paren, I agree that minimalist is NOT always the best. <jab>I have 8GB of RAM. It felt like Gnome was too resource hungry for me. And I'm just used to the keyboard driven nature of sway now I guess. <florhizome[m]> jabi the DE in CarbonOS (GDE / Graphite DE) has a Bridge for that purpose. wayfire has plugins for gsettings and dbus already. i wouldn't be keen on it working on any distro but maybe with guix it could work. it would be nice since it could then be possible to plug wayfire into other gnome based stuff,too. <apteryx>rekado: yeah, moving to libsoup 3 appears to be a mistake in retrospect... but it's more future-forward (we'll be able to update pieces of GNOME as they come without rebuilding everything, or so it seems to me). <unmatched-paren>yeah resource hungriness is a little bit of a problem but i hear it's improved in 40 (which is coming to guix at some point, i presume) <unmatched-paren>anyway... `guix search terminal emulator` returns a few terminals, but most <unmatched-paren>others like st don't support true colours, and st isn't future proof anyway since it only supports x <unmatched-paren>...ok, what i'll do is i'll adapt the c-u-f rust 1.54 into a later-rust package, and put it in my channel, then add wezterm depending on later-rust <jpoiret>jab: the wayland patch for GDM is currently on c-u-f <jpoiret>we've been testing wayland c-u-f with it recently <florhizome[m]>apteryx: maintaining a working GNOME DE at all cost seems like something that guix (master) really doesn't need to do, or more: wouldn't it be beneficial to outsource that to a separate channel? <apteryx>vivien: what do you mean by partially undoing? What you suggest (using libsoup@2) is reasonable since it seems most of GNOME doesn't use libsoup@3 yet, but I wouldn't call this undoing (it's adding a change on top :-)). <jab>jpoiret, what is c-u-f? <jpoiret>core-updates-frozen, a branch that will soon be merged with big software updates <apteryx>florhizome[m]: do you think it'd gather more hands to help in a separate channel? I don't think so. At any rate, GNOME is here to stay (I think it's a very nice thing to have in Guix). We have it nearly all prep'd on GNOME 41 in the next release. <apteryx>for the next release* (on the core-updates-frozen branch) <florhizome[m]>apteryx: well it's been in my head for a while so i could kinda write a blog post. <jpoiret>the thing is, not having GNOME on the main channel would mean: no gnome in installer <dstolfa>i feel like guix picking up all of the software that follows FSDG and making it easy to use for end-users without having to add a bunch of channels manually is pretty important for a niche distro like guix system <dstolfa>there is already a huge barrier to entry for new users, it doesn't need to be even harder <podiki[m]>I've never noticed thin font rendering in kitty... <podiki[m]>but I'm on X and on hidpi (4k monitor) so might be the scaling I use too <florhizome[m]>(it's really good you can send messages straight from the minibuffer int ement now but how do i do new line without submitting...) - I think the problem that guix has with gaining contributors is moreso with having *slightly* high barriers: debbugs, texi, etc. Since a channel for gnome could be hosted in any way it could become a good entry. moreso: why exactly would guix get less contributions if it didn't have GNOME on master? my <florhizome[m]>assumptions are: a) it's not easy to maintain: it requires special focus; quite some problems i saw here come in regards to gnome packages. it also has a lot of packages that need a similar basis (and the range of versions gnome packages want seems to be quite thin) b) if it's true that it depends on systemd functionality, it could be a bad default for a distro that doesn't work with systemd but wants to be flexible c) given that the higher <florhizome[m]>barriers that i mentioned for guix master aren't going away soon,it would be good to lessen the burden for core contributors and maintainers to focus on improving guix itself. But it's just kind of a hot idea; to search for things that could be outsourced, and gnome as a ready DE (not the packages themselves) works out good. <dstolfa>and who exactly would be maintaining this hypothetical channel <dstolfa>the work still needs to happen, it would just make it more of a nightmare for anyone to install <dissent>hey guix. is there a way to remove all the packages that are listed in a file? for <dissent> example. I can't do guix remove emacs-* to remove all emacs packages. <dissent>so I put it in a file with the hope to run guix remove < <dissent>~/.emacs-packages -- but that also doesn't work. <dissent>hey guix. is there a way to remove all the packages that are listed in a file? for <dissent> example. I can't do guix remove emacs-* to remove all emacs packages. <dissent>so I put it in a file with the hope to run guix remove < <dissent>~/.emacs-packages -- but that also doesn't work. <acrow>maybe cat ./.emacs-packages | xargs guix remove <dissent>acrow: command line magic. that did the trick! thanks. <florhizome[m]>dstolfa: many ppl wouldn't even be able to use guix without installing channels, i think you're really overstating. well, it's just a thought i found interesting sharing, so no point arguing about who should do it. but as soon as some ppl would launch a gnome DE channel, and it runs for while, the thought could be revisited. <vivien>florhizome[m], if guix does not package GNOME, what would it use then? <roptat>it's already kind of a shame we don't have kde :p <florhizome[m]>vivien: it's not about providing packages, but about assuring they work as a DE in this argument. <samplet>zimoun: That’s an interesting idea. At this point, there are so few missing Git sources that it might be practical. <roptat>what are the formats that disarchive supports currently? <roptat>if I have a choice between multiple tarball formats (or zip), which should I choose? <florhizome[m]>vivien: i don't think just the availability of packages will be ever be an issue. most parts of kde seem to be available,too. <roptat>I think the main reason why gnome is taking so long to update in guix, is because they need to be updated at the same time, and there are a lot of components that depend on them too <vivien>florhizome[m], the problems with rust or libsoup are two sets of issues that break individual packages <florhizome[m]>roptat: and they need to be in one (system) profile,bc they form one DE, and you can't have multiple system profiles, or not? <jgart>yet another way to remove packages en masse <florhizome[m]>the concept of having des as services in the system profiles kind of seems to work easier with less demanding ones <sam_>gnome doesn't rely on systemd? <sam_>plenty of distros without systemd have gnome <sam_>a gentoo developer was paid specifically to make gnome work without systemd <zimoun>samplet, yes. Basically, reading your pog repo, it appears to me doable to automatize what I am currently doing by hand once your publish the report. :-) <florhizome[m]>vivien i'm not sure if i understood your question - guix already provides a bigger number of DEs. and i guess more can/will be added. <roptat>drakonis, we saw that link earlier :) <dissent>jgart: that is pretty nifty. thanks for that. <roptat>drakonis, ludo said "the reference to Guix suggest they may think it's "just" a Guile syntax of the same underlying language" <drakonis>honestly though, how do they propose even plugging guile into it <vivien>florhizome[m], sure, but most people expect to find big names such as KDE or GNOME. I don’t think we can all use XFCE or EXWM and be happy about it :) <florhizome[m]>sam_ i'm not an expert about this, but as i understand you will then need stuff like elogind that is just stuff cut off systemd. I did not mean to say it cannot be made to run without, but from your wording I feel confirmed it's not easy ;P <vivien>drakonis, maybe it means that it’s time to make our own implementation too ! <sam_>florhizome[m]: I don't think it's that hard. elogind is a separate project and it Just Works. <sam_>(although I'd like a better solution to (e)logind given cherry-picking/rebasing stuff feels a bit fragile) <sam_>i'm just saying it's not really a systemd dependency <sam_>a lot of distros use elogind without issues <zimoun>samplet: about graph or number, are they cumulative? Or for the last revision, say f43a783 (2021-11-28)? Because 2021-11-28 says 734 missing and 2019-05-05 says 1750. It mean that 734+1750 are missing, right? <florhizome[m]>vivien: I don't think guix is very attractive for ppl who are centered on running on of those two. If you argue for providing some more "polished" distros, I don't think elementary, mint ,budgie.. would be that hard to do. on the other side, as i've heard, on older hardware gnome doesn't even run that well. <bdju>does it matter if v4l2loopback-linux-module is in my system config or user manifest file? I see it's a kernel module, which sounds more system-y <florhizome[m]>sam_ as i said, not an expert, but I would rather "invest" in nonsystemd stuff, or make it easier to do so, and if an argument is, we want to have GNOME available in the installer, and that's more important,i'm just saying i don't need it there and i think it doesn't necessarily need to be there. <vivien>florhizome[m], I don’t argue for providing a polished GNOME or KDE, I just argue for providing a usable one. <dstolfa>florhizome[m]: perhaps you don't need it, but many people do. offering a free system that follows GNU principles is a pointless goal if the system is not usable to the majority <dstolfa>i don't need rust or go tools, and they tend to require a lot of maintenance and cruft. yet, i don't think we should remove them <sam_>just explaining that gnome isn't really systemd and if you don't want to include it, that's ok <sam_>but i don't think it being systemd is a reason <vivien>I’ve never understood the bad press around systemd, to be honest. Sure, we can’t use it with guix, but why does elogind suffers from the reputation too? <dstolfa>vivien: neither. it's free software trying to solve a useful problem (and is bound to have a bumpy road doing so given it works with really messy interfaces and is a critical part of the system) <attila_lendvai>is it preferred to send the documentation update as 1) a separate commit, or 2) in one commit together with the code changes? <dstolfa>attila_lendvai: i usually see it as separate commits when people send patches, but YMMV <nckx>attila_lendvai: Together. <florhizome[m]>vivien: as long as you only use those tools, you're fine, i guess ;) but guix has already decided to part with the center. <sam_>i mean maybe but people say that about all kinds of stuff <sam_>having it as an option doesn't mean you have to use it <nckx>But it does imply having to maintain it. <sam_>you won't find me advocating for adding random stuff without maintainers ;p <sam_>i'm just saying that you can use whatever reason you want to not include something, but it should make sense <sam_>not including gnome because it's too much work? fine <nckx>When rejecting something, sure, but it's not like there's anything to reject. <zimoun>basically 851 dependent packages <rekado>on upgrading gnome: it's not that it's praticularly difficult. It just hadn't been done for a long time, which means that instead of incremental upgrades a lot of things had to change at once. <rekado>it's getting easier now that all the work to get it to a much more recent version has been done. <rekado>I suggest not doing this on core-updates in the future, but on a dedicated branch. <rekado>yes, some changes will be world rebuilding, but it's probably not a good idea to mix this with all the other world rebuilding changes. <florhizome[m]>from the other direction: should guix maintain every de that get's commited, and ensure they work from the installer? if you have a limited "budget" then why must gnome be in it. <rekado>florhizome[m]: there's really no point in arguing it. I want Gnome in Guix, so even if nobody else would work on it, I'd do the upgrades by myself. <rekado>if you don't care enough about Gnome to contribute to having it in Guix that's fine. But others will do it. <rekado>on the other hand: I don't care at all about KDE. Others do, though. <rekado>so eventually it will get added. <florhizome[m]>actual issues though: enlightenment doesn't work and since my last system update sddm doesn't show up. i'm not sure if it's sddm though... <rekado>when something falls into severe disrepair we can always rip it out. <rekado>florhizome[m]: did you report a bug or is there an existing bug report about it? <rekado>IIRC efraim keeps maintaining enlightenment. <florhizome[m]>yeah that's why i think it's something that can be handled in a decentralized style more. if some ppl care a lot about a certain DE, they can just maintain it themselves. <florhizome[m]>efraim is aware about it, i think, he said he'll do somehting about it some time ago here. maybe he just didn't get to. <vivien>Maintaining a channel is more work than maintaining the same thing in guix proper, though. <attila_lendvai>what about introducing channels for stuff like gnome, and the installer would allow to automatically configure it if requested. a warning could be added that the channel is not officially supported/scrutinized/guaranteed by the Guix project. and such channels could have a wider set of people with the commit bit. <lilyp>Splitting everything about Guix into channels would somewhat defeat the purpose of Guix <rekado>the upgrade already happens on another branch. <lilyp>particularly if you make language ecosystems, e.g. Rust, even less maintainable than they currently are <rekado>and since it's just git it doesn't get more decentralized, just more complicated. <attila_lendvai>rekado, but in the same repo; i.e. you can't just grant the commit bit to more people who can only push to a subsystem <rekado>(I think the term "ecosystem" is especially poorly matched to whatever this thing surrounding Rust is) *rekado puts ecology hat back on the dusty shelf <lilyp>what we can defer to channels are stuff that is not free software for one (given Guix' policy against it), but also your-grandmas-fork-of-that-one-repo-that-hasnt-seen-a-release-since-2001 <rekado>attila_lendvai: someone's gotta merge anyway. So you can push to whatever fork you want. Someone's gotta merge in the end. <attila_lendvai>lilyp, i assume you can't split out rust because core guix packages depend on it. but if it's possible to split it out so that guix proper doesn't need it, then i don't see how that would make life harder. <lilyp>Even with Go, there's stuff like syncthing that end users typically want in core <zimoun>lilyp: I agree although on the other hand, all in only one channel leads to scalability issues (guix pull slower, guix search slower, etc.). <attila_lendvai>rekado, that's true for something like c-u-f, but is that true for gnome? what needs merging? gnome, and stuff that depend on it is in a separate channel (that sometimes need to follow guix proper API changes) <attila_lendvai>one of the bigger issues that i see as a newcomer is that there's not enough manpower to review and merge patches <lilyp>I think it'd make sense to use Emacs style channels here <attila_lendvai>splitting gnome into a separate git repo would mean less stress to hand out commit rights <lilyp>i.e. Guix itself still has GNOME 3.32 (or 41 soon), but the channel could provide whatever at the risk of your kittens <lilyp>I don't think we're that stressed to hand out commit rights either way :) <attila_lendvai>lilyp, oh, a mixed solution would make even more sense: guix proper provides whatever it provides, but the gnome repo is set up so that merging from it back into guix proper is easy. e.g. it could be a fork of the guix repo, then a commit deletes everything non-gnome, and keep the filesystem structure? <lfam>I think we could build upon the code-signing authorization system to create more granular access control when pushing to guix.git <lfam>It's very important for the long-term health of the project that work happens within the project, IMO <florhizome[m]>lilyp keeping everything in an official monorepo with gnu standards makes channels obsolete, would you say, too? ;P also i didn't argue for rust to be split away, i said not maintaining gnome as a DE -> not gnome libs and packages; could be something that's worth. guix has so many purposes, just opening a channel to defeat it's purpose seems hard ;) <lilyp>florhizome[m]: there is an important difference between "Guix can't make everyone happy" and "Guix can not provide this clearly popular desktop environment, that every major distro has" <lfam>I do think we should feel free to interpret "gnu standards" as we see fit within guix.git <lfam>The reality is that there is very little coordination between gnu projects or common interpretation of standards, where they even exist <lfam>So, the sky is the limit for how we decide to manage Guix <florhizome[m]>i'm actually glad the arguments so far have been towards gnomes popularity and not that it's a gnu project actually :D <rekado>florhizome[m]: having Gnome as a DE is clearly desirable for many of us. There is really no point in arguing otherwise. <rekado>also: push rights to the repo are slightly overrated. There should be more self organization, like what we're seeing with bioinfo or R packages. Who ends up pushing packages to the repo is not all that relevant. <rekado>so no: having the Gnome DE in a separate channel would not be worth the extra effort of keeping the channel in sync with "core". <lfam>Yeah, in the long term we should stop pushing directly and have some quality assurance / automation <lfam>It wouldn't have to be perfect. The most basic QA system would be more reliable *rekado goes back to doing QA for c-u-f ;) <lfam>Now that we are doing discussing whether GNOME should be part of Guix, we can discuss the utility of the i686 port <lfam>Like, if c-u-f is ready on x86_64, why wait? <lilyp>Hasn't there been a case made, that we don't want to x86_64 or dust our users? <lilyp>Bear in mind, I have no statistics on users by arch here and am a privileged x86_64 grill myself <lfam>I don't understand your first message <lilyp>IIRC someone pointed out in guix-devel that "works on x86_64" is not enough grounds to merge a channel. <lfam>Did you mean "x86_64 or bust"? <lfam>Well, I would say, "why not?" Especially compared to i686, which is really a dead platform outside of hobbyist use <lfam>If anything we should focus on x86_64 and aarch64 <lfam>But overall, why hold back from deploying changes that work on what is, by far, the most popular platform? <attila_lendvai>when i start a VM, shepherd is using a somewhat older guile than guix repl. is there a way to bring it to the same version? it misses something from (ice-9 ports) that i wanted to use... <lfam>Like, if somebody is still using i686, can we fundraise to buy them an x200? <lilyp>It's not like alienating hobbyists has no long-term consequences though. <ss2>heh, I'm about to install a Debian on an i686 tomorrow. :) <lfam>I think most "hobbyists" are on ARM or PPC <lfam>Does it provide a benefit for you compared to a newer computer? <lilyp>True, but again, no statistics for this poor privileged grill. <ss2>lfam: an old NAS, beeing given a second life. <lfam>Do you think you'll use Guix on it, too, ss2? <lfam>lilyp: It's true that hobbyists are an important demographic for a project like Guix. But if we alienate the "typical" users by delaying major updates for a long time in order to support i686, I think we'll lose more people <podiki[m]>i686 still needed for things like wine though....(cough cough) ***robin__ is now known as robin
<lfam>Yeah, but almost everybody actually runs it on x86_64 <lfam>And it's a very limited subset of packages required for Wine <ss2>unfortunately not, since the flash disk is connected by ide, which is limited by write cycles, has limited RAM, and I think in this case I'll jus put a quiet stable Debian on it. <lfam>Like, in the long term, what is the value of bootstrapping Rust on i686? There will be no new i686 computers. <lfam>It's surely the same price or even cheaper to find old x86_64 computers if one is trying to save money, recycle hardware, or avoid things like Intel ME <lfam>At least in the rich countries, 10 year old computers are basically free <lfam>Do the poor countries have a ready supply of i686? <lfam>Or did they miss the desktop computing era, and go straight to ARM smartphones? <lilyp>There is at least a lot of i686 waste there to salvage. <lilyp>Also, a smartphone is no replacement for a desktop PC. <lfam>I think there must be at least as much x86_64 <lfam>No, but my point is that people never used desktops in many places <lfam>The smartphone is where they compute. It's not a choice between desktop architectures, but between a phone or nothing <lfam>Especially since important programs only run on phones <ss2>lfam: chances are, that a lot of old hardware that was supposobly recycled from "the rich" countries where sold of to other countries. This is my understanding, and it could be totally wrong. <lfam>I wonder if the computers were kept in one piece or recycled into components and even raw metals <lfam>You can get a dollar for even the most worthless old components, I think because of the metals <lilyp>but back to the topic of i686, we already cross-built a rust for it, no? <lfam>My impression is we are still waiting to fix the support in order to finish c-u-f <lilyp>all it takes now is to insert our cross-built bootstrap binary into the chain for i686 <ss2>anyway, i686 is legacy. Just after taking this NAS apart brought back memories of the looks of old hardware. And there's no way any modern manufacturer is sticking to i686 anymore. <ss2>There was an article on lwm recently discussing the fate of 32bit systems and how 64bit has taken over the market, by large. <podiki[m]>I suppose there is the question of preservation though, which is different than modern support <lfam>I wouldn't raise a stink about things like i686 or armhf if I saw that a group of people maintaining support within Guix. Rather than maintainers heroically fixing it <lfam>But it seems like there is no userbase <lfam>Especially for armhf, since it's really a dead-end in terms of manufacturing and too slow for a build-from-source distro like Guix <lfam>At least there was high-performance i686 hardware manufactured, and it can still be competitive with favored hardware like the x200 <podiki[m]>is one of the biggest issues the encroachment of Rust into everything (and being difficult on x86)? along with things like tests failing due to floating point or memory constraints? <lfam>Just general lack of support and testing upstream <lfam>It means we spend a lot of time trying to fix things, for basically no users. Compared to support for x86_64, which "just seems to happen" <lfam>There needs to be a userbase who can support itself <attila_lendvai>oh, i guess updating guile (for shepherd) means recompiling the world, that's why it's lagging behind <ss2>are there statistics on how many packets from any repository being tracked? <GuixNewUserThatW>Hi, I'm new to guix and trying to package a font, which should be fairly easy, I mimicked a font package declaration from the guix channel, but it fails at the end. Where can I get help with this? <lfam>No ss2. I've advocated for it but 1) it's more work to do and 2) there is understandably resistance to tracking usage <lfam>But considering how things break and then don't get fixed for a long time, I think we can extrapolate that there are few users <robin>(imho POWER, as distributed by raptorcs and a handful of other projects, might be important for high-performance RYF workstations in the future assuming POWER10 ends up being RYF-compatible. maybe RISC-V too at some point which i haven't been following as closely) <attila_lendvai>and as expected, guile is updated in c-u-f... so, when will it be merged again? :) <lfam>attila_lendvai: When it's ready. Which depends on how we (everyone) decide when it is ready <lfam>I don't think that platforms without a future or significant userbase should be a factor in deciding "when it's ready" <ss2>lfam: okay, that is understandable too. It'd make things slightly easier, if there'd be a counter running though. ;) <guixy>Some tests in pyglet try to connect to an x server. <lfam>ss2: I mean, one with access could log in to the server and look at the nginx logs *attila_lendvai calls it a day o/ <lfam>But there is no systematic counting <lfam>guixy: It's possible to start an X server in the build container <lilyp>I think we can do a better job than Clang, Rust, Zig, etc. when we declare "fuck your system". <lilyp>It's really not a nice thing to say after all. <lfam>I mean, nobody is going to say it like that lilyp <guixy>lfam: Is there a package that does that? <lfam>But, who would we even be saying it too, lilyp? That's my point <lilyp>They're not saying it like that, but they are saying it. <lfam>guixy: Yes, search in existing packages for use of xvfb, using xorg-server-for-tests <lfam>I don't know, I think that's too inflammatory <lfam>If there were people using those systems with Guix, back when the distro was smaller and we could actually maintain good support for them, we would have noticed that people were sending patches, fixing bugs, helping out <lfam>But my memory is that it was actually a few heroes who supported things for themselves, or who added new platforms like armhf, before moving on to aarch64 <lfam>Compare to x86_64, which has a critical mass of users sending patches for their favorite packages, fixing and reporting bugs. We don't need heroes for platforms that are popular <jpoiret>alright, I just got screencasting working on wlroots in icecat <lilyp>Not to mention the breaking of Webkit <lfam>I think we'll probably see a lot more of webkit problems as Apple moves to ARM <jpoiret>still, i'm in need of a tad bit of help: to get it working, we need pipewire libs to be available to icecat at runtime. Should we add pipewire as an input? <jpoiret>podiki[m]: update xdg-desktop-portal-wlr, add wireplumber, run all of them manually. I still have to figure out how to let all of this work by itself <jpoiret>also let icecat have access to pipewire libs <jpoiret>i'm optimistic about it working on GNOME as well <podiki[m]>glad you got it working, xdg-desktop-portals had relatively big updates when I had updated them, but did not touch -wlr <jpoiret>well, the screensharing things involve a bigger stack (pipewire and friends) <lfam>That bug report is interesting because it's still open. There wasn't enough interest to get a real solution deployed <sam_>that is literally just a timeout <sam_>it's very common to have to crank it up for certain platforms <lfam>Yeah, I've done it myself in some packages <lilyp>lfam: Note that glib builds in CI on both master and c-u-f <lilyp>Chances are that people are just using substitutes. <sam_>(lots of distributions are still packaging e.g. glib for x86 without issues, including gentoo, and that doesn't look arch specific, so no reason to be concerned there.) <lfam>It could be that whatever userbase exists for build-from-source i686 is all on Gentoo <lfam>Because Guile is relatively slow, Guix has always tended to attract people with fast computers <jbv1[m]>sneek: later tell zimoun I have used it but not on guix, time to build and size of the sysimage varies with what you put in it. The default sysimage that is currently present in our julia package is the sys.so file I think, and it is around 200M. <sam_>honestly I've been surprised at how many folks are still using it. don't get me wrong, it's not a lot based on bug #s, but it's more than I expected? <lfam>Yeah, considering that the Core2Duo was introduced 15 years ago, it's very surprising <sam_>what i've noticed is, there's some folks who sort of installed as x86 (not amd64) because amd64 was "too new" even though their CPU supported it <sam_>but they never reinstalled <sam_>I remember back when people would say stuff like that <sam_>"32-bit is better supported" <lfam>And the last i686 hardware available was apparently marketed until 2011 <podiki[m]>I remember switching to 64bit with the the early Athlon(?) processor and needing to find one persons multilib repository for Debian.....so long ago now <lfam>Anyways, my point is not that literally zero people use these computers, but rather that the cost of supporting them in Guix is too high compared to the benefits <lfam>If we are delaying work significantly in order to support them, I think that is a mistake <lfam>And I think the hobbyist users are on new architectures such as aarch64, POWER, and RISC_V <lilyp>The less bugs we have to deal with post-merge the better <lilyp>and there will inevitably be bugs <lfam>lilyp: Of course, but I hope that there *will be* a post-merge <lfam>The current core-updates cycle has gone on so long that it is unprecedented for Guix <podiki[m]>about 4 years now since Arch also dropped 32bit <lilyp>you're not opening up laplace's paradox, are you? <lfam>The delay was caused mainly by other things than platform support, but still <podiki[m]>my first core-updates cycle is one to remember (it all started with trying to get Mesa updated) <lfam>spk121: Interesting, I didn't know that <sam_>lfam: (not advocating for guix to keep it at all, not got a dog in that fight) but I do suspect it'd be so much easier if it was easier to obtain patches other distros are using <lfam>The delay was mainly caused by problems with our CI system that have mostly been fixed now, plus the pandemic hurting people's motivation and preventing community-building meetings <ss2>lfam: sadly, that is very true. :/ <podiki[m]>seems like a lot piled up too: rust, gnome updates, libsoup, etc.; unlucky timing <lfam>I don't know, in the past we handled these things in less than 12 months easily <lfam>We lost a lot of important information when we switched from Hydra to early Cuirass <lilyp>like we got webkit building and that's it <lfam>It made it very difficult to evaluate the state of the branch <lilyp>everything else still needs soup2 <lfam>Still what we have is missing some crucial features from Hydra <podiki[m]>I feel like more feature branches would make sense, seems like chaos to have so many unrelated things pushed into one branch <lfam>The current workflow is due to be re-evaluated <lfam>I've been waiting to finish this cycle to really start that discussion <lfam>Feature branches are one thing, but actual "core" updates are not easier to do in isolation <podiki[m]>yeah, a good post-mortem of sorts to discuss? <lfam>Because they will break each other <podiki[m]>yet core-updates also gets packages that "just" have a lot of decendents, not necessarily breaking changes <lfam>However, like I said, we lost tooling when we left Hydra and it made it very difficult to evaluate what was working and what was broken <podiki[m]>so at least separating out that would make sense to me <lfam>It also made it impossible to do feature branches, which we used to do on Hydra <florhizome[m]>i just started thinking about that it would be nice to thin out "core" and somehow gnome was an easy victim ;) <podiki[m]>(my example is Mesa, it only required tweaks to a few packages in the end, if I remember) <lfam>Traditionally, mesa was not considered a core package, but rather something for the staging branch <lfam>The numerical guidelines for these branches are obsolete because the number of packages has increased a lot <podiki[m]>sounds like an easy place to make some changes <lfam>But like I said, without a CI that can show you if a change is working or not, it's impossible to efficiently make decisions <lfam>On Hydra, it was easy to compare two branches to see if a branch caused a lot of breakage. That's not a feature of Cuirass yet <podiki[m]>we had some discussion here (or on devel?) about leveraging the CI for building patches as they come in or at least using it more to spot failures <jpoiret>re opt-depending icecat on pipewire: how would i go about achieving that? for now I just launched it with LD_LIBRARY_PATH=.... to let it access the libs, but we can't really detect this at run-time, right? should we just make it depend on it? <lfam>That was the main tool we used to efficiently work on branches, and we lost it <lfam>A lot of us spent a lot of time trying to keep going without it but in the end we had to wait for Cuirass to mature <lfam>jpoiret: Does Icecat have the ability to check for pipewire when building and record its location? <lfam>jpoiret: Like, is there a check for it in Icecat's build configuration scripts? <jpoiret>i don't think so, it's not a build flag <lfam>But, it can use pipewire? <ss2>lfam: I am not following the development of Cuirass, but are missing features found in Hydra planned to be implemented in Cuirass? <lilyp>oh, right, remembering icedove <lilyp>my connection went down someday today, did anyone answer the question I've asked? <lfam>ss2: I don't know at this point. I believe there was funding to fix bugs in Cuirass, and that's why Cuirass is working well now. But I don't know the state of Cuirass development looking forward <lfam>jpoiret: Someone will have to try adding pipewire as a dependency of icecat, build icecat, and then check if icecat keeps a reference to pipewire. If it does not, then pipewire will be eligible for garbage collection and the feature will stop working whenever that happens. <lfam>jpoiret: `guix gc --references $(guix build --no-grafts icecat) | grep pipewire` <jpoiret>well, we have the wrap-program phase already for icecat that adds a lot to LD_LIBRARY_PATH <lfam>I guess that's the thing to try, then <jpoiret>i could try, but my poor laptop won't handle it i think <lfam>jpoiret: If you can write a patch, I can test things on a fast computer <lfam>Send your patch to <guix-patches@gnu.org> <jpoiret>in any case, i think it's purely runtime-dependent <lfam>You don't have to build your patch all the way, but make sure it at least passes the configure phase <jpoiret>i'll grep the firefox source to see exactly where it is loaded <jpoiret>i mean, it even uses a vendored pipewire to build <lfam>It's important that we don't forget what we used to have and how useful it was, or the development of the distro will be hampered forever <jpoiret>well, i need to write a bunch of patches anyway for xdg-desktop-portal stuff and test if they work poperly <lfam>Like, even with the recent big improvements in Cuirass, it's still not as good as Hydra. But our Hydra instance couldn't scale to keep up with Guix's growth, and nobody involved in Guix wanted to maintain it anyways (it's Perl). <lfam>So, it made sense to start anew. But then Cuirass development was halted early <lfam>I think of that history as a small disaster for the Guix project <lfam>Obviously our growth continues, but it could be faster and less buggy <ss2>It could change though. I mean, then it may be the case that Guix is having a bit of a low with it's pace. But that can surely change. <ss2>I thought of that recently, and there will be other days coming. I can only sense just how much the next release will lift so much weight of some shoulders. <apteryx>lfam: I find i686 very useful to test cheaply things on another platform. Things broken on i686 are often broken on armhf too <lfam>Interesting, apteryx. Although my advocacy for dropping i686 and armhf would solve the problem too ;) <lfam>ss2: It would be amazing to think this is a low in terms of pace. Compared to when I joined in 2015, the pace is dizzying <lfam>There's clearly a lot of appetite, considering the volume of contributions <lilyp>let's say a local minimum then :) <lilyp>particularly on master, since lots of folk are busy fixing stuff on c-u-f <florhizome[m]>i actually had some problems, does someone want to help me with a) sddm boot failure (if its sddm, fault) b) struggles with custom services <lfam>I definitely think we are at a local limit <florhizome[m]>i truly think guix is only at the startof it's potential ;) *dreamyeyes but it's circumstances kind of require much work to progress <ss2>lfam: I haven't been here long enough to see a big difference. <lfam>In 2015 it was possible to read every email <ss2>The community must have been much smaller then too. <lfam>You can compare, for example, `git shortlog --numbered --summary v0.8...v0.9.0` to the equivalent command for v1.2.0..v1.3.0 <lfam>And it's also interesting to pass --committer, to see the number of committers grow <rekado>it only worked because Mark kept intervening <rekado>it was a big hit, though, to lose features <florhizome[m]><florhizome[m]> "i actually had some problems..." <- any volunteers (: <rekado>we were aimlessly flailing without the overview <rekado>it's gotten *much* better, but I still find it difficult to see at a glance where we're at <rekado>the new dashboard is helpful (for people who can distinguish green from red) <rekado>but it took me much too long to realize that a whole bunch of packages are currently broken on c-u-f <rekado>I essentially had to build them systematically by myself on my laptop to see that something's terribly wrong <rekado>(the gexp change, for example; or the Python sanity-check phase) <rekado>we dumped a whole lot on the core-updates branch that ideally would have been several short-lived branches <rekado>seeing the direct impact of changes compared to the baseline is invaluable feedback. <lfam>I think the short-lived branches weren't a viable option until recently, when Cuirass was improved <lfam>Hopefully we can get an evaluation comparison feature soon <rekado>re i686: I'm still using one of these machines, and upgraded the CPU of our T60 from i686 to x86_64 about a year ago. That said: I agree that i686 *users* need to be able to sustain maintenance. <rekado>if there are not enough i686 users who can keep the ball rolling then I'm afraid i686 support will need to go down the same way where mips ended up. <rekado>I feel that we've improved with regard to the dire situation of x86_64 dominance just a few years back. But it's aarch64, power, and maybe riscv(?) that pulled the cart out of the muck --- not i686, mips, or armhf. <lfam>I wonder if there is an actual bug report / feature request for "compare evaluations in the Cuirass web interface"? That's kind of the first step to making it happen <lfam>In my opinion, aarch64 is the most promising competitor, by a long shot <lfam>It started with low-price options like the Pi, and just keeps getting faster <lfam>It's difficult to begin with expensive choices because you don't grow a big userbase quickly that way ***sneek_ is now known as sneek
<rekado>I think it's a little funny how concern for armhf-compatibility has literally held back our purchase of ARM build nodes. <lfam>So you can spend $30 or $30000 and the aarch64 software will run on either machine <lfam>It's hard to buy armhf build nodes, because there are few options that are worth using in that way. And since aarch64 is so good, I don't predict that new armhf designs that are capable of sustained load will be created <lfam>I remember Bunnie pointing out that the Novena was obsoleted by the 64-bit Pi <lfam>It's a stark progression <lfam>But if we could acquire high-performance hardware capable of building for armhf, it could help keep the port alive and make Guix viable on low performance armhf hardware <lfam>It's easier said than done, as you know <jpoiret>damn, firefox vendors a lot of dependencies in its build code! <vagrantc>the honeycomb lx2 should be able to build armhf <vagrantc>if you have to, you can make virtualized armhf machines running armhf kernels <vagrantc>doing that for reproducible builds on aarch64 hardware <vagrantc>for debian, but ... should work the same :) <vagrantc>32-bit arm with a particular set of extensions <lfam>Right :) vagrantc is more correct <vagrantc>clearly you used shift or capslock or something, figured that would buy me time <boomerChad>Status on openjdk@17 ? I see an issue open for a patch that seems to be working but it's not listed as a package that's available. <vagrantc>the middle-generation raspberry pi would run armhf <lfam>Almost every popular 32-bit ARM SBC was armhf <vagrantc>with the exception of the first-generation raspberry pi, e.g. pi1 and pi-zero <lfam>Also the Beaglebone, the Cubieboards, some of the Odroids <rekado>boomerChad: could you share the issue number, please? <lfam>Contemporary smartphones are faster than any SBC. The good chips all go to the phones <florhizome[m]>I would really like to free up some tablets but it seems to be pretty hard :/ <vagrantc>yeah, picking platforms that weren't made with the intention of making them at least somewhat open are generally hard to get working well <rekado>boomerChad: thanks. I'll try to build it later. <florhizome[m]>yeah i guess lots of good computers will go to the bin running android 4 or so :// <lfam>I like this line from the LWN article on 32-bit computing: "The Cortex-A9 managed to surpass practically all competing 32-bit cores of the time." And that design is considered hopelessly obsolete at this point <lfam>"Cortex-A9 and Cortex-A7 together with their 64-bit counterparts have replaced most other 32-bit architectures in embedded systems, including the MIPS32r2 cores that were common in wireless networking SoCs until about 2017." <florhizome[m]>even though there are some projects dedicated to that, they seem to be mostly for google phones and those are diminishing in number :/ <jpoiret>any idea why lisp-fill-paragraph doesn't fill to where it's supposed to? (i've set emacs-lisp-docstring-fill-column to nil to have it use fill-column directly instead) <jpoiret>erm, that's because i want to format the description field of a package properly in emacs <guixy>Pyglet's tests are taking longer than expected. Should i look into disabling some of them? <guixy>I'm talking more than 40 minutes <guixy>Ok, fixed. Pyglet is now successfully packaged. <jpoiret>rekado: any reason you updated pipewire-0.3 on c-u-f rather than on master? <jpoiret>which I only stumbled upon AFTER packaging wireplumber