These are the channel logs matching your query alphapapa
2022-06-27 | [06:36:20] <alphapapa[m]> Forgive the noobish question, but I've been searching for 10 minutes and haven't found the answer: How do I list the output files of an installed package? e.g. the equivalent of "dpkg -L foo" |
2022-06-27 | [06:37:35] <KarlJoad> alphapapa[m]: Depends on what you are doing. But, I found the easiest way is usually building the package and looking into the output directory. |
2022-06-27 | [06:38:09] <alphapapa[m]> KarlJoad: Makes sense, and I tried to do that, but... how do I find that output directory? "guix show foo" doesn't seem to show it |
2022-06-27 | [06:38:29] <trevdev[m]> alphapapa: Maybe guix package --show=foo? |
2022-06-27 | [06:38:51] <alphapapa[m]> trevdev[m]: I tried that, but it doesn't show the installation directory. |
2022-06-27 | [06:39:24] <KarlJoad> alphapapa[m]: `guix build <package-name>` will eventually print the output directory in the store of the package. |
2022-06-27 | [06:40:00] <alphapapa[m]> KarlJoad: Thanks, but I've already installed the package, and I don't want to rebuild it. I just want to know the directory where it's installed. |
2022-06-27 | [06:40:15] <alphapapa[m]> I thought there was a way to quickly show that, but I can't recall. |
2022-06-27 | [06:41:01] <alphapapa[m]> right, but... isn't there a way to get that path from a command so I don't have to mess with the hash manually? |
2022-06-27 | [06:41:30] <alphapapa[m]> KarlJoad: I have done "guix pull" recently, and I don't want to rebuild 127 packages at the moment... I just need the directory where one package is installed |
2022-06-27 | [06:43:32] <alphapapa[m]> Yeah, I could always dig through a directory listing, but I thought Guix could show me where a package is installed. Seems like an obvious thing, doesn't it? |
2022-06-27 | [06:44:00] <KarlJoad> alphapapa[m]: It definitely should be able to. I just don't know the command off the top of my head. |
2022-06-27 | [06:45:10] <alphapapa[m]> Well, I ended up just using Fish's directory completion. I just hoped Guix could do it too, haha. Thanks for your help. |
2022-06-27 | [06:47:36] <alphapapa[m]> Whew, Guix has saved me again, allowing me to update the TLS certs that Git uses without having to mess with the underlying OS packages! |
2021-12-13 | [04:07:31] <ryanprior[m]> There's a new Matrix client for Emacs in just the past few months, I haven't tried it yet but interesting to see continuous improvement here: https://github.com/alphapapa/ement.el |
2021-11-30 | [23:15:18] <jgart> I remember having a conversation with alphapapa in which he was surprised at the work required to package shell for guix |
2021-11-30 | [23:18:10] <jgart> apteryx, jpoiret, found it: https://github.com/alphapapa/bashcaster/issues/6 |
2021-11-16 | [12:25:36] <M6piz7wk[m]> The syntax highlighting on github looks much more comfortable though https://github.com/alphapapa/prism.el |
2021-09-29 | [10:57:58] <alphapapa[m]> Hi, is there a way to limit the number of threads that the guix-daemon uses in the Guile process? The --cores option only seems to apply to the build process, not to the Guix Guile process, so e.g. if I use --cores=4 to limit the build to 4 jobs, the Guix Guile process may still use as many threads as my CPU has cores before it gets to the build process, which may saturate my system for a while. |
2021-09-29 | [11:07:49] <alphapapa[m]> vivien: Thanks. |
2021-08-06 | [22:06:00] <cehteh> https://github.com/alphapapa/ement.el << anyone bored and want to package that? |
2021-08-06 | [22:23:21] <cehteh> but 'alphapapa' looked familar, he maintains the magit-todos i am using :D |
2021-07-06 | [01:00:01] <jgart> what are some people's answers/thoughts/explanations to this last question asked by alphapapa? https://github.com/alphapapa/bashcaster/issues/6 |
2021-07-06 | [01:49:51] <jgart> cbaines_, thanks for the explanation! I'll relay it to alphapapa |
2021-02-17 | [15:06:45] <dftxbs3e> nckx, a bit like this: https://github.com/alphapapa/prism.el - but not really since that does scopes and not Scheme quoting/escaping levels. |
2023-08-01 | [19:30:04] <alphapapa[m]> Hi, I'm trying to install the recently released Emacs 29.1 with ~guix install emacs-next --with-commit=emacs-next=emacs-29.1~, and it builds and installs without error, but native compilation cails with errors that the files ~crti.o~ and ~crtbeginS.o~ can't be found. The Emacs 28.2 version of the ~emacs~ package works fine with native compilation. I can't find any bugs on the tracker about this problem in the emacs-next package for Emacs 29 |
2023-08-01 | [19:30:05] <alphapapa[m]> pre-release versions, so I'm not sure what's going on. Would appreciate any pointers. |
2023-08-01 | [19:30:29] <alphapapa[m]> s/cails/fails/ |
2023-08-01 | [19:33:24] <alphapapa[m]> ah, yes, maybe so |
2023-08-01 | [19:33:59] <alphapapa[m]> Forgive me, but is there a way to access those patches through the shell, or do I need to look in the git repo? |
2023-08-01 | [19:34:27] <alphapapa[m]> thanks |
2023-08-01 | [19:36:58] <alphapapa[m]> nckx[m]: Do you mean if it works without this patch? https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/emacs-native-comp-driver-options.patch |
2023-08-01 | [19:38:22] <alphapapa[m]> Oh. What changes did you make? |
2023-08-01 | [19:38:37] <nckx[m]> alphapapa: Just the version & hash so far :) |
2023-08-01 | [19:38:58] <alphapapa[m]> Oh. That should effectively be the same as using the transformation option I passed to guix install, shouldn't it? |
2023-08-01 | [19:43:20] <nckx[m]> alphapapa: I'm not sure if that preserves patches. |
2023-08-01 | [19:43:54] <alphapapa[m]> I see. Well, I looked at those patch files, and AFAICT they shouldn't affect this problem; the one about native comp only applies to Macs, anyway. But I appreciate your help. |
2023-08-01 | [19:44:43] <alphapapa[m]> For reference, here is the full set of error messages from Emacs's ~*Warnings*~ buffer:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/e3ce2e9c022abb550b4c8cdd756b964d0559c67d>) |
2023-08-01 | [19:47:32] <alphapapa[m]> pjals_fox: AFAIK it's the responsibility of the Matrix bridge to handle that. In every other bridged channel I use, it does. |
2023-08-01 | [19:48:09] <linj> alphapapa[m]: TIL |
2023-08-01 | [19:49:42] <alphapapa[m]> pjals_fox: You don't need to repeat the pattern by also yelling at others ;) |
2023-08-01 | [19:57:31] <linj> yeah, his messages are missing but mine and alphapapa's are fine |
2023-08-01 | [19:58:31] <alphapapa[m]> https://status.matrix.org/ shows that the Libera-Matrix bridge is having some issues today. |
2023-08-01 | [19:59:27] <alphapapa[m]> Yes. I'm sure it will be worked out eventually. |
2023-08-01 | [20:00:31] <alphapapa[m]> Yes, I've been keeping up with the topic. |
2023-08-01 | [20:02:48] <alphapapa[m]> I'm aware of that too. A few weeks ago there was an outage caused by the matrix.org homeserver TLS certificate, and the tracker didn't catch it. I filed https://github.com/matrix-org/matrix.org/issues/1938 |
2023-08-01 | [20:03:18] <alphapapa[m]> (I'm a Matrix client author, so I generally keep up.) |
2023-08-01 | [20:03:57] <alphapapa[m]> nckx: FYI, I just filed https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64999 about the Emacs issue |
2023-08-01 | [20:04:22] <alphapapa[m]> ugh, I misspelled the filename in the subject |
2023-08-01 | [20:05:39] <alphapapa[m]> I tend to be sympathetic, because it seems like a challenging software engineering problem, and they're doing their best, free of charge to us. |
2023-08-01 | [20:06:01] <nckx[m]> alphapapa: Thanks for the bug report! |
2023-08-01 | [20:16:08] <alphapapa[m]> I left the old room and it kicked me from this one :/ |
2023-08-01 | [21:20:31] <nckx> alphapapa[m]: I'm running emacs-next-pgtk@29.1 without issue. emacs-next@29.1 also seems to run fine. |
2023-08-01 | [21:29:22] <alphapapa[m]> nckx: Yeah the news says that only works for installed packages, but that that limitation will be lifted in the future. |
2023-08-01 | [21:29:47] <alphapapa[m]> <nckx> "alphapapa: I'm running emacs-..." <- Thanks. Can you confirm that it's native-compiling Elisp libraries? |
2023-08-01 | [21:32:58] <nckx> alphapapa[m]: Which news? I looked up the ���guix pull��� news item for precisely this reason and it specifically doesn't mention ���installed���. That's why I'm surprised. |
2023-08-01 | [21:34:33] <alphapapa[m]> maybe I misunderstood what "packages that have reached your store" means |
2023-08-01 | [21:39:04] <alphapapa[m]> ah, thanks |
2023-08-01 | [21:41:28] <alphapapa[m]> ok, running "guix locate --update --method=store" now |
2023-08-01 | [21:43:30] <alphapapa[m]> (Why does the user "Cat Disruptor 6000" keep reacting to random messages?) |
2023-08-01 | [21:44:34] <alphapapa[m]> I've seen it in the TWIM room, but I didn't realize it was in others too. It's a bit annoyingly...spammy/noisy... |
2023-08-01 | [21:45:23] <alphapapa[m]> (I'd vote in favor of kicking that bot, because ATM about half the vertical space in this room is its pointless CAT reactions.) |
2023-08-01 | [21:45:47] <alphapapa[m]> nckx: #thisweekinmatrix:matrix.org |
2023-08-01 | [22:01:15] <alphapapa[m]> lilyp: Not exactly. The package definition hasn't been updated yet. You can try to use transformation options to build 29.1, but when I do that, native compilation doesn't work. |
2023-08-01 | [22:02:09] <alphapapa[m]> nckx: What do you mean? |
2023-08-01 | [22:02:57] <alphapapa[m]> nckx: Maybe try "C-h f describe-function RET" and see if it says "describe-function is an interactive native-compiled Lisp function" |
2023-08-01 | [22:04:01] <alphapapa[m]> well... I have no idea what's wrong with my installation then... works fine on "emacs@28.2" but "emacs-next@29.1" gives the errors in the report I filed |
2023-08-01 | [22:05:12] <alphapapa[m]> I'm very far from being a Guix expert user |
2023-08-01 | [22:05:46] <alphapapa[m]> nckx: Being a non-expert Guix user, what exactly do you mean? Should I try to do the same thing? |
2023-08-01 | [22:07:24] <alphapapa[m]> oh I see |
2023-08-01 | [22:10:09] <alphapapa[m]> I just tried "guix shell emacs-next --with-commit=emacs-next=emacs-29.1 -- emacs-29.1" and I get the same errors at runtime. I don't know what I could be doing wrong. |
2023-08-01 | [22:10:32] <alphapapa[m]> s/"/~/, s/"/~/ |
2023-08-01 | [22:13:20] <alphapapa[m]> lilyp: He's testing an updated package definition that points to the released version |
2023-08-01 | [22:22:12] <alphapapa[m]> nckx: Sorry, do you mean you pushed the update to master? |
2023-08-01 | [22:35:43] <alphapapa[m]> yeah it was pretty slow for me too |
2023-08-02 | [00:17:54] <alphapapa[m]> nckx: Well, I managed to hack the emacs-next definition into building emacs-29.1 from the tarball, and after installing it, native compilation seems to be working normally. I don't understand why ~guix install --with-commit=emacs-next=emacs-29.1 emacs-next~ causes it to not work with native compilation, but as you said, updating the package definition seems to work. |
2023-08-02 | [00:19:39] <alphapapa[m]> Well, I copied some expressions, updated the checksum and the version string, etc. |
2023-08-02 | [00:19:52] <alphapapa[m]> I can share the file if you want to see it but I'm sure you know better than me how to do that |
2023-08-02 | [00:22:13] <alphapapa[m]> LOL, yes, a bit painful because I don't know enough about Guix and Guile to know the minimum I should do... |
2023-08-02 | [00:22:25] <alphapapa[m]> ACTION posted a file: (0KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/llzKWCrAFtPAYBhMrvwHcVNM/emacs-29.1.scm > |
2023-08-02 | [00:22:45] <alphapapa[m]> That's what I came up with (mass-copied the use-modules lines to get it to work), and it seems to work. |
2023-08-02 | [00:23:27] <alphapapa[m]> Ah, well, I copied the "emacs" package rather than the emacs-next one |
2023-08-02 | [00:24:17] <alphapapa[m]> nckx: Anyway, thanks for your help today. |
2023-08-02 | [00:25:15] <alphapapa[m]> Yeah, I haven't gotten that deep into Guix development yet. Maybe someday. :) |
2023-08-02 | [00:26:36] <nckx> alphapapa[m]: Thanks for not taking my Matrix grumbling the wrong way. I'm still going to try ement, just not today. |
2023-08-02 | [00:27:05] <alphapapa[m]> haha, no problem. Matrix has its quirks and problems, that's for sure. I do think it's a pretty good system overall, which is why I've been developing a client for it. |
2023-08-02 | [00:27:47] <alphapapa[m]> what client do you use? |
2023-08-02 | [00:28:46] <alphapapa[m]> BTW, looking at #65000... did you really do that 3 days ago? If only I had seen that sooner... |
2023-08-02 | [00:29:30] <nckx> alphapapa[m]: No, I forge my commit dates. Nobody seemed to care until recently. |
2023-08-02 | [00:30:09] <alphapapa[m]> nckx: I can't tell if you're joking :) |
2023-08-02 | [00:30:45] <alphapapa[m]> why do you forge the dates then? |
2023-08-02 | [00:32:16] <alphapapa[m]> hmm, okay, yeah... |
2023-08-02 | [00:32:56] <alphapapa[m]> I have occasionally considered that when I'm up late hacking and committing and pushing that I'm sort of scribing in virtual stone that I was doing something at that time |
2023-08-02 | [00:34:29] <alphapapa[m]> /shrug/ They're trying to do a hard thing, to develop a next-gen comm protocol sustainably and effectively and quickly. I try to give them a lot of leeway, because I appreciate what they've accomplished. |
2023-08-02 | [00:34:40] <nckx> alphapapa[m]: Yeah. I'm generally pretty open on the Internet, but the real-time activity log was a problem. |
2023-08-02 | [00:34:59] <alphapapa[m]> not sure what you're referring to |
2023-08-02 | [00:35:06] <alphapapa[m]> oh, that, right |
2023-08-02 | [00:40:17] <alphapapa[m]> right |
2023-08-02 | [00:40:28] <alphapapa[m]> so how do you forge the dates? manually, or do you have some kind of noise-adding script? |
2023-08-02 | [00:42:48] <alphapapa[m]> interesting |