IRC channel logs
2023-10-06.log
back to list of logs
<Kolev>rekado, I don't use Guix on Fedora anymore, so I can't test. I only use Guix as a whole system. <lechner>sneek / later tell mekeor / thanks! I misdiagnosed the issue. Whenever I open a file or a dired buffer, I get dropped into ~/.guix-home/profile/bin/. Maybe I will ask on #emacs. <snape>rather it looks like Emacs is run from another directory <snape>lechner: so it's default-directory that is incorrectly set <lechner>snape / and indeed default-directory is set to that value <lechner>which version are you using and what is your default-directory, please? <snape>emacs 29, but i dont use emacs daemon/emacs client <snape>default-directory always equal to the PWD of where I started emacs <snape>if I "cd ~/somewhere && emacs", then default-directory is "~/somewhere" <lechner>how do you deal with programs using the EDITOR environment variable? <lechner>i guess my issue is unique since i'm using EXWM <euouae>you can always use --chdir if you need <snape>well, your first question first: program like git commit -m that use EDITOR: i don't use them, I use magit instead <snape>2nd question: EXWM is way too instable, and freeze everytime Emacs freeze, also i don't like to restart it whenever i restart emacs <snape>with as little configuration as possible, because the only configuration i like to write is that of Emacs <lechner>wow, something just set the default directory to my home (i didn't) <lechner>as for EXWM, did you use the standard Emacs in Guix with GTK or emacs-no-x-toolkit? <lechner>anyway, thank you so much for your help today! <snape>you're welcome ^^ it's nothing <snape>i want to talk today to avoid thinking about the things that i try to do and that don't work <snape>anyway it's personal but I feel like what makes Emacs great is its customizability. And it's only customizable when you can restart it easily to test your new conf. But with EXWM restarting it is a pain (because you lose everything else), so you don't want to customize Emacs and try out things. Conclusion : EXWM makes you love Emacs less <lechner>yeah, i get that. i usually tweak the variables live and then record them in my init.el, hoping it will work then too <snape>but when it's stuff like (add-hook 'whatever (lambda () ...))... <snape>you can't really easily de-evaluate them <RavenJoad>How is Guix's plasma-service-type nowadays for providing a KDE Desktop Environment? I'm stuck on X if that matters. <Kolev>On Fedora, I'd do `gpgconf --launch` but it does not work on System. <apteryx>mirai: really nice work on the docbook series! <sneek>mirai, lechner says: / thanks! I misdiagnosed the issue. Whenever I open a file or a dired buffer, I get dropped into ~/.guix-home/profile/bin/. Maybe I will ask on #emacs. <apteryx>mirai: I have problems to apply the docbook series to core-updates; could you try addressing the smallish comments from the beginning of the series and resent a v3? <apteryx>then I think we could have it applied quickly <mirai>oh, could it be because you're trying to apply the v1 patches? <mirai>I've noticed now the replies were split between v1 & v2 <mirai>the remarks are likely to apply in any case so no problem here <mirai>did you have any luck cherry-picking any of them or should I v3 the whole thing? <apteryx>right, I screwed a bit while replying, sorry ^^ <apteryx>you can v3 the whole thing -- it'll be easier to apply then <apteryx>I wasn't able to cherry pick by applying disparate patches via 'git am' <apteryx>and applying in ordered failed on the 6th one <apteryx>there's a weird doc problem on core-updates for me though <apteryx>mirai: .po merge bug resolved by copying over 3 .po files from master to core-updates <lilyp>apteryx: something weird going on with aarch64? <lilyp>note that the master evaluation is still fine and even builds aarch64 stuff, strange <jbnote>Hi, i'm trying to build a parallel script (in the guile repl) to download all of of guix sources. It works, but the stdout access is garbled. Would there be a transparent way in guile to serialize accesses to stdout (at least at the format/display level)? It would probably be sufficient for my needs. <lilyp>jbnote: you can shadow builtin procedures locally <lilyp>e.g. (define (format args) (push (delay (apply format args)) some-message-queue)) <jbnote>would by chance (current-output-port) be thread-local? It is not clear from what I read. <jbnote>I understand now that I probably could make it thread-local anyway :) <jbnote>thanks a lot. I learnt a new meaning of fluid today! <lilyp>is there a GWL way to debug a procedure? <sneek>Welcome back mothacehe, you have 1 message! <sneek>mothacehe, nckx says: Any idea why a query like this would hang? psql -d cuirass → delete from Specifications where name = 'core-updates'; <civodul>i knew about it, but i had long forgotten that we were still emailing that list <mothacehe>i thought it would not work anymore, surprised it does <civodul>there’s a need for notifications, but i don’t know what it should look like <mothacehe>yes, it's probably just burning CPU for nothing <civodul>this approach seems overwhelming though <mothacehe>emailing people which commits breaks things would be more effective maybe <civodul>i found about it because it’s causing ‘cuirass remote-worker’ to block in waitpid for a few seconds <civodul>but that’d be hard because CI tests commit ranges, not individual commits <mothacehe>right that's probably why i went for the ml approach in the first place <civodul>mothacehe: yes, you can push that (don’t reconfigure just yet because there are other config changes i’d like to push) <civodul>for now i’ve modified /var/cuirass/cuirass-mailer so that it does nothing <civodul>actually there are 6 subscribers to guix-ci, one of which is gmane.org (!) <mothacehe>yeah i may have requested that, not to fill my hard drive with failure reports <cbaines>I thought this was a bug from the many "Exception thrown while printing backtrace: In procedure vector-ref: Argument 2 out of range: 99" lines, but I think maybe things are working <cbaines>guix-commits looks broken for guix.git, the last email was for the push of e718647930 2 days ago <cbaines>has anyone got the error message from pushing recently? <rekado>I think we should change the yasnippet so that it uses etc/committer.scm <lilyp>anyone knowledgeable on gwl who can tell me why auto-connect is borked? <lilyp>I get "missing inputs: * the-file" where the-file is in the outputs of another process <lilyp>simon says you should all write your associations with %something as variable names in the IRC <rekado>lilyp: can you provide a test case? <lilyp>'twas "./file" vs "file" as a result of list vs file <rekado>is this something that you think should be explained in the manual? <rekado>(or something that the GWL should work around?) <rekado>efraim: what do you think about changing the minify-build-system to use esbuild? <lilyp>Hmm, if we have a Troubleshooting section in the manual, that'd be a place to put it <lilyp>I don't think a workaround is worth it. You'd have to reason about the file system and that's quirky. <lilyp>hmm… could there be locale issues in GWL containers? <efraim>rekado: what does it currently use? <efraim>oh, i'm about 2 hours behind, IRC is quite quiet <efraim>there's also swc, but I don't actually know what it does <efraim>well anyway, swc is rust based so currently thats x86_64 and aarch64 only, and esbuild sounds like it should work on everything <efraim>which reminds me, I need to get out my cd burner and burn a new powerpc disk so I can fix my mac and make sure esbuild builds there <rekado>efraim: it currently uses node-uglify-js, which doesn’t support recent ecmascript versions <rekado>I switched to esbuild and build all js packages using it <efraim>rekado: something go based sounds better <apteryx>civodul: I got that guix-ci message, and I read it! <apteryx>but I had only recently discovered about it <rekado>this will allow me to simplify all those CRAN packages that minify JS <lilyp>speaking of esbuild et al., could we use minify-build-system to replace node-build-system or how do things work in JS land? <efraim>lilyp: now I'm going to have to look into if I can use esbuild to drop our old node version for bootstrapping node <civodul>so, the question is: will you miss it? <apteryx>I thought it was cool, but if I can subscribe via RSS or some other means, that's probably ok to and less garbage to archive on the GNU infra side of things <civodul>but i think it has the same problem: too noisy <apteryx>it only shows newly succeeding or newly failing builds, IIUC <apteryx>so it's worthy info if that's how it is <apteryx>can help to keep track of recent breakage <efraim>cbaines: re your question about the guix-commits emails, on my first push of the rust-team branch on october 3rd (I think it was) it hung a long time and said the push failed, but the branch appeared. <efraim>no, that was almost definately october 1st <apteryx>don't forget to hit 's' to save the new addition to your *Group* buffer <apteryx>fnat: that's a good question. I don't consider MELPA as the true origin, so unless that's the primary means of a package to be "released", I think the real upstream should be preferred <apteryx>primary means of being release meaning there's not even tags, so whatever is in MELPA is what most users are on <fnat>Thanks apteryx, yeah, the reason I'm asking is because the original repo no longer makes use of Git tags and releases - but of course I can simply use a specific commit (FWIW, I think I also have a preference for tapping to the original repo) <efraim>lilyp: wait a minute, I think we've had this conversation before, about using esbuild to build the node dependencies for node@18 <fnat>apteryx: yeah, that's actually the case, I think, i.e. no releases and no tags upstream <fnat>(although I think the author might consider to resume tags/releases if there's a good reason to) <efraim>probably 8 months ago, you told me esbuild would build individual files but it couldn't really replace calls to npm to build entire packages <lilyp>fnat: note that melpa distributes unstable snapshots, so to day; they may be fine under circumstances (e.g. no other release for years), but versioning should follow Guix' guidelines rather than MELPA's tagging scheme <fnat>lilyp: thanks, what do you mean by "Guix' guidelines"? <lilyp>sorry for the junk, copied directly from the emacs buffer without filtering <fnat>hey that's alright - thanks for the pointer! <fnat>ok, I'll see if the project author might be willing to make an upstream (non-Melpa) release; if not, I'll still get the code from upstream by specifying a commit (a more recent commit of what's currently in Guix) <rekado>whereiseveryone: why doesn’t native compilation work? It works for the current version. <dthompson>my emacs experience has been pretty rough ever since native compilation got turned on <dthompson>like runaway emacs subprocesses compiling things until the system runs out of resources and locks up bad <dthompson>if I ever have to start fresh I install emacs packages one by one and restart emacs each time to find the ones that cause emacs to go bonkers <dthompson>I don't hear many others complain about it but it's happened to me on multiple computers <lilyp>dthompson: It's definitely one of my pet peeves as well. I want to limit native-comp to packaging if possible <podiki>I can't say I've had that happen, and these days I do an emacs manifest and native compile on install via guix <podiki>I sometimes run into issues with the quickstart.el getting stale or something, and have to delete/regenerate <rekado>the /search/latest/archive endpoint on ci.guix.gnu.org appears to be broken <rekado>always returns "Could not find the request build product." <rekado>is “archive” no longer a valid build product? <pastor>Hello. I would like to answer to a mail I got from a patch. I usually use `git send-email` but I don't think using the --in-reply-to is comfortable. How do you guys would answer? I would like to use notmuch or mu4e <pastor>Can I paste the output of a magit formated patch? <Rovanion>IIRC you can paste the output of git format-patch at least. But it was long ago I did this. <rekado>pastor: if you don’t want to use “git send-email” please attach the output of “git format-patch” <pastor>rekado: okay. How do you normaly respond? <lilyp>pastor: I personally use my own tool to send off the mboxen prepared by git format-patch. As long as notmuch/mu4e can do that, you ought to be fine <apteryx>ACTION is modernizing out git package <pastor>lilyp: and those outputs from `git format-patch` are not just pasted on the mail I guess. Are they attachments? <lilyp>au contraire, those outputs are the entire mail, unchanged <lilyp>(safe for added To: and Cc: headers maybe) <podiki>pastor: since you are using or want to use emacs for email, you can use debbugs to see the patch thread and do a wide reply to the response you got <podiki>it will send with however you send email in emacs normally (wide reply is needed to go to the bug number and anyone on the thread, otherwise just the bug tracker gets it and not humans) <podiki>or i guess just respond from emacs normally if the email went to you (sometimes people forget and just send to the bug number) <pastor>podiki: How do I use the `wide reply` you are talking about? <podiki>if you are browsing in debbugs it is... S W I think? <podiki>but if you did get a response to a patch directly and it has the bug number in the to/cc list also, just responding how you normally would should be fine <pastor>Yeah. I have that set up. But I was expecting to see the in-reply-to tag <pastor>I will try to send it an will see how it goes <podiki>I'd say as long as it is sent to whoever is on the bug thread and the bug number email address, that's the main important part <podiki>(I assumed for a long time that sending to bug number sent to anyone who submitted the bug or participated in the discussion, but it does not) <podiki>I thought I bound wide-reply (-with-original I think) to plain old "R" in my config, but it seems to have not taken.... <podiki>thanks to simon for first pointing out the wide reply action to me in some bug thread <apteryx>hm, how can changing git to use gexps causes some dependency cycles (uses all memory when attempting to build it) <apteryx>I've only touched delayed fields (inputs and arguments) <apteryx>ah, maybe ungexps bits that consult the global scope? <pastor>What confuses me is that in mu4e I can see `In-reply-to:` but in notmuch it does not appear. It will not mantain the thread structure otherwise (I think). <podiki>I use mu4e but maybe someone that uses not much can answer <podiki>mu4e just builds off of gnus if I remember, maybe notmuch presents differently? <mirai>apteryx: is there something that uses `this-package' ? <mirai>those can do never-ending recursion if used carelessly <whereiseveryone>rekado: I'm not sure, I was just highlighting that post in case others here want to look into it. I did have an issue the other day with magit while using emacs-next <whereiseveryone>What do people think of limiting the scope of our Python packaging efforts to having a more secure Python package collection? <mirai>I don't see how limiting can lead to more security here <whereiseveryone>I just don't think we can compete with the project scope of nixpkgs or other Python package collections that have way more maintainers/reviewers <pastor>whereiseveryone: I have the same problem with emacs-next. Had to downgrade <mirai>telling someone that X can't be packaged since it goes outside of some decided scope feels rather arbitrary <mirai>and telling them to go add some channel from $RANDOM_INTERNET_USER doesn't seem to make things more “secure” <mirai>perhaps “compete” is the wrong perspective? afaik there's no competition nor some scoreboard saying NIX is leading GUIX by 999999 python packages! <mirai>whereiseveryone: sure, but then the same can be said just about any package and can you imagine the wasted effort of replicating the same package definition? <mirai>it also presumes that everyone can either effortlessly package or figure out the workarounds for some package <mirai>I'll believe this when guix is rid of the substitutions in either phases or snippets & guix-bugs contains no issues about package malfunction <mirai>You do have a point regarding the shortage of hands in guix though <whereiseveryone>I just think that the current unbounded project scope of what we package paired with our limited availability from reviewers can be slightly denting on the morale of contributors who are in it for the long run <mirai>Reviewing patches even by non-committers helps (at the very least it shortens the time to upstream since you can flag the problems early and have revisions issued in a shorter amount of time) <mirai>(personally) I believe a greater help would be to actually collaborate with upstream to actively reduce patching done from our side <mirai>its less hacks/workarounds to review and maintain. Plus, it yields in robuster software as well <mirai>It's also perhaps “the lesser fun”/yet more work though the plus side is: anyone can start upstreaming <whereiseveryone>Otherwise we are just providing big a wrapper to patch ecosystem problems. But maybe we should try to do more ground level work <mirai>indeed but it's also an investment <mirai>the N minutes done upstreaming some snippet/patching means never having to revisit the question later <mirai>you can continuing wadding through the bog or drain it <mirai>I expect that the PyPI packages are added to guix in a on-demand basis <mirai>if someone puts in the work to package it either because they use it or is a dependency I don't see the issue <podiki>well we did recently get all of texlive as individual packages, so with a good importer and dedicated people.... <podiki>unfortunately some language ecosystems have fundamental issues?quirks? of the packaging which makes things more difficult <whereiseveryone>I think that texlive, although a feat in it's own right, is more doable than all of PyPI with our current tooling <mirai>ACTION shakes angry fist at maven <whereiseveryone>I think that the Common Lisp ecosystem is also worth completely packaging <podiki>i'm not sure anyone wants all of pypi compared to all of texlive (rather than monolithic package), we package what we need and I think that is fine <peanuts>"~whereiseveryone/quicklisp-importer - <podiki>common lisp is good since there is a standard and things should remain working too <podiki>there is also a channel out there with all of melpa right? <podiki>so it is doable but I think we are constrained by what upstream does/doesn't do and quality of importers (this we can improve) <podiki>sure, but nice to know there is something to start with <peanuts>"~whereiseveryone/quicklisp-importer - <whereiseveryone>That said, it would be great to get more contributors. Maybe we can all pair on it some time <whereiseveryone>If we end up rewriting it in Guile in the future that would be fine to but it was just easier to do this in CL for now <lilyp>y'all been giving me gentoo flashbacks <lilyp>imho, having an automated channels is little better than curlbash <pastor>does anyone know where are shepherd root services declarations stored? <pastor>Like where could I read the shepherd service instantiated by `guix-service-type' <pastor>I would like to know the `substitute-urls` values for the current system <pastor>I've seen that `guix-system-type' extends a `guix-shepherd-service' which is used to deploy the `build-daemon' which seems to be the only block that knows the current substitutes <pret7>heya! is anyone else having issues with emacs-next? <pastor>Yep. Native compilation is broken <pret7>ah kk, is there a bug report for it? if not I can make one, might have some time to dig in this weekend <lilyp>pastor they're pulled into one giant, hairy file <apteryx>mirai: there is! it's for the git package <apteryx>but it was already there, just using unquote instead of ungexp <mirai>I recall OOM'ing when I misused this-package-… <mirai>don't remember the exact context or have the snippet <mirai>do you have a paste of the current malfunctioning git definition <arst>Hello the archive bug that I described yesterday has been submitted as #66358. Hopefully it gets fixed soon. <mirai>apteryx: what happens if you unquote 'inputs in the (transitive-input-references inputs …) lines? Note that there's 2 of them <mirai>I think the trouble is within this expression <mirai>either with quoted input or with (package-inputs this-package) <mirai>no idea what or how transitive-input-references works <mirai>hmmm… though gnucash is doing similar and it doesn't look like it has any trouble <rekado>(while the constant renaming of the bot to different types of food is cute, it also confuses my ossified brain.) <rekado>lilyp: what’s the locale issue you see in GWL containers? <apteryx>it's over-underquoted, so inputs must be quoted <mirai>I wonder if you could replace that whole map mess with a simpler use of search-path-as-list <apteryx>the difficulty would be to not capture too <apteryx>ah, you mean we'd still use transitive-input-references? <mirai>search-path-as-list is one of the convenience procedures in build utils <apteryx>and feed this to search-path-as-list? <mirai>should result in something easier to understand than this map quote assoc soup <apteryx>for those 3 deps we could hard code a list of #$(this-package-input "perl-xxx") ... <mirai>though I don't think it will solve the OOM <mirai>iirc, I went with the assoc + SRFI because it would make the (map …) part of the builder code <mirai>you can do '#$(map (cut this-package-input <>) '("perl-xxx")) instead <apteryx>this will yield a store file name instead of a package object though no? <mirai>srfi-26 would be imported at the file level though (instead of package) <apteryx>mirai: I have to go afk, but I shall return <mirai>I might be misremembering the actual snippet (can dig the mails to find it) but the difference boils down to whether you want a build script with a list of hardcoded paths or a have a map procedure in its place <mirai>all do the “same” thing (the build script is smaller in the later) <lilyp>rekado I'm not quite sure myself <lilyp>I have a software that uses GOutputStreams for writing stuff <lilyp>if I use that with UTF-8 filenames, it throws a recoding error <lilyp>If I use shell redirects, it doesn't <apteryx>mirai: actually, (map this-package-input (list ...)) <mirai>must have been thinking something else <apteryx>oof, search-path-as-list has a 103 characters wide line <apteryx>can't we use this-package-input in map? 'error: this-package-input: source expression failed to match any pattern' <rekado>lilyp: hmm, indeed. Does it help to throw glibc-locales at it? <apteryx>could be a procedure, which could be used with map <apteryx>is this supposed to work? (let ((outer 0)) #~(let ((inner 1)) #$(pk 'INNER #~inner 'OUTER outer)) <mirai>ah right, now I remember why I did the cut <mirai>but it was to “convert” it into a procedure <apteryx>mirai: it didn't seem to work for me either <mirai>I can't find the snippet where I did something similar either <civodul>apteryx: what you write above should “work” <civodul>but it won’t print the value of ‘inner’, because it doesn’t exist at that stage <mirai>vivien: Should dbus be symlinked to /var/run/dbus in the first place? <mirai>is /var/run/dbus really needed? <vivien>As I understand, the dbus specification was written before /run was a thing <vivien>So pedantic dbus clients might expect to connect to the socket in /var/run <mirai>indeed, I'm reading the spec <mirai>Though the sentence starts as “On systems where /var/run/ is known to be synonymous with /run/” <mirai>, implementations might prefer to make use of that knowledge to connect … <mirai>so the “knowledge” refers to whether /var/run is symlinked to /run <mirai>I don't think our dbus-service should try to forge this fact present (pass /var/run as if it is a symlink on /run if that's not the case) <mirai>it looks like the non-pedantic dbus clients are simply wrong then? <apteryx>civodul: re "doesn'txist at that stage" hm..., maybe this is my problem. <apteryx>I need transitive-input-references to operate on this result before the build code gets lowered, not after <apteryx>from my example above, do you see I way to make this work? (the paste link) <mirai>this transitive-input-references thing is interesting <mirai>a6d0b306c20f236324e4bd661d0f82750ee00e90 <mirai>it was added for git and its also the only package that uses it <mirai>I wonder whether git is really that special to warrant this <mirai>perhaps this could be replaced/modernized with something else? <mirai>something along these lines? (remove-duplicates (<sort-this> (map-append this-package-propagated-inputs '("perl-authen-sasl" "perl-net-smtp-ssl" …)))) <civodul>apteryx: ‘transitive-input-references’ works on sexps; it would need an update to work on gexps instead <mirai>if I understood the intent of that procedure <civodul>though perhaps we might want to remove it, i’m skeptical about the style <mirai>(map-append (cut this-package-propagated-inputs <>) '("perl-authen-sasl" "perl-net-smtp-ssl" …)) <civodul>‘transitive-input-references’ has two users, should be possible to get rid of it <apteryx>mirai: do you mean package-transitive-propagated-inputs ? <apteryx>this-package-propagated-inputs doesn't seem to exist <mirai>I was thinking on the accessor for for the propagated-inputs <vivien>mirai, now that I think of it, Guix has the current system in /run, so maybe we do want /var/run indeed. I will try -Druntime_dir=/var/run but I need to recompile the webkits first <vivien>OK this is not clear but I’m tired <vivien>In my head I think you’re right and we should put the dbus stuff in /var/run <mirai>apteryx: looks like you can disregard that map-append mumbo-jumbo <mirai>from the docstring for package-transitive-propagated-inputs, this seems to be what you're looking for <apteryx>it's append-map (I can never remember too)( <mirai>you could perhaps also vanquish the transitive-input-references while you're at it? Doesn't look like we'd lose much here <apteryx>ah neat, I'm back into cyclic deps territory <mirai>could it be from ("native-perl" ,perl) <mirai>what happens if you replace `perl' with `("native-perl" ,perl)' in native-inputs? <mekeor>hello. i have a rust project. when i run `CC=gcc cargo build --release`, it fails "to run custom build command for `openssl-sys v0.9.74`". what am i doing wrong? <apteryx>but that's another issue, so I guess it'd works <mirai>or these guys: ("bash" ,bash-minimal) ("bash-for-tests" ,bash) <mirai>I'm skeptical of your 'modify-PATH phase <mirai>You changed (bash-full (assoc-ref inputs "bash-for-tests")) to (bash-full #$(this-package-input "bash") <mirai>but you have both bash and bash-minimal in native-inputs <apteryx>mirai: this-package-input looks up by label, which is made from the package name <apteryx>bash is named "bash", bash-minimal is "bash-minimal". should be fine? <mirai>yes but note that bash and bash-minimal would have “bash” as name <mirai>while the previous one intentionally changed one of the labels to disambiguate them <mirai>the meaning is no longer the same as the explicitly labelled one <mirai>bash-minimal is most likely also named bash <mekeor>what's the difference between rust:cargo and rust-cargo? when to use which? or more generally, is there a tutorial on how to work on rust projects on guix (system)? or does everybody rather use a fhs-emulating, containerized guix-shell for this? <lilyp>rust:cargo is the tool, rust-cargo is the crate <lilyp>if that doesn't tell you anything, then yw <mekeor>looks like i could resolve my original problem with "guix shell pkg-config openssl"