Hyprpm: Headers corrupted. pkexec returned: You need to run make all first.

Question

Hyprpm: Headers corrupted. pkexec returned: You need to run make all first.

10kmotorola opened this issue a year ago · 30 comments

10kmotorola commented a year ago

Hyprland Version

Hyprland, built from branch main at commit 5f65946 dirty

Bug or Regression?

Bug

Description

i followed the steps to fix #4108, but when doing hyprpm update it fails to fix the headers. it states i need to run make all first, but its been months since i installed plugins manually and i honestly don't remember where to do this. if this is an easy fix and im just stupid i apologize

How to reproduce

sudo rm -rf /usr/include/hyprland
hyprpm update

Crash reports, logs, images, videos

log.txt

Answer 1 · 2023-12-28T21:14:14.000Z

that's odd. Can you give the log of hyprpm update -v?

Answer 2 · 2023-12-28T21:27:56.000Z

is that not what I attached in the initial post or are you asking for something different?

Answer 3 · 2023-12-28T21:35:38.000Z

right my bad

Answer 4 · 2023-12-28T21:37:28.000Z

uhh can you clone the source manually, run cmake --no-warn-unused-cli -DCMAKE_BUILD_TYPE:STRING=Release -S . -B ./build -G Ninja in it and see if it doesn't fail by chance?

Answer 5 · 2023-12-28T22:23:02.000Z

seemed to have built fine:
log.txt

Answer 6 · 2023-12-28T23:00:23.000Z

it's not built, it's configured, but yeah. That's odd.

Answer 7 · 2023-12-28T23:26:25.000Z

any idea what it might be?

Answer 8 · 2023-12-28T23:27:55.000Z

no clue. Hyprpm just runs standard commands in the background. See the source, try running the commands manually, see what's broken, I guess.

Answer 9 · 2024-01-27T12:06:38.000Z

uhh can you clone the source manually, run cmake --no-warn-unused-cli -DCMAKE_BUILD_TYPE:STRING=Release -S . -B ./build -G Ninja in it and see if it doesn't fail by chance?

For me it's not even configuring on fedora. I have all the deps installed, and it's not able to find any of them... Annoying.

-- Gathering git info
CMake Error at CMakeLists.txt:30 (add_subdirectory):
  The source directory

    /tmp/Hyprland/subprojects/udis86

  does not contain a CMakeLists.txt file.


-- Setting up wlroots
-- Found WaylandScanner at WaylandScanner-NOTFOUND
-- Found wayland-protocols at
-- Configuring Hyprland in Release with CMake
-- Checking deps...
-- Found OpenGL: /usr/lib64/libOpenGL.so
-- Checking for modules 'wayland-server;wayland-client;wayland-cursor;wayland-protocols;cairo;libdrm;xkbcommon;libinput;pango;pangocairo;pixman-1'
--   Package 'wayland-server', required by 'virtual:world', not found
--   Package 'wayland-client', required by 'virtual:world', not found
--   Package 'wayland-cursor', required by 'virtual:world', not found
--   Package 'wayland-protocols', required by 'virtual:world', not found
--   Package 'cairo', required by 'virtual:world', not found
--   Package 'xkbcommon', required by 'virtual:world', not found
--   Package 'libinput', required by 'virtual:world', not found
--   Package 'pango', required by 'virtual:world', not found
--   Package 'pangocairo', required by 'virtual:world', not found
--   Package 'pixman-1', required by 'virtual:world', not found
CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:607 (message):
  A required package was not found
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPkgConfig.cmake:829 (_pkg_check_modules_internal)
  CMakeLists.txt:104 (pkg_check_modules)

it's surprisingly difficult to install hyprgrass. Hyprpm is everything but easy to set up.

Answer 10 · 2024-01-27T14:04:18.000Z

Blame your packagers.

For me it's not even configuring on fedora. I have all the deps installed, and it's not able to find any of them... Annoying.

Looks like you didn't clone --recursive. Assuming this is not from hyprpm because 1) it does and 2) it wouldn't clone to /tmp/Hyprland

Answer 11 · 2024-01-27T15:25:11.000Z

Looks like you didn't clone --recursive. Assuming this is not from hyprpm because 1) it does and 2) it wouldn't clone to /tmp/Hyprland

Ah that seems to be one problem at least. It's still not able to find all the deps, but that at least got rid of the first error.
I had to run it manually because, as I said, hyprpm just errors out, doing ... something.

Answer 12 · 2024-01-29T07:32:32.000Z

It seems that the latest update has dealt a fatal blow to hyprpm.

Hyprpm will automatically detect and install header files in /usr/local/include/hyprland path.
But the arch user use the command yay - S hyprland-git installed hyprland header files in /usr/include/hyprland.
So, all arch users having to manually remove /usr/include/hyprland before using hyprpm updates.
There seems to be a bug in the header file detection of hyprpm. Even if you manually delete the previous /usr/include and /usr/local/include header files, and then run hyprpm update, the installation still fails.

Answer 13 · 2024-01-29T07:33:39.000Z

version:

Hyprland, built from branch main at commit 4b4bd90 dirty (renderer: fixup misaligned fsv1 surfaces with uv).
Date: Mon Jan 29 07:42:49 2024

