Package Details: hyprland-git 0.48.0.r53.ge76f2776-1

Git Clone URL: https://aur.archlinux.org/hyprland-git.git (read-only, click to copy)
Package Base: hyprland-git
Description: Hyprland is an independent, highly customizable, dynamic tiling Wayland compositor that doesn't sacrifice on its looks
Upstream URL: https://github.com/hyprwm/Hyprland
Licenses: BSD-3-Clause, BSD-2-Clause
Conflicts: hyprland
Provides: hyprland, wayland-compositor
Submitter: hertog
Maintainer: Vaxry (zjeffer, alba4k)
Last Packager: alba4k
Votes: 94
Popularity: 2.14
First Submitted: 2022-04-12 20:26 (UTC)
Last Updated: 2025-04-07 18:23 (UTC)

Required by (68)

Sources (2)

Latest Comments

« First ‹ Previous 1 .. 26 27 28 29 30 31 32 33 34 35 36 .. 39 Next › Last »

Frontear commented on 2023-09-28 22:55 (UTC) (edited on 2023-09-28 22:58 (UTC) by Frontear)

Honestly it shouldn't matter if the man pages are outdated or not, its part of the source and PKGBUILD's should be building the source as close to accuracy as possible. On the vein of the repo package, it's also wrong because it also lacks the portal conf file described below.

Doesn't that belong to xdg-desktop-portal-hyprland?

No, I'm referring to a file that it meant to be installed in /usr/share/xdg-desktop-portal/hyprland-portals.conf (see L72 of the Makefile in the repo). This file tells xdg-desktop-portal the preferred portal that Hyprland wants to use, fixing an age old bug where other portals would conflict under Hyprland. Your PKGBUILD does not include it at all.

I just don't understand why both yours and the repos PKGBUILD is so unbelievably complicated. The actual build instructions are simple, but for some reason both your PKGBUILD and the repo one rewrite the entire Makefile instructions manually, creating a hell of a PKGBUILD to maintain.

<deleted-account> commented on 2023-09-27 18:20 (UTC)

does not correctly build the package, missing man pages and xdg-portal preference configuration

Cannot reproduce, can you try cleanbuild?

missing man pages

The upstream man page is very incomplete/outdated (hasn't changed in a year), the hyprland package in the repo doesn't contain them either.

and xdg-portal preference configuration

Doesn't that belong to xdg-desktop-portal-hyprland?

<deleted-account> commented on 2023-09-23 14:16 (UTC)

This is only a build script, such problems should be reported upstream.

n0mm4d commented on 2023-09-23 13:47 (UTC)

The last update broke this package and it doesn't open the session on GDM anymore, I'm using the Nvidia driver, and until now, it has been working correctly.

<deleted-account> commented on 2023-08-19 20:15 (UTC)

I tested with wolfpld/tracy in the source array and prepare(). It seems to build. Here is the patch if you are interested.

From 629b7b214d3ac5e10f1ec9af766f616b27aff949 Mon Sep 17 00:00:00 2001
From: memchr <memchr@proton.me>
Date: Sat, 19 Aug 2023 19:29:25 +0000
Subject: [PATCH] include tracy in submodules

---
 PKGBUILD | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/PKGBUILD b/PKGBUILD
index 158f7d3..d31f39a 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -57,8 +57,10 @@ conflicts=(hyprland)
 source=("git+https://github.com/hyprwm/Hyprland.git"
         "git+https://gitlab.freedesktop.org/wlroots/wlroots.git"
         "git+https://github.com/hyprwm/hyprland-protocols.git"
-        "git+https://github.com/canihavesomecoffee/udis86.git")
+        "git+https://github.com/canihavesomecoffee/udis86.git"
+        "git+https://github.com/wolfpld/tracy")
 b2sums=('SKIP'
+        'SKIP'
         'SKIP'
         'SKIP'
         'SKIP')
@@ -69,6 +71,7 @@ prepare() {
   git config submodule.wlroots.url                        "$srcdir/wlroots"
   git config submodule.subprojects/hyprland-protocols.url "$srcdir/hyprland-protocols"
   git config submodule.subprojects/udis86.url             "$srcdir/udis86"
+  git config submodule.subprojects/tracy.url              "$srcdir/tracy"
   git -c protocol.file.allow=always submodule update

   make fixwlr
-- 
2.41.0

<deleted-account> commented on 2023-08-19 19:28 (UTC)

wolfpld/tracy has been added as a submodule, should it also be added to the source array in PKGBULD?

FabioLolix commented on 2023-07-08 10:46 (UTC)

I don't take everything namcap says as gospel, in gitui-git that's likely due to mass substitution of ${pkgname} with ${pkgname%-git}

eclairevoyant commented on 2023-07-08 10:42 (UTC)

The wiki says one thing, TUs do another.

namcap says that too

namcap is full of garbage, I've seen it say bash scripts don't need bash, it has a stupid way of checking for RELRO as well, and it can't even detect when the package itself contains a given library (so it complains that the package is missing itself). It's a diaper to prevent users from crapping all over the AUR. It is not the canonical reference for whether a package is correct; generally common sense and also proper analysis of the upstream code is needed.

Btw, if you're taking namcap as gospel, it's a bit ironic that a maintainer for namcap (who has also made most of the commits in the last few years) would also make such a commit as the one I linked below for gitui-git ;)

FabioLolix commented on 2023-07-08 10:29 (UTC)

The PKGBUILD guidelines refer to the general case and I don't think they account for the VCS case accurately. It seems like there is little to no consistency as to whether licenses are installed in $pkgname vs ${pkgname%-VCS}

That says twice that need to go in "$pkgdir/usr/share/licenses/${pkgname}" , namcap says that too

I just saw an example of the latter by one of the TUs in gitui-git.

That need to be corrected, just commented

docs and other stuff can go in ${pkgname%-VCS} or usual location

eclairevoyant commented on 2023-07-08 07:40 (UTC)

The PKGBUILD guidelines refer to the general case and I don't think they account for the VCS case accurately. It seems like there is little to no consistency as to whether licenses are installed in $pkgname vs ${pkgname%-VCS}. I just saw an example of the latter by one of the TUs in gitui-git.

To me it makes more sense to use ${pkgname%-VCS} because it aligns with the program/binary/package naming irrespective of whether it is the VCS version or not. It also is more consistent with where the config, docs, and libraries are located, otherwise we are just scattering files on the system

« First ‹ Previous 1 .. 26 27 28 29 30 31 32 33 34 35 36 .. 39 Next › Last »