<robin>and the "fnord" package at the end shows how it's used <robin>probably you could get halfway there with bubblewrap and --ro-bind'ing most of ~/.guix-profile, /dev, /sys, etc. and preserving some environment variables... <robin>(for diy tinkering rather than guix packaging) <robin>getting under half a megabyte per second downloading texlive :( wish there were faster/closer substitute servers <robin>'guix build -c32 --no-substitutes -e "(@@ (gnu packages tex) texlive-texmf)"' downloads from ftp://tug.org/... (ftp??) and isn't much faster, though <robin>oh, just surprised it's using ftp by default <nckx>tug is also Germany, probably by coincidence. <robin>there's a CTAN mirror ~30mi from me but that would involve using rsync <robin>...or no, https actually, but it's not obvious where to find the equivalent of ftp://tug.org/historic/systems/texlive/2019/... there, if they even have old versions <robin>(if they do, it'd be neat if guix could download from ctan mirrors) <lispmacs>hi, I was wondering if anybody had any recommendations for me on a pci-e16 gfx card purchase, known to work well with latest Guix kernel & mesa? <lispmacs>my NVIDIA GeForce 8400 was working fine for me, but the 3D accel seems to have broken by some recent mesa update <robin>i was going to say there were no such cards, then i remembered noveau existed <lispmacs>I've got a few old radeon cards, but in testing they all get fatal GPU init errors during Guix bootup <lispmacs>or otherwise freeze when you try to get past just framebuffer mode <robin>yes, that's because linux-libre doesn't have any kind of graceful fallback when the firmware is unavailable <lispmacs>I'm rather lost on what to purchase - h-node only gives like two or three cards that claim to have working 3D acceleration, but they are all as older or older than my card <robin>(istr its behavior is actually worse than if the firmware were just missing) <robin>lispmacs, hmm, maybe the noveau homepage has a better list? i also often find archwiki useful for that kind of research <lispmacs>I don't have any particular love for NVIDIA, that is just what I had <robin>singpolyma, the pango package <lispmacs>I don't see any indication there that it shouldn't be working <lispmacs>does anybody here have working 3D acceleration? <robin>lispmacs, i do, on amd vega and rx480 cards, but using the nonfree firmware <nckx>robin: Well, it would be relatively easy to add a mirror://ctan/, but it wouldn't have any concept of ‘closest’. Just a list of URLs. <robin>(amd is relatively free software friendly -- the initial reason i chose them over nvidia -- and the kernel modules are free, if only they'd liberate the firmware!) <lispmacs>well, I could get by without 3D accel, but the kiddies are sad that supertuxkart doesn't work any more <lispmacs>or, well, it is a little hard to play at 5 frames per second - I get vertigo <robin>(iirc an amd engineer wrote that they probably *could* liberate the firmware but they don't think there's a large enough market for cards free of digital restrictions management) <lispmacs>surely there must be something I can get from some vendor <robin>(i've gone as far as REing some of the amd firmware blobs but it's probably like 1% of the effort needed to produce a noveau equivalent...) <lispmacs>are there any cards out there where you don't have to install firmware? <robin>lispmacs, hmm...maybe it would be worthwhile to try another distro (e.g. debian live) to check that it's not a guix bug? <lispmacs>I suppose, though Debian would prob be using an old version of Mesa <robin>oh right, you mentioned it was working previously <lispmacs>I just thought there would be somebody here who had 3D accel on the latest Guix <robin>lispmacs, i'm sure there is...but if you don't get a response, you could always mail guix-users <robin>lispmacs, i'd also consider a bug worth filing that 3d accel stopped working <robin>and i'm sure you thought of it, but if you still have a generation where it *was* working you could use that, at least for games <lispmacs>I think I GC'd that generation (not realizing for a few months that the 3D accel wasn't working). But maybe I could build another generations from an old guix commit <lispmacs>if I could figure out exactly where the breakage occurred, that might be worth a bug report. Otherwise, I'm sure it will go nowhere <lispmacs>yeah, that seems like a good idea - I think I'll pursue that <robin>(even *any* unbroken revision would be useful to know, to binary-search for when the bug was introduced...) <robin>guix time-machine might be useful, but i haven't used it so have no idea if you can actually do e.g. guix system reconfigure with it <robin>(though the manual doesn't say you can't...) <robin>if it's a kernel bug you could even run current guix with an old kernel (presumably). a mesa bug would be a bigger problem though... <westrom[m]>My screen is high res but my fonts are tiny. Gotta squint a bit to see what I'm doing, but thankfully I'm a touch Tyler. <westrom[m]>My screen is high res but my fonts are tiny. Gotta squint a bit to see what I'm doing, but thankfully I'm a touch typer. <robin>westrom[m], console as in the linux console? console-setup might be able to increase the font size <robin>e.g. FONTFACE='VGA' and FONTFACE='16x32' on separate lines in ~/.console-setup, then run setupcon -f (for font changes only) <robin>FONTFACE='Terminus' is also available in that size <robin>apparently fbset should be able to change the resolution, if that's not enough <westrom[m]><robin> "FONTFACE='Terminus' is also..." <- unfortunately my font does not increase in size. <robin>weird. fbset might be a better approach, then <westrom[m]><robin> "weird. fbset might be a better..." <- You mean change my resolution altogether? <robin>which i guess would be the case if there are any /dev/fb* devices? <robin>westrom[m], sounds like it's worth trying <singpolyma>Oh, I think I just lucked into finding it, NVM :) <westrom[m]>Ok, now that I know the font is set right, now I just need to figure out how to make it persistent across reboots. <apteryx>should pkg-config files be installed to a "lib" output when such is used? <apteryx>otherwise it seems ackward to have to propagate both (when listed ina pkg-config Requires directive) <podiki[m]>robin: thanks for that FHS stuff, will take a look <podiki[m]>and texlive download was very slow for me too <podiki[m]>could be that lualatex is bugged in core-updates-frozen, I'll see about a bug report if I don't figure it out <apteryx>can't the copy-build-system install to a different output? <apteryx>I tried giving it an absolute path; but it silently missed installing it there <brendyyn>Anyone here succeeded in running btrfs-convert on a Guix System root that had ext4? <efraim>apteryx: It looks like it hardcodes "out" in guix/build/copy-build-system.scm:136 <lilyp>apteryx: not currently, you might want to patch it so it does <apteryx>'pkexec must be setuid root' in a build, while doing this: Installing /tmp/guix-build-colord-1.4.5.drv-0/colord-1.4.5/data/figures/colorhug2-attach.svg to /gnu/store/pdc63h2k677plcvaxpdhjk6fyv0nlw4m-colord-1.4.5/share/colord/icons <apteryx>fun; it was caused by a path pointing to /etc/... <lilyp>where else would you want to put bash completions? 🤷️ <rekado_>I see texlive mentioned in the logs, so I’d like to remind everyone that you probably don’t need the big “texlive” package. There are lots of packages starting with “texlive-” that can be installed together into the same profile, so you can pick just the subset of LaTeX that you really use. <rekado_>I’m again running into trouble with ibus on gnome… <rekado_>I can use the pinyin input method in Emacs via ibus, but not in any of the browsers nor in the gnome terminal. <rekado_>I’m about to abandon gnome (I also don’t like sticking with this old version), so I wonder: does this work better elsewhere? <rekado_>it’s a pity that input method support has regressed so much. This used to work much better once. <apteryx>rekado_: gnome 40 is on core-updates-frozen, if I followed correctly <apteryx>thanks to raghavgururajan and others <apteryx>perhaps you could try it there, report any bugs <rekado_>oh, that’s great! I’ll try upgrading my old desktop machine and see if it works better wrt ibus. Thanks everyone! <bricewge>I have a « Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS » when building a package <bricewge>So I suspect there is a loop in the dependency graph <bricewge>How do you find such loop? I tried with `guix graph [...] | xdot -` but I can't see it, there is quite a few dependencies <apteryx>sneek: later tell civodul I've refreshed the branch with the latest fixes; the gdk-pixbufs loaders commits are on top <apteryx>(core-updates-frozen-batched-changes) <apteryx>hopefully the ci build it happily this time <bricewge>Staring at it the graph output I have found the dependency cycle. <bost>Hi. I'd like to try out the guix home, but I have a problem runnig `guix home reconfigure ...`: "No such file or directory: " export HISTFILE=$XDG_CACHE_HOME/.bash_history". Does anybody know what to do about it? <lilyp>bost, you're trying to use a string as a file-like object <bost>lilyp: I copy-pasted the scheme code from INFO guix to a file home.scm. And then I invoked `guix hme reconfigure home.scm`. <lilyp>Try wrapping that string in an appropriate (plain-file NAME YOUR_STRING) or (mixed-text-file NAME TEXT ...) <lilyp>That page is probably outdated. <nckx>apteryx: <should pkg-config files> Yes. <bost>lilyp: in fact that particular page contains a bit more scheme code then the INFO page. Hmm, which one is outdated and which one is up-to-date? <lilyp>If you are using guix home without tropin's channel, the documentation there does not apply <lilyp>There has been a recent move to file-like objects, which is sadly only documented in the MLs. <lilyp>(well, it does say file-like objects everywhere in the manual too, but that's quick to read over) <lilyp>We'd probably need a cookbook entry for Guix Home, but it's still rapidly changing <bost>lilyp: OK I guess I need to add-in the tropin's channel at first, right? <lilyp>I'm not sure about that, it's being phased out due to the inclusion in Guix proper <lilyp>The fix is to use file-like objects instead of strings <bost>lilyp: I'm confused. What do you mean with file-like objects? The text I copy-pasted *is* scheme code and I saved it in a file ~/home.scm <lilyp>Creating file-like objects is done with scheme code as well. <lilyp>I think it'd be easier if you simply pasted your config (using debpaste or gnome paste) <bost>So the ~/home.scm should contain the code `(plain-file "(use-modules (gnu home) <... the-rest ...>))"`? <bost>instead of `(use-modules (gnu home) <... the-rest ...>))`? (without the surrounding quote chars, of course :-) <bost>surrounding backtick-chars I mean <lilyp>No, it should have a file-like object in lieu of "export HISTFILE..." <lilyp>but FWIW doesn't Guix Home already have a service to set environment variables? <bost>well who knows :) I can't even get it started. <bost>BTW the string: "export HISTFILE..." is in a quoted list: <bost> export HISTFILE=$XDG_CACHE_HOME/.bash_history")) <lilyp>for one, there's a service to set those variables, for another bash-profile does not take a list of strings, but a list of file-like objects <bdju>the foot (terminal emulator) package in guix is pretty old. installing the latest release using --with-commit= seems to work, so it would probably be easy for someone to just update the package <bost>(bash-profile '(plain-file ("\ <bost> export HISTFILE=$XDG_CACHE_HOME/.bash_history"))) <bost>(bash-profile (plain-file ("\ <bost> export HISTFILE=$XDG_CACHE_HOME/.bash_history"))) <lilyp>that's not how plain-file works <lilyp>the syntax is (plain-file name text) <bost>(bash-profile '((plain-file ("\ <bost> export HISTFILE=$XDG_CACHE_HOME/.bash_history")))) <lilyp>please paste your entire config with a paste service <bost>wait wait please, I just need to switch my brain on... :) You said a list of file-like objects... so leme do that :) <vivien>bost, bash-profile needs to be a list of things <bost> (list (plain-file "bash-history" "\ <bost> export HISTFILE=$XDG_CACHE_HOME/.bash_history"))) *bost sorry guys I wasn't thinking :) <bdju>I see zsh-syntax-highlighting was packaged. how do you enable it? <zacque>*Newbie* question: How to write the Makefile install target for Guix package? I've tried `cp <NAME> /usr/local/bin/<NAME>`, `install -c <NAME> /usr/local/bin`, and `install -c <NAME> /usr/local/bin/<NAME>`, but keep getting "No such file or directory" error. <bdju>/usr is pretty much not used at all on guix. the only thing I have in my /usr is a /usr/bin/env symlink <bdju>can't answer what to put instead as I haven't done any real packaging work <bdju>but you can use `guix edit packagename` to check the recipes of existing packages and maybe figure it out by looking at similar programs <nckx>zacque: What do you mean by a ‘Makefile install target for Guix package’? If you're writing the software itself, i.e., not only writing a Guix package definition for software written by someone else, please don't hard-code /usr/local at all (this is general advice, not related to Guix). <zacque>bdju: Thanks, I've tried looking into the "hello" package, but even it is beyond my level of understanding... <nckx>Use a variable: ‘prefix ?= /usr/local’, then use that variable everywhere you call cp, install, etc. <brendyyn>zacque, I think that you need to use PREFIX <nckx>Then, in the Guix package, use (arguments `(#:configure-flags (list (string-append "prefix=" (assoc-ref %outputs "out"))))). <nckx>Dammit. #:make-flags, not #:configure-flags. <zacque>nckx: Hi nckx, oh, okay... so it's something like $PREFIX/bin for my install target? <brendyyn>--prefix is already set to the output in gnu-build-system <nckx>If this is a third-party package & ‘prefix’ doesn't work, try ‘PREFIX’ (the BSD equivalent). <nckx>brendyyn: That's for autotools packages. <nckx>zacque: I think the right way is $(prefix)b <lilyp>Well, not necessarily autotools only, anything that has a vaguely usable configure script :) <nckx>My reading is zacque seems to be writing their own Makefile by hand. <nckx>Not using configure scripts or packaging someone else's code. Is that correct zacque? <zacque>nckx: Ah, yup, I'm writing a Makefile by hand to learn packaging with Guix <zacque>Truth be told, I'm new to Makefile as well... <brendyyn>gnu-biuld-system. delete 'configure, make-flag PREFIX, CC <nckx>I'm sure there's a typo in there somewhere ☺ <zacque>nckx: Oh, what's the deal with DESTDIR? <nckx>It's for other workflows where users/package managers install the result into a ’staging area’ (e.g., /tmp/my-build-output/usr/bin/blah), with the intention to later merge it to /. <zacque>nckx: I see, will refer to the Makefile that @brendyyn shared <nckx>You should set a default value for prefix, and you should do the same for CC. This is important when cross compiling (e.g., building aarch64 software on x86) because ‘gcc’ won't work there. <nckx>For some reason not setting a default CC is considered more acceptable so that's up to you. <nckx>You're not writing this Makefile only for Guix users; make sure the interface between your Makefile & Guix package is sane & follows expected non-Guix conventions. <singpolyma>If you only cared about guix users you could just do it all in scheme ;) <zacque>nckx: Thanks! Will note it down as my Makefile best practices =D <zacque>singpolyma: That's an intriguing proposal ;) <zacque>singpolyma: How would you do that? Putting everything into the package definition? <nckx>Not sure that would help Guix's image with non-(yet-)Guix users. <nckx>I don't want others to have the same reaction to Guix as I do when I read ‘first, install npm/composer/…’ or — far worse — ‘installing foo is easy [uh oh], just go get/cargo/… [aaah]’. <lilyp>FWIW, if you distribute Guile software it does feel like that :P <lilyp>"First, get yourself a distro that even has a package manager. Next, install Guix on top of it." <lilyp>But tbh I prefer that over "Installing Scheme software is easy. Just use <language package manager>." <nckx>is there a ‘go away’ command <nckx>lilyp: Well, yes, Guix being a saviour is fine. <zacque>Hmm.. kinda lost here, but being language agnostic is one of the reasons I'm learning Guix <zacque>That said, I found that there are too few (close to zero) npm related package distributed with Guix... <zacque>Have to package them by myself... <lilyp>There are too few (close to negative infinity) npm-related packages that have a sane dependency tree :) <zacque>lilyp: Err, just reacting to your previous statement <nckx>And ‘not sane’ means ‘impossible’, not ‘huge’. npm can install packages only because it doesn't build things from source, otherwise it wouldn't work. <nckx>s/not huge/not just huge/, let's give them all the credit. <lilyp>I see deno.land wants to be a node.js replacement <bost>Hi again. `guix system reconfigure /path/to/config.scm` produces: <bost>guix system: error: symlink: Permission denied: "/var/guix/profiles/system-2-link.new" <lilyp>Plot twist: Try `guix import crate` it and it apparently has no qualms fetching more code over the aether. <bost>Anyone any idea what's wrong? I did `guix pull` just a minute ago <bost>guix system: error: '/gnu/store/354vgnsb0lfbpn059ndlkn55irhagk4p-grub-efi-2.06/sbin/grub-install --boot-directory //boot --bootloader-id=Guix --efi-directory //boot/efi' exited with status 1; output follows: <bost> Installing for x86_64-efi platform. <bost> /gnu/store/354vgnsb0lfbpn059ndlkn55irhagk4p-grub-efi-2.06/sbin/grub-install: error: //boot/efi doesn't look like an EFI partition. <nckx>What's mounted at /boot/efi? <bost>/dev/sda1 on /boot/efi1 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) <bost>/dev/sdb2 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) <bost>efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,relatime) <nckx>Why do you have ‘efi1’ and ‘efi2’ and what do they mean? <nckx>So the traditional set-up is that you have one vfat EFI System partition, shared between all your operating systems (if you have more than one), and it's what your firmware uses to boot, and it's mounted at /boot/efi. <bost>nckx: Good question. I remember a bit, that I had to play with grub settings after reconfiguration... And I thought it will get fixed in the meantime. AFAIR that was in August. <nckx>I say traditional but it's also just what's normal and expected. Of course you can specify (targets (list "/boot/efi1")) — or efi2, or even both — in your system configuration, but I hope you understand why your system is weird, because I don't ☺ <nckx>Do both efiN partitions contain content? *nckx AFK for now though. <bost>nckx: yep. it was 26th of August and I remember I found it also weird that I have to edit the grub.cfg to get a bootable machine. Whatever. I changed the bootloader-configuration target to /boot/efi1 and successfully reconfigured. I'm rebooting my computer now. (I should be back in about 5 minutes, otherwise I'm screwed I guess... ugh.) <robin>GRUB could use a little more documentation about EFI system partition size. i had to refer to https://wiki.archlinux.org/title/EFI_system_partition and wp (obviously it doesn't have to be huge the way it's currently used, but there are limitations on FAT32 partition sizes based on disk sector size, etc.) <robin>i wonder if EFISTUB and other grub alternatives might be interesting; it looks like kernel+initrd is <30MB on my system <bost>So the reboot worked. The only remaining problem is that my other operating systems are gone from the boot menu. (But that's not that bad, since I can access the the grub.cfg from my Ubuntu partition, and manually put the missing entries to the grub.cfg from the Guix partition.) *bost Gotta go now. See you all! <nckx>robin: How would you create the boot generations menu? <nckx>The nice thing about GRUB is it's not tied to one specific firmware, which EFISTUB, well, is. <robin>nckx, idk, and grub.cfg refers directly to the store so obviously it's nontrivial. OTOH grub has historically had problems keeping with linux fs development (i'm not entirely confident it'd work if i made a btrfs partition using one of the newly-supported non-crc32c hashes for checking file integrity, for example) <robin>i definitely don't expect guix to stop using grub (anytime in the near future), and have no complaints about it other than extremely slow crypto and having to type in qwerty (which isn't too bad, and of course one can add LUKS passphrases) <nckx>That's literally true, but it's due to us not supporting a stand-alone /boot (pointing to /gnu/store from grub.cfg as you say), not due to using GRUB. EFISTUB wouldn't fix that, just the orthogonal preparatory work (supporting kernels on a non-store partition). <robin>keeping up with linux fs development* (if only linux were GPLv2+ and not GPLv2-only...) <nckx>Yes, that would be nice. <nckx>robin: ‘Having to type in qwerty’ is again not a GRUB limitation? It and Guix support keymaps (very advanced ones too), so if that's broken please file a bug! <dstolfa>DigitalKiwi: you can use ZFS with linux :P <robin>yeah, and while that's feasible it obviously means the separate /boot (ESP, whatever) could get out of sync with the store <brendyyn>grub keyboard layouts only work in the second stage of grub. the first stage before filesystem decryption doesnt support it <brendyyn>hence i have to type my password twice in two different keyboard layouts <nckx>But yes, slow crypto is the only thing I can't refuse (and it annoyed me enough to string up a kexec-based boot loader for full SMP powerz). *nckx refuses slow crypto wherever offered. <robin>that would explain it. i just assumed it wasn't implemented for grub i think <nckx>brendyyn: But that's still a (Guix) bug, not a GRUB design limitation, IIUUC. <robin>brendyyn, a workaround is to add a second LUKS passphrase with a "qwerty-encoded" version of the actual passphrase (passphrase 'aeou' -> 'asdf' etc.) <nckx>We store the keymap on the encrypted store partition <galaxybrain.jpg>, nothing more. <nckx>robin: I'm disgusted and impressed at the same time by your creativity. <robin>nckx, do you mind if i add that to my .signatures database? (i guess this is a public channel, but usually i want to quote people from "private" channels...) <nckx>I have far better material than that, but sure! <robin>feel free to send suggestions :p irc: everyone's favorite sit-down comedy venue <robin>nckx, how does the kexec-based thing work, roughly? <lilyp>Can't sneek or some other bot fetch random quotes from users? <robin>on a less random note than the possibility of grub alternatives, i should submit the secure-boot tool i packaged ages ago (shim?). i'm...90% sure i got it working properly with manual setup, seems like something guix could handle on its own <lilyp>I think we had some site like that <nckx>Well, (1) not, because it's bitrotten (2) it's just a kernel + initramfs that runs cryptsetup, mounts, then kexecs the kernel with the right parameters based on a very simplistic busybox sh ‘parser’. So also doubles as a simple rescue system (more useful than the --repl). That's really how it started, a bcachefs rescue initrd, then turned into world's worst boot loader. <robin>emacs has rudybot for random quotes and other things (https://github.com/offby1/rudybot), and fsbot mostly for links and text snippets (linking to wiki pages mostly, i guess the guix equivalent would be manual/cookbook links) <lilyp>bash is not a bot last time I checked <nckx>I think raghavgururajan introduced a Rudybot here once, but it failed to parse issue tracker links and kept spamming ’Download!’ orders after each one. <nckx>I lovingly quieted it with a pillow until fixed, but that never happened. <nckx>Just to note that I wouldn't be opposed to a more featureful bot here 's long as it's not spammy. <nckx>sneek: I still love you ♥ botsnack. <lilyp>I think remembering some web page with a bunch of quotes at once <nckx>So, is it normal for ‘guix import go -r’ to produce 12,000+ output lines and should I just abort, or is that indicative of a bug somewhere? *raghavgururajan peeps-in <nckx>That's for github.com/kopia/kopia, a possibly mildly interesting back-up programme, but not at that price. <singpolyma>nckx: one of mine did that and it wasn't even complete. Lots of deps :) <nckx>Was it fixable by human hands? <raghavgururajan>Would it be better to replace IceCat with Abrowser in Guix? The later appear to be newer and more stable. <lilyp>Nothing in Go is fixable by human hands. <singpolyma>I reported a couple bugs in the importer from it which have since been fixed, but have been packaging other things in the meantime, haven't been back to it. The import takes some hours to run :P <lilyp>It's by giant corpos for giant corpos <nckx>It seems to me to be mainly giant corp(se)os' internal deployments at that. <singpolyma>raghavgururajan: no need to replace right? Can easily have both <nckx>It's intertwined with some weird Google-specific ideology that doesn't work outside of their walled gardens. <raghavgururajan>singpolyma: Would be redundant. May be the upstream of both can be merged together as one project. <nckx>raghavgururajan: Packaging abrowser is a good first step before we need to discuss anything else (‘replace’ how even? Guix already has many browsers). <singpolyma>I think it's like any other ecosystem, as more of it gets packaged new packages will have fewer missing deps <nckx>I don't agree that it's redundant. <vivien>What makes deja-dup superior as a backup tool is that it’s already mostly packaged, it just needs a little bit of fixing ^.^ <singpolyma>Is Firefox proper considered nonfree by guix policy? I guess because of the add-ons area? <nckx>Sounds like a nitpick; isn't. <vivien>Wasn’t there some non-free DRM to remove? <raghavgururajan>nckx: We could build IceCat with the Abrowser as source? Both based on ESR versions of firefox. <singpolyma>vivien: there's no drm when you build from source <robin>someday(TM) i'd like to work with mozilla folks to make icecat closer to (a specially configured variant of) regular firefox (i worked on firefox for a few years as an external contributor) <nckx>And yes, that's the problem singpolyma. ‘Encourages’ non-free software by one-click access to a non-FSDG store & the ‘would you like some tasty DRM?’ pop-up or something. <robin>(similar to firefox picking up useful features from tor browser) <singpolyma>robin: we need more external contribution to Firefox. Thanks for your work there <nckx>Have you mentioned this to the IceCat folks, robin? <robin>nckx, no, i don't really have time/energy for it atm <raghavgururajan>The primary goals of IceCat and Abrowser are same. To clean/de-blob/FSDGify Firefox-ESR. I wonder why we can't merge them. <nckx>Merging of development effort is just not a question for Guix, but for the IceCat & Abrowser upstreams. We can package both, but we can't really take on the burden of ‘merging’ browsers, which is huge. <nckx>Not to mention a one-way pain train ticket to CVE country. <robin>but for example a license filter for addons would be relatively trivial, and imho icecat not having an (obvious) addons interface just encourages people to use addons.mozilla.org directly anyway... <raghavgururajan>Like we are deriving IceDove with IceCat as source (partly/mostly)? So I meant deriving IceCat from Abroswer source. <robin>and i think moz would accept most of the other changes, at least as about:config options <raghavgururajan>I think currently Guix is the upstream of IceCat. Previews are built and released primarily in Guix. <robin>probably not the librejs changes (i don't think it's designed well for the modern web tbh) but those are smallish patches iirc <nckx>raghavgururajan: For Guix (it's a pity if IceCat usage is so tiny that we're effectively the only consumer), not really by. None of the Guix maintainers make any IceCat decisions. <nckx>So you're very welcome to discuss it here but it is not the place where any of the decisions are made (and people like mhw, who do, aren't here). <podiki[m]>rekado_: I was only trying the full texlive because lualatex wasn't working (core-updates-frozen) but I think it is broken there (xelatex fine) <raghavgururajan>I assumed Guix was making changes to the source when doing preview releases/updates. <nckx>It's possible that Guix is the only place where such changes are published, but they're still airdropped (in a good, competent way) by mhw from IceCat upstream. <nckx>E.g., the guix preview version suffix is something he/they chose. <robin>(having been involved in web standards development, i probably *could* come up with a halfway-decent whatwg-acceptable design for a hypothetical "librejs 2", but imho people who care about free JS should just disable JS for the time being and there are dozens of other things i could be doing) <nckx>In part so we'd have a usable non-ancient browser while IceCat's missing a ‘stable’ release. It's all a symptom of understaffing. Pity. <nckx>I think IceCat considers the Guix previews a compromise of their ideals already, but now I'm just rambling. Mainy to delay running ‘git reset --hard’ on 12k lines of nightmare. *robin wishes snowdrift.coop was usable already (might be a good way to have more full-time guix hackers) *nckx stares at it one more time, pretending to consider maintaining it & bashing it into shape. *nckx git resets, continues using rsync for sub-10-second full-system backups anyway. *raghavgururajan visits #icecat <podiki[m]>has anyone here used lualatex on Guix? is there anything I'm supposed to do besides installing texlive (or texlive- packages)? <singpolyma>robin: snowdrift lacks leadership willing to succeed, IMO, that's why I left as a contributor long ago <singpolyma>If someone is looking to fundraise to work in guix full time I think there are acceptable solutions that already work <brendyyn>My imaginary IceCat is just as trivial as possible by deleting nonfree stuff only. going overboard to provide something as crippled as possible seems counter productive. <nckx>Well, not to be facile, but the people actually doing the work get to choose how it looks. If you actually manage to deliver your imaginary variant I for one would be happy to use it & report bugs. <robin>there's liberapay but IIUC that lacks anything like patreon's rewards system. although people might not care about that in this context <nckx>But ain't few people got time to put in the grind. <podiki[m]>okay, I had to manually do a lualatex -ini with the ini file from texlive-tex-ini-files ....is that expected setup? xelatex did not need that <singpolyma>robin: liberapay doesn't have rewards because it is anonymous. There is active discussion about making anonymity optional. And there are self hosted options like fosspay <podiki[m]>(btw, no particular reason I use lua- over xe-....) *robin checks out fosspay *raghavgururajan is under the influence of zopiclone <podiki[m]>I guess I'll file a bug report, seems lualatex should work without manually creating the fmt file <robin>hum, fosspay uses stripe, which iirc from hcoop discussions requires nonfree js. afaik cryptocurrency's the only "easy" workaround, other than maybe supporting ACH/SEPA or something <robin>woocommerce (gplv3+) is probably the easiest way to do payments without requiring nonfree js, although idk if it supports subscriptions or not <singpolyma>You can use stripe without nonfree js but you have to be willing to do the compliance work which many are scared of because it is so unknown these days <singpolyma>At work we accept cryptocurrency and payment by mail as our current "workarounds" but neither is great for recurring support <robin>oh, interesting, i'll make a note of it (although i don't think nonfree js is a major issue for hcoop users, we never got a request for an alternative payment method during my ~5 years on the board) <robin>singpolyma, woocommerce has extensions for a whole lot of payment systems, including e.g. stripe (maybe it's more accurate to say the core software is free) <singpolyma>robin: right. Every credit card system they integrate with will default to nonfree js though <robin>(notably "Supports manual renewal payments through any WooCommerce payment gateway, along with automatic email invoices and receipts") <robin>singpolyma, they support more than just credit cards, e.g. there's a monero (and presumably bitcoin, etc.) extension (presumably cash-in-mail is doable too) <robin>of course you're right that credit support/paypal/... will universally(?) use nonfree js <singpolyma>Doesn't have to, but yeah for compliance reasons that's always the default. If you self-host the js you become somewhat more liable <podiki[m]>another tex question: is everything from texlive also available in the smaller packages? <robin>singpolyma, does self-hosting js here amount to accepting CC info on your own side, and interacting with CC companies on the backend? (i don't know much about the free-software situation in this area) <robin>podiki[m], hmm...texlive is basically a union package of texlive-bin and texlive-texmf... <podiki[m]>looks like not everything has it's own package <robin>but texlive-texmf doesn't appear to include absolutely everything, e.g. texlive-latex-fancyvrb appears not to be included in the texlive megapackage <robin>(unless i'm missing some package union/propagated-inputs magic) <podiki[m]>and guix import texlive <package> doesn't produce a package using simple-texlive-package (at least for a couple I tried) <singpolyma>robin: no, it's possible to self host js that still talks to stripe directly, for example <podiki[m]>which seems to be what many use that are packaged <singpolyma>But because you own the server the js comes from there are a few requirements <robin>singpolyma, oh right, through their API(s) <robin>podiki[m], fyi, with texlive installed, lualatex works OOTB for me <podiki[m]>or you mean it does on master, so it is a core-updates-frozen regression <podiki[m]>although now I get: ---! lualatex.fmt was written by luahbtex <podiki[m]>so maybe it was partially my setup? (that still isn't lualatex working, but failing in a new way) <podiki[m]>or rather I mean with a texlive-base starting point <lispmacs>robin: where you the one who helped me with my gpu questions yesterday? <robin>lispmacs, i don't think i was able to "help" much, but yes <lispmacs>with some experimentation in supertuxkart, I found that if I disabled all "advanced pipeline" functionality, such as motion blur, I was able to get decent game performance <lispmacs>even with other the geometric and graphic detail settings all the way up to high <lispmacs>robin: I am to be honest unclear at this point whether or not 3D accel is working/partial-working <lispmacs>with advanced pipeline features disabled, I can play the 3D game at normal speed <robin>lol, yeah that is a bit tricky afaik <lispmacs>I tried switching to guix systems from six months ago, and from a year ago, and that did seem to change anything <lispmacs>except a graphics tearing problem I saw in the past reappeared <raghavgururajan>singpolyma: Out of curiosity, do you use guix system or guix on foreign distro? <robin>hrm, so possibly the change was supertuxkart adding expensive 3d effects? <lispmacs>robin: i was wondering about that, though I tried building supertuxkart from a year ago, and it was the same version of supertuxkart <podiki[m]>maybe using newer opengl shaders that aren't supported in hardware renderer version you have available? <lispmacs>maybe. Maybe I was the one who changed the graphics settings and don't remember it. I'm not sure. <lispmacs>with all advanced pipeline features disabled, the game runs fine though does not look beautiful <singpolyma>raghavgururajan: apt install guix. Which means I can't update my daemon easily heh <robin>lispmacs, in any case, i'm glad you were able to get it working usably! <raghavgururajan>singpolyma: I see. Have you tried Guix System? Would like to gather experiences of people. <lispmacs>robin: thanks. I'm not quite satisified, but it is progress. I wish I understood better how to use the mesa-utils and what all the glxinfo data meant <raghavgururajan>Like if they feel guix system better for them over using guix on top of another distro. <lispmacs>I can run glxgears but that doesn't really convey anything to me about what is working and what isn't <NicholasvonKlitz>Anyone know how to get rust-src on Guix? I'm trying to use rust-analyzer but it depends on rust-src. I can't seem to find any information about how to obtain rust-src. Usually its done with rustup. Or are there any other resources for developing with Rust on Guix? <lilyp>What exactly does rust-src provide? Is it distinct from (package-source insert-rust-here)? <singpolyma>raghavgururajan: I've just used Debian so long it's hard to imagine leaving. But if I use guix long enough I may well try system for something :) <robin>lispmacs, if your card is relatively new, it's probably worth filing a bug about it (iirc supertuxkart doesn't exactly have AAA-level graphics). if it's older i'd personally assume that's the reason (maybe related to podiki[m]'s note about unaccelerated shaders) <robin>3d stuff on guix is a bit rough around the edges ime, e.g. i've never gotten OpenCL working <robin>(but that's more OpenCL's fault than guix's, the configuration required is sort of oddly designed) <NicholasvonKlitz><lilyp> "What exactly does rust-src..." <- it provides the rust source, rather than the compiler. The rust source is required for rust-analyzer to function properly <KE0VVT>Are you having trouble getting GNOME 41 packaged? <lilyp>I think the trouble is now getting c-u-frozen to be really really really ready <lilyp>On a side note, we probably should at least update the gnome extensions in between, though I could just fix those up after the merge. <rekado_>I upgraded my desktop machine to c-u-frozen. Works. I had to skip a few upgrades: blender, lilypond, and handbrake. <podiki[m]>I'm on frozen too, nothing major missing for me, but do hit some bugs here and there that I report <podiki[m]>and a bit confused over some of the gtk+/i686 situation (I get failures building, but sometimes seems there are substitutes?), needed for wine <lilyp>podiki[m]: flaky tests perhaps? <podiki[m]>lilyp: possibly, I did look at the logs on the CI as well and that might have been it, but I was also confused over why I needed to locally build somethings. I'll look again once the world rebuild branch is merged <podiki[m]>might have been the related pixbuf changes now that I think about it <bdju>is there a guix package I can install to get the gsettings command? <bdju>or is there another way to configure gtk stuff? I want to disable the annoying fading out that happens when gtk stuff loses focus <qyliss>bdju: ohh, what's the gsettings command to do that? <qyliss>(I'm not using Guix at the moment but this has bugged me forever) <bdju>I'm told it might be: gsettings set org.gnome.desktop.interface enable-animations false <qyliss>first I need to figure out how to get the gsettings command on _my_ operating system :P <bdju>it seems like dconf is related to gsettings. I don't have the gsettings command even with dconf installed, but I wonder if dconf could be used instead. I'm not sure how to format the command, though. it says the "key" has to start with a /. I guess it must be a file path. I'm not sure where to point it to. <lilyp>dconf is a gsettings backend <lilyp>the org.gnome.dotted-keys become /org/gnome/non-dotted-keys <lilyp>but gsettings appears to be part of glib:bin, so it should exist anyway? <bdju>ah, thanks for the info. I'll install that <bdju>well, running that command didn't seem to stop the fading. I don't know if restarting my session is required or not <lilyp>bdju try "pkill -3 gnome-shell" for a soft restart, although gsettings should normally apply those changes automagically <bdju>well, I'm not actually using GNOME <bdju>but Gajim does this annoying fading thing <lilyp>If so, it might be a Gajim thing <singpolyma>I don't think gtk uses gsettings outside of running the gnome daemon <lilyp>Well, GTK-adjacent applications often use gsettings <lilyp>but org.gnome.desktop is for gnome-shell specifically I think <singpolyma>They will use gsettings if the settings daemon is running, but not otherwise IME <bdju>well, not only gajim, I just don't use a ton of gtk programs. Dino did the same <bdju>gimp does not seem to do it. maybe a different gtk version <bdju>I think I was told once that it's related to the theme. I'm just using adwaita, though. (the dark variant) <bdju>the caja file manager does the same fading thing <bdju>not something I actually use in practice, was just digging for another example <lilyp>There is no such thing as a GSettings daemon <lilyp>there is a dconf-service which usually serves as backend ***brandon_ is now known as gorjusborg
<roptat>finally pushed the translation update! <Noisytoot>gajim fails to run with the lastest Guix: AttributeError: 'PosixPath' object has no attribute 'read_text' <drakonis>i'm too tuned out of the latest nixos happenings <jwoe324>Hi all, just wanted to ask a quick question: Why does Guix on a foreign distro require ncsd while Nix does not? <nckx>vivien: Prepared your patches on the train; in the meantime they were pushed; all good. <vivien>I hope that did not make you lose too much time. <robin>OS FS question: i have a LUKS-encrypted partition on an "archive" hard drive that i only need to mount occasionally. currently i just 'cryptsetup open'+mount it myself, but is there a guixier way? <vivien>(mmh in fact if I compare my small patches to the amount of work that is pushed on master these days, maybe it was not that much work, and then my comment will appear sarcastic… I hope not) <robin>(i wouldn't actually mind just automounting on boot, but there's so much dmesg noise around passphrase prompts that i'd probably find multiple prompts confusing) <robin>(possibly linux's "quiet" command-line option would help? i haven't tried it) <nckx>vivien: I'm just glad they got pushed and the backlog is infinitesimally smaller. Of course it would have been nice if 2 bugs could have been closed instead of 1, but that's life. <drakonis>jwoe324: why not ask the nix people why that's not needed? <drakonis>also probably related to shepherd instead of systemd? <singpolyma>robin: my current trick (which may not apply) is to have my main drive encrypted with self-encryption then my spinning rust is luks encrypted to a keyfile store on the encrypted main drive and so I only have to type one password <sailorCa`>Hi, I didn't get something in the documentation. To describe a package I need to specify a (sha256 (base32 "blahblahblah")) value. For zip package the guix download command could help. But what should I do for a github-repo and a tag? <attila_lendvai>sailorCa`, what i usually do is enter a bad hash, initiate a build, and copy-paste the good hash from the error message. <robin>singpolyma, that sounds like a good approach, i might try that <robin>(maybe with a tiny service or something...i don't think operating-system permits mapped-device->file-system->mapped-device dependencies) <robin>(or luks keyfiles, for that matter) 