bug#43277: [PATCH] gnu: emacs-next: Fix load path and version
Hello guix-devel, I fear this patch may get lost (as it has not received feedback since I posted it on Sept 14th (ok maybe I'm just being impatient but I'd like to think emacs-next is an important package)) so I've decided to post it in guix-devel. While I'm here I might as well add some much needed information. The emacs-next package has been broken since it was re-added on August 31st. It was added by me so this my fault. It's broken because the EMACSLOADPATH environment variable only contains the lisp location for your user profile and doesn't include the lisp bundled with emacs-next. If you have emacs and emacs-next installed at the same time, emacs-next appears to work as expected because it's using the lisp installed with emacs. I'm not sure if there is a way to make sure people only install emacs or emacs-next, but you should only install one. I created the below patch on Sept 14th, and have been using it daily since then with no issues. The version goes from 28.0.50.1 to 28.0.50. The "1" is the build number which gets incremented every time you run "make" (so not actually part of the version). Also it's important to get the version correct as I use it to refer to the binary. When we copy the binary in 'string-double-wrap, I've decided to just string split on #\-. This is remove the end of the git-version string so we're left with just 28.0.50. I need to copy the native-search-paths section from emacs and place it into emacs-next. It would be cooler if the native-search-paths sections was thunked so I could pull the this-package trick again to get the right version, but I think this is the only way. Thanks, Morgan morgan.j.sm...@outlook.com writes: > From: Morgan Smith > > * gnu/packages/emacs.scm (emacs): > [strip-double-wrap] Modify to work with emacs-next > > * gnu/packages/emacs.scm (emacs-next): > [version] Change version from 28.0.50.1 to 28.0.50 > [arguments] Removed field > [native-search-paths] New field > --- > > The problem turned out to be that EMACSLOADPATH wasn't being set > properly. This patch fixes that. > > > > gnu/packages/emacs.scm | 37 - > 1 file changed, 16 insertions(+), 21 deletions(-) > > diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm > index 03c28ee7a7..b3d099257d 100644 > --- a/gnu/packages/emacs.scm > +++ b/gnu/packages/emacs.scm > @@ -196,11 +196,12 @@ > (lambda* (#:key outputs #:allow-other-keys) > ;; Directly copy emacs-X.Y to emacs, so that it is not wrapped > ;; twice. This also fixes a minor issue, where WMs would not be > - ;; able to track emacs back to emacs.desktop. > + ;; able to track emacs back to emacs.desktop. It's done using > + ;; this-package so emacs-next can reuse it > (with-directory-excursion (assoc-ref outputs "out") > (copy-file (string-append > "bin/emacs-" > - ,(version-major+minor (package-version emacs))) > + ,(car (string-split (package-version > this-package) #\-))) >"bin/emacs") > #t))) > (add-before 'reset-gzip-timestamps 'make-compressed-files-writable > @@ -279,11 +280,10 @@ languages.") > > (define-public emacs-next >(let ((commit "2ea34662c20f71d35dd52a5ed996542c7386b9cb") > -(revision "0") > -(emacs-version "28.0.50.1")) > +(revision "0")) > (package/inherit emacs >(name "emacs-next") > - (version (git-version emacs-version revision commit)) > + (version (git-version "28.0.50" revision commit)) >(source > (origin > (inherit (package-source emacs)) > @@ -295,24 +295,19 @@ languages.") > (sha256 >(base32 > "0igjm9kwiswn2dpiy2k9xikbdfc7njs07ry48fqz70anljj8y7y3" > - (arguments > - (substitute-keyword-arguments (package-arguments emacs) > - ((#:phases phases) > - `(modify-phases ,phases > - (replace 'strip-double-wrap > - (lambda* (#:key outputs #:allow-other-keys) > - ;; Directly copy emacs-X.Y to emacs, so that it is not > wrapped > - ;; twice. This also fixes a minor issue, where WMs would > not be > - ;; able to track emacs back to emacs.desktop. > - (with-directory-excursion (assoc-ref outputs "out") > - (copy-file (string-append > -
bug#43277: [PATCH] gnu: emacs-next: Fix load path and version
Hi Pierre, Thanks for the feedback! Pierre Langlois writes: > I agree in general it's good to reuse code, however in this particular > case it's probably better to keep the phases duplicated. For example, > in the future one could update the emacs-next package to not require a > revision number anymore, and it's likely they'd forget to update the > emacs package since it'll still work. > > Does that make sense? It might be just a matter of taste, I don't have a > super strong opinion on this. It's important to realize that this is what caused the current problem to begin with so in a way I agree. However, I think there is a big difference between code that fails silently, and code that fails loudly. The native search paths failed "silently" since the package still built and even appeared to work (since the normal emacs with in my path). copy-file, thankfully, fails very loudly since the package simply won't build if it can't find the file to move. Plus the error message is quite good (It can't find the file). For this reason, it's likely a good thing that the native search paths code is duplicated, but I think the stip-double-wrap phase should be reused. Thanks, Morgan
bug#47325: newlib-nano: are lib names wrong?
Hello Nicolò,
This is definitely a bug that I encountered today. I'm convinced it's a
bug because I came across this page that says so:
https://newlib.sourceware.narkive.com/kfT8XDEe/building-libc-nano-and-libg-nano
The git repo it links to has the following shell function. I think we
should emulate its behavior.
(On a slightly unrelated note, can someone PLEASE accept my patch in bug
44750 for a different arm-none-eabi issue. It's desperately needed.)
copyNanoLibraries() {
(
source="${1}"
destination="${2}"
messageA "\"nano\" libraries copy"
multilibs=$("${destination}/bin/${target}-gcc" -print-multi-lib)
sourcePrefix="${source}/${target}/lib"
destinationPrefix="${destination}/${target}/lib"
for multilib in ${multilibs}; do
multilib="${multilib%%;*}"
sourceDirectory="${sourcePrefix}/${multilib}"
destinationDirectory="${destinationPrefix}/${multilib}"
mkdir -p "${destinationDirectory}"
cp "${sourceDirectory}/libc.a"
"${destinationDirectory}/libc_nano.a"
cp "${sourceDirectory}/libg.a"
"${destinationDirectory}/libg_nano.a"
cp "${sourceDirectory}/librdimon.a"
"${destinationDirectory}/librdimon_nano.a"
cp "${sourceDirectory}/libstdc++.a"
"${destinationDirectory}/libstdc++_nano.a"
cp "${sourceDirectory}/libsupc++.a"
"${destinationDirectory}/libsupc++_nano.a"
done
mkdir -p "${destination}/${target}/include/newlib-nano"
cp "${source}/${target}/include/newlib.h"
"${destination}/${target}/include/newlib-nano"
if [ "${keepBuildFolders}" = "n" ]; then
messageB "\"nano\" libraries remove install folder"
maybeDelete "${top}/${buildNative}/${nanoLibraries}"
fi
)
}
bug#46496: Bug closed
Hello! Thank you for reporting this bug. This bug was fixed in commit 8799369983315d799501b4f45a3954195b630ebb made on April 8th. You are correct that libc_nano.a should be for newlib-nano and libc.a should be for newlib. However, in the nano toolchain, both libc.a and libc_nano.a (which was recently added) are used for newlib-nano. In the future, we should combine the nano and non-nano toolchain together so that it matches up with your (correct) intuition of what should be where. But that is a job for another day. Thanks, Morgan
bug#57742: QT plugins from profile not found (QT_PLUGIN_PATH)
Hello! Ever since commit 1f466ed6be932526fc69e72ffd50390691d0d382 we don't look at the user's value of QT_PLUGIN_PATH. The comment says this is to prevent plugin confusion between Qt5 and Qt6 stuff. This is very unfortunate for me. I have qtwayland (qt5) installed in my profile so QT programs can find the wayland plugin they need to display themselves on wayland. Unfortunately, they no longer can. Maybe we could make our own Guix environment variables like GUIX_QT5_QT_PLUGIN_PATH and GUIX_QT6_QT_PLUGIN_PATH and then add those to the wrapper? So like qtwayland would set GUIX_QT5_QT_PLUGIN_PATH and then the wrapper in qt-utils.scm could read that? Just an idea, I have no clue what a good solution for this issue looks like. Thanks, Morgan
bug#59185: Trouble mounting recursive file systems in containers
Hello! So I was trying to mount /run/user/1000 in a container so it would have access to all my wayland sockets and such when I got a very cryptic error message. I was trying something like this: guix shell --share=/run/user/1000 -C coreutils After far too long tracking down the issue, it turns out that the directory had submounts within it meaning that the MS_REC flag is required to bind mount it. My /run/user/1000 only had a submount because xdg-document-portal was making one. To test this yourself you can run `mount` to find something with some submounts. I think /sys/fs might fail for me for the same reason. Now I have no clue what we should do to enable this use case. Maybe we should allow users to specify mount options using something like this? guix shell -C --mount=rbind,ro=/run/user/1000 Maybe we could always bind with the recursive flag? Thanks, Morgan
bug#49353: INFOPATH and MANPATH not set in profiles
MANPATH is set by the man-db package, and /etc/profile. INFOPATH is set by the emacs package, the texinfo package, and /etc/profile. /etc/profile sets the variables as such: export MANPATH=$HOME/.guix-profile/share/man:/run/current-system/profile/share/man export INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info This means if I use multiple profiles, and I don't have `(and man-db (or emacs texinfo))` in each profile, then I can't access the info and man files using the info and man commands. For example: Fails to find man page guix environment --ad-hoc neovim man nvim Finds man page just fine guix environment --ad-hoc man-db neovim man nvim
bug#37876: Regression in MAKE-GCC-TOOLCHAIN after core-updates merge
I tried this today as of commit 49d19b35cebd749510b7773d76a3a96d1358 and it seems to build. Are you still experiencing this issue? Morgan
bug#65508: Displaying qt applications on wayland using qtwayland is complicated
Hello guix! Before I get into the actual bug I'm trying to report, I have to bring up 2 other complications. 1. qtwayland@6 currently doesn't build due a test failure. So in this bug I'm either using "--without-tests=qtwayland" on the command line or "((options->transformation '((without-tests . "qtwayland"))) qtwayland)" in manifests. 2. The way we deal with multiple package versions in a profile is really weird. "guix shell package@1 package@2" works as expected (both versions available). "guix install package@1 package@2" silently installs only the newer one. Putting package@1 and package@2 in a manifest yields: "error: profile contains conflicting entries for package" OK with that out of the way, onto my actual bug report: I use wayland. I also use some qt applications. For a qt application to display on wayland it either needs the qtwayland plugin available, or it can use some x11 fallback thingy. The qtwayland plugin is the way I'd like my qt applications to render. Some applications include qtwayland in their inputs like okular and work fine out of the box. Most applications (like openscad and jami) do not. This is fine because we can simply install qtwayland into our profile. Not everyone uses wayland so this actually seems like the appropriate thing to do. Unfortunately, openscad uses qtwayland@5 and jami uses qtwayland@6. Due to the above explained complication, I cannot simply install both into my profile. We could make qtwayland@5 and qtwayland@6 into two completely different packages and that would solve my problem. Doing "guix shell qtwayland@5 qtwayland@6 qtbase" (jami wants qtbase for some reason), allows me to run both openscad and jami. So clearly qtwayland@5 and qtwayland@6 don't interfere with each other. Of course the more user friendly option would be to simply add the appropriate qtwayland to the inputs of a package using the qt-build-system. Or maybe even make it propagated from qtbase somehow? guix size qtwayland@5 = 1203.1 MiB guix size qtbase@5 = 1171.5 MiB guix size qtwayland@6 = 1271.7 MiB guix size qtbase@6 = 1190.2 MiB Well if I understand how "guix size" works, then adding qtwayland would only add 30 or 80 MiB, which in my opinion isn't a lot. My vote is on just adding qtwayland to all wayland packages (at the cost of a full qt rebuild).
bug#65510: Errors trying to use home-dicod-service-type and home-syncthing-service-type
Hello guix!
Thank you Ludovic for adding a way to map system services to home
services! This is very exciting. However, I can't seem to use some of
those services.
Take a look at this minimal example home configuration:
--8<---cut here---start->8---
(use-modules (gnu services)
(gnu home services dict)
(gnu home services syncthing)
(gnu home services mcron))
(home-environment
(services
(list
;; guix home: error: no target of type 'system' for service 'profile'
(service home-dicod-service-type)
;; guix home: error: no target of type 'system' for service 'profile'
(service home-syncthing-service-type)
;; works great!
(service home-mcron-service-type
--8<---cut here---end--->8---
Am I doing something wrong? Both the dicod and syncthing services give
me an error when running "guix home build". The mcron service works
fine though even though it is built using the same "for-home" stuff.
I'm not that comfortable with debugging services and I don't really know
where to start.
I used the "guix repl" to print out "(service home-dicod-service-type)"
and got this:
--8<---cut here---start->8---
$1 = #< type: # value:
#< dico: # interfaces: ("localhost") handlers: () databases:
(#< name: "gcide" handler: "gcide" complex?: #f options:
(# #) (invoke
# "/libexec/idxgcide">:out> #
"/share/gcide">:out> #)) gnu/services/dict.scm:83:19
7f16dc1101b0> guile: #f options: (#:local-build? #t)>:out>)
gnu/services/dict.scm:95:18 7f16dc110120>)>) home-service?: #t>>
--8<---cut here---end--->8---
bug#76697: gdk-pixbuf GDK_PIXBUF_MODULE_FILES search path breaks some packages
I tried to reopen this bug instead of making a new one but I guess it's
archived or something? bug#75795
Changing the search-path-specification of gdk-pixbuf has broken the
build of transmission as this phase now errors out:
=
(wrap-program (string-append #$output:gui "/bin/transmission-gtk")
;; Wrapping GDK_PIXBUF_MODULE_FILE allows Transmission to load
;; its own icons in pure environments.
`("GDK_PIXBUF_MODULE_FILE" =
(,(getenv "GDK_PIXBUF_MODULE_FILE"
=
Doing a quick search it looks like there at least 10 packages that need
to be adjusted
