Arch Linux User Repository

@Gio sounds like a problem with your AUR helper. Can you build manually by cloning and running makepkg?

With your AUR helper, I'd recommend clearing its cache, or asking it to cleanbuild the package, if that's an option.

Hi. When attempting to update from v22.04.1-1 to v22.04.3.1-1 , it shows:

Checking yaru-icon-theme dependencies... Resolving dependencies... Checking inter-conflicts...

Building yaru... ==> ERROR: PKGBUILD does not exist.

I'm getting an error when trying to install the dependencies:

error: libsass: signature from "Jerome Leclanche <jerome@leclan.ch>" is unknown trust
:: File /var/cache/pacman/pkg/libsass-3.6.5-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] 
error: sassc: signature from "Jerome Leclanche <jerome@leclan.ch>" is unknown trust
:: File /var/cache/pacman/pkg/sassc-3.6.2-3-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] 
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.
error installing repo packages

Should I fill a bug report here? -> https://archlinux.org/packages/community/x86_64/sassc/

Edit: Removing some keys and running sudo pacman-key --populate archlinux fixed it.

@Remedan you're using eCryptFS? It has a 143 character filename limit.

If you scroll down/click onto the next page of comments, another user had the same issue when this package was using a git commit as the source - the filenames all had a full git hash in them which made them very long.

That's no longer the case, but there are nontheless filenames bumping up against the limit.

Not a whole lot this PKGBUILD can do about that unless there's some flags we can pass to whatever component of the build process makes those horrendous filenames, telling it to do something else. Anybody know which build tool is responsible for the .cache___aurutils___sync___yaru___src___ type filenames with slashes replaced with underscores, storing a full path in a single filename?

The underlying issue is that that tool and eCryptFS are not playing nice together, since one breaks the assumptions of the other.

I'm using aurutils to manager AUR packages. It builds packages in ~/.cache/aurutils/sync. This results in the following error:

ninja: error: stat(gnome-shell/src/___home___remedan___.cache___aurutils___sync___yaru___src___yaru-21.10.1___gnome-shell___src___gnome-shell-sass___widgets____network-dialog.scss): File name too long

A workaround that worked for me is to move ~/.cache/aurutils/sync/yaru under a shorter path and then symlink it back.

@JoveYu the mixed theme has been removed due to poor toolkit support:

https://github.com/ubuntu/yaru/pull/2922

The next version of Ubuntu won't have it either.

this package contains two theme yarn and yarn-dark,is there a theme using light content and dark title? just like ubuntu default.

With Yaru tagging 21.10.1, This package is now back to official releases instead of a git commit.

@coxackie this package is for stable releases generally - it was only pointed at a git commit since no stable release supported gnome 40 yet, but that should be a once off.

Unless it's actually broken on Arch due to other packages here updating ahead of Yaru's release cycle (is that the case with gtk4?) I think its best to stick with official releases.

Those who want goodies can use yaru-git :)

@chrisjbillington there seems to be a lot of movement in the master branch of yaru lately with gtk4 commits (last one I see is 1dece88568a336b8cf82883ac6843e1113d4c416). Maybe you could update the PKGBUILD to get the latest goodies?

Why does "yaru-gtk-theme" depend on gtk-engine-murrine and, by implication, gtk2? I just realized that yaru-gtk-theme pulls in Gtk2, even though nothing else actually needs gtk2 on my system.

Could gtk-engine-murrine perhaps be turned into an optdepends?

Have applied the workaround to the PKGBUILD for now, since eCryptFS is not uncommon.

eCryptFS can only store filenames of up to 143 characters

@drakkan

touch: cannot touch 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa': File name too long
144

@chrisjbillington Yes, $HOME is encrypted with eCryptFS I'll try the temp fix. EDIT: pkgBuild fix worked. Thanks.-:)

Hi,

please try a script like this:

num=1
while [ true ]
do
   if ! touch $(printf "%${num}s"  | tr ' ' 'a')
   then
       echo $num
       break
   fi
   ((num++))
