IRC channel logs
2025-02-26.log
back to list of logs
<ieure>coyotes4ys, No hardware OEM cares much about open-source support for their hardware, but the low-volume, low-margin manufacturers like GPD least of all. <coyotes4ys>i don't care about open-source either. i care about Free Software. that's why i am here <ieure>Well, if we agree the Free Software > Open Source (which I think we do), I'm saying they fail to clear an even lower bar than what we'd like. <coyotes4ys>can i get a confirmation on this wakyct podiki nckx ? you all have helped me before. many newer systems need proprietary blobs to make the sound work? <coyotes4ys>i need multiple people to back this up, because it is a huge change if true. not saying i don't believe you ieure it is just such a huge thing i need confirmation. <podiki>I'm not sure as i do use linux (not linux libre) and also just using builtin sound from motherboards <ieure>Search literally anywhere, it's not a secret. <coyotes4ys>i don't doubt you ieure, i just said that. and the information about this doesn't necessarily point to a summation that soundcards used to not need prop blobs, and now increasingly do, does it? <podiki> i don't know anything here you can't search also, sorry <ieure>coyotes4ys, I'm speaking from firsthand experience of owning several laptops. ex. the ThinkPad X1 Carbon 6th gen didn't need blobs, but the 7th and later do. <podiki>i would listen to ieure, they provided sources and experience <podiki>(i also haven't used guix on a laptop) <coyotes4ys>i am listening to ieure, but i am also seeking confirmation from multiple sources. <ieure>coyotes4ys, I don't know if *your specific problem* is that you need blobby firmware. But I do know that such hardware is now prevalent enough that figuring out whether your hardware needs it is pretty much job #1 if sound doesn't work out of the box on Linux. <ieure>Like I said, figure out what level of support even exists for your hardware, then figure out how to make what is supported work in Guix. <coyotes4ys>proprietary blobs being necessary for certain hardware has been a major problem for a very long time <divya>ieure: With regards to the Thinkpad X1 Carbons, are you speaking of blobs not being present for sound specifically or that it generally works fine with linux-libre for everything? <jA_cOp> In the last couple of weeks I have been setting up GuixSD on a GPD Pocket 4, which has similar hardware to the Steam Deck. I think the power management stuff would probably work on linux-libre, but wifi didn't. I also didn't test sound on linux-libre but by the sound of it, that probably wouldn't work either <coyotes4ys>they really mix up hardware on different models so i wouldn't jump to conclusions <coyotes4ys>plus the libreplanet list doesn't show anything past 2018 so at least for that page, there's no way to get an idea, even though there are several pre-2018 soundcards on that list it seems. <jA_cOp>right, yeah. Also, while I'm pretty happy with the Pocket so far, I am concerned about longevity; GPD provides a two year warranty, but I used my last laptop for 10 years and am hoping I can use this for the next 10 <coyotes4ys>here's hoping for you. and me maybe, unless this turns out to be unworkable without proprietary firmware for the soundcard, in which case i might be done with computing except for old systems and moving offline and offcomputer moreso in life. for freedom! <coyotes4ys>i have been hitting this trail hard for awhile now <elevenkb>Hi people, when are we getting Emacs 30 in guix? <jA_cOp>coyotes4ys: at least with a Guix setup it's easier to migrate to different hardware. I like the idea that I could parameterize my config a bit and use it to setup the same environment on my old Thinkpad X220 <jA_cOp>But yeah, the firmware situation sucks, and it's especially aggravating for mobile computing where you want low-weight, energy-efficient hardware. The situation for Android phones is even worse than for laptops. So much e-waste because of how Android OEMs treat the kernel. But postmarketOS helps, even if it's not quite linux-libre <divya>elevenkb: Hopefully by today! I'm checking it currently and if everything builds fine, it would be available in the latest guix pull <ngz>Kabouik: It should be #:recursive? #t <divya>Kabouik: (guix) origin Reference in The manual would tell you that if you enable (recursive #t), it will recursively fetch all the submodules. <divya>This should be in a (git-reference) <divya>Also, do we have any issues/pains in packaging Java applications? I just realized that Ghidra isn't yet packaged in Guix, while it's Apache-2.0 licensed. <divya>csantosb: Hello, I just checked that GHDL is available through Guix Science channel, is there any reason we can't have it upstream guix? I checked in GHDL github that only providing binaries of it is possible, or are we able to build it? <theruran>GHDL is written in Ada, which isn't packaged by Guix 🤷♂️ <RavenJoad>divya: I wondered the same thing and like theruran said, Ada need to be packaged. GCC's Ada cannot be bootstrapped through GCC alone. I have been toying with the idea of implementing an interpreter-based set of tools for Ada to bootstrap GCC Ada with. But that is far off from now. <divya>RavenJoad: theruran: I totally forgot the Ada part. I thought Ada folks would've already taken care of the bootstrapping part. <theruran>RavenJoad: you should get in touch with Irvise. many of us want to solve the bootstrap problem. we tracked down the GNAT lineage and it could theoretically be bootstrapped from GCC ~3.19 up to current. FreeBSD Ports tries to bootstrap it from GCC 6 <theruran>it requires writing a new compiler or interpreter, or extending Ada-Ed to Ada95+ and no one wants to touch C code :) <divya>A new Ada compiler from scratch....? <theruran>I learned that it was a big discussion in GCC dev back in the day, and somehow the maintainers were convinced that writing GNAT in Ada was gonna be OK. but the bootstrap is completely lost, done with a proprietary compiler no doubt <theruran>GNAT is Ada95 with some source files in UTF-8 <theruran>anyway writing a Guix recipe starting from an old GCC version should be OK to mitigate the risk of Trusting Trust <theruran>but ideally we want a full-source bootstrap <RavenJoad>Yeah. I am thinking a bad interpreter in Guile might be enough to kick off the process, depending on how much we need to support. <theruran>whenever I finish my PhD I'd like to work on it. 💀 <chipb>huh. how does debian build gnat? <theruran>I think they bootstrapped from old version of GNAT. Irvise had a suggested Guix path based on the Debian packaging, but I forget exactly <RavenJoad>theruran: Similar boat here. I need to get some papers out the door, hardware working, and other open-source contributions closed before I can work on anything Ada-related. <theruran>contrary to popular belief, the Ada83 spec is only 300-odd pages. one way would be to bootstrap to Ada83 then write the Ada95 compiler in Ada83 <theruran>or I guess you could do that with Ada-Ed lol. I don't know how complete it is though. <RavenJoad>That would be another way to do it, but the question is: Is Ada83 used enough to be worth it to write a bootstrap interpreter/compiler for Ada83, then write another compiler for Ada95? Or should a bootstrap interpreter just start at 95? <theruran>yeah, if you have an Ada83 compiler, you might as well extend it to Ada95 <theruran>Ada83 is interesting as a bootstrap language because of how old and well-specified it is, and relatively simple, lacking OOP. it does specify tasks though. <RavenJoad>I mean, if the spec is nice and thorough, writing an interpreter to meet it might be easier and then jumping to 95. Ahh... Well... Perhaps some day I'll get around to it. <theruran>personally I think it would help revitalize the Ada community <theruran>we are tired of GNAT shenanigans but it is the only option right now. <RavenJoad>I just want my own hardware language to be able to be "one-click" development. Just "guix shell" in the thing and you get Verilator and GHDL to simulate outputs from my compiler. <RavenJoad>But, one step at a time. I'm calling it for the day. Cheers Guix! <zkryh>Any Ardour users here that have the jack backend working? I'm getting an undefined symbol error preventing Ardour from even showing jack as an available backend <ieure>Is there a Guix equivalent of README.Debian? A place to put notes specific to the Guix packaging of a thing? <wingo>but guile no longer uses that gmp api and does not install those memory functions <wingo>hmm, my guix checkout is old, perhaps i am wrong <wingo>indeed, it is still the case <unmush>I would like to bring to your attention a most fascinating result: <unmush>scheme@(guix-user)> (use-modules (gnu system setuid)) <unmush>scheme@(guix-user)> (setuid-program (setuid? (not #t)) (program #f)) <unmush>$1 = #<<privileged-program> program: #f setuid?: #t setgid?: #f user: 0 group: 0 capabilities: #f> <rekado>unmush: same with (define no #false) (setuid-program (setuid? no) (program #f)) <rekado>not so weird when looking at the implementation <rekado>(setuid? (match (assoc-ref '((field value) ...) 'setuid?) <rekado>it's only matching on a literal #f <rekado>the module comment says: "Do not use this module in new code" <rekado>(privileged-program (setuid? (not #t)) (program #f)) does the right thing. <efraim>I would quote the next sentence: It used to define data structures representing setuid/setgid programs <efraim>it's not actually creating a setuid binary <unmush>right, it does when it's used to define an <operating-system> that is used for reconfiguring though <unmush>so for example, if you had written a service in the past that added some setgid programs, and you used anything other than a literal #f for specifying that they weren't also supposed to be setuid, on upgrading and reconfiguring they will now be setuid <zkryh>Can confirm, I am also able to pull again <x8dcc>Hello, I am still trying to fix my keyboard layout issues in Xorg. Instead of using my own 'startx.sh' script, I was trying to figure out what was wrong with the 'startx' script from the 'xinit' package <x8dcc>It seems that it's trying to look for the 'X' binary in the 'xinit' store path, instead of on the 'xorg-server' one. If I look at 'gnu/services/xorg.scm', though, 'xorg-configuration-server' seems to be (default xorg-server), which is used in 'xorg-wrapper', which is supposed to generate the 'startx' script <x8dcc>If anyone with some more experience can help me, I would appreciate it <iyzsong>x8dcc: you can use 'startx-command-service-type' which provides a working 'startx' command or 'xorg-server-service-type' with 'sx' installed to launch X without a display manager. the keyboard-layout field had to be specified twice, once for the tty, once for the xorg server. <zkryh>I have asked a few times over the last few days, but will keep asking... Does anyone have Ardour working with jack on Guix system? I'm getting an undefined symbol (jack_client_stop_thread) error, and want to make sure I haven't just set it up wrong. <x8dcc>Yes, I have specified the keyboard layout twice as well, like you. I don't think I am using 'startx-command-service-type', though. I heard that 'startx' was pretty much broken in guix and that's why I made my own script :) <iyzsong>x8dcc: okay, then you can use 'xorg-server-service-type' which make a configure X under /run/current-system/profile/bin/X, so that xinit or sx could find it. <x8dcc>iyzsong: What's the difference between the two? 'startx-command-service-type' and 'xorg-server-service-type' <x8dcc>Because I don't use either right now <iyzsong>x8dcc: set-xorg-configuration only works for the gdm display manager <iyzsong>x8dcc: startx-command service make a configured 'startx' command available system-wide, while xorg-server service make a configured 'X' and 'Xorg' command available system-wide, to use the later you also need install 'sx' (works out of the box) or 'xinit' (need some tweaks in xinitrc) package. <x8dcc>I see. I am trying 'startx-command-service-type' now <ngz>I think our gpm package is incomplete because some packages have troubles finding its shared library. <wingo>builds fine, but the tests fail, in an odd way: it fails to find version.test. <wingo>like, it runs all the tests, but gets to version.test, and doesn't find it. <wingo>hmm, maybe i should upgrade my guix, maybe it is an automake bug or something <wingo>UNRESOLVED: tree-il.test: warnings: unused-toplevel: used by macro <wingo>make[5]: *** No rule to make target 'tests/version.test', needed by 'tests/version.log'. Stop. <wingo>i was just quieted or something <wingo>then an upgrade here will surely fix the issue <wingo>cbaines: should you want to bump guile-next again, hoot would appreciate it ;) commit c8a169d38825d5a21da5392b355ca5fc9f33fa55 / sha256 01gqf6c9rnr5l8qralfwq23xmfxbnim1kqppgrd2l42pak3rm9c2 <wingo>anyway, building downstream for now <dcunit3d>is there a place where I can place modules/scripts with packages that's outside of the guile %load-path? so that i don't get deprecation warnings? <dcunit3d>i'm reorganizing code in my dotfiles. i read through ch3 & ch4 of the Guile manual a bit more deeply. <dcunit3d>so is it appropriate to just have a ./scripts directory outside the project's load path? i'm sure there are a few hiccups <dcunit3d>if the functionality was more complex, then i would simply branch or stash <mra>new screen for my laptop arrived today I can finally see <mra>yep. ordered a new panel and an LVDS-eDP converter off of aliexpress <ieure>Oh neat, LVDS, must be a classic. <mra>yeah I use a ThinkPad T430 day-to-day <ieure>Oh nice, that's a good one. I still have my modded X230, but don't use it daily anymore. Has the X220 keyboard and IPS display, fortunately the panel's a drop-in upgrade on that model. <mra>oh, that's nice. I have a t420 too that I found in a junk bin in Tokyo for ¥3000 <ieure>I have an array of older ThinkPads I rotate between just for fun, have mostly been using the P53s lately. <mra>my computers are generally just glorified latex compilers, so I don't need much compute <phfrohring>Hello Guix. I'm searching for a minimal LaTeX installation, just enough to produce a "hello world" PDF. Is "guix install texlive-base" what is supposed to be used for that? <phfrohring>Well, `guix install texlive-scheme-basic' seems to be more appropriate. <ngz>phfrohring: texlive-scheme-basic is really only useful for TeX without LaTeX. I suggest texlive-collection-latex or, possibly better, texlive-collection-latexrecommended <ngz>hmmm, no texlive-scheme-basic is actually equivalent to texlive-collection-latex, so you can scratch that part. However, my suggestion about texlive-collection-latexrecommended still holds. <wakyct>this is what I get for not reading HN for a year I guess <ieure>wakyct, Not sure when it landed, but it's been on F-Droid for over a year. <wakyct>though in typical Emacs fashion, now my search for an Android notes app will turn into a full Emacs install <chipb>has anybody started using it as an android launcher replacement yet? <Kabouik>I have had it installed on an Android phone for a while now but I never really use it because it doesn't seem to trigger the virtual keyboard, and the file hierarchy and permissions on Android are a bit discouraging for me. However, on another phone running Droidian (Debian on Android kernel), I have my full-fledged Emacs config with a billion of packages, exactly the same bundle as on Guix (and I also have Guix package manager on that phone)… And <Kabouik>it has a keyboard, so I'm right at home. <ieure>Keyboard support on phones is always dicey. <Kabouik>True but not when the OS is Debian and the keyboard is a full qwerty slider (not a BT one). <ieure>I have a Bluetooth chording keyboard I think could make the situation more tractable, but then I get into territory like needing a YubiKey to clone the repos with the stuff I want to use in Emacs. <ieure>What phone is running Droidian? <ieure>Lack of battery is the curse of all older portable stuff :( <Kabouik>From me probably, I'm annoying with that I'll admit. <ieure>Similar problem with old ThinkPads, your choices are used OEM battery in poor condition, brand new third-party battery that won't last a year, or new in box OEM battery that sat on the shelf until it drained to 0%, which kills the BMS. <ieure>I bought a couple NIB X230 batteries, I charge them up once a year or so. <mra>I did see someone who hacked together a homemade battery. it was mildly horrifying <mra>looked like a bomb-in-waiting though <ieure>Yeah, I've seen a couple attempts at recelling, but the packs aren't made to be serviced. <mra>yeah. it's one of my only frustrations with my laptop. the battery life is pretty crap and there isn't much I can do about it <mra>maybe someday it'll die and I'll have an excuse to buy an MNT laptop <ieure>Love the idea of the MNT, not sure they'd work for me. I think the graphics stack is Wayland-only, which presents issues for my preferred EXWM environment. <dthompson>so I am finally breaking down and installing something with flatpak, the latest build of Epiphany, however it just crashes on boot. are there any good resources for guix + flatpak? <mra>ieure: ah, I've been Wayland-only for years, which is funny considering ive never found a compositor that I like <dthompson>I'm just trying to use this pre-built epiphany to avoid having to upgrade/compile webkit myself <podiki>dthompson: nothing special really, "should" just work since flatpak runs in containers <ieure>mra, When there's EWWM or whatever, I'll consider switching. <podiki>does it tell you anything on the crash? <dthompson>podiki: warnings only, nothing that looks like a fatal error <dthompson>I see "Gtk-WARNING **: 13:16:18.662: Unable to retrieve the Flatpak portal version" <dthompson>I really do not like flatpak so since it's not just working I don't think I will spend more time with it <podiki>yeah you'll want portals installed (depending on your environment, maybe just xdg-desktop-portal-gtk for instance) but that shouldn't be fatal <dthompson>I already have the portal installed for screensharing reasons <podiki>the only quick thing that comes to mind is to check if you are on stable/unstable whatever for the package you want and try the other instead? <dthompson>my mission is to get a sufficiently fresh webkit based browser so I can attempt to figure out why their wasm gc support is broken without needing to use macos <podiki>also note that everything needs to run as --user (you get errors if trying to install system wide) but that doesn't seem like what you are seeing either <dthompson>hmm I didn't pass any such flag. I assumed it just did that by default <dthompson>oh well I added flathub with --user so I guess that's why <dthompson>that was some copypasta from the flathub site <mra>ieure: i would really like for something like that to exist! if not in elisp, then in guile. I've toyed with the idea of a window manager which you can hook into and just get a guile repl, but I never got anywhere with it <dthompson>so uh, funny thing. I just launched it a bunch of times and eventually it didn't crash... <dthompson>I am going to look the other way and not try to understand wth just happened lol <podiki>i'll take my 10% commission on it working <dthompson>well now it crashed when I visited a website soooo 🙃 <dthompson>podiki: it'll have to be 5% since it doesn't fully work <podiki>I haven't used flatpak in a while (yay for more guix packages) but i did have some big ol' graphics/games stuff working just fine <dstolfa>dthompson: which browsers these days are webkit-based and maintained on linux? <ieure>Never having to deal with snap/flatpak/whatever nonsense is one of the main reasons to use Guix for me. They never seem to work 100% right. <podiki>so there shouldn't be any fundamental issue in flatpak, but has been awhile since i did anything with it on guix <dthompson>there's even "epiphany technology preview" releases for trying out unstable webkit versions so you don't have to use macos for that <podiki>if there is a binary download or appimage you could run that in an FHS container <dthompson>basically I just need epiphany built against webkit 18.2+. I was hoping flatpak would get me there quickly but given the issues I'll just build it myself <dstolfa>i find chromium to be worse to build, however (: <dthompson>I also can't tell how webkitgtk versions map to webkit versions <dthompson>I'm hoping that by building the latest release I get what I want <podiki>is it the single thread for tests that takes so long on webkit? i forget, but could just turn off tests if you just need a build <lilyp>imho, the worst part is almost ooming the linker <dstolfa>IME bfd gets oomed by a lot of stuff, but lld/mold don't <lilyp>if you'd like, you can revise the guix package to use lld/mold <dstolfa>right now i'm fairly bogged down working on v8 and chromium things, so don't have (and haven't for a while) much time to spare :( <vagrantc>hrm. something in the build process for reprotest is removing the executable attribute from lib/python3.10/site-packages/reprotest/virt/ ... which breaks. <vagrantc>i am guessing something in the pyproject-build-system or related ... as it used to work. <vagrantc>to workaround it just to see that it works again ... i want to do (invoke "chmod" "-R" "+x" (string-append #$output "/build/lib/reprotest/virt/") ... but i cannot find a phase late enough to run it <vagrantc>the files in the source code are marked executable ... so there is something that is stripping it later <vagrantc>had, wrong directory, and needed another / <Desktopless>Hello guix, I reconfigured my system to guix revision 9eedd1f and now I when I identify myself in GDM, all I see is a black screen. Any help is welcome. <elevenkb>Desktopless: I think the best thing to do is to try to switch to a tty (maybe Ctrl+Alt+F4) and log in there. <elevenkb>If you succeed then try to roll back your system using sudo guix system roll-back. <Desktopless>elevenkb: Thanks. Yes, I changed to TTY2 and started sway, which is my backup "desktop". And that's what I'm using right now to connect to this chat. <Desktopless>I really don't want to rollback just yet because my neighbor uses GNOME in this same revision of Guix and they can log in normally. <elevenkb>Desktopless: cool. Sorry for underestimating your skills, Guix is a fairly advanced distro after all. <elevenkb>I can't help you further because I've used sway exclusively ever since I switched to Guix. <Desktopless>I'll look for information in other places in the meantime. <lilyp>Desktopless: might be your graphics card – I myself got a laptop where gdm has been basically useless for quite some while <Desktopless>lilyp: GDM shows up for me though, it's the GNOME shell that doesn't seem to start or something. <Desktopless>lilyp: Is your new laptop an old laptop or a recent one? <lilyp>try deleting your mesa shader cache, maybe that's the culprit <lilyp>an old one with nv*dia graphics <Desktopless>I guess this will be Generation 128: A Gnomeless generation. <lilyp>what's new/changed in between? <CoolComputerGuy8>Hi all! I'm trying out mu4e and I need to setup some mail retrieval mechanism. I'm looking at the getmail system service and wonder, shouldn't this be a home service instead? It feels wrong to configure my personal mail account under system services. Or am I doing this wrong? I looked at test/mail.scm for inspiration. (And I've never configured <ieure>Desktopless, Simplest thing is to reboot the machine and pick the previous generation from the GRUB menu. <Desktopless>ieure: Yeah, it's just I wanted to see if something could fix it. But yeah, I guess I'll do that instead of rolling back or let this be a sway generation. <ieure>vagrantc, Ugly, but seems fine. <vagrantc>ieure: i do not particularly like hard-coding the python version <vagrantc>i have not yet identified when the build system started removing the execute bit ... <vagrantc>the reprotest shipped with v1.4.0 reprotest-0.7.21 did have the execute bit set ... only 150k+ commits to bisect ... <ieure>vagrantc, Oh yeah hmmm. Does `find-files' do a recursive search? <vagrantc>ieure: yeah, probably something like that would be a cleaner workaround <vagrantc>i usually have to detach my head and put it on sideways to understand find-files :) <civodul>it’s so simple compared to find(1) ! :-) <dthompson>podiki: re: webkit, idk if the tests are what take so long. I would imagine the build itself takes a long time since there's just so much stuff. <vagrantc>civodul: those first two examples i get, but it's the third one i need ... so maybe nothing wrong with find-files, just my handle on guile <CoolComputerGuy8>Nevermind. I'll just start the getmail service with default values and put a configuration file in my home dir. <vagrantc>well, this does not work: (for-each (lambda _ (invoke "chmod" "+x")) (find-files #$output "autopkgtest-virt-")))) <ieure>vagrantc, I think the second argument to find-files needs to be a predicate function. <ieure>A function which returns a boolean. <ieure>Manual does say the arg can be a regexp, does the string you passed count / match the files you want? <ieure>Not clear to me whether the predicate gets a path or just the basename. <vagrantc>i am just trying through trial and error <vagrantc>basically, i want to find the files that match that pattern, and run chmod +x on them <ieure>Probably need .* on either end of it. <ieure>There are examples in the manual, or you can use `find-file' in a Guix repl. <vagrantc>there are three examples in the manual, and my cargo cultig skills are insufficient to transform them into working code <vagrantc>i've spent about 45 minutes trying to solve a trivial problem after spending an hour figuring out what the problem even was... <ieure>vagrantc, So `find-files' does recurse, and the pattern has to match a specific file. This is not very helpful for what you want to do. <ieure>vagrantc, (find-files (car (find-files $output "^site-packages$")) ".*") <ieure>That should give you all files under the site-packages directory. <vagrantc>this worked (for-each (lambda (file) (invoke "chmod" "+x" file)) (find-files #$output "autopkgtest-virt-.*")) <vagrantc>there might be a better way, but that is good enough for me. <vagrantc>hrm. really need to write something where i could automate a git bisect to figure out where it broke <vagrantc>but i suspect there will be lots of builds where substitutes are no longer available <mra>sneek layer tell civodul if you have time, i submitted a patch for 41602. i was being silly in my earlier email, since i didn't know about `valid-derivers`. the fix is pretty simple, i think <sneek>civodul, mra says: if you have time, i submitted a patch for 41602. i was being silly in my earlier email, since i didn't know about `valid-derivers`. the fix is pretty simple, i think <vagrantc>surprised at the substitute availability for some of these old arbitrary commits ... way better than i expected <vagrantc>reprotest was good in e85ab7d2e52543fc086dce9144748e6f4b908ca9 ... so that narrows it down to less than 10k commits, at least. :) <vagrantc>i was overly optimistic ... 12599 commits ... <vagrantc>but at least i have ruled out bugs in reprotest itself ... it is definitely something since the last change to reprotest <ieure>vagrantc, Maybe it was the python-team branch that merged in January? <vagrantc>i have a semi-automated git bisect going ... should be done in ~13 steps if all goes well <vagrantc>if i spent more brain on it i could probably fully automate it ... <vagrantc>will be curious if it reveals anything interesting...