<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
<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
<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
<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)
<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?
<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
<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 ...))))
<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
<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
<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
<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!
<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
<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
<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
<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>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 :-)).
<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.
<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.
<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.
<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
<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)
<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 ;)
<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
<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>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>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)
<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
<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.
<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?
<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>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
<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
<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?