<mekeor[m]>mekeor: for the record: it helped to install the "rust" package in order to be able to run "cargo build". <vivien>Ah, so the unison manual builds fine if I’m running in a guix shell texlive (yes, the full distribution) but not if I’m only running with a restricted texlive-union. <jgart>that's a way you can specify rust outputs that you need <lispmacs[work]>hi, I installed Guix on a 32 bit foreign distro, using the installation script. however, when I do guix pull, 28% of the way through I get error "Git error: error inflating zlib stream" <jgart>lispmacs[work], hmmm, I'd report it on bug-guix@gnu.org <lispmacs[work]>that sounds bad, like you don't expect it to be fixed until after my death, if then <lispmacs[work]>hey, I want my Guile scheme code in Emacs to indent the way that it does in the Guix source code <lispmacs[work]>was there a file of emacs variables or something I needed to load <roptat>jgart, the plan was to submit it to learnxinyminutes, and maybe submit a slightly extended and edited version to the cookbook <florhizome[m]><drakonis> "a wiki shouldn't be a stand-in..." <- Well, f.e. documenting all possible services would bloat the manual a lot. For something like 2 pages of dovecot config options a wiki seems to be the better option to me^^ and there’s so much room for more, even just more config options... <roptat>vivien, i think just adding the packages is not enough because tex can't find them <vivien>(I’m in a texlive-union as you said) <vivien>(well, not texlive-union, but the thing with a name I can’t remember) <roptat>ah nevermind, I didn't see your patch <roptat>do you get the same error with all these packages? <jgart>roptat, cool both options sounds good <vivien>roptat, yes, dvips: ! Couldn't find header file: l3backend-dvips.pro ***Xenguy_ is now known as Xenguy
<luishgh>hi, i'm trying to configure my shells through guix home. the manual suggests that i can pass a list of strings to the bashrc and bash-profile fields of home-bash-configuration. however, when i do it, it complains that it can't open a file. passing a local file works fine though. the type of the fields is text-config, and i noticed it is gexp-text-config on rde's version, does this have to do it with my problem? thanks for your attention <dragestil>I just noticed in my `guix shell -D emacs` environment, the gcc version is very old (7.5.0) <dragestil>and if I exit the guix shell to get back to normal shell, it is 11.2.0 (probably the version in guix package) <dragestil>and if i run guix shell gcc -D emacs, it downloads gcc-10.3.0 but inside the shell the gcc version is still 7.5.0... ***isolier4 is now known as isolier
<nckx_>dragestil: Because that's the version of GCC that your Guix version uses to build emacs. <sneek>Welcome back nckx_, you have 1 message! <sneek>nckx_, jab says: that's he is an awesome human being. <nckx_>dragestil: Outside of your emacs development you probably installed the latest version of gcc-toolchain, but that's not what Guix uses to build all of its packages. <nckx_>Changing that version rebuilds the world so it's bumped only on core-updates merges. <nckx_>s/development/& environment/ <nckx_>…and good morning, Guix. :-) <davidl>thanks for the review of my python pkgs patches <nckx_>florhizome[m]: On the contrary, services are a perfect example of why wikis are a step down from proper documentation. (1) Changes need to be documented and reviewed together with the code [changes], that's tedious and error-prone if you have to manually sync out-of-tree docs <nckx_>(2) Things get even more fun when the changes are merged, because there's absolutely no version control tied to Guix. You can never be sure that what you're reading corresponds to your commit of Guix without digging into both histories. <nckx_>Hi davidl! One thing down, at least. <dragestil>nckx_: ok. can i specify which gcc to use in guix shell? <nckx_>I'm sure you can, but I don't have it yet on this machine to tell you how. <nckx_>You'd just include a newer gcc package which would take precedence over 7.5. <nckx_>7.5 is always in the default build environment. <nckx_>florhizome[m]: E.g. Dovecot used to operate this way, and I genuinely can't think of an advantage for me as a user. Apart from having to reach for a Web browser every time I needed to check something :-/ If you need to grep you're cempletely out of luck. <dragestil>how do i do that though, i tried guix shell gcc -D emacs hoping that will make guix shell use the gcc in my current profile <nckx_>Why did you expect it to do that? That wouldn't make sense. <nckx_>I'm still guix pulling to a guix with shell, dragestil. <nckx_>Maybe it will finish today and I can better answer your question… <dragestil>nckx_: when you guix pull, you can't do guix shell in a separate terminal? <nckx_>I'd still have my old guix in any new terminal until the pull is complete. <nckx_>guix pull: error: Git error: great. <nckx_>It was ‘object not found - no match for id (commit id)’, I wiped .cache/guix and restarted it. <dragestil>guix pull: error: Git error: the SSL certificate is invalid <nckx_>But you said it like it was a well-known thing. Does/did it happen frequently? <dragestil>It happened disproportionately frequently in my handful invocations of guix pull... <dragestil>it probably got fixed after i installed nss-certs <vivien>Hello guix, is there someone familiar with how texlive works (especially on core-updates-frozen)? I’m trying to fix an invocation of dvips in the unison manual. If I depend on "texlive" (the full distribution), it works, but if I only depend on all the texlive packages I could get my hand on, it does not: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51435 <vivien>By depend, I mean depend on a texlive-updmap.cfg containing these packages. <rekado_>vivien: it’s likely that texlive-latex-l3backend is merely incomplete <rekado_>most of the old texlive packages are <rekado_>texlive-latex-l3backend only fetches the latex/l3backend directory and installs that <rekado_>whereas texlive.tlpdb says that it should install more <rekado_>so the fix here is to use simple-texlive-package and make it cover all the locations that are mentioned in the tlpdb <vivien>I gues the initial tl are for texlive <nckx_>dragestil: Can you try again with s/gcc/gcc-toolchain/ and, if ‘gcc --version’ is still old, share the output of ‘which -a gcc’? <rekado_>vivien: ls $(guix build texlive-bin)/share/tlpkg/texlive.tlpdb <rekado_>I’m responsible for the broken modular texlive packages, because when I started I had a very tenuous understanding of how things were supposed to fit together <rekado_>and I wasn’t aware of the texlive.tlpdb <rekado_>so whenever I had an opportunity to do so I would fix old texlive packages and make sure the replacements would install all files according to the tlpdb. <rekado_>but clearly more work is needed there <rekado_>it’s a little tedious, because we’re lacking good infrastructure to build these packages <dragestil>which -a gcc outputs /gnu/store/n2x32g03saz5js4gvmnbprqrvwkbwsym-profile/bin/gcc\n/home/foo/.guix-profile/bin/gcc where \n is newline <rekado_>simple-texlive-package was a first step, but we could automate a lot more <vivien>Aha! that gigantic tlpdb file tells me there’s a file named texmf-dist/dvips/l3backend/l3backend-dvips.pro <vivien>So, I should package this as texlive-dvips-l3backend with a simple-texlive-package, that’s what you propose? <nckx_>OK, /me still pulling (3rd time; charm). <nckx_>links takes the ) at the end of your message as part of the link. <nckx_>florhizome[m]: I think you've been confuzzled with multiple independent (and irrelevant) workflows. local.mk is for the autotools build system, the thing that bootstraps the Guix source (e.g., from git) so you can run ./configure && make to build Guix. <nckx_>It is not needed or used by Guix itself to find patches. <nckx_>And it's not even related to channels. <nckx_>Could you back up and explain where you are and what you want to do? <nckx_>And also share the patch you want to apply and where you put it (Guix expects patches for packages in gnu/packages/patches, but it doesn't automagically apply them to anything; that's just where manual search-patch invocations start looking). <nckx_>dragestil: So order matters: guix shell gcc-toolchain -D emacs != guix shell -D emacs gcc-toolchain. You get to do (and screw up and fix) your own shadowing. Makes sense. <dragestil>but i thought everything after -D is not included in the environment <dragestil>this command builds the dependencies for emacs and gcc-toolchain <florhizome[m]>I want to build/reference in builds the updated meson from c-u-f something. so I copied the definition in a local meson.scm next to my other local package definitions (just copied the use-modules forms, too, even though they will be too much) and changed the definition to meson-0.60.0 so I can reference it. <florhizome[m]>then I reference it in the arguments field like #:meson meson-0.60.0 <florhizome[m]>I will then get a message the patch that’s applied in the meson description is not found. <florhizome[m]>I asked about this yesterday and someone answered I should create a local.mk file. <nckx_>dragestil: No. -D PACKAGE. This is not guix environment with its funky positional argument bifurcation :-) The manual has a good overview of all options. <dragestil>huh? the manual says: Cause guix shell to include in the environment the dependencies of the following package rather than the package itself. This can be combined with other packages. For instance, the command below starts an interactive shell containing the build-time dependencies of GNU Guile, plus Autoconf, Automake, and Libtool <dragestil>guix shell -D guile autoconf automake libtool <nckx_>That is what I described, not what you thought (‘everything after -D is not included’). <dragestil>well i mean they are not included, only their dependenies <nckx_>‘following package’, not ‘packages’. <nckx_>auto{conf,make} & libtool are included. Their dependencies are not. <nckx_>guix shell gcc-toolchain -D emacs means ‘give me the GCC toolchain, then then development inputs of emacs’. guix shell -D emacs gcc-toolchain means the same thing, except (apparently) the order in which paths are set up is different. <vivien>It would be clearer if we could stick guile to the -D (guix shell -Dguile autoconf automake libtool), but that’s not how the argument parsing works here if I understand correctly <nckx_>It could be made to work (some tools support this) but I think it's dangerous: if you think that -Dguile is more clear (eh), then the newbie you're trying to help will very likely think that ‘-Dguile’ means something else than ‘-D guile’, when it doesn't, simply moving (and IMO slightly increasing) the potential for misunderstanding. <nckx_>IMO & all. If that makes sense. <vivien>Or, guix shell (-D guile) autoconf automake libtool <vivien>But that would require extra hacking :) <dragestil>nah, for me what would make it clearer would be rephrasing in the doc <nckx_>Quoting. And it's totally inconsistent with how unix command lines work. It'll lead to more confusion. <vivien>Alexa, open a guix shell with the development environment of guile, and then autoconf, automake and libtool <nckx_>dragestil: s/Autoconf, Automake, and Libtool/the packages Autoconf, Automake, and Libtool themselves/ <nckx_>That's super-ridiculously explicit but that's probably a good thing. <nckx_>I mean, ‘the following package’ is already enough, but apparently easy to skim over. <nckx_>we're also missing `-D PACKAGE' instead of `-D', like -e EXPR below it. <nckx_>But of course ‘--development PACKAGE’ works, when only supporting ‘--development=PACKAGE’ would me more clear :( <nckx_>I mean that users of --development PACKAGE will get an error message and can update their script, it won't silently do something else. <vivien>Removing --development PACKAGE to only support --development=PACKAGE seems like a good idea <nckx_>I agree and will submit a patch with both changes above once I get this system repaired (hello from kirc on the Linux console :-/) but feel utterly free to beat me to it. <nckx_>florhizome[m]: The people helping you were speaking the truth, but for a situation that is not at all what you are trying to do. <vivien>Oh, that explains why the link separator detection is not great. <nckx_>Well, non-existent in the client (it's just a text stream, not curses), but I had logs.guix open in links in another VT. I thinks logs.guix was to blame for the parsing but not really in the mood to debug that. <nckx_>florhizome[m]: So your custom meson uses search-patch? Then it's as simple as putting your patch in gnu/packages/patches/meson-my-patch.patch, and (search-patches "meson-my-patch.patch") will find it if your situation is what I think it is. <nckx_>No central registration needed. <nckx>Greetings from HexChat! \o/ …and a previous system generation. <nckx>Also, I have to suspend and resume my laptop at the exact right moment during boot to be able to log in later. <abrenon>previous system generation ? your pull broke everything ? <nckx>No no no. *I* broke everything ☺ <nckx>Guix is not to blame (except, maybe, making it too ‘easy’ to take silly risks). <nckx>abrenon: It's OK. I have an even older generation I can boot if I really need to get serious business work done. Praise Guix. *abrenon mumbles "all hail Guix" <florhizome[m]>nckxz: well that's how i have it. i'm now in matrix via emacs so i can paste stuff. <florhizome[m]>btw is there a favorite emacs app for such things? there are many that are called "paste"-something ... <florhizome[m]>also, just discovered xwidgets-webkit are integrated in this build from flatwhatsons channel and browsed the gnu site :O the possibilities :O <vivien>Well, the webkitgtk drama is not over yet: gnome-online-accounts fails to build on master with a few ld: /gnu/store/4436r43crxcdmz011r7i2c1niz4jvi6g-webkitgtk-2.34.1/lib/libjavascriptcoregtk-4.0.so: undefined reference to `std::filesystem::symlink_status(std::filesystem::__cxx11::path const&, std::error_code&)@GLIBCXX_3.4.26' <florhizome[m]>the filesystem error in in combination with c++ also pops up when using gcc <8 <nckx>The filesystem is a classic ‘GCC too old’ symptom indeed. You can simply include a newer ("gcc" ,gcc-N) to try. Just pointing it out since some people don't expect it to be that easy. <florhizome[m]>upstream has a gnu/packages.scm file that defines a %patch-path, maybe i need something like this? or just channel definition? ***wielaard is now known as mjw
<nckx>florhizome[m]: Can you explain your situation then? For context: I (and seemingly others) assume you checked out guix.git, are editing that, and using the result with ‘./pre-inst-env guix’. You mentioned channels earlier as something ‘maybe I should’ so I assumed you're not writing a channel now. All these details matters greatly: the search path (FWIW) for channels does differ from that for Guix.git for whatever reason. <excalamus>I'm trying to do a package -u and it's failing on gnome-online-accounts-3.36.0. Checking the log, I see a bit about Webkit and undefined references like /gnu/store/4436r43crxcdmz011r7i2c1niz4jvi6g-webkitgtk-2.34.1/lib/libjavascriptcoregtk-4.0.so: undefined reference to `std::filesystem::symlink_status(std::filesystem::__cxx11::path const&, std::error_code&)@GLIBCXX_3.4.26' <nckx>(Local and) simple complexity, dragestil, as always. I have a bit of a complex channel set-up to ‘ease’ local Guix & channel & kernel development. In hindsight: a bit more complex and fragile than probably needed, as always. 😉 <vivien>excalamus, yes, I was advised to try a newer GCC <nckx>excalamus: vivien mentioned this above. It's very likely due to the default GCC 7 being ‘too old’ to compile this code without patching (filesystem → experimental/filesystem or something IIRC). <vivien>I can’t investigate right now, because I’m trying to fix something else on core-updates-frozen <nckx>Nobody expects the dragestil inquisition of shame. Ehm: I have a script that takes Linux and applies a few (less than 200) patches to it, then uploads the result to a repo, then updates my local channel, but then also (for reasons indefensible today) modifies my ~/guix and commits to it then pushes that to another remote repository and manually invokes a hook there so ‘guix pull’ can pull from it without having to run a CGI server. That hook broke. *nckx feels lighter after their confession. <vivien>excalamus, you must modify the package itself <vivien>I don’t know exactly how to do that <dragestil>nckx: it's late at night and your confession is beyond me. i've put a bookmark there to reread it tomorrow. <nckx>excalamus: Guix doesn't use anything you happen to have installed. Only the (in this case: ‘implicit’) build inputs. You'd need to modify those. Maybe --with-input= works, did not test. <excalamus>well, I guess I wouldn't be upgrading this morning <nckx>dragestil: It's not something worth reading or understanding or emulating. It's something I will *not* be doing soon. <vivien>Maybe there’s an argument for the build system to override the gcc package to use for compiling? <florhizome[m]>i hope i am not annoying, but wouldn't it be possible to merge something like the meson update (a build tool that's increasingly often used within newer software, including gtk/gnome and wayland development into master -- the old default could just be kept, like with gcc, until compatibilities are assured? availability of functional and up-to-date build tools seems like a central thing for guix to workout for most people to me. it's ok if i <florhizome[m]>can't install the newest wlroots/gnome/elementary stuff from the guix repo but if I cannot be sure to have the build tools that guix has available working correctly to build it myself, that makes guix unusable for all newer releases in a certain spectrum. (glib, wlroots, others need meson => 0.55, but the current "meson-for-build" is 0.53.2. knowing that meson on c-u-f (0.60.0 ,0.59.0) are patched, i just can not be sure pulling the <florhizome[m]>seemingly unpatched meson-0.57.2 on master into a build will work out... <dragestil>nckx: the setup looks interesting. i've been trying to create my own automated build workflow <florhizome[m]>@ discussion for me it worked to just put it into native-inputs <nckx>vivien: Simpler: the GCC used is whatever's available in $PATH (the package's build system is really what decides, not Guix), so you can simply add (native-inputs `(("gcc" ,gcc-N))) and almost all packages will DTRT. <vivien>nckx, will it work for cross-compilation? <nckx>Good question. I have never tried. <vivien>I mean, nothing works correctly for cross-compilation obviously, but at least we should try to do the right thing. <nckx>Give it a quick --target=aarch64-linux-gnu and see. <nckx>Some things do, and more are fixed every day. <nckx>Let's hope c-u-f doesn't regress but it may well improve matters. <nckx>florhizome[m]: There are too many Meson packages (=rebuilds) to change the global defaults but what you describe is already how things are done. New meson-x.y versions are added directly to master, and individual packages can opt in with #:meson, also directly on master. So I'm not sure which problem you're describing. *nckx needs to concentrate on their lunch or their fancy x220 keyboard will be for naught. BBL. <dissent>it isn't clear to me why xinput settings aren't working <nckx>dissent: This is what I used long ago in the pre-Wayland times and it worked. <https://paste.debian.net/plainh/61ac6c35> I don't see anything obviously wrong with yours. libinput didn't used to be part of the default list but surely that's fixed by now. <nckx>One big difference is you matching on the driver & me matching on the device name to *set* the driver, I guess. Again, I'd hope that's legacy cruft, but who knows. <florhizome[m]>nckx: the problem is that meson apparently needs to be patched (and i don't know if the manner of that has changed) <florhizome[m]>so right now upstream you will have meson-0.53.2 , meson-0.57xx, meson-0.55xx, and a "meson-for-build" that is used in the build process. <florhizome[m]>you can specify the meson version you want to use in arguments. but while there is at least one compatible meson in master for newer packages (not sure if the incompatibility includes 0.55 or not) it seems to me like they're not patched. in master, there is a dedicated meson-for-build, while in c-u-f both meson versions currently available are being patched). that v 0.57.2 just doesn't need modifications seems highly unlikely to me - also i <rekado_>the “update” yasnippet seems to no longer do the right thing. It consistently pick <florhizome[m]>*that *could* correspond. it's pretty confusing overall. but maybe you can keep the default meson-0.53.2 and meson-for-build around and switch the newer versions with those on c-u-f or sth like that. <excalamus>nckx, I look forward to the day I can quickly make updates like that. I'll get there. Thanks again <dissent>nckx: your suggestions did that trick <nckx>florhizome[m]: You're talking about a ‘patch’ in the sense of a change that 0.59.0 contains by default, right? Because Guix doesn't patch Meson 0.59.0 at all. IIUC (which I'm not sure is likely at this point) you'd simply do this on master: https://paste.debian.net/plainh/91f9ad8f <nckx>Apologies if I'm still misunderstanding. For reasons which are surely my own I find it hard to follow your story. <nckx>I don't think so either, pinoaffe. Meanwhile, Chromium does have some extensions packaged in Guix. Sad situation. Mark's ‘Would you like to work on it?’ still applies! <nckx>excalamus: You might be crediting me with the revert, which I didn't do, I just wanted to save y'all time debugging on a stale commit. <pinoaffe>nckx: okay, I may take a look at it myself <excalamus>nckx, even that would have taken me a non-negligible amount of time. I appreciate it *nckx swears out loud as git conflict errors fill their screen, all they want to do is just update to Linux 5.14 already, why is this so hard, why can't everything just— <nckx>The merge conflicts are because upstream rebased on 5.15 \o/ <vivien>Oh, so the gcc stuff with webkit is reverted <roptat>M6piz7wk[m], do you really need to install the docker package globally? I thought it would be enough to have the docker service (it also automatically adds docker-cli to the system profile, so you don't need it as user either) <roptat>I'm running into memory issues again with guix pull... <roptat>this time even on a fairly powerful machine, it stops at 99.7% with "GC Warning: Failed to expand heap by 8388608 bytes"... and "Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS" <roptat>I'm pulling for armhf on an x86_64 system with 64GB of ram, mostly empty <roptat>on the armhf machine, I don't have enough memory and get "builder for `/gnu/store/j78681gbk02hy5am0mnkb1bkbl8ls5h2-guix-packages-base.drv' failed due to signal 9 (Killed)" <abrenon>the builder's required amount of memory depends on the target architecture ? <roptat>abrenon, not sure, but on x86_64, I get substitutes <roptat>also, it still fails when emulated, but doesn't use all my memory <roptat>maybe qemu is limiting the amount of memory it uses? in that case, how can I give it say, 10GB? <apteryx>roptat: do you mean through transparent (user) emulation? <apteryx>it should use all the available memory you have on your host <roptat>then the issue is the default heap size in guile? <apteryx>it's a bit like WINE from what I understand; it translates/emulates in usermode to run the software via a specific qemu binary registered in binfmt <roptat>yes, I had to play with the registration, because it's a foreign distro <roptat>my understanding is that it detects that it's armhf binary due to some magic first bytes, and runs it with qemu-arm as its interpreter <roptat>(whereas it would use /lib/ld.so or similar as the interpreter for a native binary) <apteryx>roptat: thats sounds correct, from the little I know :-) <apteryx>and because of the F flag in the binfmt registration, the interpreter is loaded in memory and made accessible even to namespaced processes <apteryx>(this requires qemu to be built statically) <roptat>again, this time building with -c1, at 61% :/ <roptat>is there a way for me to pass MAXHINCR or MAX_HEAP_SECTS to the build, without changing the derivation? <apteryx>when core-updates-frozen-batched-changes reaches the coverage of core-updates-frozen, I'll merge it <luishgh>"GUIX_PROFILE=\"/home/luishgh/.guix-profile\""). passing a local file works fine though. the type of the fields is text-config, and i noticed it is gexp-text-config on rde's version, does this have to do it with my problem? thanks for your attention! <jpoiret>how do you people cope with the mailing list traffic? <jpoiret>i don't read them for one day and i feel overwhelmed instantly <roptat>I have to filter what's interesting to me or not <jpoiret>true, looks like i'll have to setup my notmuch tagging now then ehe <roptat>luishgh, to pass a variable, you should instead use the environment-variables field <roptat>otherwise, bashrc and bash_profile are lists of file-like objects, not strings <florhizome[m]>You could as well spare this definition up front and just type it out but to me it provides a bit more overview, and a cleaner sense about what’s going on. <roptat>luishgh, ok I don't remember exactly, I don't have my config on me right now, so I might be wrong, sorry <luishgh>roptat: no, i mean, i agree with you, i think it expects file-like objects. i remember the manual saying so somewhere and the error also suggests that. the problem is that i think the rde's version expects a list of strings and the example section of the manual uses it this way, which is apparently inconsistent with how it works on guix proper <luishgh>florhizome[m]: hm, just saw your answer. so it seems it really expects a list of file like objects... should i send a mail somewhere warning guix maintainers that the manual setup example is incorrect? ***wrk is now known as pjotrp
<lfam>Maybe we should check our build logs to see if this it would break our builds <roptat>maybe check logs from previous versions on other architectures to check for warnings? <nckx>I said N. Would that propagate to modules? <lfam>Not sure. The default is N <nckx>We should be realistic. It might turn Guix into a distro that reports slightly more kernel bugs (*would* we?) at the expense of, well, us. <nckx>‘If in doubt, say Y’ is not quite a Kconfig meme but close. <lfam>Yeah, I agree with your assessment <lfam>If people were discussing our build logs, then maybe I'd say we turn it on <nckx>And by us I mean the already overtasked person who — well, you. <lfam>But, I'm not sure anyone looks at them <nckx>I'm happy the option exists and I hope those who can easily afford it — the IBMs and Googles of the world — enable it on all their builds. <apteryx>we don't yet have a geckodriver package, right? <apteryx>seems all we need is --enable-geckodriver on our icecat package *apteryx will give it a try <jgart>is anyone else having trouble import a python library with guix shell? <roptat>jgart, you need python and that library together in the guix shell <jgart>I tried importing pandas but it fails to find the module now <jgart>python-wrapper would be fine? <roptat>don't know, as long as it defines PYTHON_PATH <lispmacs[work]>Hi, I'm trying to figure out if I can get single-word code completion in Emacs Guile mode, thought somebody here might know <jgart>do you mean geiser mode for guile? <jgart>a quick way to get an emacs ide for guile is guile-studio <jgart>I think it comes with everything you'd need <nckx>lfam: That's simply CONFIG_X86_SYSFB (which we didn't set) renamed. <lispmacs[work]>jgart: hi, I'm using geiser mode already, but I haven't figured out how to get code completion. <nckx>I did set it back when I still used UEFI. <nckx>So I never booted without it. <nckx>But nothing should regress if you say N. <apteryx>the qemu build seems to hang on cufbc <florhizome[m]>Well I don’t see something speaking against that. It’s pretty much easier getting the functionality that we have now just by defining something yourself to append some strings in to the file. It should be a bug... <florhizome[m]>the functionality of integrating file-like objects by itself is cool, if it means these file s are then also stored so you can reproduce them, store metadata to them... but that has nothing to do with the default code right now <apteryx>no way to put a '^rust$' in the cuirass search? <dissent>any users of dmenu? none of my scripts located in .local/bin are appearing in the prompt. it is definitely in the path. <podiki[m]>I think there were changes to file objects vs strings after the initial commit of guix home, maybe manual wasn't updated? that would be good to report and fix <podiki[m]>dissent: I use rofi, but same idea I think, but I think works on my end <podiki[m]>one guess would be if PATH is different in dmenu's env (if in a different profile?), not sure <roptat>like podiki[m] said, if it's started from an environment where PATH is not set, it won't find stuff in .local/bin <dissent>i also have rofi installed and same thing. <podiki[m]>perhaps how/where you are sourcing profiles? i source all mine in .zprofile (zsh), and add .local/bin in .zshenv <podiki[m]>(oddly, .local/bin then not in my terminal PATH, but is seen by rofi. mayhaps my config is a bit weird) <dissent>podiki[m]: sourcing all my stuff in `.profile` <podiki[m]>hrm. maybe it is how dmenu is being launched? different from a WM shortcut or from a terminal? not sure, sorry <pinoaffe>dissent: it's been ages since I last used dmenu, but are you sure your dmenu gets its list of programs from $PATH rather than from "desktop" files? <dissent>pinoaffe: no, not sure. but that seems to be the cause. just trying to figure out how to alter this behavior. finding some answers on arch forums. <apteryx>building kexec-tools on i686 fails; for reasons unknown (it passes in kexec-tools CI and also tested by the author with ubuntu 20.04 (same GCC as ours)) <nckx>dissent: I use dmenu from Sway. Picks up .local/bin wrappers. <nckx>I guess it's trivial to check its environment. <nckx>pinoaffe: If we're talking about the same dmenu, definitely $PATH. <nckx>Using .desktop files would be weird. *apteryx laughs at the 431 MB xz-compressed source tarball of icecat <dissent>don't know what exactly i did... but it works now :D <roptat>oh, I finally managed to build guix-packages-base after more than 10 tries ***iyzsong- is now known as iyzsong
<pinoaffe>nckx: ah yes, "i3-dmenu-desktop" gets its list of commands from .desktop files while "dmenu" itself just gets it from $PATH <nckx>apteryx: One of the better arguments for zstd even at rest. <podiki[m]>speaking of rofi and dmenu: I make a link for dmenu->rofi (some things need to see a dmenu bin) <podiki[m]>to make that a package, just have rofi as an input, and "building" is just making a symlink to input rofi's bin? is that allowed (store to store link) <nckx>lfam: Sorry to pop this so late but I was thinking about this on the bike (…yeah): did you enable DRM_SIMPLEDRM? <apteryx>this ssh connection that drops every 5 minutes drives me nuts <nckx>apteryx: Did you play with ClientAliveInterval/ClientAliveCountMax? <apteryx>no; the config is pretty much a Guix System vanilla openssh-service-type config <apteryx>I've tried ServerAliveInterval 15 in my local config but that didn't help :-/ <nckx>Try setting something like ClientAliveInterval 15 | ClientAliveCountMax 4 <nckx>That would be on the server. <nckx>Whatever = the above sends pings every 15s to keep the connection busy (in case that helps) and will disconnect if 4 pings are missed. <nckx>I think I mentioned TcpKeepAlive last time? IDR. <apteryx>TCPKeepAlive is on by default (according to man ssh_config) <ss2>good evening. I don't know how I managed this, but somehow the Guix script installer is failing on a Debian system at the moment: https://paste.rs/YOY <apteryx>I think I probably shot myself in the foot; I recently configured another remote machine, and copy pasted the autossh snippet, but left the port unchanged <roptat>record-abi-mismatch-error on any guix command <apteryx>nckx: so both autossh services must conflict, leading to connection loss perhaps <ss2>It stops everytime at that stage, and I tried this on another VM, but it completed there. <apteryx>nckx: man autossh -> this port and the port immediately above it ( port + 1) should be something nothing else is using ***mark__ is now known as mjw
<nckx>OK, I haven't used autossh, but that sounds plausible and funny :) <apteryx>autossh is great for the 3rd world which doesn't have ipv6 yet, such as canada <apteryx>open a tunnel to home (with a dyndns service), then you can hop back into work <nckx>ss2: You can run it with ‘bash -x’. <nckx>Or sh -x, although I'm not 100% sure it's POSIX'd gud. <nckx>apteryx: I've heard there are even some third-world servers out there that don't support IPv6. <nckx>Great fun learning that on an IPv6-only VPS :-/ <roptat>should I try and split some modules further, to reduce the size of guix-packages-base? I think that could help a lot reducing memory usage when building, but would such a change be acceptable? <nckx>ss2: Hum? I wonder if it's waiting for an agent or pinentry or something. <nckx>What does that command do when run manually? <nckx>If there's any gpg-agent/dirmngr running, kill it. <nckx>roptat: Package modules? <ss2>No such file or directory. <ss2>gpg can't find the file, which means it is not looking over to /tmp, where the files are placed. <nckx>Well, you have to download that file or cd to the temporary directory in the log (/tmp/guix.Eu9) if it still exists. <nckx>It should exist for the run-time of the script at least. <roptat>guix-packages-base builds the closure of (gnu packages) and (gnu packages base), which is 411 modules <roptat>(well a bit less, because there are some modules that are ignored) <nckx>I'm downloading the tar.xz myself but it's @75KB/s :-/ <apteryx>hmm: In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): ("./obj-x86_64-pc [...] <apteryx>nckx: IPv6-only VPS ouch :-) you must have had to mess with IPv6 over IPv4 (ISTR this was a thing) <nckx>roptat: No ‘real’ API programming modules though. I'm personally fine with splitting package modules if it makes a measurable difference. <ss2>me smarties copied missing .sig file to ., but that didn't work either. Why is the script failing to go over to /tmp? <nckx>apteryx: Yes, after fighting far too long to get berlin behind an HE.net tunnel. TL;DR can't be done. <nckx>ss2: Why do you say it's failing? <nckx>Furthermore, it would error out of that were the case. <nckx>OK, I think I see what you mean. <nckx>(The one time I really miss syntax highlighting 😃 This is giving me a headache.) <nckx>ss2: I didn't find a bug in the script after all. <nckx>wget -q --show-progress -P /tmp/guix.Eu9, then pushd to that directory, then invoke gpg, all correct. <nckx>If it magically started working my best guess is that something got stuck between the different processes that make up GPG. <nckx>ss2: Why did you say ‘missing .sig file’? <ss2>The difference was to call sudo ./guix-install.sh instead of openning a shell with sudo -i and initiating ./guix-install.sh from there. <ss2>Did I mean it so? Well not really. I was wandering why the script would never carry on working in tmp. <ss2>anyways, got it working now. <nckx>Wonderful! There was nothing wrong with the script BTW. I suspect a GPG bug/unexpected behaviour. <ss2>maybe, or just how Debian has its own magic with doing things. <nckx>Hence why invoking it manually might be valuable, but maybe not. <nckx>Well, OK, but ‘GPG freezes when you call it’ is pretty disappointing magic ☺ <ss2>anyway, I hope I never questioned the script being at fault in a way. <nckx>It did sound like you doubted the script at one point. <nckx>Questioned its infallibility. <nckx>I hope you've learnt your lesson! <mekeor[m]>jgart: you can define user-space shepherd-services in ~/.config/shepherd/init.scm? :O <ss2>There might have been a slight moment. <lfam>nckx: DRM_SIMPLEDRM is "m" as of linux-libre 5.14 <podiki[m]>...hrm maybe an update to that with more examples would be good for the cookbook <mekeor[m]>podiki: ah, right, i remember reading that xD <jgart>the article that podiki[m] linked also confirms it <nckx>lfam: Now there would have been an idea to check. <podiki[m]>I would love a good cookbook on setting up user shepherd services, though maybe that is part of guix home now? haven't checked <nckx>So I think the module that DRM_SIMPLEDRM builds is de facto useless on x86 without the SYSFB one? I'm just not 100% sure. <nckx>s/one/setting/, did not to imply that it's a module (it's not). <jgart>I'd like to devote some guix packaging meetups to bettering the cookbook <jgart>roptat just wrote a nice intro article to texinfo <podiki[m]>jgart: that sounds great, I have a few ideas I wanted to do (moving store from /gnu on foreign distros, and making live system images) <apteryx>eh, the cufbc branch is finally catching up with cuf <jgart>podiki[m], next meetup is 27th <jgart>it's always on the last Sat. of the month and I'll announce it on guix-devel a few days before <podiki[m]>I think it has been at a time when I'm not home, but hopefully will be able to make it <podiki[m]>apteryx: any prospects on when they will be merged? I assume that's one big step towards getting it closer to merge with master <apteryx>we'll have to sort out the non x86_64 architectures, particularly powerpc64le, which I think may be a bit of a challenge given rust doesn't build there (perhaps polkit-duktape can be the default one used in guix) <apteryx>so a bit more stabilization will be needed in core-updates-frozen <podiki[m]>I saw gtk+ wasn't building on i686 either, I'm guessing that's blocking a lot of packages <podiki[m]>or is that fixed on batched-changes? something with pixbuf/svg test? <lfam>nckx: I'll CC you when I submit the patch for 5.15. And maybe you can test this? <florhizome[m]><podiki[m]> "I would love a good cookbook..." <- can confirm, it is ;) <podiki[m]>florhizome: oh nice. and now that guix home is on core-updates-frozen (what I'm on) I have no excuse <nckx>Well, I got rid of UEFI completely, I don't know if I can. I know that coreboot provides a similar FB but it's a different driver from the EFI one. <apteryx>podiki[m]: gtk is broken there because of kexec-tools <apteryx>that mysteriously fails to build on i686 only on guix <jgart>has anyone attempted packaging tree-sitter packages? <podiki[m]>apteryx: oh, I thought it was a pixbuf svg test failure, but maybe I looked at the log wrong <apteryx>introduced with the update to kexec-tools <florhizome[m]>so. i think i will write that mail about the meson situation. If c-u-f will take much longer i need more transparency there <podiki[m]>florhizome: I'm on x86-64 and running on c-u-f is fine for my system, if you wanted to switch branches *mekeor[m] realizes that c-u-f means "core-updates-frozen" <nckx>florhizome[m]: Thanks for your earlier reply. I was indeed wholly that there were newer commits on c-u-f-b-c. <nckx>This whole situation is thoroughly confusing. <nckx>That's how confused I am. <apteryx>florhizome[m]: what kind of clarification would you like on meson? it's at 0.60 on cufbc, with 0.59 still there for the occasional package that doesn't like it <apteryx>it's also been patched with a nix-provided patch to allow installing to a bin output for example <apteryx>finally the check phase of the meson-build-system has been adjusted to accept a 'test-options' argument, and the 'test-target' is no more <apteryx>python-asynctest is abandoned with no python 3.9 support. Hmm. <florhizome[m]>meson-0.53.2 (default), meson-0.55, meson-0.57.2 but for building you get a patched meson 0.53.2 (meson-for-build). you can have a different one but then it's not patched. In c-u-f you get meson 0.59 but it's not patched. In b-c you get 0.60 or 0.59 but both are patched. <florhizome[m]>the Patches seem Not be the Same between master and b-c. At least different names. <florhizome[m]>So for example wlroots 0.14 requires meson > 0.55 (i think). But also newer glib packages (or something Else quite central in the gtk/gnome Stack). Of course you can build this from master but you will use a not patched meson knowing that there are lower and Higher Versions needing Patches. so If the build fails, it could always just been meson. <nckx>florhizome[m]: But… Sway/wlroots don't require the patched Meson IIUC? <florhizome[m]>aka I would like to say "meson is the reason why this fails" but actually i could never know without really digging into these things. <nckx>The patch doesn't make Meson Better, it just allows one specific directory layout used by some Guix packages, and not by these two. <nckx>florhizome[m]: Installing almost everything to /gnu/store/<hashA>-foo-1.2/ and a few things to /gnu/store/<hashB>-foo-1.2-bar/ <nckx>Where bar is an output, of which most packages have only one. <nckx>That is my understanding. <nckx>Meson resists this because it's bloody Meson, and this patch pays it a visit to convince it otherwise. <nckx>I'm missing way too much context to answer that. Including my own: I'm the one who pushed some of these things to c-u instead of master, and I know I wouldn't do that without a good reason (which might've been obvious, or very subtle) but don't ask me now what it was ☺ <anjan>hi all, I have a laptop that requires nonfree firmware <nckx>Hi anjan. I'm not aware of such an ISO, and recommending non-free software (including firmware loaded at run-time) is against the values that the Free software community holds, so whilst we don't break software to forbid its use, we don't provide support for it here either. <anjan>I have found my way to help. Thanks for being so helpful guys <mekeor[m]>i have an off-topic question. sorry. in unix and english, if "(symbolic) links" and "directories" are also "files", is there a synonym for "proper files" (i.e. files which are neither links nor directories)? <nckx>I'd say regular files but I'm can't swear on my life that it officially excludes symlinks. <florhizome[m]>hm lol installing binutils at least gives a different error. so let's propagate that maybe.