Tag: v0.34.0-79-g4b4bd90b

flags: (if any)

Answer 14 · 2024-01-29T10:06:26.000Z

Oops, will fix in a sec.

Answer 15 · 2024-01-29T10:30:47.000Z

check above.

Answer 16 · 2024-01-29T10:59:29.000Z

It seems that the latest update has dealt a fatal blow to hyprpm.

Hyprpm will automatically detect and install header files in /usr/local/include/hyprland path.
But the arch user use the command yay - S hyprland-git installed hyprland header files in /usr/include/hyprland.
So, all arch users having to manually remove /usr/include/hyprland before using hyprpm updates.

There seems to be a bug in the header file detection of hyprpm. Even if you manually delete the previous /usr/include and /usr/local/include header files, and then run hyprpm update, the installation still fails.

the second issue was fixed, how about the first issue?

I still need to remove /usr/include/hyprland after running 'yay-S hyprland-git' before using hyprpm update.

Why not set the installation path of hyprpm to /usr instead of /usr/local?

@vaxerski

Answer 17 · 2024-01-29T11:04:58.000Z

overwriting system headers is a bad idea and nobody should do it. It can corrupt updates.

For example:

hyprland's headers have a new header, "xyz.h".
hyprpm writes it
user later updates their system headers
pacman: error, cannot update. "xyz.h" exists in the filesystem

Answer 18 · 2024-01-29T11:11:32.000Z

overwriting system headers is a bad idea and nobody should do it. It can corrupt updates.

For example:

hyprland's headers have a new header, "xyz.h".

hyprpm writes it

user later updates their system headers

pacman: error, cannot update. "xyz.h" exists in the filesystem

The user had to delete /usr/include/hyprland themselves, otherwise hyprpm update could not be used,

so now the system header file is not only overwritten but also needs to be deleted.

That doesn't sound like a good idea either...

Answer 19 · 2024-01-29T11:18:25.000Z

if system headers are up-to-date, no errors should occur.

I have said that elsweyr and will say it again, what to do when system headers are outdated is a question that needs thought and thinking through, both of which I am not very able to do right now

Answer 20 · 2024-01-29T12:19:44.000Z

if system headers are up-to-date, no errors should occur.

I have said that elsweyr and will say it again, what to do when system headers are outdated is a question that needs thought and thinking through, both of which I am not very able to do right now

Isn't it better this way:

Allow the /usr/include/hyprland path to be used. When this path is detected, remind the user to use 'yay -S hyprland-git' to update the header file, which can also ensure that the version of Hyprland execution file and header file is consistent.
If /usr/include/hyprland does not exist, hyprpm manages and installs the header file to /usr/local

Answer 21 · 2024-01-29T14:17:03.000Z

so what you are saying is that if we have system headers already, and they are mismatched, hyprpm should refuse to run?

Answer 22 · 2024-01-29T14:25:54.000Z

so what you are saying is that if we have system headers already, and they are mismatched, hyprpm should refuse to run?

It seems that if there is a system header,hyprpm will refuse to run until the user manually deletes the system header now.

So either the policy I proposed above or the current one,hyprpm is not allowed to run if there is a system header.

The only difference is that what I mentioned above is reminding the user to update, rather than forcing the user to delete the system header.

Answer 23 · 2024-03-01T02:41:01.000Z

(I'm not sure if this relates to this issue, but it's the closest one to the problem i had and since it's still open, i figured i'd post it here, sorry if this doesn't help)

the first time i tried updating hyprpm (first time using hyprland) i got a very similar issue. I unfortunately did not save the logs. The only difference i remember is the error code being 2 instead of 3 (The "You need to run make all first" part was the same). after a while i uninstalled cmake (I did not know hyprpm required it) and tried updating again. This time i got these error messages

[v] cmake returned: sh: line 1: cmake: command not found
[v] meson returned: sh: line 1: meson: command not found

I then installed both packages and got a little further. This time the error was:

/bin/sh: line 1: cpio: command not found

And after installing cpio, the update completed with no errors

So, it seems the issue here is that hyprpm does not warn you if don't have cmake, meson and cpio installed

full log: hyprland-log.txt

Answer 24 · 2024-03-01T02:45:29.000Z

and apprently the "Command not found" messages only appear if cmake is not installed. If it is, the errors messages for meson and cpio are hidden

Answer 25 · 2024-03-01T03:49:05.000Z

@vaxerski see my messages above. Sorry if this is unrelated to the issue.

Answer 26 · 2024-03-01T13:36:48.000Z

I think this can be closed cuz how we store headers has changed since

Answer 27 · 2024-03-01T13:47:06.000Z

well I ran into a similar issue again recently. It wouldn't even start compiling and errored out at the command that uses "*.h", apparently unable to find anything. No idea why but hyprpm definitely still has its issues... :/

Answer 28 · 2024-03-01T13:48:48.000Z

nothing's perfect

Answer 29 · 2024-03-01T15:35:26.000Z

what about warning the user if one of the required packages is not installed? In the arch repos meson, cpio and cmake are listed as optional dependencies, and imo it should stay like that, but there should be at least a warning if they're not installed.

Answer 30 · 2024-03-01T20:08:01.000Z

feel free to MR or open an issue for that