IRC channel logs
2023-01-14.log
back to list of logs
<elevenkb>I've read the manpages for `sane(7)` and `sane-airscan(5)` and didn't find any precise debugging. <dthompson>podiki[m]1: joycond is for getting nintendo joycons to work over bluetooth. I like using the switch pro controller. <mirai>dthompson: does it not work ootb with kernel driver? <elevenkb>Sorry after chasing some links I see that there are path variable issues. <lechner>sneek / later ask rekado / Hi, in Mumi "open" issues are green while issues that are "done" are shown in red. Meanwhile, red is more commonly associated with a need for action than green, which usually indicates that a matter has been resolved. Would you accept a patch that reverses those two colors, please? <ulfvonbelow>how does one properly execute child processes in shepherd to completion without waitpid-racing? E.g. suppose I need to execute a certain command in order to stop a service, and I don't know for sure that it's done stopping it until that command terminates. If I just try to invoke waitpid on its pid, shepherd may reap it between fork() and the actual waitpid call, causing shepherd to wait for a process that no longer exists (or, perhaps <ulfvonbelow>worse, does exist but is now an unrelated process with the same pid). <mirai>lechner: I guess this one's a matter of taste <mirai>github uses red and purple for "closed" issues <mirai>and depending on which part of the globe you are, the meaning between red-green "reverses" <lechner>mirai / thank you for your thoughtful comment! having been a foreigner nearly my whole life, please let me know which place you were thinking about <mirai>you might have noticed that š (chart with upward trend) is usually red and š (chart with downward trend) is occasionally green (though typically blue) <mirai>in East Asian stock exchanges, red represents upward movement and green (or black) downward movements <mirai>which is the opposite you'd expect European or US exchanges <mirai>any colour scheme that gets decided should take colour blindness into account <lechner>which should probably rule out red and green. as for east asia, i believe it. i have lived in china <mirai>(you could conjure locale aware colourings :))))) <lechner>either way, your comment regarding color blindness is most acute and well-placed <gnucode>I am re-discovering how tricky it is (and confusing) to create shepherd services. wrong type to apply errors... <ulfvonbelow>it helps a lot to look at the expanded version. You can run "guix system build ...", look at the derivation files it mentions building, find "shepherd-<servicename>.scm.drv", and look at its output. <gnucode>ulfvonbelow: apparently my problem is too obvious for that. It's not even producing a derivation file. haha. <lechner>it's a curse for fixing the opensmtp service <gnucode>lechner: hahahaha! I haven't really fixed much of anything yet. But thanks for the encouragement. :) <gnucode>I think all I can do at the moment, is start commenting out lines. and see if changing things helps... <Ashy>how do you use guix import with guix shell or pack? <Ashy>I'm trying this `guix import pypi s4cmd > s4cmd.scm` which seems to work fine but I can't figure out how to launch a shell with python-s4cmd <Ashy>`guix shell -L . python-s4cmd ` is throwing errors <Ashy>are the outputs of guix import intended only to go into the main repo? <Parnikkapore_m>afaik (use-modules *) needs to be added manually, and for 'guix shell -f' you need to return the package value <ulfvonbelow>gnucode: does the "wrong type to apply" error appear when you try loading the shepherd service, or when you try building the system? <ulfvonbelow>if you've already built the shepherd service scheme file, it won't spit out messages about the derivation again <mirai>I've seen that error so many times and hung shepherd in the hundreds <mirai>(and I still see that occasionally) <mirai>I find the backtraces to be almost always useless <mirai>your list-of-bind-family could use some of the srfi-1 procedures <mirai>but that's not where your issue is <Ashy>Parnikkapore_m: ok thanks <ulfvonbelow>while trying to reconfigure I'm getting ;;; WARNING: loading compiled file /run/current-system/profile/lib/guile/3.0/site-ccache/guix/build/utils.go failed: <ulfvonbelow>;;; In procedure load-thunk-from-memory: incompatible bytecode version <gnucode>ulfvonbelow: are you reconfiguring from guix-src? via ./preinstall-environment ? <gnucode>mirai: thanks for the tip. I'll try that! <mirai>gnucode: I'm suspecting some list-gexp chicanery at line 124 <mirai>try adding quotes, ungexping in another order or using lets <gnucode>ulfvonbelow: that issue normally has to do with the compiled version of guile is different form the guile version that guix uses... <mirai>ulfvonbelow: it doesn't usually matter <mirai>if you're building from source, make clean-go <ulfvonbelow>now that I look at it, those warnings might be unrelated to the actual thing <gnucode>ulfvonbelow: that error is normally from code that does (if x #t). If x is #f, then #<unspecified> is the result. <ulfvonbelow>hmmm, does activation-service-type take a single gexp? <mirai>ulfvonbelow: you're using a when/unless in a list <mirai>ulfvonbelow: unless you 100% need to use activation-service-type, try to use it as little as possible <gnucode>mirai: what do you mean by "try adding quotes" ? <ulfvonbelow>mirai: gotta make a /var/run subdirectory, don't know of a higher-level service for it <mirai>activation-service-type is not the best choice to "create directories" <mirai>create that inside your service constructor <mirai>unless you want to deal with cryptic troubles of the likes of #57589 (read #60657 for the issues with activation extensions) <mirai>gnucode: things like '#$ or performing that serialization outside of the gexp <mirai>ulfvonbelow: in general, activation-service-type is to run things either at boot-time or after a system reconfigure <mirai>and the boot-time thing does not come after file-systems service <mirai>so activation-service-type might work on a reconfigure if your mounted volumes are already present <gnucode>mirai: gexps are just confusing. So is (define-configuration I feel like the guix manual could use a bit more stuff to explain it. Though it least it is documented. <mirai>gnucode: I've seen a few things involving both <gnucode>mirai: which service would you say is fairly simple, but uses (define-configuration really well ? <gnucode>is that something you are working on currently? <mirai>it might look pointless but it actually fixed the issue <mirai>(next morning I came up with a much simpler way that didn't require all that voodoo stuff) <mirai>it used to look a lot more horrible before I rebase+squashed <mirai>looking at your endless ssh configuration, it looks almost the same thing <mirai>you could rename the fields and documentation strings <ulfvonbelow>in short, in your generated shepherd-service scheme file, line 169 looks like: "-f" (string-append ...) <ulfvonbelow>I'm no expert, but I think most programs expect configuration file names, not configuration strings passed on the command line <gnucode>ulfvonbelow: ahhh. that makes lots of sense... <mirai>you most likely wanted a mixed-text-file <gnucode>I'll do that then. thanks gentlemen! <ulfvonbelow>still not sure how that'd be causing your apply error though <mirai>gnucode: try looking at that last link I sent you, I think you can just substitute the docstrings and names <mirai>the config files are extremely similar <gnucode>believe it or not, with the mixed-text-file change, I am still getting a wrong type to apply. checking out issues.guix.gnu.org/60788 now. <mirai>herd configuration vnstatd should give you the .conf file <ulfvonbelow>I suspect the issue you're running into is a subtle issue with the record implementation using macros. Switch 'serialize-endlessh-configuration' to come after your 'define-configuration'. <gnucode>mirai do you work for centos? also, it's cool that you don't have to define (serialize-vnstat-configuration <mirai>gnucode: no, it just happened to be a paste that I find easier to use <ulfvonbelow>my guess is that define-configuration is taking a "pure syntax" approach instead of making procedures available at runtime for its accessors. <mirai>(I find paste.debian.net to be a bit more jarring to the eyes as well) <gnucode>ulfvonbelow: hmmm, I had it that way before, but then put 'serialize-endlessh-configuration' before 'define-configuration' to try to fix some errors... <ulfvonbelow>when your definition of 'serialize-endlessh-configuration' is evaluated, the (presumably) macro 'endlessh-configuration-bind-family' doesn't exist yet, I think <gnucode>mirai I will modify my service to use the layout that you provided in your link. thanks again! <gnucode>ulfvonbelow: thanks for your tips too! <apteryx>OK, (ice-9 exceptions)'s define-exception-type works better than (srfi srfi-35)'s define-condition-type <apteryx>OK, (ice-9 exceptions)'s define-exception-type works better than (srfi srfi-35)'s define-condition-type, in Guile 3.0.8 at least <apteryx>oops, sorry for the duplicated message <mirai>how can I add an extra git repository as a dependency/input for a package (that uses gexps) <mirai>the package in question uses git submodules <ulfvonbelow>my understanding is if you include (recursive? #t) in your git-reference, it'll do a recursive clone <apteryx>mirai: the guix way, if they are truly independent packages, would be to package them separately <apteryx>(recursive? #t) is frowned upon, as it's typically used by upstream to add bundled libraries. at the very least if it's justifiable, it needs to be explained in a comment <mirai>it doesn't look like independent <mirai>> It is currently targeted at version 0.12. <mirai>There are no formal releases planned for this module, and it is not <mirai>intended to be installed at this time. <Fare>if I somehow manage to define a tracker/untested package that doesn't run its unit tests by modifying the upstream tracker package... how do I make it the "official" tracker package referenced by all the packages that want tracker? <Fare>i.e. can I hotpatch a failing package without having to fork and modify the upstream source code? <Fare>I see that on the command line you can use guix build --with-input=package=replacement --- how do I do that in my system.scm file? <podiki[m]1>python-pytest is in (gnu packages check); try "guix show python-pytest" to see that <Ashy>hmm, so if i add "#:use-module (guix packages check)" i get this error: no code for module (guix packages check) <Ashy>i'm just in a bare directory with this module and not in the guix repo, does that matter? <vivien>Ashy, try importing (gnu packages python-xyz) and (gnu packages time) <vivien>If you run "guix show python-boto3" (the first input of your new package), you should get a line: location: gnu/packages/python-xyz.scm:15607:2 <vivien>So that tells you you need to import (gnu packages python-xyz) (transformed from "gnu/packages/python-xyz.scm") <vivien>Similarly, if you run "guix show python-pytz" (the second input of your package) you get a hint to import (gnu packages time) <Ashy>OH "gnu packages check" not "guix packages check", i misread <Ashy>hmm, maybe i can disable the check step temporarily in the package definition? <vivien>Ashy, in gnu/packages/python.scm, look at python-jupytext for instance. See the (arguments ā¦) part, and how it replaces the check phase by invoking pytest directly. Can you reproduce that? Make sure you replace the disable-tests with the empty list '() <vivien>(and then if some tests fail for valid reasons, add them to the list) <vivien>I believe there is work being done in guix about that issue, but I donāt know much about it <Ashy>ah yeap i see the python-jupytext example too, thanks <Ashy>is it possible to build a package up to a certain phase and then land in a shell in the build environment? <Ashy>nix has a way to do that from memory <vivien>Ashy, you can throw an error in the build phase, and build it with guix build -K ā¦ <vivien>So it will abort, and print the location in /tmp with the state it had when the error was thrown <vivien>(usually /tmp/guix-build-package-version or something like that) <vivien>You should see an environment file that you can source to get in the build environment <vivien>Thatās maybe not enough but I beleive thatās the best guix has <SUPERB[m]>I didn't select any wm nor de through the installation <SUPERB[m]>So after rebooting I installed XFCE and then lightdm <vivien>SUPERB[m], you would edit /etc/config.scm to add lightdm-service-type and xfce-desktop-service-type according to the example in the manual for lightdm-service-type and as (service xfce-desktop-service-type) for xfce, and run sudo guix system reconfigure /etc/config.scm <vivien>I donāt know much about those so I donāt know what you would configure <SUPERB[m]>I installed xfce but it doesn't boot up automatically as I boot upvivien <vivien>Did you edit /etc/config.scm and run sudo guix system reconfigure /etc/config.scm? <vivien>The fact that you use the verb "install" makes me think you just did guix install ā¦ <vivien>(replace "itās not sufficient" with "Itās not sufficient nor necessary") <torb> Hi! The package emacs-org-ref in emacs-xyz is currently at version 2. Version 3 is available in melpa since about 1Ā½ years. It's configuration is not compatible with version 2, and silently updating would break org-ref for users of version 2. Would the correct way to handle this be to add a emacs-org-ref-3 package? <ardumont>hello guix, regarding development, is there some "how-to write tests" in the guix documentation somewhere? (i did not find any so far) <ardumont>context is i'm trying to write some tests around the 'guix index' cli i have worked on but i'm a bit overwhelmed by the current existing tests <ardumont>ideally, i'd like to have a way to have a sandboxed (and not too big) store i can execute the script against to check the index and search feature is actually working as expected <ardumont>if anyone has any clues on how i could do that, that'd be great and thx in advance <ardumont>ACTION getting back, a bit reluctantly, to read some more of the existing tests ;) <bumble[m]>would anyone know, what is roughly the most popular matrix client for guix desktop users? <SUPERB[m]><vivien> "The fact that you use the verb..." <- I just installed guix <jonsger>bumble[m]: I use nheko, but I find it only so "lala"... <vivien>mirai, replace `("xdgmime" ,(origin ā¦)) with (origin ā¦) <vivien>Oh that wonāt work with search-input-file <vivien>So, donāt put that origin in the native input <vivien>But in the phase, replace (assoc-ref inputs "xdgmime") with #$(origin ā¦) <mirai>does anyone use guix to work with XML? <vivien>Could you be a bit more specific? <mirai>I meant to ask if xmllint and xmlto tools work "as intended" <mirai>or if using other tools, how are they handling DTDs? <mirai>it's possible to fetch them over internet or locally through a xml catalog <mirai>related to this is if anyone's using docbook DTDs without having to cargo cult substitution* in <mirai>**if anyone's using xmlto or xmllint strictly offline (only fetching DTDs that are installed) <vivien>libxml2 has a search path specification for XML_CATALOG_FILES <mirai>yes, it does but we are not generating a /etc/xml/catalog file <mirai>and I don't think each of the DTD providing packages do it internally <mirai>this step is what generates /etc/sgml/docbook/xmlcatalog and /etc/xml/catalog <tremon>hi all, where does the error "cycle detected in the references of <pkg-output>" come from? how do I find out what the cycle is? <mirai>this missing step is the source of most XML miseries that plague XML-touching guix packages <vivien>mirai, isnāt XML_CATALOG_FILES enough? <mirai>vivien: the catalog must itself exist <vivien>Well, XML_CATALOG_FILES is a space-separated list of existing catalog files <mirai>vivien: it is but none of the packages take care of having it set <vivien>Thatās a limitation of guix, this variable is only set if libxml2 is in the profile <vivien>Have it in the profile and then it should be set with all catalogs of all other packages in the profile <vivien>Thatās how I understand the search path specification in guix <vivien>guix shell --pure libxml2 docbook-xsl coreutils -- env | grep -i xml <vivien>gives: XML_CATALOG_FILES=/gnu/store/hixl26vvdidf11g0l43hlnvv1jv10wdf-profile/xml/xsl/docbook-xsl-1.79.2-0.fe16c90/catalog.xml <vivien>This should work the same way in the build process of a package <mirai>I was still collecting more info about this <mirai>I'll try figuring out what's stopping all these packages from playing well <vivien>Maybe libxml2 needs to be a propagated input <oriansj>I know shepherd is the init for guix but wouldn't it be nice to be able to choose a different init? <nckx>tremon: It means that, for example, :lib kept a reference to :out (this is common and fine) but out also has a reference to :lib, making the two essentially a monolith. Personally, I just grep :out for /gnu/store/hash-foo-0.1-lib and try to figure out how to convince the build to either not insert that reference (it is often bogus), or manually remove it in a phase after building, or perhaps move some files around. The answer is very specific to the package. <mirai>GDM is really full of surprises <mirai>boot computer, SSH into it with X forwarding and xdot opens (from SSH client side) <mirai>log the same user in GDM to GNOME on Wayland <mirai>and using ssh to launch xdot opens it in the remote GNOME session <mirai>lechner: btw, I found out why GDM is making your PC suspend. Some GDM update made it that once you login, it sets some dconf variables to enable auto-suspend and that overrides the guix configured one. <mirai>back to the GDM x11 forwarding trickshow, emacs launches fine with X11 forwarding even after a GDM login <mirai>no idea why xdot gets launched on remote side <tremon>nckx: ah, thanks, so it's not about a dependency cycle between package inputs, but it's about the outputs referencing each other? so I'm wasting my time analyzing the output of guix graph <nckx>I think so yes. I don't have the Guix source handy. <tremon>well, not having to analyze that graph makes me very happy, so I'll take it :) <pjalsDanielv[m]>by nongnu you mean nong**x? the project makes it very clear not to talk about it in official guix channels <nckx>I don't know the exact relationship between SC and nonguix, but they probably both have their own support channels, as should Avahi Linux. <tremon>nckx: muchas gracias, confirmed and fixed <tremon>I was building musl, and musl-gcc ended up in <out>/bin, while musl-gcc.specs ended up in <lib>/lib. They kinda need eachother <nckx>Aha. Yes. I don't know what the right fix is, but you seem to do :) New musl package/update incoming? <tremon>I'm considering upstreaming it when I'm done, yes. For now it's just me getting to know guix <tremon>I'll probably rip out some of the output foolery when I'm done, it's not doing what I want it to do anyway <tremon>next step is to build a working cross-gcc against the musl libc <mirai>what's the way to show the files from a package without having to build it? <mirai>is guix extendable? I vaguely recall that you could add custom commands or switches to guix <mirai>or I'm not hitting the right keywords for it <nckx>Not in the Manuel, it seems. <mirai>there's no indication about how it works as well <mirai>which guix files should I look at <two[m]>does guix import hackage wreq segfault? <two[m]><nckx> "Not in the Manuel, it seems." <- is there an input autocorrect package? <mirai>nckx: if I change a package that has 13 deps but is inherited by a package B with 1K+ deps, does it mean my change will cause 1K+ rebuilds? <nckx>Probably, if the inheriting package doesn't happen to mask your change in turn. <nckx>This is not tracked by 'guix refresh'. <mirai>does the trivial-build-system #:builder require a trailing #t <mirai>or is that no longer the case <two[m]>nckx: how did you get uppercase Manuel instead of manual š¤ <nckx>It does not seem that mysterious to me. <two[m]>sorry i thought it corrected that to a name <nckx>It did, but I can't say what I did to make it do so. My OSK is tiny, so I typo more often than most. <nckx>I'd be slightly less incompetent otherwise. <nckx>I don't like the way default keyboards take up a third to half of the screen. Makes it hard to do anything useful. <Fare>nckx, hi. Thanks for the help. I don't understand though how I am supposed to globally modify a package, so that all those who refer to tracker see the modified tracker instead. <Fare>I must use package-input-rewriting around the operating-system statement? <Fare>nope, doesn't work :-( operating-system doesn't return a package, so package-input-rewriting can't apply to it :-( <Fare>ACTION tries his luck with define-public ... but how do I know it will override the previous one? Because it's evaluated last? <attila_lendvai>Fare, hi. what's your highlevel goal? if the package is just a random package, then just install a transformed one into your profile. if it's something for the OS definition, then at most places you can provide your own package instance. <attila_lendvai>ACTION realizes it's about the pakcage called 'tracker'. then i guess just install a modified tracker instance into your profile. <Fare>attila_lendvai, tracker-3.3.3 (from gtk) fails unit-tests on aa64, so to get things that depend on it to build I'm trying to disable tests. That's not something I think should be upstreamed, though. <Fare>that's the question: how do I get everything in my operating-system definition to use the untested tracker? <attila_lendvai>Fare, you can conditionalize on the target, and mark it with a BIG FAT TODO comment. i think it's appropriate. <Fare>Oh, and how do I conditionalize on target? <Fare>ACTION greps and finds things like (if (target-aarch64?) ... <attila_lendvai>Fare, you need something like #:tests? (eq? (%current-target-system) ...) <Fare>looks like chez scheme, needed by racket, also has some issues. <Fare>Also... I'm not 100% sure whether my issues are indeed due to being on aarch64, or due to my still being trying to bootstrap from mobian. <Fare>I'm also tempted to give up and adopt mobian as the OS, using the guix package manager without the guix operating system distribution. <Fare>That said, phosh is largely unusable anyway, so even with mobian, I'd have to figure out how to configure a regular X installation instead. <singpolyma>I tried to use guix on my pine rockpro64 the other day, but the lack of substitutes was prohibitive <Fare>singpolyma: with bordeaux.guix.gnu.org you have some aa64 packages, but not enough, not at the version you'd want. <Fare>singpolyma, I've been desperately trying on a pinephone pro. <Fare>singpolyma, what do you use? And did you have a working system.scm file at all? <singpolyma>No, I didn't even get as far as trying system. Just trying to install my window manager took hours compiling inkscape, then started on something else big and I gave up <Fare>singpolyma: I count on leaving it on a few weeks compiling. <Fare>not like the machine is terribly useful otherwise, anyway <SUPERB[m]><vivien> "SUPERB, you would edit /etc/..." <- How shall I configue that? <Fare>what distribution do you use for that? <Fare>anyway... I'm quite disappointed that guix seems to make hotpatching even harder than nix, even though it has side-effects that should make it a breeze. <Fare>not enough use of late binding, I presume. <SUPERB[m]>What's you suggestion for graphical login manager to install manually? <elevenkb>hello there, I'm curious about how `python` actually knows to look up stuff in `GUIX_PYTHONPATH`. <Fare>SUPERB[m], on what environment? On a desktop or laptop, I just let %desktop-services install whatever GNOME nonsense, as space is relatively plenty. <Fare>elevenkb, probably a patch? <elevenkb>more precisely it `python-<version>-search-paths.patch`. <elevenkb>So yah, if I were to a native-search-paths mechanism for SANE I would have to patch it as well... too lazy I shall use an environment variable instead. <Fare>SUPERB[m], have you tried lightdm ? <Fare>why can't we use good old xdm ? <SUPERB[m]>Fare: I've installed xfce and lightdm but don't know how to enable it <Fare>SUPERB[m], my uninformed guess would be to look at what %desktop-services does and patch it somehow <elevenkb>yah has to do with the customize-site function. <SUPERB[m]>"systemctl enable lightdm" would enable it on Debian <Fare>SUPERB[m], herd is the daemon on guix <SUPERB[m]>vivien told me to configure it through /etc/config.scm <Fare>so far, guix is both surprisingly good and surprisingly bad. <SUPERB[m]>oriansj: Shall I add them into packages section? <SUPERB[m]><vivien> "SUPERB, you would edit /etc/..." <- I thought I should add them under service section cuz it was xfce-desktop-service-type and lightdm-seevice-type <oriansj>you would replace the (service slim-service-type) with (service lightdm-service-type) in the services section of your configuration <oriansj>look into lightdm-configuration if you want to configure it away from stock <mirai>where should I place a custom "makefile" for guix packages? <mirai>tbh, I'm not what it classifies as <oriansj>SUPERB[m]: lightdm like most login managers allow you to select the desktop environment you run at login time. <mirai>it's a XSL file that patches URIs to point to the store but it's not your typical .patch file <SeerLite[m]>debbugs won't accept any of my emails because my email server uses starttls :/ What mailing list should I ask for help about this? help-debbugs? <mirai>I can think of an AWK way for this but am out of ideas to do in Scheme <nckx>SeerLite[m]: GNU runs their own fork/installation of debbugs, and debbugs isn't responsible for the raw SMTP session anyway. You could ask in #savannah. But even today, forcing TLS implies accepting that you won't be able to deliver everywhere, that's just a fact. <nckx>SeerLite[m]: However, looking at my own logs, your explanation does not sound plausible at all, unless you forgot a ānotā. <nckx>E.g., host=eggs.gnu.org command="MAIL FROM:<>" result="530 5.5.1 Invalid command: Must issue a STARTTLS command first" <nckx>They also use greylisting. <nckx>I was just typing AFK, now you've made it awkward. <nckx>ACTION leaves sheepishly. <SeerLite[m]>nckx: "forcing TLS implies accepting that you won't be able to deliver everywhere", Thank you, I'll look into using another e-mail server instead then. <SeerLite[m]>Interesting though, when I messaged the server admin they told me it was debbugs not accepting TLS/starttls and that I should contact them instead <mirai>depending on the platform? the aliases can have restrictions on their number <mirai>and it makes typing entries more verbose? <mirai>if you wanted to add 100 lines to it, using records would be a lot more effort (though it's not hard to write an AWK/<favourite tool here> script that can automatically generate scheme record declarations) <civodul>mirai: there's only one "platform" we're talking about :-) <civodul>re verbosity, we can arrange to reduce it <civodul>first using define-record-type (no star) <mirai>eh, I said platform but idk if it's really the kernel that's fussy about it <civodul>or (define* (host name ip #:optional (aliases '())) ...) <civodul>the point being: if there's an actual data structure, users can manipulate it as they wish, and we can ensure we generate a valid /etc/hosts <mirai>so (host "127.0.0.1" "example.com") as a shorthand? <mirai>yeah, it would be "reflective", that's a nicety if we go that way <mirai>I can change it to use records but I don't plan to add any sanitizers (for now) <mirai>they can be added latter without causing too much trouble I think <mirai>without looking deeper into the subject, I'd rather not implement naĆÆve checks (I suspect topics like these are never trivial) <SUPERB[m]>I added it in two sections but still not working <nckx>SeerLite[m]: I did not mean to imply that your server operator's doing anything wrong or that there are no valid arguments (or even legislation) for disallowing plaintext. But they might be misdiagnosing the issue: I just confirmed delivery over TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256. <nckx>SUPERB[m]: You added a string to a list of other things which are clearly not strings. <nckx>That's why it's orange, the colour of failure. <nckx>Both images are completely equivalent, so it doesn't matter which one you choose, but yes, remove the bogus "s and then share what goes wrong. āUselessā is not a helpful error message. <SUPERB[m]>But which one is the right place gor lightdm command? <nckx>(I mean, the comment applies to OpenSSH so for your own sanity I would use the first variant, but Guix doesn't see them as different, at all.) <podiki[m]1>civodul: thanks for the careful review on #60556, TIL 'when' can be unspecified in guile (my CL is showing, it is nil when the test form fails there) <nckx>sneek: later give guix-helper-bot a botsnack. <civodul>for a while i wondered if we were getting bug reports about Guix on Windows :-) <civodul>podiki[m]1: re 'when', yeah, the other lisps can be weird sometimes ;-) <podiki[m]1>civodul: it is enough to try to remember what is true, false, '(), etc....let alone all the equivalence tests <nckx>civodul: I've never used WSL, but I wonder what it (the boring "/") does there? Probably nothing. But how cool would it be if it could work. <podiki[m]1>SUPERB: I think you have an extra ) on the light-dem-service-type line (it should be part of the same list as the rest of the services) <nckx>If you look at the other service-types below it, like openssh, you'll see they all have one ). Just emulate that. gpm has 2 simply because it's the last element of a (list ā¦). <nckx>Also make sure you're importing the (gnu services lightdm) module at the top of this file. <civodul>nckx: no idea! maybe / is the actual root? <nckx>It must be virtualised somehow, but I'd support adding Windows-specific code if it could be (ab)used for thatā¦ <nckx>ā¦not going to install Windows to test it though. <gnucode>hmmm the $(guix build vm config.scm) is stuck at generating the ssh keys... <nckx>gnucode: Is this a headless machine or VM? <nckx>They can run low on entropy. <nckx>I.e. does āguix system vmā build a VM inside a VM? <nckx>What doesn't work, and why? <nckx>gnucode: How long has it been stuck? <gnucode>but the first time it started up, it also was stuck for 10+ minutes, then I had to shut off the machine. <nckx>SUPERB[m]: Nobody can help you if you refuse to say what's wrong. <podiki[m]1>civodul: oh and just learned that 'type' is different in zsh, or at least type -p still says "<command> is /path/to/command" which is not as helpful if you wanted just the path <gnucode>*then I had to shut off the host machine, which probably hard shut off the vm. <civodul>podiki[m]1: use "type -P" (uppercase P) <SUPERB[m]>nckx: I installed Guix without checking any DE and after installation was complete and reboot installed XFCE and lightdm through the shell <SUPERB[m]>And added the configurations as I sent over the photos <podiki[m]1>I find that kind of surprising; zhs has "whence" <civodul>that's for the "guix shell -CF" test? <podiki[m]1>yeah, I was just trying out the variation you gave, but in my normal environment to fiddle <nckx>SUPERB[m]: So what are you doing, exactly, after editing your system configuration file to look like the last image you sent? <podiki[m]1>the test environment is in a bash shell I assume? or I tend to be in a pure shell anyway for that <nckx>You didn't run āguix system reconfigureā? <nckx>To be exact: āsudo guix system reconfigureā? <nckx>Your system configuration is not a configuration file that is read at boot. It is a file read by āguix system reconfigureā (and friends) to (re)initialise your system. Just rebooting won't change anything to reflect changes to the file. <nckx>gnucode: I just realised I think I misunderstood you: I thought you meant that āguix system vmā was failing āinsideā the $(), but you probably mean it's failing āoutsideā, right? The VM is built fine? <nckx>That would be 99% less mysterious, and nice. <SUPERB[m]>sudo guix system configuration /etc/config.scm <SUPERB[m]>* sudo guix system configurationāØnorāØsudo guix system configuration /etc/config.scmāØnone works! <gnucode>running: /gnu/store/a61fxpb2g7fgcr3zmcq891qlwqjinyvn-run-vm.sh doesn't quite boot the vm. <nckx>gnucode: You can try adding rngd-service, but I'm not sure it's magically enough. <gnucode>I was trying to test out an endlessh service with it. so it could be that service is breaking stuff. <nckx>If you have a console to the VM, you can also just mash the keyboard. <nckx>This does not sound like a build failure, sounds like the system boots fine but is just starved for entropy. <gnucode>at first I was playing videos in the host OS, then realized that the guest vm, wouldn't be able to gather the entropy from the videos.... hahaha. <nckx>Any vaguely modern CPU should support RDRAND or similar instructions, unless you've chosen not to trust them. <gnucode>lechner told me yesterday that I'm cursed because I tried to fix guix's opensmtpd service. hahah. <nckx>I had trouble porting my configuration to it, but that might have been user error. It seems like it's completely order-free, is that right? If so, I'm not sure it can express everything that the smtpd.conf grammar can. Which is a total bummer. <gnucode>I do not believe that it is order free. <gnucode> The match records are evaluated sequentially, with the first match winning. <gnucode>nckx: do you want to throw your smtpd.conf file my way, and I can try to show you how you would use my sexpression syntax? <vivien>Up until a few months ago, my CPUāÆdid not support RDRAND (a bug in the motherboardā¦), so I couldnāt compile some cryptography packages <gnucode>it might not work for everything, like if you use text files or databases for tables... <nckx>Hm, it wasn't quite that, but I don't remember what snag I did hit. I don't have my Scheme version with me. <vivien>Well it claimed to support RDRAND but it reported the same value every time <nckx>vivien: I guess some ***boot flashers might disable it, too, but that's pure conjecture. <vivien>So well-behaved cryptographic functions would ask for a new value again and again <nckx>This is the start of a Friday-afternoon post-mortem horror story. <nckx>There is some old cruft there that could be removed now, but let's say it makes the exercise more ārealisticā :) <gnucode>I currently do not support file:/etc/guix/mail/virtuals . <vivien>To be honest linux told me every time on boot that there was an issue with rdrand, and that I might want to disable it, but it would only solve the issue for linux itself, not other programs <gnucode>So I would have to add in code that would allow that. Or you would hav eto convert your file tables into an (opensmtpd-table ... (data ...)) record. <gnucode>put, I will try as an exercise to generate your configuration. thanks! <nckx>Pretty sure I open-coded that, or punted on it. That was not the issue. I wish I could give you the exact problem, but I don't have access to that machine right now. It was something to do with naming not being entirely consistent, at least not how I expected it to be. You know, how your records have explicit ānameā fields that kind of sit outside of Scheme. Also, something *really* didn't like the angle brackets in <table> IIRC. <nckx>And it was in this naming that I managed to code myself into a loop. <nckx>All IIRC YMMV IANAL WTFBBQ ETC. <vivien>Did you know? "IIRC" means "In IRC", which is the opposite of "IRL", which means "In Real Life" <gnucode>nckx: well I think it's cool that you gave it a go! <gnucode>I hope my documentation helped a little bit. <nckx>I also just used (let ((mx "mxā¦") (rx "ā¦) ā¦))), I didn't try to use $variables of course. <nckx>I thinkāI know I did, I just hope I find themāI made notes about a few inaccuracies, but on the whole it was very helpful. And I'm used to having to read Guix service code alongside the documentationā¦ <nckx>vivien: That sounds as plausible as anything I read IIRC. <gnucode>nckx: that is perhaps a downside with the way I modified the service. With any sufficiently complex configuration, you almost need to use (let ((var )) to use the service with any complicated set up. So it perhaps forces people to learn a little bit of scheme. <nckx>That's OK: it is Scheme. <nckx>What makes it unintuitive Scheme to me is the (name "foo") business. <nckx>You'd have to autogenerate names to make the Scheme feel natural, but others might object to that, and I'd understand. <nckx>gnucode: Do you have any nontrivial (or not too trivial) examples to share? It's also possible I've been trying to force my āstyleā onto your service in a way it wasn't meant to be used. <vivien>podiki[m]1, yesterday it worked fine <gnucode>nckx: if you can forward me your inconsistancies and any other notes that would be really helpful! <nckx>gnucode: Yes, sorry I can't, but I will when I can. <gnucode>the biggest one is probably on my blog or in my org documentation...just a second I'll share the one in the org doc. <podiki[m]1>vivien and nckx: thanks for confirming it is not gremlins in my ethernet <bjc>does anyone know how to fix the āUnknown # object: \"#~\"ā errors from geiser? i'm not sure how it manages to get to a place where it's reading that syntax without having also loaded what's necessary from guix, but it's a pretty constant annoyance <gnucode>Let me check to make sure it still works.... <nckx>podiki[m]1: 5xx very reliably means server error, those would have to be haunted gremlins at best. <nckx>ACTION shoots gremlin in the face. <podiki[m]1>nckx: good point, rather than a local dns issue (i've broken my local dns enough times I should remember) <vivien>bjc, what do you do to trigger this error? <bjc>vivien: use geiser with guix <vivien>I have emacs opened and I did: M-x geiser <gnucode>nckx: that example-configuration still works. But It's not terribly complicated. <vivien>I have a new buffer with geiser loaded up <bjc>vivien: emacs-guix pulls it up every time you type āguixā in eshell <bjc>unless you're editing a file with the #~() syntax, the error won't show up <telmo[m]>thinking of migrating to niches while waiting to stop the distrobox from being added in guix <vivien>Then itās beyond my emacs expertise <gnucode>nckx to be fair, I checked to make sure the example config generated an smtpd.conf. I did not check to see if that smtpd -f /gnu/store-tahesnteahntha-smtpd.conf worked. <nckx>cbaines: ā¦ohā¦ Is the log overwritten on (re)start? <bjc>vivien: no worries. one of these days i may dig into it. it seems like a pretty common problem, though, so i hoped there was a known solution <nckx>gnucode: I'm pretty good ad reading smtpd.conf, I'll give it a go and see what it generates. Thanks! <nckx>No smtpd.conf ad reads are pretty good. <podiki[m]1>(it has happened before and returns, I assume some server hiccup) <vivien>podiki[m]1, I donāt, because I have a cron job to synchronize my own clone of guix! So when the repository goes down, I can still pull ;) <podiki[m]1>vivien: pull worked fine I think, must just be the cgit frontend; I was just about to push and definitely would have panicked if I saw that after :-P <nckx>By āreturnsā, you mean shows a summary? <podiki[m]1>I mean it shows under the "Index" heading in red text "No repositories found"; so the general cgit interface is there at least <podiki[m]1>I find some GNU sites sometimes come up blank for me too and need a refresh, no idea why <nckx>But do you mean this ānoā messae is unusual/temporary orā¦? <nckx>Yeah, mumi does that for me regularly. <nckx>I chalk it up to Guile Web jank. <nckx>A refresh always fixes it, like reboots do my computer <rekado>with mumi itās likely an undiagnosed crash in guile-xapian <sneek>Welcome back rekado, you have 1 message! <sneek>rekado, lechner says: / Hi, in Mumi "open" issues are green while issues that are "done" are shown in red. Meanwhile, red is more commonly associated with a need for action than green, which usually indicates that a matter has been resolved. Would you accept a patch that reverses those two colors, please? <podiki[m]1>normally where that "no" message is the git log and such, when I've seen it before it returns to normal some time when I check later <nckx>vivien: GuixĀ® is free and open source software, which means that it's developed on GitHubā¢. So you can always clone from there. <nckx>podiki[m]1: Understood. If it's not always been like this, I'll not report it yet. <podiki[m]1>nckx: I use the github interface sometimes for searching, enough that "mirror" in my address bar goes there first :) <podiki[m]1>ssh access works, so something funky with cgit browser I'm guessing <nckx>It is almost the witching hour here. <podiki[m]1>but I'll not push as I run out the door, will do that later <podiki[m]1>ACTION must pill a cat and throw axes, in that order <podiki[m]1>medicine or else! (no, no animal cruelty here! axes will be thrown at dead plants probably) <nckx>Have fun! /meesa ā š“š¤ <bumble[m]>hey everyone, using guix, when rendering gui emacs in sway the text is extremely blurry --would anyone recommend a solution? <morganw>I think you can fix that by editing/creating ~/.Xresources although I've not tested it myself <gnucode>bumble[m] you could try emacs-next, and disable x in sway. works well enough for me. <bjc>i'm using the normal emacs package in sway, and the text was fine without any configuration <bjc>i am also using an almost-default %desktop-services, though, so it may have installed something necessary that i'm unaware of <morganw>When I've tried it is slightly blurry when compared to not using sway <bjc>might be the font itself? i switched to iosevka for most things a while back, and it looks extremely crisp <morganw>I have a note that this as the file contents may fix it: Xft.antialias: 1 Xft.hinting: 1 Xft.autohint: 0 Xft.rgba: rgb Xft.hintstyle: hintslight <bjc>also: i'm not using hidpi or anything <morganw>It could be font related, I just used the default 
