<podiki[m]>if it is difficult (impossible?) to tell what rust package updates might cause librsvg builds, would it be worth it to have rust updates batched on a branch and merged every so often once it is built already? (but quick enough to avoid conflicts or changes building up, long enough to build though) <podiki[m]>or is the CI normally quick enough when things are running smoothly? <lfam>I had a similar idea podiki[m] <lfam>Normally, the build farm can build such changes very quickly for x86_64 <lfam>At least, it would let us do some quality assurance before deploying, which is technically what CI is for (we don't really do CI now) <podiki[m]>I think the topic of more branches and builds with the CI has come up before, I guess part of a general thought for post-1.4.0 changes in branch organization? <lfam>It's come up before, and we also used to do it before Cuirass, when we used Hydra <podiki[m]>at least a build is a basic check and means people can try it <lfam>When we switched to Cuirass, it was such a regression in terms of capability that we stopped doing that <lfam>But, it's improved enough now that we should try it again <singpolyma>Could do ye-olde merge to branch a, CI runs, CI merges to master on success <lfam>Yeah, that's the idea with CI <podiki[m]>since I am post-Hydra era and of the only core-updates being the recent one...my perspective will be skewed <podiki[m]>but from my view using that beefy CI to build more things in smaller pieces rather than always going into a core-updates (unless it really is "core" for some definition) could be a nice boost <lfam>It was a hard transition podiki[m]. We switched to Cuirass when it was still somewhat simplistic, and then the main Cuirass author quit the project soon after <podiki[m]>perhaps fits in with that discussion a bit ago about working groups/committees/whatever they will be called? <podiki[m]>not to splinter guix as a collective, but to hopefully better harness the energy by keeping things moving more quickly <lfam>Now, we still have some challenges with the build farm, but they are more manageable than a couple years ago <podiki[m]>I was thinking of submitting a guix days presentation for something like "a newcomer's perspective on guix after 6 months" (an eventful and educational 6 months!) <podiki[m]>of what I've learned, rough spots for someone new, that sort of thing. would that be worthwhile? <lfam>I can't think of a presentation topic that would not be worthwhile <podiki[m]>I find guix to be at a pretty good size for getting involved and helping make it better <civodul>lfam: ouch; i terminated the "guix gc" processes now so it'll hopefully be doing something for a few hours <lfam>civodul: I had a thought, maybe it offers a marginal improvement in disk usage there. We should encourage users on berlin to remove profiles that are older than N months <lfam>Or else we might see some 30-month old store items <civodul>lfam: yes, we can do that, but prolly it'll be marginal compared to big rebuilds like today's <gnucode>Hey guix, does anyone know the setxkbmap -option to swap shift and caps lock keys? <nckx>I think I did so relatively recently, but I'll check whether I have any old forgotten stinky profiles on berlin. <nckx>less $(guix build xkeyboard-config)/share/X11/xkb/rules/base.lst <nckx>for the authoritative list. <SeerLite[m]>You could swap them with something like kmoand though, give that a try <SeerLite[m]>Btw I couldn't manage to read the xkeyboard-config man page on Guix, it looks like the package doesn't have it? <SeerLite[m]>$ guix shell man-db xkeyboard-config -- man xkeyboard-config <nckx>You can also create a custom XKB keymap but that's beginnig to dive rather deep into things. Can't speak for kmonad(?) but probably easier. <nckx>Does it carry overhead compared to only XKB SeerLite[m]? <nckx>I hope SeerLite[m]'s suggesh is more useful. <SeerLite[m]>nckx: It probably should but personally I don't notice any delay. It takes over the keyboard input and creates a fake one with the remapping, so it's not restricted to a graphical server (it think it even works in a TTY) <nckx>(Just FYI, so would a custom XKBmap used through Guix. It's Unified.™) <nckx>But at a much higher difficulty curve for sure. <SeerLite[m]>Is that a thing in Guix? I know NixOS has one where you can literally write it in nix language in the config file <gnucode>nckx: I'm trying to help out my friend who is using Linux mint. <gnucode>He is having a weird thing with his shift key not reliably working. <nckx>Best to prefix non-Guix questions in #guix. <gnucode>I think we might try to update his linux to a new distro. <nckx>As long as it's not a stray crumb wreaking havoc. It happens. <SeerLite[m]>Tbf I use a combination of both kmonad and a modified xkeyboard-config package. kmoand is nice for the layers and crazy setups which you can't get with just XKB. e.g. have a layer to get the Vim HJKL everywhere <nckx>gnucode: No need to apologise, but you risk getting Guix-specific answers otherwise, like my XKB-works-for-the-Linux-console above. Although I think that's true on Debian as well, which Mint probably inherits. <gnucode>SeerLite[m]: thanks for the tip as well. <SeerLite[m]>Aha! xkeyboard-config is missing an input to generate the man page <marusich>Is it just me, or was there recently a world-building change on master? <marusich>Maybe it was the version-1.4.0 merge into master? *scratches head* <podiki[m]>more recently some rust stuff, which is connected to like everything now <podiki[m]>plus a frozen CI for a bit, but it is building now <marusich>OK. Good to know I wasn't going crazy. I was just surprised. <nckx>Phew, almost caused a new world rebuild by accident. ***califax- is now known as califax
<lilyp>podiki[m]: inputs, home-page etc. could all go in one line imo <podiki[m]>lilyp: will keep that in mind in the future (rofi-calc was merged) <PotentialUser-49>does anyone else have a issue with glib-schemas having incorrect output? <PotentialUser-49>guix package: error: derivation `/gnu/store/xafyfs8gndg92hvxw20vlvaj3sd3cpmh-glib-schemas.drv' has incorrect output `/gnu/store/ab85lch5ba8lvd53rp3zdiczbn2avrd5-glib-schemas', should be `/gnu/store/5wf97dz1wd5k61b0bmw58iifx705vzpx-glib-schemas' <efraim>sneek: later tell civodul I think it would be best to just set the minimum guile version to 3.0.3 in configure.ac rather than try to support 3.0.2 <tschilptschilp23>mhm. 'guix system reconfigure' keeps failing for me at webkitgtk after the pull from some 8h hours ago... <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, efraim says: I think it would be best to just set the minimum guile version to 3.0.3 in configure.ac rather than try to support 3.0.2 <attila_lendvai>damn rust crates-io.scm merge conflicts! i'm almost redoing the same work as it was to initially create the patchset... <attila_lendvai>there's so much to gain by adding better project management tools... there could be an issue/place/project where people who want to add/upgrade rust packages can drop a line. and no, the mailing list is not appropriate for that, because it's a flat streamline of noise, and people who don't care about rust shouldn't even see my coordination email about it. <daviwil>Hey Guix! Anyone have a good reference for setting up certbot correctly on a Guix system? Simply setting up the certbot service in my config doesn't seem to have caused the certificates to be generated and I'm not sure how to diagnose it <daviwil>Also, anyone have any experience (or references) on running a multi-user Guix system in a way that doesn't compromise security or performance? The majority of the users will not have admin access <attila_lendvai>when shall i add #:skip-build? #t to rust packages? is that purely an optimization thing, that some packages are just a waste of time to be built, because rust apps use them as source, not as binary artifacts? <civodul>daviwil: hi! i think you have to initially generate the certificates by running certbot by yourself <civodul>the certbot service only helps with renewal <civodul>daviwil: re multi-user, do you have specific security or performance concerns in mind? <civodul>the store etc. are designed with multi-user setups in mind <daviwil>Thanks! Didn't realize I'd have to do the initial cert generation, I'll look into that <civodul>there was a paper by Eelco Dolstra of Nix on the security implications of the store in a multi-user system <daviwil>Regarding security, I wonder if there's any risk to any user having access to `/run/current-system/configuration.scm`, specifically around credentials. For performance, I'm mainly just thinking about any user being able to run `guix install` and possibly throttling the impact of that a bit if the server is also hosting public services <civodul>first there shouldn't be credentials in config.scm, and they shouldn't go through the store <civodul>but overall i think services do not encourage you to do that <civodul>as for resource usage, yes, that could be a problem <daviwil>Understood, I haven't seen anything in particular, it was just a thought that came up <civodul>it's not very different from other resources though (processes, memory, CPU, etc.) <civodul>but you can't have quotas on the store <daviwil>Oh nice, I'll look for that in the manual <civodul>whereas you can have quotas on /home, say <daviwil>So yeah! Sounds like I might need to set up some monitoring to ensure that CPU and disk resources aren't being brought to their limit <civodul>IOW, it's possible to escape process/CPU/disk quotas via guix-daemon <daviwil>I'm experimenting with the idea of creating a "Pubnix" server using Guix as a way for folks to play around with it <daviwil>and also host some services there, like XMPP and an IRC bouncer <civodul>giving away SSH access to those who'd like to try it? <daviwil>basically. It's a little risky, for sure <civodul>yes, there are also risks unrelated to Guix (local privilege escalation due to bugs in random packages) <civodul>"git am" fails and "patch" says "malformed line" <rekado>on berlin: builder for `/gnu/store/nh20k8jk0ylv1ramb7lqzypbpbsq6biq-guix-packages-base.drv' failed due to signal 11 (Segmentation fault) <civodul>rekado: is --patch-format=mbox necessary? <civodul>(i pipe mbox files from Gnus to "git am -s") <rekado>I don’t know if it’s necessary, but I got ‘Patch format detection failed.’ when I downloaded the email (saved to ‘0’) and then ran ‘git am 0’. <rekado>could be that it’s not necessary when piping <civodul>rekado: where was the segfault that you saw? <rekado>I ran ‘guix pull --no-offload --system=i686-linux --commit=76f87b01ad’ manually on berlin <civodul>the situation on i686 needs to be improved <ekaitz>hmmmm let me take a look to the thing <ekaitz>well I don't feel very comfortable talking in a place with google as main sponsor <civodul>but... it might still be good to be heard there <ekaitz>yeah the linux foundations is not a saint of my devotion neither... <janneke>hmm, yeah a talk there could be nice <civodul>rekado: "guix pull -s i686-linux" fails to build guile 2.0 here (a test failure) <rekado>yes, that’s why I used an older commit. <vats>Builds for several packages are failing for some time. Wine packages, and transfig. I was wondering if that has come to notice yet. <rekado>civodul: I’ll apply the patch for 53363 <phf-1>In the sources, there is no '_yaml.c' ***phf-1 is now known as phf-1[away]
<civodul>phf-1[away]: looks like the source code may be incomplete then? <civodul>maybe you can try to fetch it from their Git repo instead of PyPI <mbakke>phf-1[away]: looks like you may have to invoke 'cython _yaml.pyx' "manually" as a build step <mbakke>or, looking at the package definition, probably you just need to add (native-inputs (list python-cython)) <mbakke>note that there is already an older version of pyyaml in guix ***phf-1[away] is now known as phf-1
<phf-1>ok, thanks will dig that way. <tschilptschilp23>When I enter the savannah git clone of guix with emacs through dired, I receive the following request: <tschilptschilp23>I don't really know how to handle it -- should I deny or let it write to my .emacs? Will either of that have any effect on doing some changes in the files (I'm not working interactively, at least not intentionally, just adding a package definition)? <davidl>the screenlock on Gnome doesnt seem to work anymore - do I need to do something special to make it work? <tschilptschilp23>davidl: how does not-working express? here I'm having the problem that sometimes after locking, the login mask presents itself without username, then I cannot log in. If I press Esc 2x my username reappears and things are fine again! <phf-1>mbakke, civodul: Adding 'python-cython' as a native-inputs built '_yaml.c', adding ~libyaml~ as a ~native-inputs~ make the package build correctly. Here is the relevant part of my tutorial: https://paste.debian.net/1228205/ <davidl>tschilptschilp23: 1. there is no button after clicking in the top right corner -> Power Off / Log Out button. 2. in the gnome-settings the automatic screen lock is clicked and should set in after 5 mins but doesnt. <mbakke>phf-1: great, that is similar to how to current pyyaml is built (see 'guix edit python-pyyaml') <tschilptschilp23>davidl: uh. that's out of my scope, maybe someone deeper in the matter has a clue... <phf-1>Now, I've to get that to the main repo depot. <civodul>phf-1: nice that you took notes of the various steps <phf-1>I will share that with my team, but I guess these can be useful for a wider audience. <phf-1>Maybe adding these "packaging stories" to the cookbook or somewhere can help? <phf-1>civodul: yes, looking at it now. <civodul>but having a step-by-step textual version in the cookbook or manual would be useful <phf-1>civodul: so, I may add it to the cookbook ? I will try. <apteryx>rekado: are the IPs of the kreuzberg public and static? <sneek>Welcome back apteryx, you have 2 messages! <sneek>apteryx, rekado_ says: Two of the aarch64 machines are running as usual. I just connected to pankow. The cuirass-remote-worker.log doesn’t indicate anything is wrong. <sneek>apteryx, rekado_ says: The problem with kreuzberg (10.0.0.9) was that it doesn’t do the wireguard handshake regularly. All of them have that problem. And I can’t upgrade the systems because ‘guix deploy’ sends x86_64 binaries to them. <apteryx>or are they e.g. behind a home NAT behind a dynamic IP? <ekaitz>hi guix how I'm supposed to replace (swap-devices (swap-space "/dev/sda3")) with the new syntax? <ekaitz>i don't understand the dependencies field very well *attila_lendvai has found gcc's lib output <efraim>attila_lendvai: you almost definately want gcc-toolchain <attila_lendvai>efraim, well, i'm trying to run a foreign binary on guix... guix shell gcc:lib didn't help `ldd openethereum` finding libgcc_s.so <ekaitz>efraim: can I keep the /dev/sda3 or whatever? or now everything is done in swapfiles? <efraim>ekaitz: you can keep /dev/sda3, I found the example in the manual lacking the 'list' part <attila_lendvai>FTR, the way i'm trying to run it is: ~/.guix-profile/lib/ld-linux-x86-64.so.2 openethereum --version (it works for some other binaries) <attila_lendvai>hrm, a step closer: guix shell gcc:lib and then `export LD_LIBRARY_PATH=${LIBRARY_PATH}` gets me to an ldd openethereum without anything missing, but then it still doesn't start. according to strace due to not findin: /gnu/store/mf8mfvw5gzq3dqblk98zqll3x7vx96c5-glibc-2.33/etc/ld.so.cache <efraim>ok, patch sent to add %final-inputs-riscv64, with an explanation <podiki[m]>oh nice, I see CI has broken 60% on master branch, that's a nice jump up from where we started after core-updates-frozen <apteryx>tschilptschilp23: you should allow the guix repo .dir-locals.el definitions for two reasons 1) better integration with emacs-guix and emacs-geiser and 2) avoid emacs pestering you about it every time (that's a fault in emacs). <apteryx>there were none on master for a little while post cuf/version-1.4.0 branches merges <apteryx>I still don't have a proper understanding of grafts (shame), but I'm always wondering why the (seemingly repetitive) work for grafts must be incurred for every profile generation; can't it be cached? pre-crunched on the CI? <civodul>you mean work to determine which grafts apply? <apteryx>applying 33 grafts for /gnu/store/jsf909dm04bzjcc4grh3zsmw1g1280lw-python-ipython-7.27.0.drv <civodul>it should generally be faster than downloading its result <civodul>so we don't provide substitutes for grafted packages <apteryx>I don't think it is, at least on rotative hard drives <apteryx>but assuming it might be, can't we reuse the result grafted packages instead of recomputing it at every profile generation? <civodul>but note that "downloading" really means download + decompressing + unpacking + deduplicaating <civodul>like for any derivation, we reuse its result when it's already in store <civodul>now, if you pull + upgrade, maybe you end up with different packages and different grafts <civodul>phf-1: yes, i reported it earlier today (via weblate) <civodul>(reachable via the "+" sign of the new language menu) <civodul>it's the translation platform we use <phf-1>I was wondering how could you maintain the doc like this in /= languages <apteryx>civodul: re "we reuse its result when it's already in store", OK, good to know! I'm not sure I saw it twice in a row before, I must have been distracted, but now I confirm that I don't see ipython being grafted anymore. <davidl>tschilptschilp23: no Winkey+L doesn't work either :/ <phf-1>In the documentation[1], we can see: ~./etc/indent-code.el <phf-1>gnu/services/file.scm~ but the file ~indent-code.el~ does not exist, <lilyp>phf-1: indent-code.el was removed in favour of Guix style (which isn't as good as Emacs, but hey, we can do it in Guile) <lilyp>imho we should teach GNU indent to indent Scheme code, that'd be fun :) <phf-1>Great! I try to spread Emacs but well... will try ~guix style~ then. Thx! <civodul>rekado: i686 segfault reproduced while pulling 13b905bf28ec6309043bd61c5a92744b13352021 for i686-linux <ngz>I'd like to update qpdf to 10.0.0.3 (on core-updates branch). Are there any gotchas with this package? I'm surprised it has so many dependants. <attila_lendvai>is it really reasonable to expect a contributor to fill in the description beyond (description synopsys) for countless rust libs imported from crates.io? i have no clue what they are beyond what the crates import generates. and mindlessly prefixing the synopsys with "This package provides " is less than useful IMO. is Nicolas Goaziou around? <ngz>I am. And if you don't do it, I'll have to. So… well… <attila_lendvai>ngz, well, i'd go as far as to try to convince you *not* to do it, and spend your time more effectively... :) <ngz>What is reasonable in any case, is to tell a contributor not to do (description synopsis), tho :) <attila_lendvai>ngz, the crates importer generates identical strings for many packages. i replaced those to decrease the noise. <ngz>I understand, but it is not what should be done. <ngz>Usually, I visit the project repository to find some valuable description to use instead of the one provided by the importer. <attila_lendvai>this situation with golang and rust lib importing is not very satisfying. and trying to have a higher standard wrt descriptions in guix than on their home package repository, feels even more self-defeating... <lilyp>Yes, "This package provides" is not nice, but it's a string <lilyp>If you don't provide a meaningful description, at least let it satisfy the constraints set by Guix. <ngz>Note that the description from the importer (i.e., from crates-io) is usually _not_ the same as the description in upstream repository. <attila_lendvai>i think it's arguably already an issue to begin with that the countless rust-* libs are matched/displayed by a simple `guix search foo`. most users won't be interested in those packages, and they are close to as numerous as the rest of the packages... <ngz>There are around 3k Rust libs. <lilyp>recsel -e "!(name ~ 'rust-')" *attila_lendvai makes a note <taxuswc>Hello! I really can't wrap my head around guix texlive packaging and will appreciate any help. For some reason, pdftex can't locate any fonts (I have texlive-base, texlive-pdftex and cm-super that I'm trying to use installed). Upon close inspection, there are no font maps for pdftex in .guix-profile/share/texmf-dist/fonts/map, only dvipdf/dvips <taxuswc>stuff. I tried manual updmap-sys, but apparently no results. Am I missing something terribly obvious? <lilyp>I think we should subtract 10 from the relevance of any proglang binding when the language wasn't listed on the command line <lilyp>Anyone willing to implement that? :) <attila_lendvai>ngz, ok, to summarize: it's preferred that description is a string, even if it's the same as synopsys, and in that case preferred to prefix it with "This package provides ", right? <ngz>attila_lendvai: Correct. Bonus point if you can turn the description into a real description, of course. <lilyp>Let's say you have rust-frobnicator, which provides a frobnicator. <lilyp>Then synopsis: Frobnicator and description: "This package provides a frobnicator." is minimal standard :) <ngz>You can also write "this packages provides", for fun ;) <lilyp>btw. extra bonus points if the synopsis is too long and you shorten it <attila_lendvai>lilyp, trouble is, i have no clue about rust. e.g. what those foo-derive packages are... they are just needed for my end-goal (openethereum), but then i have managed to make an openethereum-binary package that works, so... <ngz>lilyp: IIRC, this is a very common typo, even caught by the linter. <lilyp>yeah, foo-derive is really just rust being rust <lilyp>it's like coming up with something smart for parent-poms <civodul>we've reached the point where people have energy to write software, but not to describe what it does :-) <civodul>it's concerning that our synopsis/description standards look so "high" compared to what crates, etc. are doing <lilyp>but hey, it improves your algorithm scores, because you now have to provide three packages per package <lilyp>one package, one derive package and one obligatory serde/something-else converteer <lilyp>But hey, at least you avoid off-by-one errors :) <attila_lendvai>lilyp, to be fair, an average rust programmer doesn't care much about any of this, it's all handled by their build system. they usually just specify the few toplevel dependencies they actually care about. <lilyp>I'm pretty sure you still have to go through the boilerplate of actually creating the derive packages. <lilyp>Not to mention the huge compile times. <lilyp>"oops, you bumped serde, let's give it three more days" <lilyp>civodul: quality control is also too much to ask, see npm ;) <cwebber>"the selected network does not provide access to the Internet and the guix substitute server, please try again" <cwebber>anyone else having this problem with the installer atm? both a friend and I seem to be <cwebber>when I press ctrl-alt-f3 to get to a tty, I can seem to access the internet and substitutes just fine <lilyp>Last time I checked the ncurses UI was completely divorced from whatever you did in TTY <lilyp>i.e. even if you enabled the network there it'd do whatever <cwebber>well it looks like there's an escape hatch with /tmp/installer-assume-online ;) *cwebber touches that file <KarlJoad>Is there `guix search` support for Guix service-types? <civodul>KarlJoad: yup, "guix system search"! <KarlJoad>civodul: Ahh... I was just using `guix search`. Thanks! <lilyp>can we (test-assert ...) with a timeout? <KarlJoad>Are there service-types for TWMs? I am looking into stumpwm right now. It is a package, but no service type. <apteryx>KarlJoad: if it provides a .desktop file, should be picked up by the desktop manager, IIRC <phf-1>When I install ~git~ with ~guix~, there is no ~git send-email~ command <civodul>lilyp: nope, but you could do (sigaction SIGLARM ...) and (alarm 123) <rekado>apteryx: sorry, I’m responsible for one of the grafts. Better than rebuilding the world because of missing files in texlive-amsfonts, I guess. <lilyp>That won't work, I'm trying to solve the Halting Problem <phf-1>Am I supposed to see it right away or should it appear there later? <podiki[m]>will take a few minutes, and if first patch ever sent might have to wait moderation first? <phf-1>which might be useful for beginners (I have to << teach >> (as far as I can) to newcomers) <phf-1>so, maybe a cookbook entry somewhere, I don't know, you tell me. <phf-1>Well, thank you for being so responsive :). ***phf-1 is now known as phf-1[away]
<apteryx>rekado: no worries! grafts are necessary <KarlJoad>podiki[m]: Ok. I guess I will look into that eventually. Still slowly moving things over to Guix and exploring. <apteryx>I'd be tempted to try serving them as substitutes though; that'd probably help on low powered machines (either CPU are IO) <apteryx>rekado: are the machines looing the wireguard link behind changing IPs? <lfam>Offering substitutes of grafts would roughly double the storage requirements on the build farm, which is fine, but something we need to plan for <lfam>I agree, they are painful on rotational storage <lfam>How often to absorb the grafts ("ungraft") is an interesting question that we've never really needed to discuss, due to limitations in build farm capacity. <lfam>We definitely have the capacity on x86_64 to ungraft every 2 weeks, but then we have to ask if that would be considered a "safe" update or not. It's a question that grafts let us ignore <lfam>The safety of these micro-core-updates actions is enhanced by limited the scope of the graft, but there's still a chance that the package graph breaks halfway through building it <lilyp>but what about arches that aren't x86_64? <lfam>My opinion is that they are basically experimental right now <rekado>apteryx: no, the IPs don’t change (I think), but they aren’t configured to keep the connection alive <lfam>We didn't have a working 'guix' package on i686 or aarch64 for several weeks recently, lilyp <rekado>apteryx: that was my mistake when I wrote the operating-system config; I corrected it since, but I can’t upgrade with ‘guix deploy’. <lfam>lilyp: Don't worry, I'm not going to advocate that we just abandon those users tomorrow. But, we need to be realistic about how many users there are and what needs to happen in order for those platforms to be viable for the distro <lilyp>My very personal opinion is that we need less of such incidents, not more. <lfam>We started to see some patches for those architectures after a few weeks of breakage. To me, it shows that there is some interest, but not enough to be sustainable. <rekado>as a i686-linux user I agree with lfam <lfam>I predict the userbase will grow on new architectures such as aarch64 and ppc64, but i686 and armhf are not going to keep growing <rekado>(I’m switching from i686 to aarch64 soon) <rekado>the exploding power supply forced my hand <lfam>Anyways, I just wanted to dump my thoughts on the subject of "ungrafting" because, like I said, we've never had the capability to ungraft regularly until now. However, when we implemented recursive grafting, we always expected that we would ungraft quickly <lfam>The user experience of grafts is not amazing, so it's worth thinking about how close we are to our goal <lfam>But, the UX of grafts *is* pretty good! <lfam>Most people are on solid state storage <lfam>But nevertheless, the increased space usage has a real cost <rekado>I hope that we can bypass a lot of the build farm problems with our new storage; then we can build more quickly (because we’re not held back by endless GC) *and* keep more stuff. <lfam>Yeah, that's going to be awesome <cwebber>I've been hitting a lot of tls issues while using the installer also <cwebber>is there maybe something goofy about one of the current substitute servers being misconfigured? <lfam>The connection to the substitute server dies, cwebber? <cwebber>lfam: got a tls error but I'll check again when I'm upstairs <lfam>Yeah, I think I know what you're talking about <lfam>That's something we should iron out for the release <lfam>I'm not sure if anyone has a strong understanding of it yet <cwebber>I know I have a friend who was excited to try installing guix <lfam>Fixing that would make a huge difference to the first experience of new users who are attracted by the new release <cwebber>we're going to have a call for me to walk them through <cwebber>ut yeah I've been hitting a ton of issues too <lfam>When you get a chance, cwebber, it would be helpful to know the error message and (if possible) the name of the subsitute that failed <attila_lendvai>an interesting note here: the chores around sending this patchset, including the need to rebase them, and the weeding out the duplates, probably took longer than the actual work of the initial importing and fixing/testing the packages. <lfam>That's basically what I would expect <lilyp>Thinking hard, here computer go script easy <lfam>Languages that fully integrate dependency management, such as Rust, should basically "just work" when using an importer. But there is still a bit of human work required to integrate them into another distro. That is, into guix <lfam>You can think of it like copying one part of distro A into distro B <lfam>But, if there is more stuff that we could automate, we should <attila_lendvai>lfam, but what i'm saying is that initially writing/testing the scheme code took *less* time than sending the commits, resolving a most unlucky series of merge conflicts that happened due to lack of coordination, and then trying to give birth to description fields for packages i'm clueless about... <lfam>I have the same experience with such languages. Namely, Go and Rust <SeerLite[m]>Hi, is there a reason Guix needs to import all Rust dependencies as package definitions in the first place? Can't it just use cargo with Cargo.lock? Other distributions don't seem to package Rust/Cargo deps like Guix does. So I guess I'm missing something? <drakonis>you could always roll something of your own making to read off lockfiles <lfam>I'm not sure that we *need* to do it. Rather, it's what we do <cwebber>lfam: yes, getting it in a sec thanks :) <SeerLite[m]>Sorry, I know it's been discussed before but I couldn't find it by searching <lfam>You're probably overthinking it, SeerLite[m] <cwebber>I want to also say something positive, since I also pointed out a problem <lilyp>Is there a reason Rust needs Cargo.lock? Can't it go with what the distro has? <cwebber>the guix installer is, experience-wise, extremely nice these days! <cwebber>it's such a nice flow, and clearly has improved a lot over time <lfam>It's not a matter of what we need to do. But, it's what was implemented, so now it is what we do. If we wanted to do something else, then we'd need to change the implementation <drakonis>it is, but guix does not retain any control over it <lfam>The most powerful force in existence is the status quo. So, we cont <lfam>So, we continue using the implementation of Rust packaging that we have <attila_lendvai>lfam, why would he be overthinking it? it's completely resonable to expect that if there's a complex system to build Rust/Golang packages (reproducibly), then distros would rely on them, unless there are good reasons not to. <Karthik[m]>(help): can anyone please point me to a friendly guile scheme http intro? the gnu docs are confusing for me ☹️ <drakonis>there's been a move away from relying on distribution maintainers for packaging <lfam>attila_lendvai: What I mean is that asking why we need to do it this way is overthinking the situation. We don't need to do anything <drakonis>Karthik[m]: you mean scheme the language or a library? <SeerLite[m]>Because I feel like just rolling with Cargo.lock directly would get rid of all issues of having to recursively import Rust deps, and then also have to update them and deal with the conflicts <lilyp>It's not a complicated topic, it's a contentious one built in distrust. <Karthik[m]>drakonis: drakonis: a friendly intro to guile http module <SeerLite[m]>lfam: Ah, I see. Well my first thought is that it has to be done that way because otherwise it would be done the easier way (assuming just using cargo.lock is easy) <cwebber>good news: while I was downstairs, the installer succeeded because I restarted the flow! <cwebber>bad news: now I don't have the error <lfam>SeerLite[m]: Yes, it's largely a matter of status quo and implementers making decisions in the past <cwebber>the installer doesn't write a log I'm guessing? <Karthik[m]>drakonis: It is. But I am unable to understand it. So looking for friendly intro posts <lfam>I'm not sure about a log... <lfam>If your friend can get that info, it will still help us out <cwebber>ok lfam, i'll tell them to get it to me if they get it <lfam>I'll try to find the failed request in our nginx logs and see what errors we need to handle more gracefully <drakonis>cargo exists to sidestep maintainers and to make it easier for crossplatform developers i guess? <lfam>It's a bit of a "just so" story, in my opinion, drakonis <lfam>When older languages were invented, it doesn't seem that there was any kind of popular and integrated approach to dependency management <lfam>Since then, humanity invented those things, so now people expect them and build them in <lfam>For one thing, cryptographically secure hashing wasn't feasible in the past, and that's the linchpin of most of these systems <lfam>Since computers got fast enough to do that, you see all kinds of new inventions based on it <lfam>So, now that we can reliably build these dependency trees, and we have a couple decades of experience with integrated dependency management, it's expected everywhere <cwebber>if you require a blob to boot your device (argh, and I do), you can't "really" use the graphical installer, I forgot <cwebber>but I bet from the installer stick I have I can get in and guix system reconfigure my thing with the channel-that-must-not-be-named <lfam>I think people aim to address that problem in a more integrated way, too <cwebber>it's nice that the channel-that-must-not-be-named does have a way of producing an identical installer image <lfam>But of course, it doesn't happen within the Guix project <cwebber>I'm kinda sad I got an AMD board that needs this kind of thing. I don't recommend it. However after using blender's intel driver which literally crashed my entire desktop, and not being able to use blender for years and years despite it being a major part of my workflow, I decided I didn't want to risk getting another intel graphics card. <cwebber>AMD/ATI's graphics sytem is very close to being a great option to recommend. they probably have the best FOSS drivers around, allegedly better than the windows version <cwebber>but, blobs needed to boot. I'd love to see that fixed/replaced. <cwebber>too bad it's not something I have the bandwidth to contribute to. only so much time. <cwebber>in the meanwhile I'm also excited that I'll have a machine with enough ram that I should be able to do more things like compiling complicated packages without either shredding my SSD while swapping or OOM'ing... should help on the guix usage/dev front :) <podiki[m]>cwebber: yes it is a shame, at least for me on new AMD hardware I could install and boot from pure guix, with nomodeset (and thus very limited resolution) <cwebber>podiki[m]: oh I wonder if I could do that <podiki[m]>everything else on new hardware was kosher with linux-libre, but I don't use wifi <podiki[m]>this was pre-recent mesa updates, I wonder if that improved the limited capabilities... <podiki[m]>I've been meaning to write up a short thing for the cookbook about making live images, so I could see what that is like with current guix <vivien>Dear guix, how would I write a test for a function that is expected to emit a warning and a couple of hints, and check that the warning is emitted? Also, in what file should I write unit tests for an importer (pypi in this case)? <vivien>(also ideally I would check that the hints are correct) <vivien>For the latter question, I have the answer: tests/pypi.scm <vivien>Also, I’d like to check that another unit test does NOT emit a warning <rekado>vivien: you can rewrite the default output stream, or you could split the procedure into a function that produces the warning and a procedure that outputs it <vivien>When I call (warning (G_ "something")) in the code, it translates to a display, correctQ <apteryx>rekado: OK, thanks. We should look into that deploy bug then :-) <rekado>vivien: pretty sure you can parameterize the current-error-port (or a similar port) to capture the message <rekado>vivien: guix-warning-port is the port to parameterize here <rekado>warning is a diagnostic defined in (guix diagnostics) and they all print to guix-warning-port <unmatched-paren>i've added emacs-nim-mode to emacs-xyz.scm below emacs-fennel-mode, but when i install it and look in ~/.guix-profile/emacs/site-lisp/nim-mode/nim-mode-autoloads.el, i see lots of stuff related to fennel-mode... <rekado>unmatched-paren: hard to say anything about this without seeing your code <rekado>my guess is a copy & paste error, perhaps even a copied hash…? <unmatched-paren>just a moment... i'll paste the nim-mode-autoloads.el and the two packages <unmatched-paren>i usually copy in another hash, then try to build, then copy in the hash from the 'mismatched hash' error message... it usually works... <rekado>this pattern is really common, so common in fact that it feels silly to call it wrong <rekado>the right way is probably to use ’guix download’ first <unmatched-paren>i think implementing a `guix git-download` command would stop people doing this <unmatched-paren>since the maintainers appear to have forgotten to add tags for the past few years... <unmatched-paren>i am not very good at scheme, but i suppose adding a guix git-download shouldn't be too hard even for me... <civodul>unmatched-paren: "guix hash -rx /path/to/checkout" :-) <rekado>civodul: the last disk was supposed to arrive today but it hasn’t. I’ll install the five disks I’ve got tomorrow; we’ll add the last disk later when it finally gets here. <unmatched-paren>there's an error message 'Cannot open load file: No such file or directory, commenter'... <civodul>rekado: awesome! let me/us know how we can help then <marusich>Suggestion for a Guix Days talk: An introduction to common debugging techniques in Guile. pk is neat, and in theory I understand that the REPL has some debugging features, but I'm not sure what the most common debugging techniques are. I'm not even sure if most people use a debugger. Would be neat learn about from experts. <marusich>I mean, it would be neat to learn about what the experts tend to do. <marusich>Like, when there is a failing test, usually I end up inserting pk statements or (somewhat tediously) firing up a "guix repl" to manually invoke procedures and poke around. But I don't even really know how to set breakpoints and "walk through the code execution" like I can in other languages. <marusich>I know you can, in theory, set breakpoints, and I've tried it at the REPL, but I wonder if anybody is actually doing that. It does not "feel" as useful to me as, say, setting breakpoints in the debugger of a Java IDE, which is usually a very straightforward, very useful feature. I worry I am missing something simple. <apteryx>marusich: you are not missing anything, or that makes us 2 <apteryx>the debugger in Guile is sadly not very useful. <apteryx>to the point everybody seems to use 'pk'. <marusich>I mean, that's my suspicion. I suspect that the debugging experience in Guile really is bare-bones in that you are provided with simple building blocks, and you can in theory do a lot, but in practice it's kind of hard unless you know exactly what you want to do already. <marusich>It is in some ways not fair to compare the debugging experience with that of Java. Apples and oranges. Java has a huge ecosystem and has had lots of support from deep pockets and the community alike. The details of the debugger are pretty complex. But the debugging UX in most Java IDEs is simple and really ergonomic. <apteryx>I think it may be due to macros; the source code as you see it gets lowered into something that looks foreign; such as debugging C programs with -O3. <apteryx>Perhaps due to being optimized/simplified away, many lines are also often unreachable, IIRC. <marusich>Re: "the debugger in Guile is sadly not very useful" - I would say that it is useful, insofar as I can see how you could use its building blocks to build a great debugging experience. However, I don't know if that's been built. If it has, I'm unaware of it. My Java-oriented brain wants to be able to set a breakpoint, start the process in debug mode, and then "connect" to the debugger from another process (ideally, from within an IDE or Emacs, so it <marusich>can tell me interactively "where" it is in the execution). <marusich>I mean, "connect" to the process being debugged. <apteryx>marusich: I don't think it can. It's not the debugger -> IDE glue that's lacking, it's the debugger itself. Try it from the command line. <marusich>I have tried it there. I saw that what it provides out of the box, is some stuff like printing the stack (somewhat useful, but limited when there is a lot of tail recursion and continuations etc.) and local variables. That's useful. But I saw the REPL features more as an example of what you could do, rather than as something people are actually using regularly. <marusich>So getting back on topic: if somebody has lots of experience debugging Guile programs and is doing it in ways beyond just "pk", I'd love to know more about what you do. <marusich>Even knowing a few more tricks at the REPL would be useful. <marusich>And yeah, the macros probably make it hard, also. <lilyp>I mean, in some ways debugging Guile is just like debugging C/C++ <lilyp>you either printf or you pull out GDB :P <marusich>Well, what is GDB for Guile? I don't know of any debugger beyond the commands provided at the Guile REPL. <marusich>And the API presented by Guile, of course, described in the manual, upon which those REPL debug commands are built. <apteryx>if the Guile debugger was able to break anywhere in the source and show understandable evaluation context, we could try to plug it with GUD (the Emacs library that enables debugging while following the source) <apteryx>or RealGUD which is a rewrite of GUD with useful features such as a keyboard-driven interface. <lilyp>geiser+gud would be really gud :) <apteryx>but AFAIK it isn't so there's no point in trying (yet). <efraim>I should try to wrap my head around guix repl more, I'd love to use it instead of shelling out in guix.vim <phf-1>I've just bump into that, but yeah, maybe a bit late though. <robin>phf-1, i was just about to post the article :) <marusich>efraim, as far as I know, "guix repl" is basically just guile with the right modules on the module path so that you can use the guix libraries without much fuss. It also provides some REPL commands, but I don't use them often. <robin>(much of it doesn't apply to guix (imo), some of it does but i think the relevant problems can be solved with time & labor) <lilyp>so the programming language "bad" doesn't exist for guix <lilyp>drakonis: Guix does not try to define a Turing-complete config language, it uses Guile <drakonis>yes i know, i thought you were referring to something else <lilyp>If someone implemented Nix in Javascript, people would be using it all day and not care about any of its concepts. <lilyp>The "real isolation" thing is imo a misunderstanding of what Nix/Guix try to achieve. <lilyp>The main goal is not to hide stuff from processes -- though at least Guix can and I'm p sure Nix too -- but to provide deterministic setups. <robin>yeah, sounds like the author may want something more like qubes <drakonis>its not like that couldnt be built with guix <drakonis>is rewriting shepherd in demand like rewriting the nix daemon? <lilyp>In my personal experience, stuff you'd like to add to shepherd is quite slow to review. <drakonis>not surprising since ludo is practically the only maintainer <unmatched-paren>when creating the package for the nim package manager, should i call it 'nimble' or 'nim-nimble'? <lilyp>To be fair, finding reliable maintainers for a PID 1 is probably one of the hardest Guix-related tasks. <lilyp>I'd probably go with nim-nimble, but is it really something that can be packaged for Guix? <unmatched-paren>nimble should be pretty easy to compile; all i have to do is run `nim compile` on a file, as far as i can tell from the source of the `koch` bootstrapping tool (which we can't use, since it tries to clone the nimble repo, so i'm just going to study it and try to replicate its functionality) <unmatched-paren>another thing: nim shells out to git to grab packages from git repos, but it isn't strictly required (it can also use mercurial); do i add git to propagated-inputs or no? <lilyp>no, if at all you patch the command <lilyp>but I think the larger problem here is that packages built on top of nimble will likely require it shell out to git during build, which is bad obviously <lilyp>can we really pull this in in the manner we tried for npm or should we rewrite it t use something else (koch for example) <lilyp>i don't know how nim works and whether it can link against libgit2 <lilyp>and i'm not sure if nimble devs cared <unmatched-paren>koch is just a nim script in the nim repo that's used to buid nim tarballs and bootstrap nimble, stuff like that <unmatched-paren>libgit2 bindings would definitely be possible, nim is a systems language and without c bindings it would essentially be unusable for most things <rekado>the komascript bug really confuses me <lilyp>btw rekado thanks for fighting the good fight on ycombinator <lilyp>well, it's mostly printed on paper, not on plastic, so... 😋️ <rekado>lilyp: armed with a spoon and a colander <civodul>marusich: FWIW, pk is one of my main debugging tools :-) <rekado>I have no idea how anyone maintains this. There must be some generational knowledge passed down from master to apprentice that I’m missing. <civodul>marusich: i do use the REPL and its inspection capabilities a lot, though, but i rarely use breakpoints & co. <rekado>civodul: I’m also a pk person, but every time I feel like I should have known a better way. <civodul>rekado: i've come to think that if you're doing functional programs, it kinda makes sense that pk is your main tool <civodul>often you just want to check intermediate values <lilyp>unmatched-paren: npm and rust are both appeased by constructing the directory structure they want so that they don't try to download the internet <lilyp>civodul: I agree, stepping through program flow makes little sense if everything's but a value <rekado>civodul: in the projects where I attempt to be a responsible professional I start a REPL server and use call-with-error-handling, hoping to see jump right in with debugging as bad things happen. <podiki[m]>on the upcoming Intel Arc GPUs...do we think that could finally be an option for powerful GPU without binary blob or driver...? (do we have any reference for intel besides their integrated graphics currently?) <unmatched-paren>nim comes with `niminst` to generate installers for programs... have people just completely forgotten about the existence of package managers? <apteryx>civodul: when building programs, a REPL is enough, but when debugging real life situations, a workable debugger would provide real value. <apteryx>it's not impossible to stage it, but it takes a lot of effort even in functional programming, that a breakpoint would make trivial. <drakonis>(although i think guile has most of those already?) <civodul>apteryx: to be clear, Guile does support breakpoints and all <civodul>i just rarely feel the need for them <civodul>there are other tools i really miss though, first and foremost a heap profiler <apteryx>I know it does *on paper*, but in practice I find them unusable (won't stop at the line, and if it does, the code/context is nothing close to what I'd expect) <apteryx>perhaps when debugging Guile needs to be told to not optimize things <civodul>it's the same tradeoff as with any compiler <civodul>it's also the compiler's job to try hard to make it possible to debug in the presence of optimizations <unmatched-paren>hm, what's 'the original BSD license minus the "obnoxious advertising clause"' called? nimble gives its license as just 'BSD' <panosalevro>question, what packages should i install to have full font support for all languages on guix? i usually consulted the arch wiki on other distros but i cant find corresponding packages <drakonis>panosalevro: there's various font packages you can install and call fc-cache to cache them <drakonis>noto sans, any cjk font and an emoji font <unmatched-paren>lilyp: i'm afraid you were right about directory structure :( nimble tries to access $HOME <nckx>"." is too weird to live; use (getcwd). <marusich>civodul, rekado, thanks for replying. It's good to know I'm not really missing out on some secret debugging knowledge. ***analognoise1 is now known as analognoise
<apteryx>do we have a guideline for using suffix/prefix in wrap scripts? <apteryx>prefix is closer to patching the source; suffix is more like some convenient way to have a fallback when the user hasn't explicitly provided the needed commands, for example <nckx>I mean, you got it in one. <apteryx>yes; so the question is do we favor a deterministic result or provide the user with an escape hatch in general? :-) <nckx>We vastly favour determinism. <nckx>Whether that is due to thought or blind copy-pasting is anybody's guess, but it's the current norm. <apteryx>OK. That seems reasonable; after all users have tools in their arsenal to alter their deterministic copy of a program (input rewriting is one). <nckx>I'm for escape hatches in general but — in general — ‘suffix’ is a poor one. Far more likely to blow accidentally than on purpose. <nckx>‘Random package B added an environment variable I don't care or now about to the profile, now A breaks, halp.’ <nckx>‘Ah, but you are using the escape hatch provided to power users. Enjoy! Also, have a nice swim & good luck reaching the surface.’ <apteryx>no, thanks for colorfully imaging the problem for me <apteryx>I'll probably remember the outcome better <jonsger>any idea how to use `invoke` in a mcron job? <apteryx>I'd define the job as a gexp, and decorate it with 'with-imported-module' to import (guix build utils). <apteryx>actually that's what the 'complex' example does in the manually, so simply mimic what you can see in 'info "(guix)Scheduled Job Execution"' <kocio>Hi, I'd like to compile some apps using specific compiler flags, how can I set them for specific package or system wide? <kocio>Is there any howto about it? <civodul>kocio: hi! there's no direct way to do that right now <apteryx>Did I dream that we settled to use the American flavor of English for our English manual? Perhaps it was in some other GNU manual? <ngz>I think all GNU manuals favor American over English. ***mon_aaraj is now known as mon
***mon is now known as mon_aaraj