IRC channel logs
2023-01-15.log
back to list of logs
<telmo[m]>due to the lack of some unavailable packages, lack of the distrobox, the non default setting of the flatpak and other small reasons I think I will abandon the guix for now, but I will continue with the linux libre kernel in nixos <mirai>I'm wondering if it's possible to make a "fake flatpak" frontend but with guix <mirai>that is, mapping guix shell options to flatpak options <mirai>telmo[m]: what non-default setting of flatpak <gnucode>why does define-configuration place such a huge importance on creating gexps? I feel like lots of fieldnames don't need serializers. They can just use procedures that return strings. <Maya[m]1>guix_noob: i mean i have working yuzu package, the only thing is that it is not gpu accelerated because mesa and vulkan aint that great on guix (or werent when i wrote the package) <mirai>gnucode: the examples use gexps <mirai>my guess is that they could have been convenient for file-like objs <mirai>your strings are passed (in general) to a mixed-text-file object (again, not required) <gnucode>mirai: actually i think I was looking at your code. could you have defined vnstat-serialize-string to not use gexps? <mirai>I've used it to generate HTTP headers for instance <mirai>it's a bit old and can be reworked <mirai>gnucode: in that service I could <mirai>common sense dictates that you use strings there <mirai>but if for $REASONS you were to pass a file-like obj (could be a procedure that builds a directory in store) <gnucode>mirai: I'm starting to really like (define-configuration . <mirai>yeah, it gets interesting when multiple types are involved <gnucode>mirai: I shamelessly used a few procedures from your vnstat-configuration code to re-organize my endlessh patch. <mirai>feel free, it's not like the code disappears when you use it <mirai>fixing some of the guix packages can get tiring really fast <mirai>some are very outdated or "never worked" (?) <mirai>it's worse when things are __recursively__ broken <mirai>you're working on package A but then you find out its it's full of workarounds (that might no longer apply) for dependency B <mirai>or you're troubleshooting some problem and want to use a package C only to find out it's broken <vagrantc>sounds like maintaining packages alright :) <mirai>it quickly becomes a problem of "can you remember where/what you were working at?" <mirai>(originally I was planning to submit a image lib update) <vagrantc>for me, the answer is pretty much always no ... as soon as i think i remember, usually i quickly realize i'm in another layer or two deeper than that ... recursively <mirai>it has now turned into mime-types being very outdated which then devolved into a docbook xml adventure <mirai>taming this xml mess is a real drag (while testing the hypothesis out, turns out xpath command from perl-xml-xpath was also broken and never worked) <pkill9>is there no service for the kde plasma desktop environment? <mirai>taming xml also came with its can of reading how the thing works (that included XSLT and friends) <mirai>gnucode: I reworked the camelfy procedure a few hours ago <mirai>you might want to update that one if you're using it <gnucode>did you submit a new patch to issues? <SUPERB[m]>sudo guix system reconfigure /etc/config.scm <mirai>screw it, I'm sending a "non-functional" patch before it gets lost in this recursive maze <Kabouik>I'm playing with ChatGPT for the first time, asking it to write Guix packages for things I never managed to package myself. The thing is even capable of throwing the hash to check the sources. -.- <Kabouik>I did not try those packages, though, I expect dependeny rabbit holes anyway (which often was why I abandonned myself) <mirai>does it generate coherent output? <mirai>or does it hallucinate scheme code out <Kabouik>It did fill inputs that look quite relevant to me. :< <Kabouik>Seeing spit the code is worth it even if the code does not work anyway, though it'd make me cry after the sweat I put into writing a handful of simple packages. :O <mirai>you "could" use it as a starting point I guess <Kabouik>Heck I'm sure I could ask it to write a simple package that does not exist yet, and then ask it to spoonfeed me with the commands I need to run to try it locally. <mirai>but there's guix import or templates/emacs skeletons so I don't see much value in it <mirai>I'd be interested if it could simplify code snippets instead <Kabouik>A patch bigger than what I could write myself <Kabouik>I asked it to write a program in Bash to interact with it without having to use the web UI. It's doing it. -.- <mirai>that would be too amazing to be true <mirai>but can it "write" or "guess" the implementation of proprietary file formats? or even programs <Kabouik>Actually for Guix packages, it told me after providing an example code that I need to check the hash and ask the community for help if I don <bjc>everything it does is "guessing", for lack of a better term <Kabouik>don't know how, and that the license is important for Guix. <mirai>afaik copy"right" applies to work derived from human effort <bjc>in the us, at least, that's true <mirai>non-humans or inanimate objects doesn't count <bjc>but copyright, in this case, refers to the license on the package being imported <mirai>I was thinking it was referring to the output <Kabouik>I did give it a gpl3+ license, and I think it was right. <bumble[m]>which guix package brings the 'gsettings' command? <apteryx>does libtool have issues cross-compiling? <apteryx>'guix build libtomcrypt --target=aarch64-linux-gnu' suggests yes <mbakke>apteryx: are you sure it should not be a native input? <mbakke>oh, I see what you mean now, maybe you can specify LD=#$(ld-for-target) or similar <rekado>for my rockpro64 I’d like to change the device tree file to enable SPDIF. IIUC the device tree files are not built separately but are part of the linux package build. <rekado>is there a way to decouple them without having to rebuild the kernel? <PurpleSym1>Is there a reason why cyclic references are not allowed in /gnu/store? I’m trying to untangle haskell-build-system’s outputs, but every library references /bin, /lib, /etc, … through the autogenerated Paths_library module. <PurpleSym1>Thus I cannot (properly) move anything into a different output. <rekado>PurpleSym1: I don’t know, but I’ve spent a lot of time fighting these cross-output references in Haskell packages in the past. <PurpleSym1>rekado: I’m at the point where I would just patch Cabal to obfuscate these, so Guix doesn’t “see” them. <rekado>I wonder if that’s merely a constraint to make traversing dependencies easier. <rekado>yes, different side of the same coin, that <PurpleSym1>Looks like patching Cabal is the only option to avoid yet another side project. The Haskell upgrade is big enough as-is. <PurpleSym1>Not sure if it’ll actually solve the problem that Haskell binaries are huge. <PurpleSym1>Maybe going for a fully static Haskell ecosystem is getting us closer to that. <pkill9>has anyone installed windows to dual boot, after having installed guix system? <Maya[m]1>but windows may mess up your boot order, they do whatever they want with it <pkill9>it feels like dual booting is going to be too complex, because my home partition is encrypted <pkill9>i think i will just get another laptop for linux and use this one for windows <Maya[m]1>pkill9: that doesnt matter, do you use uefi or bios <Maya[m]1>pkill9: when you open disk manager does the disk have an System EFI partition? <Maya[m]1>pkill9: okay, that means you have mbr and bios booting, you would need to resize one of your partitions to fit windows, but i think it should be possible <Maya[m]1>only thing that you need is that your computer must be booted in “legacy bios mode” <neox>Hello there ! I'm trying to find a gnat version suitable for guix. It seems there is no package for this, and I'm trying to bootstrap but no success at this moment. Did anyone succeeded to have gnat in guix ? <mirai>there's some Ada packages in guix <two[m]>in ada channel on matrix someone was porting ada to guix, you could ask there, maybe they have a package <neox>two[m]: well don't have/use matrix, but definitely interested in more infos about that <pkill9>i'm just gonna do the simple option of wiping the disk <jlicht>IWBN to have gnat packaged. Perhaps we could have {core,libre}boot builds <neox>jlicht, that's exactly why I need gnat x) <MrCauliflower>I'm running Guix on a foreign distro (Garuda) and many programs from that distro crash with this error: <MrCauliflower>symbol lookup error: /gnu/store/…-glibc-2.31/lib/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE <jlicht>MrCauliflower: do you happen to run these programs using a terminal emulator that was installed via guix? <jlicht>MrCauliflower: if you need things to work right now, I'd just not source your guix profile on login. It seems that there are some environment variables that the guix-installed software sets that break your distro packages :/ <jlicht>Having a look at `env | grep /gnu/store' could give you a hint on which particular package/env var seems to break things <nckx>I'd not expect common Guix-set environment variables to contain 'guix'. More like 'gnu' or 'GUIX' (se grep -i). <nckx>Would you be willing to share your entire env output in the problematic environment? <nckx>Thanks. More boring that I'd hoped indeed. <jlicht>MrCauliflower: it's this one: GIO_EXTRA_MODULES=/home/cauli/.guix-profile/lib/gio/modules <jlicht>I recall running into issues with that particular env var and firefox on my previous fedora machine <nckx>MrCauliflower: Is there any pattern to the kind of programme that fails to start? I suspect GIO_EXTRA_MODULES: it's exactly the kind of thing that would lead to libraries being loaded where they shouldn't be, unlike, say, PATH. <tremon>what's the correct modify-inputs incantation to effect this statement: (propagated-inputs `(("kernel-headers" ,linux-libre-headers))) ? <tremon>if I understand correctly, it's supplying the package input under a different label, but the naive replacement: (modify-inputs (append `("kernel-headers" ,linux-libre-headers))) just gives me "package has an invalid input" <vivien>Package labels are not used anymore <rekado>tremon: modify-inputs adds labels by itself <tremon>that's good, but trying to build a cross-compiler for a libc without that labeled input just gives me package `gcc-cross-x86_64-linux-muslx32@10.3.0' has an invalid input: ("xkernel-headers" . #f) <tremon>is there any way I can tell modify-inputs not to use the package name for the label? <tremon>because the package name is not "kernel-headers", it's linux-headers-cross-x86_64-linux-muslx32 <tremon>(autogenerated from cross-base.scm) <jpoiret>unfortunately not with modify-inputs <jpoiret>you can write that code by hand though, it's not too hard, just some alist manipulation <tremon>I was afraid you were gonna say that :p <tremon>I'll just use the hardcoded list for now since the original musl package doesn't have any declared propagated inputs, and leave a note to my future self <jpoiret>always the one with the most responsibilities <reyman>i'm moving my mail to proton, and i see proton bridge is open sourced, is there some package for guix started ? <Formbi>I tried to make a package for protonbridge, but the state of go packaging is a cluster <Formbi>after going deeper and deeper into the dependencies I found a package which I couldn't get to work at all <jpoiret>i ended up just self-hosting my email <jpoiret>i still have the preliminary work if you want, with the qt bindings done iirc <reyman>oh :/ So the only way is to install protonbridge on some docker or install it on debian machine on private network <reyman>i see there is the possibility to make with no gui jpoiret <reyman>perhaps that could remove some dependencies ? <Formbi>I did try doing it without the gui first <jpoiret>i don't think the problem was the gui dependencies but rather the sheer number of transitive dependencies <jpoiret>and also, just looking into what actual dependencies were being pulled in just made me realize that it was actually a steaming pile of garbage <reyman>more than rust :D ? i package rust deno for myself and there are thousand of dependencies also, lot of things with probably garbage in it <jpoiret>small libraries that had not been maintained for 10+ years, 1 outdated framework used alongside one of its supposed replacements, etc... <jpoiret>because in go you can pin dependencies to a specific commit that is not even a release <jpoiret>i mean, if google wants to do whatever, then sure go ahead, but don't encourage open source projects to do that <Formbi>the entire dependency tree has muiltiple versions of some packages <jpoiret>and on the other hand they're now complaining that open source projects aren't maintained well enough <reyman>yeah, that a common problem with lot of langages it seems, rust, go, nodejs <Formbi>I wonder if some of those old pinned encryptions libraries have some vulnerabilities <jpoiret>now i'm just trying to stay out of all of those languages, but with rust in the kernel it's going to be harder <pkill9>does anyone here use fedora, and if so how do you like it? <reyman>finally we say commonly that python is a mess, but that's worse with another langages. <jpoiret>although rust in the kernel doesn't really have the cargo packaging downsides <reyman>that's really questionning the reproducibility, when i see some tool like RMarkdown / R notebook jump on new quarto-cli that contain deno, and dependencies one thousand more complicated and huge than initial RMarkdown package. People only see the top of the iceberg. <jpoiret>yeah, the iceberg metaphor isn't even good enough at this point <jpoiret>but now that we have the FHS containers, you could also run the pre-compiled binary on github inside of one <jpoiret>just hope that the dependencies have the right version <jpoiret>since it's go it's mostly statically linked but you still have the qt bindings and some other things i think <reyman>ok, so that works using Docker top of guix now i suppose ? <jpoiret>docker is too large, we just use a home-grown FHS emulation layer using linux namespaces <jpoiret>you could call them "containers", but they're not LXC/Docker containers <reyman>yeah i use docker for lot of dev things on top of guix, because nodesjs, scala and other dev things don't actually work well with guix <reyman>i need to dig into LXC container actually <Formbi>btw there is a similar situation with Veracrypt out of all things <Formbi>countless bundled dependencies, hard-coded checks for /usr/bin/konsole (!) etc. <reyman>i install syncthing service and reconfigure system, but the service seems not available, i need to reboot ? <jpoiret>it should be available but nothing's better than a good old reboot <lechner>pkill9 / the traditional linux distros are nearly all the same. with windows in the mix as well, are you running too many operating systems at the same time? <reyman>jpoiret nop, i will try to reboot <pkill9>lechner: why too many OSs? im just switching from guix system <pkill9>currently i installed windows as i will need to use it for a remote exam <pkill9>but im considering moving to fedora as main desktop OS only because it has more efforts put into it to make it more cohesive and that 'just works' kinda experience <pkill9>or i'll move back to guix system,or use guix package manager idk <pkill9>and by more efforts i mean just sheer resources put into it due to being supported by an evil corporation <pkill9>i may just find it's not really though heh <podiki[m]1>anyone try mimetype from perl-file-mimeinfo? doesn't seem to work, errors with "Can't locate Encode/Locale.pm in @INC (you may need to install the Encode::Locale module) (@INC contains: /gnu/store...." <podiki[m]1>including perl-encode-locale as I think it is suggesting doesn't change it <podiki[m]1>I see, it want's perl as part of the environment as well <mirai>podiki[m]1: see #60824 for an example on fixing these situations <mirai>the cons might not be necessary, you'll have to try running it <podiki[m]1>I see, so some things that are more like a standalone application should be wrapped <podiki[m]1>along with that I think that package should just be mimeinfo (and likewise for exifinfo) as they are used more like that I imagine, but I don't know our perl packaging at all <jpoiret>podiki[m]1: In general, for most interpreted languages if you want a library to be available you also need to include the base package <podiki[m]1>but something that is meant to be a standalone program shouldn't; e.g. we don't require python to be in your profile to run programs in python (they get wrapped likely) <podiki[m]1>e.g. perl's exifinfo doesn't need perl in the profile <podiki[m]1>(likewise perl-image-exiftool should be called exiftool I would say) <podiki[m]1>anyway, I can't speak to perl and such, but for python that's what I've seen in guix: drop the python or py prefix if it is more of a standalone application and it should work as is <mirai>podiki[m]1: in fedora, the package for xpath is perl-xml-xpath (like we do in guix) <mirai>would separate outputs help here? <podiki[m]1>i know nothing about perl so maybe that's just my perspective <podiki[m]1>one I find is naming, though guix search will find it fine anyway; the second though is for usability: I don't think we should expect a user to include perl/python/etc. to use a little utility <jpoiret>oh, if the utilities don't work then you're right <jpoiret>i think sometimes though the line gets blurred, but here i think the dependency should be propagated probably <podiki[m]1>probably need to see what wrapping is done (mimetype is wrapped) and what's missing <podiki[m]1>perhaps some builtin libraries from perl? just a guess <antipode>podiko, others: if this abot what I think it is -- you can make perl scripts find external perl libraries without wrapping and without bash, by prepending or appending the appropriate directory to '@INC' in the beginning of the perl script. <antipode>In the past I wrote a variant of 'wrap-program'/'wrap-script' specifically for perl, but I didn't save it. <antipode>lechner: We (Guix) don't control how perl scripts import stuff. <antipode>I think it's much more convenient to just set @INC in the beginning of the script than to rewrite every Perl command for importing a library. <antipode>lechner: When would it be more convenient? That web page mentions as pitfalls that relative a path is problematic when combined with @INC, but Guix would use an absolute path. <antipode>Also, lib::relative is not built-into Perl, so the Perl script wouldn't find it. <antipode>(Unless its in the Perl search path, but that defeats the point.) <podiki[m]1>antipode: I don't know the internals at all, just that I would expect mimetype from the perl-file-mimeinfo package to work as is, without needing to include perl and perl-encode-locale installed as well <lechner>podiki[m]1 / they may not receive that message w/o sneek's help <apteryx>ACTION is nearing completion on cross-compilation enabled pyproject-build-system <apteryx>fun, 'guix build python-pycryptodome --target=aarch64-linux-gnu' now works <apteryx>file reports on its lib/python3.9/site-packages/Crypto/Hash/_SHA512.abi3.so that it is indeed "ELF 64-bit LSB shared object, ARM aarch64" <apteryx>vagrantc: do you know what the python inputs are use for in u-boot? <efraim>how much is the llvm backend needed in mesa? I'm working on stripping out dependencies for my gparted image and I'd love to remove llvm from the closure <SUPERB[m]>I configured /etc/config.scm like this and saved it but doesn't run user manager and desktop! <SUPERB[m]>sudo guix system reconfigure /etc/config.scm <reyman>well, i test the flatpak of protonmail-bridge, and i have a problem, the flatpak don't recognize the fact "pass" is installed on my machine, and reclaim it <reyman>i don't know what env variable need to be overriden to help protonmail-bridge to recognize the path of password-manager pass <SUPERB[m]><lechner> "and then you rebooted?" <- There is an error for lightdm-service-type <lechner>you may be missing a line in (use-modules ...) which would bind that variable <SUPERB[m]>lechner: I installed neofetch on another one but it doesn't run by typing neofetch through the terminal <SUPERB[m]>How shall I run programs through the the terminal? <lechner>sorry, i do not know what neofetch is (and do not see the connection to our earlier conversation) <mirai>SUPERB[m]: source your guix profile again <lechner>attila_lendvai / regarding your certbot question, never set the webroot field and my certbot service (but am also not sure it's working). do the temporary server definitions have to be served from the same webroot as my TLS content? <mirai>you could change the root for that location <podiki[m]1>efraim: I'm not sure, but there is the llvm based software render and I think some part of llvm is used for shader compilation on accelerated drivers? i think it is pretty necessary, at least some linked libraries <efraim>I'll see if I can trim space elsewhere. Already doing better than expected, just produced an ISO at 965 MB <sneek>civodul, you have 1 message! <sneek>civodul, mirai says: Regarding etc-hosts-service, when you suggested define-record-type (non-star), how would you specify a default value for 'aliases'? <civodul>mirai: you'd define a procedure with an optional argument wrapping the "real" constructor <mirai>oh, so it was a mathematical 'or' yesterday =) <mirai>it can be done with the star as well? <civodul>yes, but the star would also provide tons of things you wouldn't use <podiki[m]1>civodul: I wanted to note you as a co-author of the --emulate-fhs PATH env fix, should I also update/add your copyright lines? (2023 and all) <civodul>podiki[m]1: no big deal, either way is fine <podiki[m]1>there was a time when kgs was probably pretty well correlated with performance, eh? <mirai>civodul: the sanitizer is also star specific? <mirai>^H^H^H^H is the sanitizer .... <vagrantc>apteryx: binman is used to build a variety of u-boot related things, which uses python ... of course, easiest way is to remove the input and see what breaks :) 
