hyprwm
Can't hyprpm update
Hyprland Version
System/Version info
Hyprland, built from branch at commit cba1ade848feac44b2eda677503900639581c3f4 (props: bump version to 0.40.0).
Date: Sat May 4 15:42:32 2024
Tag: v0.40.0, commits: 4606
flags: (if any)
System Information:
System name: Linux
Node name: Oscarounet
Release: 6.9.1-arch1-2
Version: #1 SMP PREEMPT_DYNAMIC Wed, 22 May 2024 13:47:07 +0000
GPU information:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [1002:67df] (rev e7) (prog-if 00 [VGA controller])
os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo
plugins:
Bug or Regression?
Regression
Description
Can't hyprpm update :
$ hyprpm update -v
[v] version returned: Hyprland, built from branch at commit cba1ade848feac44b2eda677503900639581c3f4 (props: bump version to 0.40.0).
Date: Sat May 4 15:42:32 2024
Tag: v0.40.0, commits: 4606
flags: (if any)
[v] parsed commit cba1ade848feac44b2eda677503900639581c3f4 at branch on Sat May 4 15:42:32 2024, commits 4606
! Cloning https://github.com/hyprwm/hyprland, this might take a moment.
[v] will shallow since: sam. avril 27 15:42:32 2024
╍━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0 / 5 Cloning the hyprland repository
✖ Could not clone the hyprland repository. shell returned:
Clonage dans 'hyprland-quelquun'...
fatal : error when processing superficiality information : 4
How to reproduce
Type the hyprpm update command, on hyprland stable arch, with hyprland-plugins
Crash reports, logs, images, videos
I did all my yay -Syu and sudo pacman -Syu
If you're using hyprland from the official Arch repo, then you can do something like this:
cd ~/.local/share/hyprpm/headersRoot
rm -rf include/hyprland
rm share/pkgconfig/hyprland.pc
ln -sf /usr/include/hyprland include/hyprland
ln -sf /usr/share/pkgconfig/hyprland.pc share/hyprland.pc
Hyprpm stopped using system provided hyprland headers because it caused some issues with some distributions, but in Arch the hyprland package provides correct header files, so there's no need to clone them from git. This creates symlinks back to the system provided hyprland headers.
BTW, before you try the solution from my previous comment, can you try running hyprpm like this?
LANG=C hyprpm update -v
1st try
BTW, before you try the solution from my previous comment, can you try running hyprpm like this?
LANG=C hyprpm update -v
Shel returned :
$ LANG=C hyprpm update -v[v] version returned: Hyprland, built from branch at commit cba1ade848feac44b2eda677503900639581c3f4 (props: bump version to 0.40.0). Date: Sat May 4 15:42:32 2024 Tag: v0.40.0, commits: 4606
flags: (if any)
[v] parsed commit cba1ade848feac44b2eda677503900639581c3f4 at branch on Sat May 4 15:42:32 2024, commits 4606
╍━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0 / 5 Cloning the hyprland re! Cloning https://github.com/hyprwm/hyprland, this might take a moment. ╍━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0 / 5 Cloning the hyprland re[v] will shallow since: Sat Apr 27 15:42:32 2024
✔ cloned
[v] git returned (co): Your branch is up to date with 'origin/main'.
[v] git returned (rs): rm 'subprojects/tracy'
HEAD is now at cba1ade props: bump version to 0.40.0
✔ checked out to running ver
! configuring Hyprland
[v] setting PREFIX for cmake to /home/quelquun/.local/share/hyprpm/headersRoot
[v] cmake returned: sh: line 1: cmake: command not found
[v] meson returned: The Meson build system
Version: 1.4.0
Source dir: /tmp/hyprpm/hyprland-quelquun/subprojects/wlroots-hyprland
Build dir: /tmp/hyprpm/hyprland-quelquun/subprojects/wlroots-hyprland/build
Build type: native build
Project name: wlroots
Project version: 0.18.0-dev
C compiler for the host machine: cc (gcc 14.1.1 "cc (GCC) 14.1.1 20240522")
C linker for the host machine: cc ld.bfd 2.42.0
Host machine cpu family: x86_64
Host machine cpu: x86_64
Compiler for C supports arguments -Wundef: YES
Compiler for C supports arguments -Wlogical-op: YES
Compiler for C supports arguments -Wmissing-include-dirs: YES
Compiler for C supports arguments -Wold-style-definition: YES
Compiler for C supports arguments -Wpointer-arith: YES
Compiler for C supports arguments -Winit-self: YES
Compiler for C supports arguments -Wstrict-prototypes: YES
Compiler for C supports arguments -Wimplicit-fallthrough=2: YES
Compiler for C supports arguments -Wendif-labels: YES
Compiler for C supports arguments -Wstrict-aliasing=2: YES
Compiler for C supports arguments -Woverflow: YES
Compiler for C supports arguments -Wmissing-prototypes: YES
Compiler for C supports arguments -Walloca: YES
Compiler for C supports arguments -Wno-missing-braces: YES
Compiler for C supports arguments -Wno-missing-field-initializers: YES
Compiler for C supports arguments -Wno-unused-parameter: YES
Compiler for C supports arguments -fmacro-prefix-map=/prefix/to/hide=: YES
Found pkg-config: YES (/usr/bin/pkg-config) 2.1.1
Run-time dependency wayland-server found: YES 1.22.0
Run-time dependency libdrm found: YES 2.4.120
Run-time dependency xkbcommon found: YES 1.7.0
Run-time dependency pixman-1 found: YES 0.43.4
Library m found: YES
Library rt found: YES
Run-time dependency wayland-protocols found: YES 1.36
Build-time dependency wayland-scanner found: YES 1.22.0
Program /usr/bin/wayland-scanner found: YES (/usr/bin/wayland-scanner)
Has header "linux/dma-buf.h" : YES
Run-time dependency egl found: YES 1.5
Run-time dependency gbm found: YES 24.0.8-arch1.1
Run-time dependency glesv2 found: YES 3.2
Program ./embed.sh found: YES (/tmp/hyprpm/hyprland-quelquun/subprojects/wlroots-hyprland/render/gles2/shaders/./embed.sh)
Dependency pixman-1 found: YES 0.43.4 (cached)
Dependency gbm found: YES 24.0.8-arch1.1 (cached)
Checking for function "gbm_bo_get_fd_for_plane" with dependency gbm: YES
Run-time dependency libudev found: YES 255
Run-time dependency libseat found: YES 0.8.0
Build-time dependency hwdata found: YES 0.382
Run-time dependency libdisplay-info found: YES 0.1.1
Run-time dependency libliftoff found: YES 0.4.1
Run-time dependency libinput found: YES 1.25.0
Run-time dependency xcb found: YES 1.17.0
Run-time dependency xcb-dri3 found: YES 1.17.0
Run-time dependency xcb-present found: YES 1.17.0
Run-time dependency xcb-render found: YES 1.17.0
Run-time dependency xcb-renderutil found: YES 0.3.10
Run-time dependency xcb-shm found: YES 1.17.0
Run-time dependency xcb-xfixes found: YES 1.17.0
Run-time dependency xcb-xinput found: YES 1.17.0
Run-time dependency wayland-client found: YES 1.22.0
Run-time dependency xwayland found: YES 24.1.0
Dependency xcb found: YES 1.17.0 (cached)
Run-time dependency xcb-composite found: YES 1.17.0
Run-time dependency xcb-ewmh found: YES 0.4.2
Run-time dependency xcb-icccm found: YES 0.4.2
Dependency xcb-render found: YES 1.17.0 (cached)
Run-time dependency xcb-res found: YES 1.17.0
Dependency xcb-xfixes found: YES 1.17.0 (cached)
Run-time dependency xcb-errors found: YES 1.0.1
Checking for function "xcb_xfixes_set_client_disconnect_mode" with dependencies xcb, xcb-composite, xcb-ewmh, xcb-icccm, xcb-render, xcb-res, xcb-xfixes, xcb-errors: YES
Configuring config.h using configuration
Configuring version.h using configuration
Configuring config.h using configuration
Message: Patches found. Applying...
Build targets in project: 136
wlroots 0.18.0-dev
drm-backend : YES
x11-backend : YES
libinput-backend: YES
xwayland : YES
gles2-renderer : YES
vulkan-renderer : NO
gbm-allocator : YES
session : YES
xcb-errors : YES
egl : YES
libliftoff : YES
User defined options examples : false renderers : gles2
Found ninja-1.12.1 at /usr/bin/ninja
✔ configured Hyprland
[v] installation will run: sed -i -e "s#PREFIX = /usr/local#PREFIX = /home/quelquun/.local/share/hyprpm/headersRoot#" /tmp/hyprpm/hyprland-quelquun/Makefile && cd /tmp/hyprpm/hyprland-quelquun && make installheaders
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╍━━━━━━━━━ 4 / 5 Installing sources[v] installer returned: You need to run make all first.
make: *** [Makefile:91: installheaders] Error 1
✖ failed to install headers with error code 2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5 / 5 Failed
✖ Headers missing. Please run hyprpm update to fix those.
2nd try
If you're using hyprland from the official Arch repo, then you can do something like this:
cd ~/.local/share/hyprpm/headersRoot rm -rf include/hyprland rm share/pkgconfig/hyprland.pc ln -sf /usr/include/hyprland include/hyprland ln -sf /usr/share/pkgconfig/hyprland.pc share/hyprland.pcHyprpm stopped using system provided hyprland headers because it caused some issues with some distributions, but in Arch the hyprland package provides correct header files, so there's no need to clone them from git. This creates symlinks back to the system provided hyprland headers.
Didn't work
3rd try
Can you update hyprland and try again? I've just merged the fix.
I sudo pacman -Syu but didn't work. I think it's because I'm using hyprland stable. I'll wait a bit :(
I'm using hyprland stable on Arch and I have no issues with hyprpm (I use hy3 installed via hyprpm). Maybe you're missing some build dependencies in your system. I see you don't have cmake installed. Maybe try installing it and try again?
$ sudo pacman -S cmake
résolution des dépendances… recherche des conflits entre paquets…
Paquets (3) cppdap-1.58.0-1 rhash-1.4.4-1 cmake-3.29.3-1
Taille totale installée : 75,10 MiB
:: Procéder à l’installation ? [O/n] O (3/3) vérification des clés dans le trousseau [----------------------------------] 100% (3/3) vérification de l’intégrité des paquets [----------------------------------] 100% (3/3) chargement des fichiers des paquets [----------------------------------] 100% (3/3) analyse des conflits entre fichiers [----------------------------------] 100% (3/3) vérification de l’espace disque disponible [----------------------------------] 100% :: Traitement des changements du paquet… (1/3) installation de rhash [----------------------------------] 100% (2/3) installation de cppdap [----------------------------------] 100% (3/3) installation de cmake [----------------------------------] 100% Dépendances optionnelles pour cmake make: for unix Makefile generator [installé] ninja: for ninja generator [installé] qt6-base: cmake-gui [installé] :: Exécution des crochets (« hooks ») de post-transaction… (1/4) Arming ConditionNeedsUpdate... (2/4) Updating the MIME type database... (3/4) Updating icon theme caches... (4/4) Updating the desktop file MIME type cache... [quelquun@Oscarounet ~]$ hyprpm update
! Cloning https://github.com/hyprwm/hyprland, this might take a moment.
╍━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0 / 5 Cloning the hyprland repository
✖ Could not clone the hyprland repository. shell returned:
Clonage dans 'hyprland-quelquun'...
fatal : erreur lors du traitement de l'information de superficialité : 4
Try again with
LANG=C hyprpm update -v
Last time it helped go further (even though it still failed afterwards). It seems that having git command output messages in French (or rather non-English) may not be what hyprpm expects.
I think the issue is with this line: https://github.com/hyprwm/Hyprland/blob/db5d39a66f1285f78321d953eac398feaedfc63d/hyprpm/src/core/PluginManager.cpp#L450
The execAndGet() call (it wraps the popen() call) tries here to set the LC_TIME to retrieve date and time value, which is then used with the git command to do shallow clone to speed up the cloning process. But I don't think popen works like that. The way the LC_TIME is set for the command here is specific for the shell (for example bash), but popen doesn't start the command it a shell, so the variable is not set here at all. So in the end a system-wide locale is used. In your case it's French.
I think this should be called using /usr/bin/env command.
The second issue is setting the LC_TIME to en_US.UTF-8. There's no guarantee that this locale is present in every system. It's better to use the C locale instead.
So with both changes, this should look like this:
const std::string SHALLOW_DATE =
removeBeginEndSpacesTabs(HLVER.date).empty() ? "" : execAndGet("env LC_TIME=C date --date='" + HLVER.date + " - 1 weeks' '+\%a \%b \%d \%H:\%M:\%S \%Y'");
@vaxerski @fufexan
Continuing on my last comment, I think there's not even a need for using date command to get timestamp for shallow clone. Since version 2.20.1, git supports relative date definition for --shallow-since option. So instead retrieving date 1 week in the past using the date command and using it with git command, you can just do:
git clone --recursive https://github.com/hyprwm/hyprland --shallow-since="1 week ago"
Git 2.20.1 came out 6 years ago, so I think it's rather safe to assume that everyone using hyprland already have a newer version.
Anyway is there a specific reason why the clone is shallowed since 1 week in the past? Can't hyprpm just use --depth option and shallow clone, for example, last 50 commits instead?
we need 1 week before a set timestamp, not 1 week before whenever the command is ran
Ah, yes. That makes more sense. Anyway, setting LC_TIME still needs to be fixed.
Ok, I don't think any changes are necessary in the end. I've just tried hyprpm update from git main and it seems that setting environment variable like that works ok. So I'm sorry for saying it's a bug as it clearly is not. I was in the wrong here.
I'd still change locale from en_US.UTF-8 to C though. But I don't think there's a necessity to create an MR for such a small change. It's going to work anyway, but some commands may print a warning to stderr that locale doesn't exists if it's not generated. It seems that date doesn't do that though (although it may be OS dependent, idk).
same issue on manjaro, not on arch though strangely enough, works fine on arch
same issue on manjaro, not on arch though strangely enough, works fine on arch
seems to just be a out of date package in the manjaro repos, the git version seems to work just fine
I think I need to wait for the next stable release and see what appends. Also, I installed the en_US.UTF-8 stuff but still doesn't work.
I think I need to wait for the next stable release and see what appends. Also, I installed the en_US.UTF-8 stuff but still doesn't work.
I figured out my problem, the extra repos in arch don't have an essential package as a depend for some reason, I think it's called hyprwayland-scanner, and I tried to tell the repo maintainer that it was missing depends, but had issues making an account for some reason
I think I need to wait for the next stable release and see what appends. Also, I installed the en_US.UTF-8 stuff but still doesn't work.
I figured out my problem, the extra repos in arch don't have an essential package as a depend for some reason, I think it's called hyprwayland-scanner, and I tried to tell the repo maintainer that it was missing depends, but had issues making an account for some reason
To be honest, hyprwayland-scanner is a build dependency. If someone doesn't use hyprpm then that package is not needed at all. I think that (at least in ArchLinux) it would be better to package hyprpm separately from hyprland and add hyprwayland-scanner as a dependency to that package. Unfortunately I don't have an account on ArchLinux's GitLab to suggest that and they've disabled registration because of a lot of spam.
I think I need to wait for the next stable release and see what appends. Also, I installed the en_US.UTF-8 stuff but still doesn't work.
I figured out my problem, the extra repos in arch don't have an essential package as a depend for some reason, I think it's called hyprwayland-scanner, and I tried to tell the repo maintainer that it was missing depends, but had issues making an account for some reason
To be honest, hyprwayland-scanner is a build dependency. If someone doesn't use hyprpm then that package is not needed at all. I think that (at least in ArchLinux) it would be better to package hyprpm separately from hyprland and add hyprwayland-scanner as a dependency to that package. Unfortunately I don't have an account on ArchLinux's GitLab to suggest that and they've disabled registration because of a lot of spam.
I whole heartedly disagree, hyprpm is the only official way to get plugins into hyprland, which imo is an integral feature, without plugins hyprland is barley a DE, and especially without hy3 considering there's no obvious way to change the looks of the normal tabs for groups, but I would agree that if hyprwayland-scanner doesn't come with the package then hyprpm should at least be packaged separately with its own depends.
In either case there's a package in the arch repos that is not functional because of missing depends, hopefully one of us gets an account soon to be able to at least tell them that
I think I need to wait for the next stable release and see what appends. Also, I installed the en_US.UTF-8 stuff but still doesn't work.
I figured out my problem, the extra repos in arch don't have an essential package as a depend for some reason, I think it's called hyprwayland-scanner, and I tried to tell the repo maintainer that it was missing depends, but had issues making an account for some reason
To be honest, hyprwayland-scanner is a build dependency. If someone doesn't use hyprpm then that package is not needed at all. I think that (at least in ArchLinux) it would be better to package hyprpm separately from hyprland and add hyprwayland-scanner as a dependency to that package. Unfortunately I don't have an account on ArchLinux's GitLab to suggest that and they've disabled registration because of a lot of spam.
I whole heartedly disagree, hyprpm is the only official way to get plugins into hyprland, which imo is an integral feature, without plugins hyprland is barley a DE, and especially without hy3 considering there's no obvious way to change the looks of the normal tabs for groups, but I would agree that if hyprwayland-scanner doesn't come with the package then hyprpm should at least be packaged separately with its own depends.
In either case there's a package in the arch repos that is not functional because of missing depends, hopefully one of us gets an account soon to be able to at least tell them that
I've requested an account and got one already. I've reported the issue.
I fully agree that the hyprpm is an integral part of the hyprland. But I don't think 100% of hyprland and ArchLinux users use addons for sure or use hyprpm for them (they may choose to go with unsupported AUR route for example). Adding hyprwayland-scanner as a dependency to hyprland would add unnecessary dependency for anyone who doesn't use hyprpm. At the same time I don't think there's anything wrong is separating hyprpm to its own package, as it's going to be built at the same time as hyprland one. Arch's PKGBUILD has ability to create split-packages. This basically means that single PKGBUILD generates separate packages from the same source code, but each of the packages may have its own dependencies. So the hyprpm package would be always synchronized to the hyprland version in the Arch's repositories.
BTW I symlink Arch package provided hyprland headers to .local/share/hyprpm so hyprpm doesn't clone them every time - in this case hyprwayland-scanner is also not needed.
BTW here's the issue I've created in Arch's GitLab: https://gitlab.archlinux.org/archlinux/packaging/packages/hyprland/-/issues/10
I've also linked it back to this issue.
BTW I symlink Arch package provided hyprland headers to
.local/share/hyprpmso hyprpm doesn't clone them every time - in this case hyprwayland-scanner is also not needed.
@vaxerski is there a reason hyprpm doesn't just use the installed hyprland headers? (Can easily be found with pkgconfig)
BTW I symlink Arch package provided hyprland headers to
.local/share/hyprpmso hyprpm doesn't clone them every time - in this case hyprwayland-scanner is also not needed.@vaxerski is there a reason hyprpm doesn't just use the installed hyprland headers? (Can easily be found with pkgconfig)
Isn't it because issues with some distributions, which ship outdated headers or no headers at all? But it could be done in a way, that hyprpm first tries locating the system/package provided headers and fall back to cloning hyprland repo in case of an issue.
One issue I see with system provided headers (even in Arch, which seems to be ok in other circumstances):
Right after running system update (e.g. pacman -Syu), before restarting system (or hyprland at least) the installed headers will be newer than currently running hyrpland. This would cause issue when hyprpm update is run before restarting.
Right after running system update (e.g.
pacman -Syu), before restarting system (or hyprland at least) the installed headers will be newer than currently running hyrpland. This would cause issue when hyprpm update is run before restarting.
There can be an option that doesn't reload plugins if the headers version and the running Hyprland version doesn't match. For greater control we can add a commit field in the pkg-config file.
distro headers are unreliable, thats why. They can also be incorrectly user-supplied (they once built hl manually and installed the headers)