IRC channel logs

2022-11-05.log

back to list of logs

<rekado>it’s a culture mismatch. Very few people build Java from source, recursively.
<rekado>most people build the package of interest from source, but all dependencies are downloaded as binaries from maven central.
<rekado>this was especially painful for early Java packages as we had to go back to ancient source archives to build packages without dependency cycles
<Luchadoritos>I see. Thank you for your input. There's no guix import Java command either. This is gonna be gruesome.
<rekado>we’re in considerably better shape today, though, because we no longer need to build everything with plain “ant”. We’ve got a maven build system nowadays, which greatly simplifies the task.
<Luchadoritos>Awesome!
<rekado>(I still have nightmares in which I patch and cobble together build.xml files…)
<Luchadoritos>You really took one for the team on that end.
<Luchadoritos>Thank you for your service o7
<vagrantc>ACTION still remembers the kickoff of bootstrappable.org and "why are they talking about java so much"
<vagrantc>took a while for it to sink in :)
<rekado>the bootstrap story was actually pretty nice as far as these things go
<rekado>thanks to jikes, jamvm, and GNU classpath. All pretty straight-forward.
<rekado>not at all like this mutually recursive GHC story
<rekado>or Scala…
<apteryx>rekado: java was literally designed to run in applets fetching their dependencies from the internet (just read the spec of the CLASSPATH, it's not intended to be used as a RUNPATH at all)
<apteryx>of the JAR Class-Path attribute, I meant
<rekado>huh?
<rekado>CLASSPATH is effectively how Java can be told where to load classes though.
<rekado>*from
<rekado>ACTION —> zzZ
<silicius>I managed to get mesa 22 to work, can't wait for core-update to get merged into master
<user_>hello #guix
<user>nckx`:
<user>remount /gnu/store rw seem to work
<user>:(
<vagrantc>wow, the desccription and synopsis for rust-is-debug are a) identical and b) not very syopsisy or descriptionish
<user>nckx`: time of truth
<user> guix 1.3.0-27.598f728 → 1.3.0-32.682639c
<zpiro>mbakke: https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=o.+smorholm so between iee article reffused pulled, will mine get more citations over time?
<zpiro> https://en.wikipedia.org/wiki/Haakon_Sigurdsson and as puns fly freely for insight here. For sæming, it doesn't fall apart to the seems or seams for the blood and axes or swords that all involve English wrods that stem from Norse.
<zpiro>From a heritage that is such a brutal storm of bullshit, that cloest neighborts don't give a shit as a way of survival.
<zpiro>What is not bullshit is that I am Mørejarl or Orkneyjarl ancestry -- whatever floats your boat so to speak.
<zpiro>And well, beeing from this part of Norway, in tech, you can never really know -- can you?
<PotentialUser-52>why guix doesn't use wayland as default?
<rekado>there is no “default” system configuration. What is used depends on what services you have in your OS config.
<PotentialUser-52>can I change the OS config after the system is installed?
<PotentialUser-52>and like reconfigure the system with the new os config
<unmatched-paren>Yes.
<PotentialUser-52>cool
<unmatched-paren>modify /etc/config.scm
<unmatched-paren>then use ``sudo guix system reconfigure /etc/config.scm''
<PotentialUser-52>so like If I want to clone the configuration of my system I can just copy config.scm
<unmatched-paren>are you using gnome, btw?
<PotentialUser-52>yes
<unmatched-paren>yeah
<unmatched-paren>okay, so, i'm pretty sure this is how you enable wayland for gnome:
<unmatched-paren>replace %desktop-services with (modify-services %desktop-services (gdm-service-type config => (gdm-configuration (inherit config) (wayland? #t))))
<unmatched-paren>what this does is replace the gdm-service-type in %desktop-services with a version that uses the exact same config, except wayland? is set to true
<PotentialUser-52>it is like an override
<unmatched-paren>(gdm-configuration (inherit config) ...) is a bit like an object-oriented override, yeah
<unmatched-paren>PotentialUser-52: this will make GDM run on Wayland instead of X, and enable launching Wayland sessions from it
<PotentialUser-52>don't I need to install wayland packages?
<unmatched-paren>so, if you click the drop-down session menu on GDM, there should now be a GNOME (Wayland) option
<unmatched-paren>PotentialUser-52: nope
<unmatched-paren>the services will handle everything that's necessary to get it to work
<PotentialUser-52>so basically all packages in guix repository are repackaged to use guile config
<unmatched-paren>besides, wayland is just a library
<unmatched-paren>not quite
<unmatched-paren>some have services for configuration
<unmatched-paren>but some don't
<unmatched-paren> https://guix.gnu.org/manual/devel/en/html_node/Services.html
<unmatched-paren>once you're experienced enough with guix you could try to write some of your own services :) https://guix.gnu.org/manual/devel/en/html_node/Contributing.html
<PotentialUser-52>cool
<unmatched-paren>anyway, wayland is a library and protocol, there's no wayland-server daemon that needs to be running for wayland to work
<sash-kan>hi all! how to use `guix repl` with certain channels? i tried through `time-machine`, but without success: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58841
<PotentialUser-64>Hi. I have installed guix system but now when I try to install for example firefox I see that it tries to compiles it from source even when I enabled substitute servers at installation time
<civodul>sash-kan: hi! i've just replied
<civodul>basically you need to start by running ,use(gnu packages) at the REPL
<unmatched-paren>PotentialUser-64: Are you using icecat or firefox from the other channel?
<civodul>it's an annoying issue
<PotentialUser-64>I ran guix search firefox and then installed the firefox package
<PotentialUser-64>from guix repo
<unmatched-paren>PotentialUser-64: Are you using the non**** channel though?
<PotentialUser-64>yes I added it to channels.scm
<unmatched-paren>Firefox isn't in Guix, only Nonguix
<unmatched-paren>I believe the problem is that it recommends nonfree extensions...
<lilyp>well done with the censoring there ;)
<PotentialUser-64>ah
<unmatched-paren>...yeah, i noticed too late :P
<PotentialUser-64>wow policies are really strict
<unmatched-paren>PotentialUser-64: Non**** does have a substitute server, but it might not have a substitute for firefox rn
<unmatched-paren>try guix weather firefox
<lilyp>putting the evil channel aside, does anyone have an idea how to setup mingw-gcc to actually compile stuff (i.e. finding things such as crt2.o)
<lilyp>welp, twas easier than i thought
<gabber>i can't pull -- am i doing it wrong? https://termbin.com/
<civodul>gabber: hi! you forgot to actually paste what you see :-)
<gabber>hi! lol :) yes https://termbin.com/jmix
<civodul>it's likely a bug in the channel that provides the games/packages/minecraft.scm module listed there
<gabber>ah yes, thanks!
<unmatched-paren>probably guix-ga**** :)
<civodul>i recommend reporting it there :-)
<civodul>we should do something about these package-cache errors
<vivien>Hi guix, noone wants the beautiful minetest dynamic shadows?? That I cannot believe. https://issues.guix.gnu.org/58932
<unmatched-paren>vivien: it's much easier to review and merge if you use git send-email instead of attachments, as described here: https://guix.gnu.org/manual/devel/en/html_node/Sending-a-Patch-Series.html
<vivien>I said that I would send one email per patch instead of attachments if I have to do a v3
<unmatched-paren>ah, okay.
<unmatched-paren>well, they all LGTM
<unmatched-paren>actually, i think it's preferred to use (prepend PKG) rather than (append PKG)
<unmatched-paren>more efficient, i think
<vivien>The docstring has an example with append
<vivien>So I thought it would be more recommended
<unmatched-paren>that should probably be changed...
<Korven[m]>Well guys, it was fun messing with Guix. But I think this is about as far as I go with it currently.
<Korven[m]>Thanks for all the help tho XD
<Korven[m]>Peace! Till some other day when I inevitably join Guix again
<unmatched-paren>Korven[m]: :(
<vivien>Do you want me to change the docstring, or should it go in a separate issue?
<unmatched-paren>vivien: that should be separate, yes
<unmatched-paren>if you want to send a separate patch for that, cool
<unmatched-paren>i can't find a single use of (modify-inputs ... (append ...)) in gnu/packages
<unmatched-paren>it's all prepend, so i think that would definitely be the recommended way to add inputs
<vivien>So I’ll now send the emails, I hope everything goes well…
<unmatched-paren>one of them has appeared in my inbox
<unmatched-paren>2/4
<vivien>Yes, this one appears in the issue page too
<vivien>But not the others :(
<unmatched-paren>3/4 and 4/4 have appeared
<unmatched-paren>oh, and there's 1/4 :)
<vivien>Can you read and apply them?
<unmatched-paren>it's much easier to do that, yes, because i can just open them in aerc and use ``rq'' to reply to them like i could any message
<unmatched-paren>it's very hard to do that when they're attachments
<unmatched-paren>and applying them is much easier like this too, but i don't have commit access yet, sorry :( but i can say it all LGTM
<vivien>civodul told me it would appear in qa.
<vivien> https://qa.guix.gnu.org/patches
<vivien>For now it does not respond…
<unmatched-paren>yeah, it's very slow for me
<vivien>Gateway time-out :(
<unmatched-paren>same for me
<unmatched-paren>it's useful when it works, though! :)
<unmatched-paren>oh, it's working for me now
<vivien> https://qa.guix.gnu.org/issue/58932 has not done anything yet
<unmatched-paren>is it possible to make a herd service stopped by default, until you ``herd start'' it manually?
<unmatched-paren>actually, never mind. that wouldn't work for what i'm thinking of doing
<vivien>And the prepend documentation issue: https://issues.guix.gnu.org/59048
<vivien>I can’t wait for the next JS framework in guilescript :)
<vivien>On the "QA" page, https://qa.guix.gnu.org/patches, what is the meaning of the orange dot?
<unmatched-paren>-.o.- sorry
<vivien>On patchwork, the v3 does not seem to appear correctly for #58932
<vivien> https://patches.guix-patches.cbaines.net/project/guix-patches/list/?series=14550 does not have the first patch
<vivien>Is it because the issue is cursed (it has mixed attachments / patches-as-mails)?
<unmatched-paren>maybe
<unmatched-paren>I had no idea patchwork was a thing, though. Thanks. :)
<cbaines>sometimes searching for the issue number in Patchwork is useful
<cbaines>it seems like Patchwork has associated the first patch of the v3 series with a different series to the rest of the patches https://patches.guix-patches.cbaines.net/project/guix-patches/list/?series=&submitter=&state=&q=58932&archive=&delegate=
<vivien>Oh maybe your IRC client pinged you because of the URL, sorry
<vivien>But the qa site tells me I have to thank you for your work ;) So thank yo :D
<cbaines>I think git send-email might chain the messages together with some headers to help avoid this, but I'm unsure
<vivien>I have not set the "--thread" option, maybe that’s that
<vivien>And there’s no cover letter
<vivien>Next time I’ll experiment with a cover letter so maybe patchwork will understand it better
<Kabouik>Is there anyone using btrfs as their filesystem on / here? I started using it (with no RAID, just a single SSD) but it would be enlightening to see which commands those who know it better use on a regular basis to keep it in a good state. I'm asking here because I think the very nature of /gnu/store and the multiple generations are more demanding on a filesystem like that than ext4 for instance, and I think it's responsible for some slowness on my
<Kabouik>system every time I run a guix command.
<Kabouik>I suppose I should btrfs balance on a regular basis, but perhaps there are other tips and I'd prefer reading them from Guix users than some wiki dedicated to some RAID setup, which is not exactly my situation. If that's too off-topic, then just ignore the question, and sorry for the noise!
<nckx>I mean, I do, but apart from a periodic scrub I do nothing special.
<nckx>And +C /var/guix/db amongst others, but that's based on 'common sense' rather than testing, who knows if it even helps.
<nckx>Can you quantify 'some slowness'?
<podiki[m]>Same here, no issues I noticed on btrfs, I don't use raid or do any maintenance (and use compression on all except swap of course)
<nckx>I don't use btrfs 'RAID' but the whole thing's perched atop mdraid6 on spinning drives, adding more delicious ingredients to the stew.
<unmatched-paren>nckx: don't you use bcachefs though?
<nckx>If you think I back up my bcachefs to bcachefs I like the image you have of me, but no.
<nckx>In other news, it did in fact totally self-destruct yesterday, and I'm itching to finally use that blank 2TB SSD in my laptop, so maybe multi-device booting will be written today. Maybe.
<nckx>It's a slower link than the main SSD so this is the perfect use case \o/
<nckx>The btrfs sits in a dusty warm box in the corner, unloved.
<Kabouik>Glad to hear you both noticed no specific issues on Guix, I had no particular view on it but was just afraid that there were few users on Guix to even detect them, if any.
<Kabouik>So, a periodic scrub it is then. No balance?
<Kabouik>I have not run any btrfs command since I installed the Guix machine in August this year. Just started remembering about the filesystem I am using a few days ago when we discussed free space nckx, which then reminded me that there might be some janitor work to do with this filesystem every now and then. But I have not done it yet.
<unmatched-paren>Kabouik: i suppose you could try using mcron-service-type for your periodic scrub and possibly balance
<unmatched-paren>so you can't forget :)
<Kabouik>Slowness is hard to measure because I don't have a comparison point with another filesystem and Guix, but you noticed a few days ago that a `du -h` would take close to an hour on my /gnu/store, and also every guix remove or guix install now takes a couple or three minutes (~235 packages installed), while I remember it was a few seconds at the beginning on a fresh system.
<Kabouik>Sure unmatched-paren. I am not too concerned about forgetting though, perhaps it's actually better to do it manually when I need it than automating some disk/cpu intensive commands. But it is good to know that scrub and balance should be enough, I was not sure if some other things would be needed.
<Kabouik>For instance you mentioned that you use compression
<Kabouik>I don't know if I do.
<unmatched-paren>could somebody please review this package? https://issues.guix.gnu.org/56959
<unmatched-paren>Oh, cool. GLAD's v2 is actually out now.
<unmatched-paren>I guess I'll be updating that package.
<nckx>Kabouik: grep compress /proc/mounts should tell.
<Kabouik>Thanks. Apparently I don't use compression. Something I can add in my config.scm? Can it be done now that the system is already up and running, given that this is my full SSD and not just some data storage partition?
<nckx>It can be added as a mount option (compress=algo, or compress-force=algo, documenting that is beyond scope and finger strength) at any time, but it will affect only new writes. But those can be forced by a balance.
<nckx>I use zstd:6, but that's (deliberately) a bit high.
<nckx>Berlin uses force & zstd.
<Kabouik> https://0x0.st/oEog.txt does that look OK to you?
<Kabouik>Then sudo guix system reconfigure and a btrfs balance
<nckx>Sure.
<nckx>Actually, I lied, berlin stopped using -force very recently because it was suspected to cause excessive fragmentation contributing to long (~15-min) mount times. File systems are trade-offs all the way down.
<nckx>(You will not see such mount times, worry not.)
<unmatched-paren>new GLAD 2 patchset sent: https://issues.guix.gnu.org/59056
<Kabouik>I am not sure I need -force anyway, it seems to be designed to force compression on typically incompressible files if I understand it right, not sure there is much to gain
<nckx>If you're reading good docs, they should explain the specific meaning of ‘incompressible’ here, and why -force exists and can be useful. I'm sorry I can't point you to any. Not computing comfortably ATM.
<Kabouik>No problem, this is not even specific to Guix in the end; thanks for the help already!
<nckx>lechner, civodul: Just FYI, I'm still waiting on SFC's response to those questions and some others. A human has confirmed they got the mail and are working on it, but I have no idea whether to expect 1 paragraph (pointing us elsewhere) or twenty.
<nckx>ACTION also can't mail good right now.
<civodul>nckx: noted!
<civodul>i just wanted to make sure we merge our conversations into one :-)
<nckx>An excellent idea.
<user>nckx: How can I close a bug?
<nckx>Edit the CC header to reply to NNN-done@debbugs instead of NNN@debbugs.
<nckx>Or NNN-close@debbugs, both work, we don't really rely on the subtle difference AFAIK.
<user>Should put how we resolved it in the NNN-done or NNN?
<user>the remounting and copying from savvanah just worked
<user>Not a beautiful thing... but this was the last resort for my case :|
<nckx>You just change the address of your last mail, you don't send two.
<nckx>From: you CC: 123-done@debbugs Subject: unchanged Hi Guix, turns out I had to XXX, oh well. Kind regards, user_
<nckx>Or I don't understand your question.
<user>YOu got it, but the subject is that its solved now
<nckx>You don't need to edit the subject.
<nckx>You may, but it's unimportant.
<nckx>Problem is users often change it to just ‘Fixed’ or ‘Never mind’, with no mention of the problem, which means those who receive it as mail and didn't save the thread won't know what was fixed. But I digress.
<nckx>I'm ‘glad’ you fixed your problem and that I could help, but yeah, having to resort to that never feels great.
<user>Oh SOrry I just read here aftet sneting the mail :( I changd it to "solved"
<user>But from now on I know about this
<lizog>hello guix, i think i encountered some problem with guix container. i would like to have access to gpu in the container. at the beginning, it works; but when i add network access to the container, it then broke
<lizog>here are the logs that i ran `glxinfo -B' in each container: https://paste.sr.ht/~lizog/32120809c1458f6b16479d65860a3d39e96c10fa
<user>also thanks nckx :)
<nckx>user: It's OK :) It's worse when it's a 3-year-old bug. Most people will still have the thread and their MUA will give them context. Thanks!
<nckx>lizog: That's certainly unexpected! Is ‘env’ in each container notably different? (‘Notably’ as in there might be a different /gnu/store/$hash-profile in places, but they should otherwise match.)
<nckx>I'm not a user of Guix containers or AMD GPUs (and they don't pay me to provide support), so that's all I can think of for now.
<nckx>ACTION AFK.
<lizog>nckx: they have the identical env, even the `GUIX_ENVIRONMENT' variable is the same
<vagrantc>civodul: well, rebuilding guile-git against the newer libgit2 in debian fixed the test suite failures and guix is back on it's way to debian/testing
<vagrantc>maybe just in time for a new guix release :)
<Kolev>Can I use Guix to install GNOME 4x on Trisquel?
<unmatched-paren>Odd. My system just froze up.
<civodul>vagrantc: yay, well done!
<unmatched-paren>where are the past dmesg logs stored on guix system?
<nckx>lizog: Hmm.
<nckx>unmatched-paren: /var/log/messages if your system was still alive enough to write them in blood.
<nckx>lizog: This exceeds my feeble expertise. It also feels more like a mailing list bug to me.
<unmatched-paren>Hmm. All I get in there is this over and over:
<unmatched-paren> https://paste.sr.ht/~unmatched-paren/56d89b0d150aad2f33cd750fae278c8f512ba708
<unmatched-paren>did my wireless hardware freeze up or something?
<nckx>There's no evidence for that. No evidence of anything, if that's all you have ☹
<nckx>Did you recently update your kernel? I'm not asking because I have a particular bug in mind.
<unmatched-paren>I've updated to 6.0 recently, yeah.
<nckx>Which 6.0?
<unmatched-paren>6.0.7.
<unmatched-paren>That's the one in Guix...
<Kolev>unmatched-paren: Are you ( on Trisquel Forum?
<nckx>unmatched-paren: So was 6.0.6.
<unmatched-paren>Kolev: I'm not on the Trisquel Forum. Never touched Trisquel :)
<nckx>An impostor!
<Kolev>unmatched-paren: Ah. I wish I could get back on Guix.
<Kolev>unmatched-paren: I have a complicated setup. The Lounge, Syncthing, OnionShare, Tor Browser.
<vivien>Syncthing, that’s a great program
<Kolev>vivien: I know Guix can do Syncthing, but it cannot do The Lounge, OnionShare, or Tor Browser.
<unmatched-paren>ah, looks like The Lounge uses electron (ugh...)
<unmatched-paren>we do have an onionshare package though
<Kolev>unmatched-paren: How does The Lounge use Electron? It's used in the browser.
<Kolev>unmatched-paren: The OnionShare package is broken.
<unmatched-paren>Kolev: Seems to work in both.
<unmatched-paren>Ohh. By "runs whereever node.js runs" it means on a server hosting the web instance...
<Kolev>unmatched-paren: Yes. It's a service you run, and you access it from a browser.
<user>Kolev: Guix can run tor fine
<user>I dont use Tor Browser itself but I connect to anything though Tor in guixsd, even guix daemon use tor here
<minima>hi, i'd like to write a minimalist system definition that includes emacs plus a specific init.el configuration file; how do i do that? shall i just use 'local-file ...' to copy my init.el to the correct position - eg '/home/user/.emacs.d/init.el'?
<nckx>Has someone tried the Tor browser in a guix shell -CF yet?
<nckx>* -CFN. -CF is a bit too secure.
<civodul>that reminds me that someone had done a lot of work towards packaging the Tor Browser
<minima>(or maybe i should simply scp my config file init.el into the system once that it's been deployed)
<podiki[m]>nckx: I have not, but do have in my shell history the right invocation for browsers more generally (though Tor one probably doesn't need as much hardware access as chromium?)
<nckx>One'd hope not.
<nckx>I'm still rebuilding my system (including Firefox), but I'd expect it to be the same.
<nckx>I mean, if networking works, the Tor proxy should too… I'd think.
<podiki[m]>I was hunting down a vaapi bug in firefox (haven't checked icecat, should be same?) where they use sandboxing and I think it needs general read access to /gnu/store
<podiki[m]>the nix folks added /nix/store; I thought it should work with ld_library_path for the relevant libraries (the sandbox will allow that) but mysteriously did not hardware accelerate
<podiki[m]>speaking of, should start a local firefox build to try out the patch I have in mind
<nckx>That's pretty bad.
<nckx>Would adding mesa (and/or libva and/or other libraries)'s runpath not suffice?
<podiki[m]>I added all the stuff it would complain about, vaapi shows loading the driver fine, output all looks good...but uses much more cpu than e.g. disabling the (rdd) sandbox
<nckx>rdd?
<podiki[m]>"remote data decoder"
<podiki[m]>something something sandbox something hardware decoding something
<nckx>Oh. We might not be talking about the same thing. I thought security.sandbox.content.read_path_whitelist.
<podiki[m]>right, that is something else apparently
<nckx>Bah.
<podiki[m]>that has access to /gnu/store without patching (set via preferences)
<nckx>Shouldn't.
<nckx>Am I looking at the wrong code?
<nckx>'build-sandbox-whitelist in icecat.
<podiki[m]>I see (in the not guix firefox code) security.sandbox.content.read_path_whitelist set to the store directory
<podiki[m]>let me check icecat
<nckx>Does nonguix's Firefox not build on IceCat?
<podiki[m]>yeah, same thing, but that's a different(?) sandboxing from my extremely limited understanding
<podiki[m]>actually let me try again vaapi in icecat....
<podiki[m]> https://phabricator.services.mozilla.com/D142268 is the nix (mozilla upstream) patch
<podiki[m]>they already had /nix/store in a different part of that same file, but needed it here
<podiki[m]>I think they have gl drivers in /run/opengl-driver/lib and that will link to their store so they gave blanket (read) access
<nckx>That's some confidence-inspiring code.
<nckx>Even upstream.
<nckx>So
<nckx>it turns out that Guix System supports multi-device bcachefs root file systems out of the box.
<nckx>And here I was expecting a long night.
<nckx>The only snag is ’--skip-checks’ when init'ing.
<nckx>I guess I'll spend the time on adding a system test instead, to make sure it stays that way.
<podiki[m]>I was hoping ld_library_path could just be augmented with all the things libva needs, but like I said that didn't give errors yet didn't really work
<podiki[m]>on icecat I'm not even seeing vaapi trying to be loaded on my end :-|
<nckx>How does one check?
<podiki[m]>4k@60hz video goes from ~130% cpu to <20% or even < 10%
<nckx>But how do you know it's not even trying.
<podiki[m]>or even regular 1080p, but hard to notice on my desktop; a laptop would probably show nicely
<podiki[m]>the trick is that you need a video that uses a codec you can hardware accelerate
<podiki[m]>oh for icecat? not seeing output in terminal of vaapi being loaded, which I would with firefox; but maybe it doesn't say
<podiki[m]>about:support also seems to indicate a config error
<Kabouik>Do we have an alternative to https://github.com/imapsync/imapsync in Guix?
<podiki[m]>mbsync
<Kabouik>Thanks, will look into it (I need to transfer from one email server to another)
<podiki[m]>aka the isync package
<Kabouik>Does it allow server-to-server or is it intended for online-offline sync?
<podiki[m]>you could probably set up server to server? I use it to fetch/sync mail from places like gmail, but should be able to then sync that to another server
<podiki[m]>it is a pretty well known program I think, so if you search around you might be able to find an example of what you are looking for
<morganw`>Kabouik: if you are using Dovecot it comes with a sync process that should let you migrate server or keep two servers in sync.
<nckx>Are there even other IMAP servers in Guix?
<podiki[m]>nckx: I guess I didn't even ask: do you get vaapi acceleration in icecat?
<morganw`>I think there would be one in mailutils (imap4d) but I haven't checked (or ever used it)
<nckx>podiki[m]: I don't use IceCat, but I could try installing it once I've plowed through building the stuff I really need.
<nckx>morganw`: TIL.
<nckx>It doesn't sound… high-volume.
<podiki[m]>well same question for firefox then, but no worries; pretty sure I see what is happening and maybe need a full ld debug to see if I'm missing some libraries rather than the blanket /gnu/store access
<nckx>Heh, uhm, my Firefox build doesn't even have working video on anything that's not YouTube. I'm not your fella, guy.
<nckx>I don't really care, so I don't debug.
<podiki[m]>haha no prob
<podiki[m]>but I confirm by doing LD_LIBRARY_PATH=/gnu/store (the horror) and running firefox and that works
<nckx>I will take a look, just in case I do see something vaapi scroll by.
<nckx>Who knows, it might be related!
<podiki[m]>:-P youtube does serve up several codecs, so maybe it gives you what you are able to use
<podiki[m]>nckx: more general question, if something is trying to load say libva.so in some sandbox that needs every file access to be explicitly allowed...that would entail the entire dependency tree of the library right? down to libc, gcc, etc.?
<podiki[m]>(for dynamic linking, I guess static it is all there in the library already)
<nckx>Depends on how good the sandbox is, strictly speaking, but yes it would.
<nckx>Hence the runpath dance for Guix's icecat package.
<nckx>Which does exactly what you describe, with parse-elf.
<podiki[m]>yet with just a few additions (to ld path/sandbox access) it does load vaapi and show what seems to be activation of hardware decoding
<nckx>Cool.
<podiki[m]>I would think I would get some access denied error eventually, considering it doesn't do what it should in the end
<nckx>It doesn't need to load things already loaded in the address space.
<rekado>commit 040006d81c20c68d4291a7e5d82517691756c4c1 seems to have broken pdfposter
<rekado>the sanity-check phase fails, so I wonder why this was pushed
<podiki[m]>since full /gnu/store give the actual hardware accleration expected (reduced cpu)
<podiki[m]>gotcha
<podiki[m]>ACTION returns to scanning the 14M ld log...
<Kabouik>morganw`: I don't use Dovecot. I am just investigating online services where I could host large amounts of emails, but with some respectable privacy policies. I ended up setting up something on midagu.com (just trial for now), but recommendations are welcome. My point is to migrate stuff from some email account that I had stored on some other email service that is probably not advisable at all for privacy. If I could transfer server-to-server
<Kabouik>directly, that would be best, but I guess it is not mandatory indeed since it would just be a one-time transfer (then, I'll store my email backups directly on the new service).
<morganw`>As it happens I was also looking for something to use and was going to use Migadu, but then as it happened the domain I bought came with a free mailbox so I've just used that instead. I have also used mbsync for my work mail and I didn't have any problems with it. Possibly you might want to test what happens to message IDs if you rely on them being the same.
<Kabouik>My active accounts are now all on servers that I deem ethical and good, but I still have a need for large storage of old emails that I cannot keep offline and backed up offline, since they would eat too much disk space.
<Kabouik>My domain came with a free domain as well, but not much storage for it. Also, I am actually not interested in the domain because all I wanted was storing messages online, and storing new ones with a mail redirection, but not sending messages or receiving them directly there. a @midagu.com would have worked for me too.
<Kabouik>s/with a free domain/with a free email service
<podiki[m]>mails should compress really well no? and you could just encrypt and store wherever then as backup?
<Kabouik>Probably, but there is some convenience in being able to retrieve and search old emails from anywhere using a webmail when you don't have you beloeved and well configured machine. I guess mbox files would not be retrieved and parsed as easily from a foreign machine.
<nckx>Any tool worth its salt will preserve Message-Ids. It's not generally a concern.
<nckx>I know you don't use it (yet? :) but Dovecot can store mails compressed, including xz.
<nckx>It's nothing like .tar.xz efficiency, but then you can search inside of them.
<Kabouik>But you'd have to set that up on a server, right? I could do that but that isn't really the kind of time sink I'm looking for right now
<nckx>Sure, it was just a side note. Because you mentioned Webmail.
<Kabouik>That's a valid point for sure, but for the future most likely
<Kabouik>Mailpile.is is also an interesting solution (I've used it for some years) as it also supports mbox at its core (and mail encryption in a user-friendly way) and offers a webmail. I stopped using it when I moved to a ncurses-email client but that's actually not incompatible at all, since in my mind the webmail would just be necessary for cases where I don't have my configured machie and desktop/terminal client.
<Kabouik>But yeah, it will take time to set that up again (be it Dovecot or mailpile).
<nckx>I considered Mailpile, but… it's written in Python, so maintainability nightmares danced around my head.
<singpolyma>You're against *python*? Is there anything you like? ;)
<nckx>?
<user>How someone can learn guile ?
<nckx>I like turtles.
<singpolyma>Sorry, I may be misattributing, but I see just about every tech stack get heavy hate in here. Rust, JavaScript, but python of all things is so normal and boring?
<unmatched-paren>user: There's the https://spritely.institute/static/papers/scheme-primer.html
<unmatched-paren>and of course the guile manual...
<singpolyma>user: I'd suggest to learn normal scheme first, but if you want guile specifics the manual is good
<nckx>Rust is OK, it just got swept away by (or had the misfortune to be born into) a timeslot where it's cool to do packaging poorly.
<nckx>I never said I hated Python, but it's fragile and I don't want to have to babysit my mail server.
<nckx>It's great for kids though.
<singpolyma>What's less fragile thru python? (I'm by no means a python fan, it just seems so common and boring. Like half of some distros is written in python)
<user>Nice, going trhgouh schemce primer first
<user>You all uses emacs for scheme programming?
<singpolyma>user: whatever editor you already use and like
<unmatched-paren>user: Emacs is generally the best option, as there's a lot of Scheme plugins for it, but you could use a vim variant too
<unmatched-paren>just expect some inconvenience
<unmatched-paren>if emacs' keybindings bother you (they bother me), you could try evil-mode
<unmatched-paren>which emulates vi keybindings in emacs
<singpolyma>evil mode is surprisingly complete and good
<unmatched-paren>and evil-collection is really useful too
<unmatched-paren>it provides evil keybindings for various plugins, like magit and company, and builtin non-core emacs features, such as minibuffer, dired, eshell
<Kabouik>Mailpile had some bugs/limitations when I was using it, and I don't think it changed much since then because the main dev had a burnout, but I still liked it and may get back to it one day if I decide to self-host these large amounts of emails (but that is a big responsibility, and it gets bigger as years pass and I get more emails to store).
<user>I acctually uses nano, but I think it will "impossible" to scheme
<Kabouik>user: I was using kakoune in the last couple years, and started diving into emacs for the first time a few weeks ago. I'm mindblown. And I still think Kakoune is awesome, if you want something lighter. But the emacs flexibility and ecosystem are simply impressive, to my newbie eyes.
<unmatched-paren>emacs is the least worst editor :)
<Kolev>My problem is keeping Emacs confined to the scope of an editor.
<nckx>Hmm, Firefox 106 builds in 106 minutes. So that's what that means.
<unmatched-paren>Fair.
<Kabouik>I had issues with Lisp languages in Kakoune. I was using parinfer with it but it would sometimes close parenthesis where I didn't want to, and I couldn't enforce what I wanted unless disabling parinfer completely, no such issue with Emacs of course.
<Kolev>Emacs apps like ERC are clunky. I prefer The Lounge. And for Telegram, I prefer Telegram Desktop and not Telega.
<unmatched-paren>I use it for text editing, shell, and git (Magit is just too good :)) and use terminal apps for mail (aerc) and IRC (senpai)
<Kabouik>I guess that's a good summary: https://imgs.xkcd.com/comics/real_programmers.png
<Kolev>unmatched-paren: But I do admit, notmuch is good.
<Kabouik>I have not tried any of the Emacs email packages yet, still use nmail which I really like (patch submitted but not merged).
<unmatched-paren>*REAL* Lisp Programmers use theoretical text editors.
<user>Use cat with HEREDOC notation to create files
<user>cat <<EOF>file.extension
<user>code.....
<user>EOF
<user>just a joke ofc
<Kabouik>Yes, but I guess they would do that in Emacs' eshell and not in a terminal emulator :O
<nckx>Real Lisp programmers use LaTeX, have their code peer-reviewed, publish it, then never look at it again.
<unmatched-paren>Real Lisp programmers model a computer using binary Church numerals.
<nckx>podiki[m]: I thought running FF in a terminal would be a deluge of nonsense and bad-practice warnings (so, any GNOME application) but no: it's just this, over and over, and one other line than p.d.o thinks is spam: https://paste.debian.net/plainh/007fdafb
<nckx>Nice.
<nckx>/run/current-system/profile/lib/dri/i965_drv_video.so exists, but maybe it's an ABI mismatch. I'll have to reconfigure before I blame sandboxing.
<user>Which sandbox u use?
<nckx>Firefox.
<user>Oh.. I was thinking about something like firejail etc
<nckx>rdd, I think it was called? It was mentioned above.
<nckx>lol no.
<podiki[m]>odd, would expect a permission denied error based on what I was seeing
<podiki[m]>oh is this with vdpau-va (whatever it is called) for intel?
<user>firejail have some default template for firefox
<nckx>Maybe that's comin'. I'll start a reconfigure.
<nckx>podiki[m]: VDPAU is not Intel AFAIK.
<podiki[m]>because I don't think vdpau works with firefox currently?
<podiki[m]>i meant vdpau via intel drivers; i'm always confused by vdpau/vaapi and all that though
<nckx>I've never used VDPAU.
<podiki[m]>ok
<podiki[m]>(me neither?)
<nckx>I'm installing mpv as well.
<nckx>It had working vaapeez yesterday.
<pkill9>"a deluge of nonsense and bad-practice warnings (so, any GNOME application)" this puts words to the experience I always felt from running gnome applications in terminal heh
<pkill9>it always gives me some kind of anxiety
<nckx>I feel dirty, like I saw something I wasn't supposed to.
<pkill9>also chromium I think
<podiki[m]>yeah, vainfo and mpv worked fine for me without tweaking on guix