*rekado found a cleaner way to get the derivation file, but it’s not a one-liner. <terpri_>something's up with TLS certs + flatpak + guix (as in, they don't work except for browsers that bundle their own TLS stuff). probably related to the p11-kit-proxy used by flatpak? <jackhill>If it is p11-kit, it's not obvious to me what that has to do with the CA resgistry <terpri_>hrm...well, flatpak adds "module: p11-kit-client.so" to /etc/pkcs11/modules/p11-kit-trust.module in the container, that might be broken (p11-kit does build that library file) <terpri_>i'll try a substitute* after guix finishes upgrading ***bkv is now known as bqv
<lfam>I'm taking a look at libsndfile now <lfam>I'm curious, did you try diffing the built packages? Something like `diffoscope /gnu/store/...-libsndfile-1 /gnu/store/...-libsndfile-2`? <lfam>Also, did you try searching upstream bug reports about this? <lfam>Hm, I wonder if the libraries need to be propagated <lfam>That sounds suboptimal, but libraries named in the "Requires" field of a package's pkg-config file (sndfile.pc) must be propagated, as described in the manual section "package Reference" <sturm>lfam: I didn't but I can try diffing now <lfam>In this case, they are listed in Requires.private <lfam>I'm not sure what the difference is <lfam>I would try either propagating them, or making them available in the build environment of sbc <lfam>After we know either of those options work, we can learn about Requires.private <lfam>I suspect that error message "configure: error: sndfile library is required" is actually trying to say "error: sndfile's library dependencies are required" <lfam>It would really be great to not propagate these widely used libraries, especially since the built libsndfile keeps a reference to them. I checked with `guix gc --references $(./pre-inst-env guix build --no-grafts libsndfile)` <lfam>Well, grepping in gnu/packages for 'Requires.private' shows that we propagate libraries named in that field in several places <lfam>sturm: I think the diffoscope suggestion was a red herring <charles`>Hi everyone. I'm trying to add the CursorTheme configuration to sddm, and I got it so /etc/sddm.conf has "CursorTheme=Adwaita" in it after system reconfigure. However, the cursr actually used is still the default one. Any ideas? <sturm>lfam: ok, thanks - interesting tool I haven't used before though <lfam>Yeah, it's a great tool to be comfortable with :) <lfam>I especially like the ability to output HTML reports <sturm>lfam: I'm not sure I'm 100% following, but I did just try moving those dependencies to `propagated-inputs` and it seems to build ok now <sturm>but I think you're saying that would be best avoided? <lfam>sturm: Sorry to be subject you to my stream of consciousness <lfam>We prefer to avoid propagation, but in this case, with the pkg-config thing, I believe it's unavoidable <sturm>and what that means is that when you install "sbc", these C-libraries will show up in your $profile/libs, right? <lfam>It reduces the flexibility that Guix typically provides, where installed applications can each use different versions of libries in /gnu/store <lfam>Instead of the application calling the library as /gnu/store/...-library, it will be found in the profile <lfam>But like I said, there's probably no way to avoid it <sturm>lfam: right, I think I'm following <lfam>And in case it isn't clear, the lack of flexibility is because, for example, the "$profile/lib/libopus.so" path is not versioned. So there can only be one library there <lfam>So I guess that, all this time, our libsndfile package has not actually provided these libraries! I wonder what we were missing... <lfam>It's an example of why it's important to read the build logs, especially the configure phase, once in a while :) <sturm>lfam: thanks for the explanation - my knowledge of this C-library stuff is pretty dusty, so that's useful <sturm>lfam: good find, thanks! that Efraim person does a lot of work around here ;) <sturm>alright, so then I guess all I need to do is wait for core-updates then? <sturm>lfam: wonderful, thanks for all your help Efraim :) <lfam>I think we can hope for core-updates to be completed later in the spring. The core-updates branch has already sat for way too long, but I think a lot of us were less productive in the last 12 months, and it won't pay to rush integrating the low-level updates <sturm>absolutely, and I can continue the MediaGoblin work based on that branch anyway, so doesn't need to hold me up <lfam>If the core-updates branch is not quite usable, you could also cherry-pick this libsndfile change to your own dev branch <lfam>I wish we had a little more coordination / big group meetings to discuss the workflow for big updates. Maybe we could squeeze this commit in for the upcoming release (mid-April) <lfam>It's unlikely that we'd reach a consensus in favor of that, just because it's not clear why this one "heavy" commit should go in, but nothing else <lfam>Maybe the fact that it's fixing a bug, and not updating something <lfam>I would reply in favor it. I think that MediaGoblin should enjoy a small degree of special treatment :) <sturm>lfam: I could, but it would also be ok if it took a few months - I basically took the last 8 months of MediaGoblin so any delays are really down to me <lfam>Alright, then I leave it up to you :) <apteryx>avalenn: after the dependencies are captured OK, we need to be able to build go modules for protobuf otherwise we'll have to package tens of protobuf-something packages, including internal stuff not supposed to be standalone packages <apteryx>the GOPROXY URL can be a simple file:// URL pointing to a pkg/mod (module cache) directory, IIRC. So we need to build this cache, point GOPROXY to it, set GO111MODULE=yes, and then after perhaps we'll be able to build protobuf as a go submodule <apteryx>I'm thinking every package could install their sources under the pkg/go directory, and then at build time we could simply create a union of these and set GOPROXY to it <apteryx>hmm, the directory that can be used as a GOPROXY via file:// URLs is the pkg/go/cache/download ***stikonas_ is now known as stikonas
<ryuslash>apteryx: what is this related to? I don't have the full history here, it just seems relevant to what I'm trying to do (well, learn about really) <apteryx>this is my brainstorming about ideas or things required to enable our go-build-system to build go modules <apteryx>which seems like a must (requirement?) for packages such as google.golang.org/protobuf <apteryx>what nix does it not elegant; they fetch all the dependencies using 'go vendor', hash that, and use it as the build input <apteryx>I think in Guix it'd be nice if we could do it more like gentoo; expose the cached elements that go wants (via a file local GOPROXY) and have the individual go packages that are required for a build contribute their files to that cache <apteryx>this way we'd still be capturing the dependency graph of Go packages <ryuslash>it sounds like that's what the native-inputs are for essentially? <apteryx>if it's a library that depends on another library, it would have to use propagate-inputs, but yes, otherwise native-inputs seems fine for Go, as everything is built statically. <vagrantc>roptat: hah! yeah, armhf is like the slow foods movement. <vagrantc>hrm. kernel panic when building guile-3.0.5 on the veyron-speedy ... no armhf for me ***iyzsong-- is now known as iyzsong-w
<muradm>any reference to working cups configuration with hplip? when setting (extensions (list cups-filters hplip)) and adding printer hplip is not showing up in the list of manufacturers <raghavgururajan>sneek, later tell apteryx: Regarding #47274, it would be great if you could first review 0001 and 0038-0042 and merge to master, so then we have to deal only with linphone.scm module. ***apteryx_ is now known as apteryx
<muradm> rekado_: thanks I have the same, with hplip in extensions, but can't see hplip printers only hpcups when adding printer <avalenn>apteryx: I will look at the importer today. <avalenn>apteryx: I looked at google-golang-protobuf and the dependency to github.com/golang/protobuf is a fake one which is never used for compilation. <avalenn>It is just there so that codebase depending on both have compatible versions considering they share internal types. ***overclucker_ is now known as overclucker
<avalenn>more generally we will have to take care of conditionnal compiling (what they call build constraints) <avalenn>which is not reflected at all in go.mod or go.sum <civodul>these two commits show "when" rather than "why" tho, no? <PurpleSym>True, civodul, which is why I argued it would not be safe to graft. <civodul>but i think it's useless to graft since apparently there's only one package that retains a reference to it <civodul>initially i didn't want to get involved :-) <PurpleSym>civodul: I think the graft was introduced to avoid rebuilding >1000 packages, see `guix refresh -l -e '(@ (gnu packages imagemagick) imagemagick)'`. ***iyzsong-- is now known as iyzsong-w
<l00p>Hello, how can I install a pypi package through Guix? I'm able to get a package definition through guix import pypi <package>, but how do I go about installing it? <i1l>pkill9: hi man. did you used `unshare` in your namespace-things? if so, did you get it to run things like `apt <i1l>or `su`? Proot works well, but i wonder, etc.. <i1l>pkill9: i maybe mistaked, but i remember you mentioned namespaces. <i1l>pkill9: idk. myself just tested few GUI apps from Debian. <i1l>so i have unprivileged chroot, so GUI works in Wayland. <pkill9>i think you may mean someone else, im not sure what you're talking about <civodul>is anyone running the latest cuirass? <roptat>sneek, later tell vagrantc I have substitutes for 13953f0e7ec230e701faa679bcf2c1d6a3ab4693 on armhf if you're interested <apteryx>avalenn: interesting. I was under the impression that the 'build constraints' thing was failing because not building in module mode, but that's was just a guess. <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, raghavgururajan says: Regarding #47274, it would be great if you could first review 0001 and 0038-0042 and merge to master, so then we have to deal only with linphone.scm module. <sneek>Welcome back lle-bout, you have 3 messages! <sneek>lle-bout, lfam says: I have always ignore Xen entirely. It's not used by Guix, many of the "fixes" are in the kernel, and I think that, in general, high-security virtualization is not a feasible goal for a volunteer project <sneek>lle-bout, lfam says: About QEMU CVE-2021-3416, we can concatenate the 10 commits into a single patch file, from qemu.git, for example: `git format-patch --stdout 705df5466c98f3efdd2b68d3b31dad86858acad7^..37cee01784ff0df13e5209517e1b3594a5e792d1` <sneek>lle-bout, lfam says: In the past I personally did not rush to fix these QEMU denial of service bugs. They seem to discovered all time. Maybe once a month I'd fix them all at once. <lle-bout>lfam: I see, and yes of course concatenate *lle-bout everyone angry because mongodb and imagemagick feels bad <roptat>nice work making everyone angry! :D <roptat>(but really, nice work on CVE patching :)) <roptat>we do need more tooling to ensure you stop breaking everything all the time though :p <roptat>or maybe we should accidentally break guix lint -c cve <lle-bout>roptat: :-S - I don't think actual stuff broke but some engineering principles were broken for sure <lle-bout>roptat: I may start working on core-updates and there only <lle-bout>Maybe that's better, and we would get more incentive to merge core-updates back in (batches of security fixes) <apteryx>what command can I use to find out which process is listening to TCP port 8000? <lle-bout>And I wont break stuff, and I can start not relying on grafts (it's probably not a good mechanism for how I would like to do things after all) <apteryx>ah, the -p switch of the ss command seems to be for that <lle-bout>as root, or the user of the service that's running <roptat>lle-bout, right, it's ok for backporting fixes, but not really for whole package upgrade <lle-bout>roptat: I don't think we have resources for backporting fixes always, it's very time-consuming and the security patch load is big <lle-bout>I spend 10x more time on backporting/testing a patch than just upgrading version <apteryx>lle-bout: thanks; it didn't list anything with :8000 for some reason; but ss -ltp | grep 8000 showed: "LISTEN 0 4096 *:8000 *:* users:(("weechat",pid=886,fd=5))" (my weechat relay) <lle-bout>apteryx: reason for that may be that somehow 'lsof -Pni' doesnt show everything unless root <lle-bout>roptat: reason that it takes more time is because it's more error-prone and stress-inducing <roptat>but then if you fix only on core-updates, we might not receive security updates in a timely manner <lle-bout>roptat: yes but it appears people don't care <lle-bout>I would probably start basing my system off my own custom branch then <roptat>well, I do care, though I prefer if it's not broken ^^ <lle-bout>roptat: It may be broken but I think for 95% of commits I created it broke nothing <roptat>right, we only see the ones that are broken <lle-bout>roptat: I also think it's a great thing we start merging core-updates or at least staging more often <lle-bout>Maybe we should have a security-updates branch <roptat>that's exactly what I was thinking about <lle-bout>That would be awesome if you think that's a good idea <roptat>as long as we have the CI power for it <lle-bout>roptat: I can pay for more machines also <roptat>maybe a bit of grafting could work too if that means merging more often <lle-bout>I have one AMD Epyc 7nm 48 threads I use <lle-bout>But I can also donate access to a rented one to GNU Guix <roptat>I don't know if the limitation is the number of machines or bottleneck on cuirass, but you can always send an email if you're willing to donate hardware :) <lle-bout>Right now we have a case where mariadb server software has a CVE but the package provides both the lib and the server software so we need to graft where we shouldnt need to <roptat>right, for this kind of change, I think a security branch could work, because we don't expect the lib to change at all, so nothing would break except substitute availibility <lle-bout>roptat: the problem is for when people don't use substitutes <roptat>you can also create a feature-branch, like wip-mariadb-cve-fix, and ask ci admins to evaluate it when you're done <roptat>then you can merge the branch back to master <lle-bout>roptat: Probably if I have access to add the branch myself it'd be even better because I feel the people with access are also pretty busy <zimoun>lle-bout: people do care about security. And there is a difference between ~15 days (average time for reviewing grafts) and ~3-6months (average between core-updates or whatever massive rebuild branch merges) <rndd>hi everyone! i'm trying to pack go application. how to force guix to build binary from go code and put it in /bin/ ? <lle-bout>for regular patches OK, but security related, I think it's too long <zimoun>maybe, but it is your opinion. And that does not mean people do not care. <rndd>lle-bout: thanks, no examples in (gnu packages golang) <lle-bout>zimoun: well you were suggesting we delay this mariadb change in core-updates <rndd>i found some go packages that builds binary utility, but don't see any difference from other packages <lle-bout>rndd: ah maybe I didnt get your question <roptat>lle-bout, I think you can create the branch yourself, but not start the evaluation <lle-bout>roptat: yes, I would need an admin access on ci.guix.gnu.org somehow, to add manifests from the web ui <roptat>there are only a handful of people with that kind of power, I'm not even one of them <lle-bout>roptat: yes also it's a recent feature I think <roptat>I don't think it's too much work, so you could try bother someone about that when you have the feature branch <lle-bout>only mathieu has access or ludo maybe I think <lle-bout>mathieu is almost never here on IRC for example they must be busy or don't like IRC <roptat>yeah, ludo has access, I think there are one or two more people <roptat>just send them an email and they'll eventually do it <roptat>a day or two is better that two weeks, which is better than 6 months :p <lle-bout>roptat: I think to do this every day 'eventually doing it' is not convenient enough for it to be doable <lle-bout>1-2 days is hopeful I think seeing the amount of mail some get <lle-bout>I wouldnt want to waste their time meaningfully when we could just share access rights somehow and be independent <lle-bout>and decide at review-time, instead of having to ask several times <roptat>or simply have a single branch, then it's only one specification <lle-bout>'branch and substitutes are ready see link: xxxx' 'merge yes no?' <lle-bout>roptat: also that, security-updates .. I really like that idea! <lle-bout>But some people don't use substitutes so how do we handle that? <roptat>we don't handle that even for core-updates, so I don't think it really is an issue <roptat>if they don't use substitutes, they know they'll be rebuilding a lot anyway <roptat>it's not like we can do anything about that <lle-bout>roptat: OK, this is something that interests me a lot, how much we care about users who don't use substitutes <lle-bout>I think we should care as in GNU Guix should work without substitutes but that it would be viable to use GNU Guix on a low-power laptop I don't think we should care about that <roptat>well, it works on a low-power armhf server without substitutes ^^ <jlicht>so then they get fresh and secure package updates at the same time as other folks <roptat>it just takes three days to run guix pull and reconfigure <lle-bout>I put myself behind a vision where several entities or organizations run substitute servers and independently rebuild all packages but I don't get behind many individuals rebuild everything on their laptop and expect to not world rebuild every so often <roptat>(so after a reconfigure I'm already behind in terms of security fixes ^^') <lle-bout>I think the former is much more practical <lle-bout>Also there is the question of limited bandwidth <roptat>I think the core-updates and staging thing is mostly to prevent world-rebuild for users that *use* substitutes <lle-bout>World rebuild somehow implies heavy bandwidth usage on updates, maybe we can do some delta updates etc. to solve that a little <lle-bout>roptat: what kind of armhf-server do you have? does it run off a microsd or some more reliable disk? <lle-bout>I have a Freebox Delta S at home and it actually can run VMs inside but I couldnt get offloading to work <zimoun>lle-bout: it is case per case. My opinion about mariadb is maybe not the good one. That’s why we are discussing. ;-) Sometimes The Right Thing is fix in core-updates, sometime grafts with a minor version update, and sometime graft by backporting a patch. That’s why having security and stability is hard. :-) <roptat>which is crazy because the CPU doesn't follow the disk speed ^^' <lle-bout>zimoun: Alright well for MariaDB I think that minor update 10.5.9 is actually very small (it's almost as if it only contained the security fix) <roptat>even running the guix command takes 10 seconds of startup before it prints anything... <lle-bout>roptat: GNU Guile JIT on more platforms when <zimoun>lle-bout: maybe, and I trust you if you say so. <lle-bout>roptat: how does it run off an SSD? USB? <lle-bout>I would like to run a GNU Guix offload server inside my Freebox Delta S (kind of funny to even do that lol) but it doesnt work and also doesnt have enough RAM <roptat>I had it for a number of years now <muradm>how does one correctly define sysctl configuration for operating-system? I had (servive sysctl-service-type ... ) with a bunch of entries, but since last pull configuration same configuration fails with "sysctl" already exists or something like.. <rekado_>the fact that core-updates exists shows that we do care about people who build things from source. <roptat>muradm, you'd override the sysctl-service-type that now exists in %base-services or %desktop-services with modify-services <lle-bout>muradm: oh yes well some default one was added, you will need to use (modify-services ..) to alter the existing one in %base-services (also included in %desktop-services) <lle-bout>rekado_: I was thinking it could also be for the load of our own build farms <zimoun>lle-bout: What I suggested is to check the ungraft of zstd@1.4.9 with the upgrade/fix of mariadb; as a whole. Because the current mariadb@10.5.8 is an issue with ungrafted zstd@1.4.9. <lle-bout>zimoun: I see, do you have a log? I didnt notice that <roptat>oh the online manual is stuck at a version from a few days ago <muradm>lle-bout: thanks, that was expected, could you point to defaults that was added? <lle-bout>roptat: also yes if security updates with world rebuilds mean people have to download several GB to actually do the security update with substitutes it's also not fine, so we should find a way to do some kind of delta updates of substitutes or something, don't know <roptat>markasoftware, (gnu services sysctl) for %default-sysctl-settings *roptat really needs to focus on his presentation for tomorrow <roptat>well it's my fault, shouldn't have connected to IRC <rekado_>lle-bout: the build farm is pretty big and could churn through lots of builds (thanks to Mathieu’s fixes), at least for x86(_64) <lle-bout>rekado_: I am very happy about that! core-updates predated Mathieu's fixes also, so probably a bit of both (the reason) *lle-bout is eye-ing at switching to MATE for Wayland desktop environment that can easily be maintained in GNU Guix <muradm> lle-bout: I see in gnu/services/base.scm that %base-services has (service sysctl-service-type), does it mean that it does not set any sysctl values? <lle-bout>muradm: it does, it just has some default ones, look at the actual definition of it <zimoun>lle-bout: not at hand, I have checked out wip-next-release, applied my patch fixing the zstd test, then rebuild all ’guix refresh -l zstd’ says and I noticed that a lot of these packages depends on mariadb and the build of mariadb fails. Then I have not investigated more. Well, that for a preparation of the Ungraftathon. :-) <muradm>lle-bout: yes I see now.. checking thanks <lle-bout>zimoun: okay! I'll try to have a look soon now trying to convert my setup to MATE <lle-bout>CVE-2021-28957 - for python-lxml and friends if anyone wants to look at it <SanchayanMaity>Hello. Do I understand correctly if I am building a package xyz.scm which downloads xyz.tar.gz while specifying the sha256 in package definition, I need to give the output of "guix hash -H sha256 xyz.tar.gz". <lle-bout>SanchayanMaity: to get the hash, run: guix download <url> <lle-bout>However, it would be nice if 'guix download' also printed hashes in other formats than nix-base32 so that we could check against upstream's published also <lle-bout>But you can also recompute them manually by hashing the store item <muradm> lle-bout: (sysctl-service-type config => (sysctl-configuration (inherit config) (settings ...))) how to get settings from config and append more to put into instead of "..."? (append my-settings (sysctl-configuration-settings config)) will work? <muradm>or i have to use %default-sysctl-settings? <lle-bout>I think you could also do the former but not sure <muradm>lle-bout: I see... so there is no function "to get" existing settings from config? <lle-bout>muradm: there must be a way even without a function, but I don't know it <muradm>other things some helpers like (package-native-inputs PKG), this seems not having it.. pity <roptat>muradm, (sysctl-configuration config) <roptat>er (sysctl-configuration-settings config) <muradm>roptat: yes exactly, tried the same and working :) thanks, roptat, lle-bout <muradm>roptat: no, that does not work, sysctl-configuration-settings unbound symbol :) <roptat>you'll have to use %default-sysctl-settings <muradm>roptat: yeap.. srfi-9 defines them, but not exported.. may be good for first patch? :) <roptat>though technically we use (guix records) instead of srfi-9 <lle-bout>when grafting/recompiling mate and mate-panel <muradm>I have another issue with swap file. I use full disk encryption with btrfs, and my swap file on btrfs volume. having: (swap-devices '("/.swap/swapfile0")) in configuration. then shepherd "swap-/.swap/swapfile0" service fails to mount it at boot time. after boot enable+start makes swap working <lle-bout>muradm: as a suggestion, you could alternatively run zram swap if that's interesting to you (compressed swap) <muradm>as far as i understand that swap activating service just does not wait for mount, maybe only waits for device-mapper <muradm>lle-bout: that says "device service provides a compressed swap device in system memory".. I think I don't have enough ram to have swap in ram even compressed :) <muradm>also I suppose it should be terrible in performance as well since it is compressed.. idk <muradm>I'd rather add something like (swap-device '(my-fs "/.swap/swapfile0")) <lle-bout>civodul: sounds good! like it! Feels great to report work so we get a feeling of progress :-) - Thanks for all the work there! <muradm>so that swap activation service wait for proper fs to be mounted first, or something like that <lle-bout>when disk backed, the compression/decompression is faster than disk I/O so it's actually free most of the time <lle-bout>You definitely don't want to be swapping bunch of repeated bytes <lle-bout>I have 16G of it here, it's great for many ungoogled-chromium tabs :-P <efraim>IIRC zram aims for 2:1 compression on swap <zimoun>civodul: all in all, 1.2.1 looks like more than a 1.3 than a minor. :-) Otherwise, blog LGTM. <muradm>lle-bout: i see.. disk backend seems to be not an option any way, I dont have free partition and/or can't free one for swap. but idea looks good, will definetly try it when there is some free time. still I'm concerned about performance :) will have to test. but this does not solve the problem with swap-devices file :) <civodul>i realized we had progress to report about <civodul>we hadn't done so in a while a probably there wasn't a clear story even to insiders <muradm>civodul: I have read that article, great things there. I'm just curious if it will solve duplicate items in store. for example I have this right now: <muradm>ls -la /gnu/store | grep "mariadb-10.5.8/" <muradm>dr-xr-xr-x 1 root root 16 Jan 1 1970 6kn6xcp3snxkgmc3697r17247017wxyx-mariadb-10.5.8/ <muradm>dr-xr-xr-x 1 root root 16 Jan 1 1970 8yl2s0zshb16gxx88zig7839kfk16i08-mariadb-10.5.8/ <muradm>dr-xr-xr-x 1 root root 16 Jan 1 1970 fmjj731sn7hq599vjwajx0755p2b8ak6-mariadb-10.5.8/ <civodul>muradm: it won't solve more than it claims to :-) <civodul>but as you know, guix-daemon implements file-level deduplication <muradm>i don't understand why same package exists multiple times, I suspect that it is also downloaded multiple times :) <civodul>so even if you have 10 mariadb variants, that's okay <civodul>it's probably downloaded 10 times though, indeed <civodul>the last section hints at this problem <muradm>civodul: yeah content hash, i see, thanks :) <roptat>although I noticed it doesn't do deduplication until the store item is complete <roptat>like, I was grafting a big package and I noticed disk space going lower and lower, and as soon as it finished, it went back up, probably because of deduplication <roptat>it's a bit wasteful, but not sure we can do anything about that <leoprikler>lle-bout: w.r.t. python grafts, I suppose that grafting is actually effective in python, since everything gets expanded at runtime from various PYTHONPATHs (both the original and the ones Guix patched into it) ***jx97 is now known as jx96
<jlicht>the zfs person seems frustrated :/ <lle-bout>jlicht: :-/ - I understand their frustration <jlicht>yeah, me too, if that wasn't clear. Just don't know what to do about it <lle-bout>jlicht: I don't feel competent enough to review their patches <lle-bout>jlicht: I saw npm stuff, thanks for submitting!! <genr8_>I would like to report a build error, or question if I am doing something wrong <genr8_>this is a fresh install, the only commands I've run are "guix pull", (ive nuked the installation once already because I thought i made a mistake) <genr8_>i've disallowed using substitutions <genr8_>i believe the issue is At line 1496 you can see a backtrace: [execle "./conftest" # "./conftest"] ERROR: In procedure execle: No such file or directory <genr8_>whats weird is when I re-run "guix pull" a 2nd time, It skips over "bash" and moves onto "bzip" and also fails on that package, in a different way <jackhill>raghavgururajan: I'm having problems with psi and psi-plus where they don't seem to be able to verify the certificates of the servers I connect to. I've tried them both in my default profile, with nss-certs in the system profile, and in an environment with both psi and nss-certs. Are you seeing that? <genr8_>jackhill, I noticed an issue with Abiword also <jackhill>genr8_: oh, interesting, I don't think I've used Abiword since I started using Guix :) I didn't even realize it made network connections. I brought up the psi here because I know raghavgururajan recently added that. Woule you mind sending mail to bug-guix@gnu.org to open a ticket about the Abiword problem? <rekado_>civodul: “store file names contains a hash” —> “contain” <genr8_>jackhill, yes i mind, im a noob. all i did was run "guix refresh" and abiword was the 2nd package and it errored out on the X509 verify, and i seem to have lost the exact wording <jackhill>genr8_: for the pull problem, no you're not doing anything wrong, please keep trying. There were some bugs that make scary looking failures more likely. Once you are able to pull and run guix system reconfigure to get the updates to guix-daemon the behavior should be better :) <jackhill>genr8_: oh! That's slightly different than my problem as it seems in your case it's guix that's not able to verify the certs rather than the installed abiword program. There may be something that can be fixed to make it work for you. Are you using Guix System or guix with another distribution? <jackhill>genr8_: re: pull, hmmm, I think that's beyond my knowldege then. Hopefully someone else can help. <genr8_>It seems to be going incredibly well, right up until it errors out.......... and then nothing I do will get past it <jackhill>genr8_: oh, I'm sorry, I didn't read you past correctly the first time … yeah the problem you ran into is a different one than what I was thinking of. Is it your intention to build everyting locally rather than getting binary substitutes (pre-built packages) from ci.guix.gnu.org? It's still a bug that it doesn't build for you, but with substitutes you may be able to avoid encountering the bug :) <muradm>as far as I understand shepherd patches are also service by guix-patches@gnu.org? <genr8_>yes build everything from source <genr8_>thats the whole reason im using this <jackhill>genr8_: awesome, it's great that guix supports that. I think what you've encountered is a bug, but I don't have much experience with the bootstrap, so can't advise beyond that unfortunately ***jx97 is now known as jx96
<genr8_>I dont think it helps that I can't install "guix install nss-certs" due the previous "pull" bug, so i just used the OS version...... so either thats not the same thing, or it doesnt contain the right certs, or something else is wrong <genr8_>I think its actually an upstream server side error <jackhill>genr8_: ah! I've been able to reproduct the abiword thing here too, for what it's worth. So sorry that I haven't been much help. <genr8_>Looks like curl had the right variables, because Its picking up: "CAfile: /etc/ssl/certs/ca-certificates.crt" <--- from what Ive just set in the ENV vars. without that var, it says "CAfile: none" , but the failure is still the exact same. <jackhill>I agree that is looks like a problem on the server <jackhill>for my xmpp-client thing, other clients work with the same servers, so I don't think that's a problem there :) <genr8_>they're using a recent LetsEncrypt cert, for some reason the CA is missing. however my firefox browser verifies it <genr8_>yeah sorry, two different things, sorry to jump on your issue <genr8_>my cert issue was a temporary distraction. I need to fix the initial "guix pull" bug building "bash" from source, with no substitutes, on a fresh guix install on a fresh Devuan distro https://dpaste.com/E4NV9NEEU but i know no way to proceed on my own <genr8_>it seems like a serious bug if true <genr8_>I dont know how to cheat and fix the bug myself either, or i would. <genr8_>maybe you can help with something <muradm>is there any difference between (define-module (some-module) #:use-module (gnu services ssh)) and (define-module (some-module)) (use-service-modules ssh) ? <genr8_>i've just synced from the git with "guix pull" (that part worked), yet running "guix refresh" prints a LOT of stuff like "gnu/packages/xorg.scm:3207:13: xf86-video-nouveau would be upgraded from 1.0.16 to 1.0.17" where it seems to be communicating over the network and finding newer versions <civodul>jlicht: re zfs, perhaps you can review the patches? :-) <civodul>i'm sorry i dropped the ball, but i feel like i'm doing more than my share of patch review <civodul>we're 40+ committers, surely someone can pick it up :-) <lfam>I noticed that the "devel" version of the manual isn't being updated <lfam>Is there anything I can do to help with that <civodul>rekado_: thanks for spotting the typo! <civodul>lfam: perhaps you can check whether "guix build -f doc/build.scm" works locally <pkill9>which is better for use on a desktop system, ZFS or Btrfs? <genr8_>i like ZFS but I dont use it on a desktop. it wants a lot of RAM and it doesnt exactly agree nicely with the Linux kernel as well as it does with FreeBSD <rekado_>genr8_: why do you use “guix refresh”? <genr8_>i needed another command to run, was trying to get "guix pull" to work <genr8_>refresh sounded like it was worthwhile <rekado_>I don’t understand. You wrote “"guix pull" (that part worked)”. <zimoun>Damned! The Project.toml from Julia seems doomed to have all the dependents. So, I am afraid if a “guix import julia” seems possible… <genr8_>the SYNC part of the pull worked <rekado_>genr8_: and then the build of bzip2 fails? <genr8_>bash failed first. then i ran pull again, but the error now shows up in bzip2. <genr8_>now i cant get past it, forwards, or backwards <genr8_>i tried as a non-root user. same error. its unclear what the error even exactly is <genr8_>do you have any ideas that WILL make a difference? ive been at this for hours <rekado_>the daemon builds on behalf of users; no matter if you ask for the build as root or any other user. <genr8_>yeah, makes sense. just trying things. <rekado_>I did this: guix build --check --no-grafts /gnu/store/3lv7bg1vxkpi3igx5zhr80glr4zwywa4-bzip2-mesboot-1.0.8.drv <genr8_>maybe you already had pre-requisites <rekado_>that is the exact same derivation that fails for you <rekado_>you also have the prereqs for this very derivation <rekado_>your logs say that the build of /gnu/store/3lv7bg1vxkpi3igx5zhr80glr4zwywa4-bzip2-mesboot-1.0.8.drv failed <genr8_>rekado_, thats the 2nd error. scroll up. <lfam>Indeed, the bzip2-mesboot-1.0.8 derivation builds successfully <terpri_>pkill9, btrfs for desktop use imho (it's also not clear whether zfs-on-linux is permitted by their respective licenses, though canonical thinks it is) <rekado_>genr8_: can you link to the exact line please? <rekado_>(this looks like interleaved output) <lfam>Yeah. It's not clear what is going on <rekado_>running guix build --check --no-grafts /gnu/store/b759axs76z0wdswksdy5sdmszmrqi6hh-bash-mesboot0-2.05b.drv now <rekado_>about prerequisites: you will *always* have them for any derivation that is attempted to be built. <rekado_>Guix will never attempt to build a derivation whose inputs don’t exist. <genr8_>I originally ran the build-daemon with multiple build processes, and when I got this error, first in bash, then in bzip2, i thought "oh maybe this is some kind of interleaved race condition conflict or something" so I completely deleted that installation and started again, this time with 1 builder. SAME exact error. <genr8_>rekado_, i get thats the theory, but something is invalid here <rekado_>with more than one concurrent build it will just build more independent things at the same time. <lfam>It's hardly a theory. It's not possible to start a build without its prerequisites <lfam>We agree with you that something is not working, but let's not jump to conclusions <rekado_>so what does “make: stat:Makefile: sterror: unknown error” mean…? <civodul>lfam: re the manual, "Unbound variable: %strict-tokenizer?", that's due to 25db3b2f8bb4a18e9405d2cd32aa899e0007f236 <rekado_>is there anything … unusual you could tell us about your file system perhaps? <lfam>Ah, I was still building it civodul <rekado_>successfully built /gnu/store/b759axs76z0wdswksdy5sdmszmrqi6hh-bash-mesboot0-2.05b.drv <lfam>Can you say what kind of computer you are using? <civodul>lfam: we'll have to reconfigure berlin so it has a newer guix with the new guile-lib package <rekado_>line 1741 has the same error: “make: stat:Makefile: sterror: unknown error” <lispmacs[work]>hi, I was wondering if somebody knew how to set the default slim window manager. when I go to login, openbox is always selected, and I have to switch it to lxqt using the F1 key. <lfam>Is this something we can ping mothacehe about, civodul? <lfam>rekado_, genr8_: That bash-mesboot0 derivation also builds successfully for me on tmpfs <rekado_>I mean: a corrupted store item, perhaps, that renders make unusable <genr8_>well that would be highly unusual <civodul>lfam: not necessarily; several of us are root there so we can do it "eventually" <genr8_>rekado_, can we focus on Line 1496 of the file? The backtrace seems to indicate "checking whether #! works in shell script" <-- is what failed <genr8_>[execle "./conftest" # "./conftest"] ERROR: In procedure execle: No such file or directory <rekado_>that’s what configure does: run test programs and see if they fail <genr8_>yes but it actually ERRORED the "gash" system <roptat>civodul, looking good, I'll try and build all that later, I'm a bit busy now :) <rekado_>genr8_: the early bootstrap (that’s what you’re compiling here) doesn’t have many more than the most basic features needed to get to the next step, so this kind of ugly behavior is completely acceptable. <genr8_>its literally the error that caused the chain reaction failure <rekado_>just to be sure: sha1sum /gnu/store/mza3q27yrm2zldksmhq1nj9s4m5zql0j-make-mesboot0-3.80/bin/make returns 0c3c396d8aff51489735227a748c99cfe2ff857a here. <terpri_>btw, i investigated flatpak TLS errors further and indeed, the problem is with p11-kit; it specifies a proxy module (.so) in the sandbox's /etc that doesn't exist inside the sandbox <rekado_>genr8_: you don’t have to believe me, but this is not the problem here. <lfam>Can you clarify what you mean, muradm? <terpri_>adding --ro-bind /gnu /gnu as a bwrap argument, and using the full path to the proxy library in /etc, fixes the problem but seems like overkill <genr8_>rekado_, then we will never make progress. its clearly the error. it has nothing to do with a configure test. "Backtrace" means the .scm script errored. gash/shell.scm:235:17 - [sh:exec-let () "./conftest"] <muradm>few weeks back I managed to build grub HEAD. I whish to submit it "grub-next" and "grub-efi-next" as patches. currently it is (name "grub-next") (version "git.635ef55e"), is it fine to version like this? is there any preference for "next" versions? <lfam>muradm: I ask the same question, can you clarify what your intentions are with grub-next? *rekado_ steps away for a few hours <lfam>In general, we don't include unreleased software muradmn <rekado_>genr8_: I hope someone here can help you figure out what’s wrong <rekado_>I just have a few more things I need to get done today <lfam>muradm: Sometimes, we do include it, if there is a compelling reason. But it's important that it solves problems and doesn't add others. GRUB is special on Guix System because it's the only part of the system that cannot be rolled back. So, we have to be very careful with how we use it and what we make available to users <lispmacs[work]>I think that I must need to set slim auto-login-session, but it is not quite obvious to me exactly what I should set it to to make lxqt the default <muradm>lfam: you provided link to documentation for sysctl-configuration, and asked if I managed to solve it, my answer was yes, of course, and even I submitted a patch to expose two functions for easier access to sysctl-configuration instance fields. and provided a link for your information :) <lfam>Well, I'm very familiar with the sysctl service, but it's not clear to me why these fields should be exported <lfam>It's already possible to append to the default sysctl parameters, or to erase them <lfam>But, maybe I am missing some use case that would benefit from the change you suggest, so I'm asking about that <terpri_>if flatpak has a "base runtime" (minimal FHS tree) it might be easiest to build another copy of p11-kit and stash it there, as of course the guix package uses absolute rpaths, etc. in its libraries <muradm>snippet from my layered configurations <muradm>with accessors I may add sysctl fields as necessary at any level, i.e. I would mofify configuration, without them, I have to overwrite settings field, and track manually who and where added more configuration entries <lfam>It won't be changed from %default-sysctl-settings <lfam>Any future changes will go into %default-sysctl-settings <muradm>in the first case, I'm forced to use %default-sysctl-settings, thus if on previous layer I added something, I have to go there and either expose something like %previous-sysctl-settings and use it on the next layer <lfam>As for the rest, your workflow is "over my head" <lfam>I don't really understand it <muradm> basically I have (base-workstation-system) and (base-lenovo-system) which inherits base-workstation-system and base-office-system which inherits base-lenovo system <lfam>I wish that the addition of these new parameters did not affect your workflow, but they do <lfam>I had wanted to create a new service that only set up defaults, but instead we made this change <lfam>If you want your patch to be used, I recommend you explain all of this in a reply to your patch submission <lfam>Otherwise, you'll have to answer these questiong again :) <lfam>I was worried about people having trouble with the change, but this way was considered more correct <lfam>And since I'm quite a weak Schemer, I can't really say :) <lfam>The thing that was important to me, when making this change, is that people are not induced to turn off the defaults. They are very important <muradm>lfam: coming to grub, my laptop was luks2 encrypted. I decided to move it to guix as my main system. then I faced an issue that grub 2.04 does not support boot from luks2 encrypted boot, but HEAD version of grub long time includes those patches. when next version will come up i have no idea, I don't know if one has :) so I managed to build grub from HEAD as package and use it. Some one here few weeks back suggested to submit it as <muradm>package. The problem with HEAD build is that it requires more steps than build from released source. <lfam>In this case, we aren't going to support unreleased GRUB, so you'll have to maintain grub-next independently until they release their support for luks2 <muradm>the grub-next package will not affect anything, it will just sit next to the grub-2.04 that is it. if some body will like to use, he can override default in bootloader configuration, or use it for development purposes <lfam>We just can't offer it to users, considering that it can't be rolled back if something goes wron <muradm>lfam: if you don't want to turn off defaults, then these two sysctl entries should be somewhere else i think, as they are quite critical as far as I understand. Because now, if I want to add my own entries I can just modify-service and intentionaly or unintentionally not include your %default-sysctl-settings. <lfam>I know muradm. I made the same argument <muradm>lfam: what does it mean it cannot be rolled back? <lfam>Everything else about Guix can be rolled back, including the entire system. This is achieved with GRUB. When booting, you can select "previous generations" of the system from the GRUB menu <lfam>But if GRUB breaks, then it is really broken <lfam>So, we are very careful about changing GRUB in Guix <lfam>Regarding the default sysctl parameters, we can re-open the conversation. But I would prefer to wait a couple days to do that, since those of us involved are still recovering from the stress of the bug that spurred their inclusion <muradm> lfam: why not add these two hardlink related sysctl settings into sysctl-configuration-settings->sysctl.conf ? then they will be present no matter what <muradm>lfam: if grub does not work, system does not work :))) this what happened to me :) <lfam>That way, you'll understand the arguments on both sides, and be able to more effectively participate in the discussion <lfam>Well, yeah muradm, but it's not our fault that you used a feature that GRUB does not support <muradm>lfam: my proposal is just add extra packages, no configuration changes <lfam>Do you understand my objections? <lfam>It's okay if you don't, I want to make them clear. And we were having to discussions at the same time :) <muradm>lfam: noted 47013, will read it at home <lfam>By the way, I'm the Leo in 47013 :) <muradm>lfam: for grub, if my naming and versioning are ok, I will submit the patch with explanation why and how it can be used, let it be decided in the mailing list then ) <lfam>Okay, I'm just letting you know that I'll object there, too. <lfam>I understand your use case but if GRUB upstream has not released luks2 support yet, then Guix isn't going to choose to include it <muradm>no, issue :) in my opinion, there should not be harm to have just another package :) <lfam>Alright, we can discuss it there :) <pkill9>does btrfs have any problems when it runs out of space? <lfam>muradmn: Guix makes it much easier than other distros to have custom packages :) <muradm>as soon as it does not change any default configuration, there should not be issue in having it, on the other who can build it using it anyway, the issue is that it is not very trivial to build it from head <muradm>of course, it makes easier, if you know how to build it :) <lfam>So, we don't like to package unreleased software, because upstreams don't intend for it to be redistributed in that state. They will not have done the usual quality assurance tasks, and so there may be more bugs than usual. <muradm>i wasted like 2-3 days to build and test it, why every body should waste time also :) <lfam>And then, users love new things, and will choose to use it <lfam>You can put your custom package on a public repo somewhere :) <lfam>You can even share your package on guix-devel <lfam>These objections are something I think about after a few years supporting Guix users and working with upstreams <muradm>any way, it is very late here, i'm leaving, i will read that 47013, and according to that i will either explain my patch as you suggested, pull it back or if I have better idea will share it. <lfam>I would like to improve the sysctl thing muradm. Basically, along the lines of my penultimate patch <lfam>I agree, we should make it unlikely that anyone remove the defaults by accident <lfam>It seems like a spurious failure, judging by the log <lfam>It successfully builds the source tarball and then the job fails <lfam>Well, the wip-next-release branch looks done <lfam>No pending jobs, all the failures are "expected", IMO <terpri_>pkill9, yes, btrfs is quite annoying when it's very low on space. it reserves some space for recovery operations, but probably isn't the best fs if you're literally filling up the drive constantly <raghavgururajan>lfam: Hi! I am gonna start the process of applying for commit access today. I was wondering if you could be one of my vouch? :-) <genr8_>I've made theoretical progress. /gnu/store/6rn4l3h0p9x0m615pp1ynlv9v0743kl3-guix-1.2.0/share/guile/site/3.0/gnu/packages/commencement.scm <--- thats the file that is calling the "bash-mesboot" and "bzip-mesboot" derivations for the bootstrap <lfam>raghavgururajan: I haven't been paying attention in the last month, so I will review the last month or so of your contributions and decide. Does that sound good? If you haven't been as active in the last month, I can go back some more <lfam>genr8_: Can you say what kind of computer you are using? <genr8_>fresh Devuan install in a virtualbox VM. <raingloom>(pls tag me, i don't have IRC visible all the time) <raingloom>(or mention or whatever it's called in IRC lingo) <raingloom>the operating-system description is basically the same as gnu/system/examples/yggdrasil.tmpl <lfam>genr8_: I'm asking about the computer hardware itself <genr8_>lfam, the host is a Ryzen 2600x, everything is amd64, the VM kernel counts as a KVM Paravirtualized instance using AMD-V extensions. <raghavgururajan>lfam: I have been active for a year and a half. Recent contributions started from Jan 2021. :) <lfam>I know you've been active for a while raghavgururajan, but your oldest contributions wouldn't qualify you for commit access. I will be looking at your growth :) <raghavgururajan>lfam: Ah gotcha! Wasn't sure of the process. In that case, yeah, Jan 2021 to now, should be good. :) <genr8_>lfam, it appears to be building an 'i686' host type. <lle-bout>turns out MATE on Wayland isnt really a thing for now, there's no Wayland compositor in MATE, you actually have to user another like Mir, Wayfire or on top of Sway <lfam>genr8_: Is that expected? That's 32-bit Intel compatible <lfam>Maybe the bootstrap is all i686, IDK <genr8_>no. it should be System: x86_64-linux <efraim> #$molly-brown-command looks like it should be molly-brown-command <lle-bout>It works on top of Sway (tested), but well.. several extensions arent ported over yet so.. <leoprikler>raingloom: where exactly does this unquoting occur? what error do you get? <lfam>genr8_: You could do `lscpu` in the VM to check the virtualized host architecture <genr8_>Architecture: x86_64 <-- it comes up right <lle-bout>I figured I want to spend time updating GNOME instead, I wonder why we don't go to GNOME 40 directly though <lfam>genr8_: I'm not sure, but I'd guess the bootstrap is i686 <genr8_>that sounds like a good guess to me. im just trying to grasp at straws here. <leoprikler>Jumping to GNOME 40 sounds like an interesting ride, but like GNOME 36 or GNOME 38, we would need to package all of it in a timely manner :) <raingloom>leoprikler: first, i have an entry like this: (service molly-brown-service-type (molly-brown-configuration (config '(("Port" . 1965) ("Hostname" . "whatever")... <lfam>genr8_: I'm sympathetic. It sucks when you have a problem that others can't even reproduce <genr8_>lfam, maybe you can help me skip it. do you know how to add 1 substitution only for the faulty /gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05 <lle-bout>leoprikler: I was thinking using the refresh/updater and testing everything as you go.. don't know <lfam>Yes, you can do `guix build /gnu/store/m89p469fxwn4hj7an9givd1ry9vk7j2l-bash-mesboot0-2.05`. If you have enabled substitutes, it will fetch a substitute if it is available <dongcarl>Hi all, what is the current thinking on a v1.2.1 release? I apologize I haven't been following the ML as closely as I would like to :-) <lfam>dongcarl: It is still on track for April 18 <leoprikler>Having a powerful machine certainly helps; mine's too weak for rigorous GNOME testing. <genr8_>lfam, Im afraid it will then try to get EVERY substitute, because its got a ton of stuff already queued up <lle-bout>lfam: I don't participate a lot on the release but do we actually merge PowerPC 64-bits? <lfam>dongcarl: It will consist, basically, of the master branch, but with an update of tzdata <lfam>lle-bout: Not sure! That's a question for the people working on PPC <lfam>I thought there was a patch series that could be applied to master, lle-bout <lle-bout>lfam: well I'd like to, and Chris too, we think it is ready <lle-bout>Yes there is, and that one's ready, do we apply it now? <leoprikler>but apart from updating the hashes, you need to make sure all our careful patches and snippets still apply and that upstream did not introduce any other features, that don't play nice with Guix <lfam>genr8_: You already have all the dependencies for that derivation, since you are attempting to build it <leoprikler>and with "features, that don't play nice" I mostly mean statefulness <raingloom>leoprikler, efraim: and the error is this: source expression failed to match any pattern in form ("Port" . 1965) <dongcarl>lfam: BTW, is there a ML thread where the April 18th date comes from? Thanks in advance for help <genr8_>right but theres an altogether larger "pull" procedure thats stuck, its got a ton of packages waiting to be built, and i cant seem to cancel it out <lle-bout>leoprikler: Okay, do you have examples of that? <lle-bout>raghavgururajan: hey! what's up with GNOME? My IPv6 address for substitutes must've changed now <lfam>genr8_: The command I told you to run will only build that derivation. It's not the same as `guix pull` <leoprikler>Not directly for stuff that'd break with GNOME 40, but gnome-shell and gdm have a lot of caches etc. <lle-bout>raghavgururajan: that's it now: http://[2a01:e34:ec31:3140:85a1:4057:48e5:33c4]/ <raingloom>the builder script starts like this: (call-with-output-file ((@ (guile) getenv) "out") (lambda (port) (display "# Generated by molly-brown-service\n" port) (write-toml (("Port" <lle-bout>leoprikler: I see well I think right now there's already some caches causing crashes because I had some and these were a reason I switched to XFCE heh <efraim>Sorry, looks like a bit more than I can troubleshoot from my phone <lle-bout>raghavgururajan: I could try setting up a domain with dynamic DNS to ensure it's always right <lfam>genr8_: What do you mean that you can't "cancel it out"? <leoprikler>raingloom: this looks like the fault of #$(molly-brown-configuration-config config), can you verify? <raingloom>leoprikler: i'll see what removing the ungexp does. but #$(yggdrasil-configuration-file config) worked for yggdrasil. <raingloom>which basically does the same thing, except with json. <raingloom>leoprikler: hMM. that did result in a finished build. but i have no idea why.... <leoprikler>check whether the build actually contains what you want as well <dongcarl>lfam: You said that v1.2.1 will consist, basically, of the master branch, but with an update of tzdata. Wondering if that will be the "master" branch on April 18th or of a much earlier date? <lfam>It's hard to say "much earlier" because April 18 is less than a month away <dongcarl>Okay, but it hasn't happened yet, right? <leoprikler>raingloom okay, I can understand the difference now <raingloom>leoprikler: when i try to boot the VM i see a loooot of type errors from Shepherd, so my hunch is that the ungexp should have stayed. <lfam>To clarify, I was listing "major differences" between current Guix and what we aim to release. There will be other bug fixes, and then we have to validate the installer, etc <raingloom>leoprikler: they are both just calls to computed-file, only with different contents. the type should be the same... i think. <leoprikler>you probably want something like (display #$(scm->toml-string etc) port) instead <raingloom>guess i'll wrap it with a with-output-to-string and then display that. rather ugly, but i guess it will work. <raingloom>...yeah, because write-toml and display both have the same "type" <raingloom>so now i just shuffled where the writing happens.... i think. <raingloom>oh, wait, i removed the write-toml while i was editing. *facepalm* <raingloom>errors again... ok, i'll take a shower and come back to it later. <genr8_>I am making progress although ive gotten into a weird state. <zimoun>dongcarl: this Apr. 18th release date is chosen because it is an anniversary date. The idea is to try to keep the schedule ~Apr and ~Nov for releasing twice a year (first commit and first announce dates :-)). <roptat>ouch, "GC Warning: Repeated allocation of very large block (appr. size 1052672):" <boomerchad>I'm having trouble recompiling Xmonad on guix system. It seems that ghc can't find the xmonad package. <l00p>Hello, is there a way to import debian packages easily? I tried using guix-import-debian, but it's not working <terpri_>boomerchad, are you using guix's xmonad package or something else? <terpri_>what are you doing that triggers the ghc error? <boomerchad>ghc-pkg list does not show xmonad installed either <boomerchad>The error happens when executing "xmonad" as a shell command with my xmonad.hs saved in the right place, but the same error prints when compiling the xmonad.hs with ghc directly. <boomerchad>This was all done under "guix environment xmonad" so that it would use the correct version of ghc <Whyvn>I am using dmenu, which usually has a config.h you edit and recompile dmenu to make any changes to it. With guix using guile to configure the system, how would I go about "patching" my dmenu to customize it from the default install? <jackhill>raghavgururajan: yes, when I try to sign-in to an account (I've tried three differen xmpp servers). i get a popup that says "The hcoop.net certificate failed the authenticity test. Invalid CA certificate." (where hcoop.net is my XMPP domain). I'm happy to post more information to the issue tracker, but was wondering if you had run into that. <jackhill>terpri_: interesting about flatpak, thanks for investigating. As far as I know, Guix doesn't yet (wouldn't it be cool if we did) provide "runtimes" for flatpak, so I'm not sure how we'd solve the problem there. <raghavgururajan>jackhill: I see. Can you post the full error message? Does it say "domain is not a match"? <terpri_>jackhill, on further investigation, the relevant freedesktop runtime *does* include p11-kit, and if i simply change the configuration to point to the (sandboxed) .so with an absolute path it works fine. it seems unlikely a flatpak bug like this would go unnoticed, but maybe (complete speculation) related to guix disabling the "system helper"? <terpri_>testing with io.github.sharkwouter.Minigalaxy (a gog.com client, remember to only play free software games like Beneath a Steel Sky ;)), which pops up a TLS error immediately without the patch <terpri_>but org.mozilla.firefox works fine, hmm <genr8_>I keep getting this "make: stat:Makefile: sterror: unknown error" , on different bootstrap build from source packages. now its stuck on diffutils-mesboot-2.7.drv <genr8_>i cant think of any reason why the filesystem would be bunged up <terpri_>i'll poke around the in-sandbox ld.so.conf generation and see if it does something different based on the "system helper" option or other things we modify <jackhill>raghavgururajan: yep, same error with both. I'll post to bug-guix@. Thanks for doing the packaging. <jackhill>raghavgururajan: great. I'll probably put of writing the report until later today because I need to get some other stuff done, but I'll let you know. <rhou[m]>I imported a haskell package from hackage, but it got built with ghc version 8.6.5 although the newest ghc version is 8.8.3, an clues why this behaviour? <terpri_>boomerchad, i see what you mean about xmonad now, totally broken for me beyond loading the default config after printing some errors :( <terpri_>boomerchad, you could send a report to bug-guix@gnu.org with steps to reproduce <cons-this[m]1>So I have been working on some minor fixes to a variety of packages (a lot of them are just editing a few lines) and was wondering if it's generally best to submit all the patches at once or to submit one patch for each package modified, or is it best to categorize them (so each modification of the `emacs-xyz` file is in one patch)? <cons-this[m]1> * So I have been working on some minor fixes to a variety of packages (a lot of them are just editing a few lines) and was wondering if it's generally best to submit all the patches at once or to submit one patch for each package modified, or is it best to categorize them (so each modification of the `emacs-xyz.scm` file is in one patch)? <cons-this[m]1> * So I have been working on some minor fixes to a variety of packages (a lot of them are just editing a few lines) and was wondering if it's generally best to submit all the patches at once or to submit one patch for each package modified, or is it best to categorize them (so each modification of the `emacs-xyz.scm` file is in one pull request, with the clojure edits in another)? <leoprikler>you should probably send the emacs-xyz patches as a series, but with one patch per change as that makes it easier to (cherry-pick if needed) and apply <atuin>mmm after running `guix pull' i get "record ABI mismatch; recompilation needed" from one of my modules <atuin>it's actually the file where i define the system, how can i recompile it <atuin>To avoid the error i need to run guix from the "/run/current-system" but ofc that complains that guix it's old <atuin>mmm strange now i'm getting "service sysctl provided more than once" <atuin>could it be that it's defined in the base-services somehow now? <atuin>seems that base-services are used indirectly by network-services <atuin>lle-bout it worked now, thanks <gxr>Hey guix. I had some trouble with guix pull the last week. I often get error messages like "guix pull: error: corrupt input while restoring archive from #<closed: file SOMEIDHERE>". It is not fully reproducible. It seems like to happen in different stages of the process.. <gxr>It usually comes with this error: "Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'." somewhere in "guix/ui.scm:2164:12: In procedure run-guix-command:" Any hint where to start finding the cause? <iyra>I'm new to guix. I installed it yesterday; and it's on a desktop machine. I'm running a wayland window manager (sway). I'd like to know what the best way to suspend to ram is on guix. <iyra>Any help is appreciated! <gxr>Hi iyra. I don't know if there are many ways to suspend. I use 'loginctl suspend' <iyra>I think I tried that as root, and nothing happened. But I'll give it another go now <iyra>Do I need any special services? <iyra>Hm, yeah, it still doesn't work :< <iyra>bdju: I think I found your config on gitlab through duckduckgo. I'm using some of your manifest file, if that means anything <gxr>iyra: loginctl controls the elogind login manager. So at least that should be running as a service, I guess :) <iyra>I do have (elogind-service) as part of my (services ...) block <gxr>And your 'sudo herd status' shows this service? <iyra>sudo herd status doesn't return anything, seems to just hang <iyra>root@rarity /home/iyra# echo mem > /sys/power/state <iyra>bash: echo: write error: Device or resource busy <iyra>Oh, sudo herd status finally returned 'pam_open_session: Success' but after that, 'sudo: policy plugin failed session initialization' <iyra>So this could be something to do with permissions stuff. <gxr>Looks like it. Are you running a guix system or are you using guix on a foreign distro? <iyra>I can upload my config if that helps <lispmacs[work]>hi, are there any SLiM or LXQT experts around? I was trying to figure out how to set default window manager (lxqt) for slim. I think auto-login-session in slim-configuration is what I need, but I'm not quite sure what value to put in for lxqt <gxr>iyra: I can't spot anything wrong right now. I would check the root account, check the groups of the user account and try to find out if you have some permission issues. Good luck. I will leave now. Bye <iyra>Alright, thanks a lot for your help so far, bye! <jlicht>It actually seems trivial to build jquery from sources using esbuild. Does this not remove quite some headaches with many packages? <OriansJ>lispmacs[work]: traditionallyr your ~/.xinitrc would have "exec $1" if you wanted to use F1 to select the session or "exec i3" (or any other window manager you would demand) <lispmacs[work]>OriansJ: what currently happens is after booting up the laptop, I get presented with a SLiM login screen, and I have to press F1 to switch from OpenBox to LxQT <lispmacs[work]>OriansJ: is .xinitrc setting someway to choose WM after I've logged in...? <atuin>"In addition, @file{~/.xsession} files are honored. When available, @file{~/.xsession} must be an executable that starts a window manager and/or other X clients." <atuin>lispmacs[work] from the service docstring <lispmacs[work]>I'm a little confused because it appears that I select my WM in SLiM before entering in my login credentials <atuin>yes, I think that's the $1 passed to .xinitrc <lispmacs[work]>should 'exec lxqt' work? I'm not sure what the binary name to call is for lxqt <lispmacs[work]>exec lxqt doesn't work, I get error that command cannot be executed. I think that must be because lxqt is not in my user PATH <atuin>did you try just creating a link to your session file? <atuin>mys stumpwm package creates a session file under "/run/current-system/profile/share/xsessions/stumpwm.desktop" <atuin>there I can see the path to the wm binary <lispmacs[work]>atuin: I see the lxqt.desktop file now. So I link .xsession to that with a symbolic link? <atuin>I don't think that file is suitable to be executed as a link in .xsession <atuin>but you can see the path there which should be linked in /run/current-system/profile/bin/ <atuin>so you can try to create an .xsession file that just does "exec /run/current-system/profile/bin/wm-binary-you-want-to-use" <atuin>cat the lxqt.desktop to see how the binary is called <atuin>it should be a line "Exec=path/to/binary" <lispmacs[work]>atuin: I see it. So, I'm going to have to update that then every time I update lxqt on the system <atuin>that contains the path to the version installed <atuin>but you should have a link in /run/current-system-profile/bin <atuin>example: my desktop file has this line: "Exec=/gnu/store/7nkji080agz9snhxlh21hds8hchn610c-stumpwm-20.11/bin/stumpwm" but i can use "/run/current-system/profile/bin/stumpwm" <atuin>since /run/current-system/profile/bin/stumpwm -> /gnu/store/7nkji080agz9snhxlh21hds8hchn610c-stumpwm-20.11/bin/stumpwm, once you update your system the symlink in the current-system/profile will point to the new version you have installed <atuin>and you need to make .xsession executable as well <lispmacs[work]>atuin: so, what i found in there was /gnu/store/(blabla)/bin/startlxqt. so I did command `ln -s /run/current-system/profile/bin/startlxqt' which makes sense. but i am still getting error at slim login screen <atuin>create a file ~/.xsession that contains "exec /run/current-system/profile/bin/startlxq" <atuin>that should work according to the documentation <atuin>the *.desktop files are the ones you can choose using F1 in slim <lispmacs[work]>atuin: I did what you said, excepting fixing your typo. but am still getting the error "cannot execute..." (slim text is somewhat garbled) <atuin>that's what the documentation in the slim service says at least <lispmacs[work]>it appears just to be ignoring whatever I have put in .xsession or .xinitrc, as I can stillogin by pressing F1 and selecting lxqt <atuin>well you get an error so seems it's not ignored :) <lispmacs[work]>I get the exact same error if I delete .xinitrc and .xsession files and try to login to openbox <lispmacs[work]>atuin: which section of the manual were you looking at for those instructions? <lispmacs[work]>I see in 10.8.6 I could use slim-configuration auto-login-session option to set default session <lispmacs[work]>presumably the value would be something like (file-append lxqt "/bin/startlxqt") but I'm not sure <jlicht>civodul: I have no clue what's going on with those patches. Besides that I'm of a similar mind to GKH of the Linux kernel w.r.t. ZFS: if half of the energy spent bikeshedding about in online was redirected to getting Oracle to license, life would be good :) <jlicht>s/about in//, s/license/relicense/ <lispmacs[work]>(file-append lxqt "/bin/startlxqt") seems to work in the config file, at least the reconfigure has not crashed yet <raghavgururajan>Can anyone who have access to harbourfront, paste the pub-key of it?