done

to understand your file name limit. Are you using something like eCryptfs?

@vlatkoB no idea why that's happening. You could shorten the directory like this if you like as a temporary fix until this package starts shipping an official release again (which will have a shorter name owing to not containing a commit hash):

diff --git a/PKGBUILD b/PKGBUILD
index c55a3b1..7170eb4 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -24,7 +24,8 @@ source=("https://github.com/ubuntu/yaru/archive/${_commit}.tar.gz")
 sha256sums=('e2a400527451e33abb44d96b6878514482d008355639add6ab30d6e9b2dd70f3')

 build() {
-  arch-meson $pkgbase-$_commit build
+  mv $pkgbase-$_commit $pkgbase
+  arch-meson $pkgbase build
   meson configure build -Dubuntu-unity=true
   ninja -C build
 }

@chrisjbillington Using ext4

$ df -TH
Filesystem            Type        Size  Used Avail Use% Mounted on
/dev/nvme0n1p3        ext4        388G  326G   46G  88% /home

What filesystem are you using @vlatkoB? 161 characters shouldn't be too much to ask for a filepath on any system I know about.

Obviously the fact that the filepath now contains a commit hash is pushing something over a limit, but I would not expect limits this short (I certainly don't see the problem here on an ext4 filesystem).

I'm receiving this error on upgrade to 21.04.1-3

Found ninja-1.10.2 at /usr/bin/ninja
ninja: error: stat(gnome-shell/src/___home___vlatko___.cache___yay___yaru___src___yaru-b01004d7ca3eb86f2110c5aabecd9fed93ede70f___gnome-shell___src___gnome-shell-high-contrast.scss): File name too long

I've updated this package to pull in the changes so far from the gnome-shell-40 branch of Yaru's github repo (see https://github.com/ubuntu/yaru/pull/2736).

Once there is an official release with gnome 40 support, I'll move this package back to targeting the official release.

The gnome-shell-40 branch seems to work fine on GNOME 3.38 as well.

Looks like my polite nudge on the bugtracker had the desired effect :p

https://github.com/ubuntu/yaru/pull/2736

Once GNOME 40 is here on Arch, if there hasn't been a release of Yaru with GNOME-40 support, I'll include the relevant patch with this package so that it will keep working for us until there is a release.

@coxackie I didn't realise Ubuntu was holding back for a release, I actually assumed Yaru 21.04.1 was designed for GNOME 40 and was pleasantly surprised it "still worked" on 3.38.

But breakage with the shell themes in GNOME 40 seems likely, and it looks like the Yaru devs are planning to sync the relevant changes once GNOME 40 lands in Ubuntu (presumably they mean the in-development Ubuntu 21.10 after 21.04 is released):

https://github.com/ubuntu/yaru/issues/2667

So yeah, shell themes here might be borked until they make those changes.

There's already a GTK 4 theme in the current package, so I think it is intended to work already (though if it's new then rough edges are to be expected).

@chrisjbillington many thanks for the update. Since you have looked closely, I wanted to ask, preemptively, whether the theme will be usable with GNOME 40 and GTK4. I know Ubuntu is holding back until October to update, but these updates will arrive in Arch in a month or so.

Package has been updated for 21.04.1.

There are now metacity and gtksourceview theme packages.

The shell themes have been renamed. They were previously "Yaru" for the light version and "Yaru-dark" for the dark version. They are now "Yaru-light" for the light version" and "Yaru" for the dark version. You'll need to update your selected theme in gnome-tweaks accordingly.

@drakkan if you are happy to leave it to me, I'm figuring out the minor restructuring needed to get this and the -git packages working with the latest changes.

Seems like the changes are the addition of a metacity theme and a gtksourceview theme, which should probably be split off as separate subpackages, and the location/names of the shell themes having changed slightly.

@coxackie I haven't seen any issues like that, no. I installed scummvm just to try, and it didn't segfault. I'm running GNOME under X, perhaps is specific to your WM/DE?

@chrisjbillington ok, thanks, another question: The yaru cursor theme appears to play badly with some apps. For example, scummvm segfaults (something related to libXcursor.so.1) with yaru cursor theme, while it is perfectly fine with adwaita cursor theme. I asked upstream, but they do not see this in Ubuntu. Anyone faves similar problems?

@coxackie it's for the yaru-unity-theme package, without that flag it doesn't build the unity theme.

Maybe this is nitpicking, but what is the reason that -Dubuntu-unity=true is passed in the build system? It is supposed to "build Yaru with Unity assets", but I do not see why this is relevant.

I see some commits in Yaru about syncing with the new release of gnome-shell. Last time this package was updated out of sync with gnome-shell there were some issues, so I think this package should be held back until gnome-shell 3.38 hits the Arch repos.

Please flag Yaru out of date again once gnome-shell 3.38 is in the Arch repos, if I don't update it before you notice.

@snfesh, I'm not seeing the issue on my computer. You might consider reporting a bug upstream.

It occurs to me that the Yaru shell theme, since it is targeting Ubuntu 20.10, might expect gnome-shell 3.38 which is to be released next week. If that's the issue then it might be resolved once we get the new gnome-shell release, and you can downgrade in the meantime.

After update package apps grid has narrow. Shell theme: Yaru-dark Image: https://imgur.com/4be65Ej

@Zwenn76 can you download the source URL [1] via e.g. a web browser? If not, the issue is your network. Perhaps launchpad.net is blocked where you are.

[1] https://launchpad.net/ubuntu/+archive/primary/+files/humanity-icon-theme_0.6.15.tar.xz

@chrisjbillington Sorry for posting in both sites. Still doesn't work for me. I am getting the same error again. I tried several times during the day.

@Zwenn76 works for me. Perhaps the site was down temporarily, have you tried again? In any case if it were broken it would be an issue for the humanity-icon-theme AUR package and not this one, so you should limit your comments to the thread there instead of posting in both.

I get an error downloading sources : humanity-icon-theme

@rhysperry111 it ships a GTK2 theme, so I think so, yes.

If it's not a build-time requirement though we could split the GTK2 theme into a separate subpackage to avoid the dependency for those who don't want it.

Is there a need for a dependency on gtk-engine-murrine? Currently this is the only package on my system that requires it (and therefor gtk2)

Maybe temporary blindness but Is there a xfce window manager theme?

The libsass-related build failure has been resolved in the latest release, so no need to hold back libsass anymore if you were doing so for this package.

@FiNeX yes, see the pinned comment.

You can either downgrade libsass to 3.6.1 (if only temporarily to build this package), or install the -git versions of the packages, as the issue was fixed in a recent commit (though there hasn't been a release with the fix yet).

Hi, the package is still broken due to the libsass 3.6.3 incompatibility.

@covegeary it's due to this issue regarding recent releases of libsass:

https://github.com/ubuntu/yaru/issues/2079

You can downgrade libsass to 3.6.1 and then the build will complete. Until the issue is resolved either in Yaru or libsass, this package won't build.

In libsass 3.6.2 the issue is an indefinite hang with high CPU, in libass 3.6.3 the issue is a long hang and high RAM usage - it will in principle complete if you have enough RAM but will take a long time and most likely exhaust your RAM (I think someone said it exhausted 32GB).

Hopefully it is fixed one way or another!

Trying to install this package leads to CPU-intensive hang on my system. The last few lines from makepkg are:

Found ninja-1.10.0 at /usr/bin/ninja
ninja: Entering directory `build'
[4/23] Generating dark-gtk-3.20-gtk-generated.css with a custom command.

It went overnight with no signs of stopping. Anyone else?

EDIT thanks @chrisjbillington ! Temporarily downgrading libsass for now.

@coxackie, the icon theme inherits humanity, so looks like it should depend on it for now at least.

I'll add it to the git version

Thanks @coxackie, updated.

Not sure why humanity-icon-theme is a dependency - I am not the original maintainer of either package so I didn't make either decision to depend or not depend on it. I'll see if I can find out whether it actually depends on it or not.

@chrisjbillington gnome 3.36 is already rolling out in arch repos. It is safe now to use yaru 20.04.2. quick question: why is humanity icons a dependency for yaru-icon-theme? it is not for the git alternative that you also maintain.

Although there has been a new upstream release (20.04.2), it is based on changes to gnome-shell in the upcoming gnome 3.36 release, and has some minor issues when running on gnome-shell 3.34. So this AUR package should be held at 20.04.1 until gnome 3.36 hits Arch likely in March.

FYI one can now select the gnome-shell theme (dark or light) from gnome-tweaks, so use of yaru-session is optional. The only noticeable difference I see is that yaru-session changes the appearance of the lock screen as well.

(@drakkan I unstickied your comment advising that this was not possible in the previous version)

i am not using login screens or any stuff that manages sessions

so this works fine:

GNOME_SHELL_SESSION_MODE=yaru QT_QPA_PLATFORMTHEME=qt5ct QT_QPA_PLATFORM=wayland XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session

Just a heads up, there are directory layout changes in the upcoming Yaru release that will require changing this PKGBUILD. See yaru-git if you want to copy its PKGBUILD. Furthermore, the shell theme will be selectable in gnome-tweaks from the next release, so using the session will be optional.

If anyone wants to build the dark version of the gnome shell theme, they can add the following prepare() function to the PKGBUILD:

prepare(){
    sed -i  s/light/dark/ yaru/gnome-shell/src/gnome-shell.scss
}

In the long run, Yaru aims to provide a switchable dark/light shell theme:

https://github.com/ubuntu/yaru/issues/1483

@drakkan it is indeed! Thanks

@figue, it should be better now, thank you for your suggestion

@drakkan thanks for these packages.

Only one request: can you hide all these hundreds of thousands lines while building? It's impossible to find anything significant in that huge log.

Thanks!

Why is this package flagged out of date? Can you please remove the flag? the latest release is 19.10.2 https://github.com/ubuntu/yaru/releases

@chrisjbillington thanks for the investigation I reverted to 19.04.3

The overview search bugginess is due to a change to Yaru required to be compatible with an upcoming gnome-shell change. So in gnome-shell 3.34 there will be no problem, unfortunately the 'fix' makes Yaru 19.10.1 buggy on gnome-shell 3.32. Either stick to Yaru 19.04.3 until gnome-shell 3.34 is out as @Mershl has done, or use a gnome-shell package with the required backported changes.

The aur package gnome-shell-performance has the required patch (it is the patch for merge request !110), but it is disabled at the moment, so you have to uncomment it manually for now if you use that package.

The latest release (19.10.1-1) shows icon misplacements and cut strings when searching using the Super-key in Gnome 3.32. Downgrading to 19.04.3 fixes these issues on my system.

@drakkan Still didn't works :( but i found the solutions https://bugs.launchpad.net/ubuntu/+source/yaru-theme/+bug/1832137

@malwareslayer

I just retested and it works fine here. I have the following packages installed

pacman -Q | grep yaru
yaru-gnome-shell-theme 19.04.2-1
yaru-gtk-theme 19.04.2-1
yaru-icon-theme 19.04.2-1
yaru-session 19.04.2-1

To use yaru-gnome-shell-theme you need to choose yaru session using gdm login screen.

To use gtk and icon theme you need to select them in gnome-tweaks

Doesn't work even i changed the session into yaru-session :(

@ribald_om it works fine on my laptop, can you please provide more info? For example the yaru packages installed and the settings in gnome tweak. Do you use the latest gnome-shell or an older version? Thanks

@drakken I set theme to default but an unable to log into Yaru Session or Yaru Session on Wayland. It either lock ups or boots me back to the display manager.

yaru-icon-theme should be depending on humanity-icon-theme, as the theme definition inherits from it.

gnome-shell-theme is not listed in gnome-tweaks, this is as upstream designed the theme.

To use shell theme you need to set the default shell theme in gnome-tweaks and select "Yaru session" in the login screen.

gnome-tweaks no longer lists yaru-gnome-shell-theme after update to 18.10.7-2

@FelixHaller, the upstream build system build all packages, we can separate them after the build as we done.

If a package update trigger the update for all componenets this seems a bug in your aur helper, yay works as expected here, If I remember correctly yaourt had this bug, please let me know if I'm wrong, thanks!

Could you please separate the packages? If I install yaru-icon-theme it builds: icons, gtk, shell, session and sound theme. When updating, every package updates all five components. Therefore the update process builds the same packages several times, with hints that the packages are up-to-date -- reinstalling.

This is a waste of time and resources.

Thanks

@chrisjbillington

should be fixed now:

7670e75a2dab

thanks for reporting

There is an issue with the way this package is built, either with the patch being applied, or with the x and wayland sessions being removed - leading to this bug with ugly buttons in the shell theme:

https://github.com/ubuntu/yaru/issues/1018

If I modify the PKGBUILD to not rm the wayland and x sessions and to not apply the patch, then the shell theme isn't able to be selected from within gnome-tweak, but the ugly buttons problem is resolved by logging into the session from GDM.

It looks like the shell theme maybe isn't designed to be used without the session, though I don't fully understand why.

@drakkan Thanks! Too bad it seems they won't fix it anytime soon!

@amoka, I think this is an upstream issue not a packaging one.

This specific issue seems already reported upstream

https://github.com/ubuntu/yaru/issues/914

Issue with the current directory title color using the non-dark version "Yaru" theme.

Please see image: hXXps://i.imgur.com/0ROtwHZ.png

never used pamac before, just installed and tested, it seems to work fine using this command:

pamac build yaru-gnome-shell-theme

In you output I see "Interrupt.." This generally means that the build was intentionally interrupted (using CTRL+C or similar way to send a SIGINT). I don't see obvious error in the PKGBUILD

Cant build this from pamac

Installing /tmp/pamac-build-gavr/yaru/src/yaru/gtk/src/light/gtk-2.0/assets/combo-entry-rtl-entry.png to /tmp/pamac-build-gavr/yaru/pkg/yaru-gnome-shell-theme/usr/share/themes/Yaru/gtk-2.0/assets Installing /tmp/pamac-build-gavr/yaru/src/yaru/gtk/src/light/gtk-2.0/assets/handle-vert.png to /tmp/pamac-build-gavr/yaru/pkg/yaru-gnome-shell-theme/usr/share/themes/Yaru/gtk-2.0/assets ==> ERROR: package_ya ru-gnome-shell-theme () failed. Interrupt...

Gr8 theme thanx, waiting for more support.

Yaru developers are messing around with the Light/Dark theme, and moved file structure a bit, which breaks your PKGBUILD. The git commit that breaks this PKGBUILD is pull request #816 (7eebdd859a9a774d1e7beed5ebacf6c526b804dc)

Errors (I install {gnome-shell,gtk,icon} together): /usr/share/Yaru-dark/gtk-3.0/assets is both in 'yaru-gnome-shell-theme' and 'yaru-gtk-theme' /usr/share/Yaru-dark/gtk-3.0/gtk.css {error as above} /usr/share/Yaru-dark/index.theme {error as above}

Note that Yaru developers are removing the dark variant during building, and will only enable it after they think it's good. Technical details are above me, though, sadly.

EDITv2: For now, I added 'rm -r "$pkgdir/usr/share/themes/Yaru-dark" to package_yaru-gnome-shell-theme(), since it's dark-themed anyway (mostly) and it works (dark gtk theme is present too).

Please add "git" to makedepends, it is required for pulling the git sources. Without that you cannot build the Yaru packages inside a clean chroot