Package Details: libunity 7.1.4-15

Git Clone URL: (read-only, click to copy)
Package Base: libunity
Description: Library for instrumenting and integrating with all aspects of the Unity shell
Upstream URL:
Licenses: LGPL
Submitter: adsun
Maintainer: drarig29
Last Packager: drarig29
Votes: 13
Popularity: 0.29
First Submitted: 2018-10-07 13:17 (UTC)
Last Updated: 2022-04-13 21:34 (UTC)

Latest Comments

UndiedGamer commented on 2022-05-06 13:34 (UTC)

well this works with Vala 0.56.1

fred118 commented on 2022-05-06 10:48 (UTC)

Installing vala made it compile again. Shouldn't vala be installed through dependencies of this project?

UndiedGamer commented on 2022-05-04 14:55 (UTC) (edited on 2022-05-04 14:55 (UTC) by UndiedGamer)

@draig29 even i am facing the same issue, my vala version is Vala 0.44.11

drarig29 commented on 2022-04-16 19:53 (UTC)

@peter.kehl what's your vala --version?

peter.kehl commented on 2022-04-16 19:36 (UTC)

The most recent update keeps failing in Manjaro:

drarig29 commented on 2022-04-13 21:38 (UTC) (edited on 2022-04-13 21:39 (UTC) by drarig29)

@mnabid oh yes, Fedora for the win! Thanks for the help.

It's funny because this patch is exactly the same as the one I came up with on my own in this old commit:

But I had to remove it because of a downgrade... :(

Anyway, everything should work fine now, simply with vala and dee.

Strixpyrr commented on 2022-04-03 21:29 (UTC)

For anyone facing the same issue I was, I was able to successfully build:

Install "vala0.52" and build "dee" (with gcc; clang doesn't work). Install "vala" from the official repo, replace "icu69-bin" and "vala0.44" in the "libunity" PKGBUILD with "icu" and "vala" respectively, and build using makepkg -si.

mnabid commented on 2022-02-07 21:52 (UTC)


This patch from Fedora Rawhide fixes building against vala 0.54.

icu69-bin isn't needed anymore. The one in the official repo works fine.

drarig29 commented on 2022-01-09 21:59 (UTC)

@leo_sk you are right! And it indeed compiles with icu69-bin. I'm going to add it as a make dependency.

leo_sk commented on 2022-01-09 21:00 (UTC)

Compiling the above package requires icu69, while the one in arch repos is icu70. However icu69 is available in AUR via package icu69-bin . Consider adding it as a make dependency

Zame commented on 2021-12-05 08:20 (UTC)

@CaptainKrull Thank you, solved )

Zame commented on 2021-12-04 17:40 (UTC) (edited on 2021-12-04 17:43 (UTC) by Zame)

The same update problem

/usr/bin/ld: warning:, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning:, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/, not found (try using -rpath or -rpath-link)
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to `u_strFromUTF8Lenient_69'
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to `u_errorName_69'
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to `utrans_transUChars_69'
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to `utrans_close_69'
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/ undefined reference to `utrans_openU_69'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:504: unity-scope-loader] Ошибка 1
make[3]: выход из каталога «/home/feltsi/.cache/yay/libunity/src/loader»
make[2]: *** [Makefile:419: all] Ошибка 2
make[2]: выход из каталога «/home/feltsi/.cache/yay/libunity/src/loader»
make[1]: *** [Makefile:575: all-recursive] Ошибка 1
make[1]: выход из каталога «/home/feltsi/.cache/yay/libunity/src»
make: *** [Makefile:479: all] Ошибка 2
==> ОШИБКА: Произошел сбой в build().
 -> error making: libunity

tari01 commented on 2021-11-28 10:20 (UTC)


For me it builds with 0.44 when dee is built with 0.52.

michaldybczak commented on 2021-11-28 10:05 (UTC)

Won't build with dee compiled with newer vala :(

/usr/bin/ld: warning:, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning:, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/, not found (try using -rpath or -rpath-link)

drarig29 commented on 2021-11-27 16:17 (UTC)

@tari01 it's done, I reverted my changes.

tari01 commented on 2021-11-27 06:53 (UTC)


We also need to remove 0001-Fix-optional-types.patch to make it build again with 0.44.

drarig29 commented on 2021-11-25 12:00 (UTC)

@tari01 oh okay, sorry I haven't tested if everything works. Just that it builds. I used vala0.52 because this is what dee needs to build. I'll change this back.

tari01 commented on 2021-11-25 11:39 (UTC)

It appears we'll need to change back to vala0.44. With 0.52 the gobject-introspection bindings are broken.

(When built with 0.44, all works fine)

mcterra commented on 2021-10-22 02:08 (UTC)

Heads up, dee fails to compile on the latest update of vala. You will need to downgrade to an older version from the Arch Archives (I used 0.52.4-1) for it to build correctly, since it won't build with 0.44 or 0.42 from the AUR. With newer versions, you'll get an error along the lines of

  GEN      dee-1.0.vapi
Dee-1.0.gir:1180.7-1180.58: warning: Field `Dee.Filter.destroy' conflicts with method of the same name
      <method name="destroy" c:identifier="dee_filter_destroy">
Dee-1.0.gir:1274.7-1274.42: error: `Dee.Filter' already contains a definition for `new'
      <function name="new" c:identifier="dee_filter_new">
Dee-1.0-custom.vala:19.3-19.27: note: previous definition of `new' was here
                public static Filter @new (Dee.StaticFilterMapFunc map_func, owned Dee.FilterMapNotify map_notify);
Dee-1.0.gir:8618.7-8618.70: warning: Field `Dee.ModelReader.destroy' conflicts with method of the same name
      <method name="destroy" c:identifier="dee_model_reader_destroy">
Generation failed: 1 error(s), 2 warning(s)

NovaViper commented on 2021-10-03 03:43 (UTC) (edited on 2021-10-03 03:44 (UTC) by NovaViper)

I can't get this crap to compile for nothing, I've tried setting vala to 0.44 and 0.42, it still wont compile It always fails when trying to compile dee no matter what version of vala I use. My system's running EndeaovurOS

Generation failed: 1 error(s), 2 warning(s)
make[2]: *** [Makefile:569: dee-1.0.vapi] Error 1
make[2]: Leaving directory '/var/tmp/pamac-build-novaviper/dee/src/dee-1.2.7/vapi'
make[1]: *** [Makefile:527: all-recursive] Error 1
make[1]: Leaving directory '/var/tmp/pamac-build-novaviper/dee/src/dee-1.2.7'
make: *** [Makefile:433: all] Error 2
==> ERROR: A failure occurred in build().

Cantello commented on 2021-07-06 07:50 (UTC)

Installing the newest vala prior to building dee did not work but, as described below, changing libunity's build file to vala0.42 worked and building libunity did produce several warnings but installed fine and now I have notification badges on electron apps in task manager. Thanks!

CaptainKrull commented on 2021-06-10 20:15 (UTC)

It seems like dee (which is a dependency of this package) needs the newest vala to build. Vala0.44 won't do it, therefore you have to install the new vala first, build and install dee, then uninstall the new vala, build and install vala0.44 and use it to build/install libunity.

michaldybczak commented on 2021-06-09 16:33 (UTC) (edited on 2021-06-09 16:33 (UTC) by michaldybczak)

For me, editing to "vala" worked out fine. However, instead picking vala from repos, it built vala-0.44.11 anyway...

nfs commented on 2021-04-21 21:39 (UTC)

I found that editing the libunity PKGBUILD makedepends so that "vala" became "vala0.42" of "vala0.44" worked all right, but changing it to "vala-git" or leaving it as "vala" did not.

commented on 2020-12-18 21:36 (UTC)

Note: The build works fine if you replace vala with vala0.42

mokkurkalve commented on 2020-12-02 14:56 (UTC) (edited on 2020-12-02 14:57 (UTC) by mokkurkalve)

Building errs out with:

unity-sound-menu-mpris.vala:714.5-714.48: warning: DBus methods are recommended to throw at least `GLib.Error' or `GLib.DBusError, GLib.IOError'
    public async PlaylistDetails[] get_playlists (uint32 index,
unity-sound-menu-mpris.vala:407.5-407.55: warning: DBus methods are recommended to throw at least `GLib.Error' or `GLib.DBusError, GLib.IOError'
    public abstract async void EnableTrackSpecificItems (ObjectPath object_path, string desktop_id) throws IOError;
unity-sound-menu-mpris.vala:408.5-408.56: warning: DBus methods are recommended to throw at least `GLib.Error' or `GLib.DBusError, GLib.IOError'
    public abstract async void EnablePlayerSpecificItems (ObjectPath object_path, string desktop_id) throws IOError;
Compilation failed: 1 error(s), 22 warning(s)
make[2]: *** [Makefile:1391: libunity_la_vala.stamp] Error 1
make[2]: Leaving directory '/tmp/makepkg/libunity/src/src'
make[1]: *** [Makefile:573: all-recursive] Error 1
make[1]: Leaving directory '/tmp/makepkg/libunity/src'
make: *** [Makefile:477: all] Error 2

Kodehawa commented on 2020-11-26 21:21 (UTC)

Anyone else getting

unity-scope-channel.vala:312.33-312.50: error: Argument 7: Cannot convert from `void Unity.Internal.ScopeChannel.OwnerWatcher.owner_changed (GLib.DBusConnection, string, string, string, string, GLib.Variant)' to `void GLib.DBusSignalCallback (GLib.DBusConnection, string?, string, string, string, GLib.Variant)'
DBusSignalFlags.NONE, this.owner_changed);\

I haven't been able to build this for a while

billypilgrim commented on 2020-05-20 09:02 (UTC)

I don't use this package any more so I think it's probably best if someone else becomes maintainer.

j1simon commented on 2020-05-20 07:14 (UTC)

Error with gnome-common:

$ pacaur -S libunity
:: Package libunity not found in repositories, trying AUR...
:: resolving dependencies...
:: looking for inter-conflicts...

AUR Packages  (1) libunity-7.1.4-9  
Repo Packages (19) dee-1.2.7-8  glib2-docs-2.64.2-1  gnome-common-3.18.0-3  gobject-introspection-1.64.1-2  graphviz-2.44.0-2  gtk-doc-1.32+37+gefc3644-1  gts-  intltool-0.51.0-5  itstool-1:2.0.6-1  libdbusmenu-glib-16.04.0-4  mallard-ducktype-1.0.2-4  perl-xml-parser-2.46-1  python-anytree-2.8.0-1  python-beaker-1.11.0-4  python-mako-1.1.2-3  python-markdown-3.1.1-4  vala-0.48.6-1  yelp-tools-3.32.2-1  yelp-xsl-3.36.0-1  

Repo Download Size:   11.52 MiB
Repo Installed Size:  71.46 MiB

:: Proceed with installation? [Y/n]
:: Retrieving package(s)...
update complete: /home/juan/.cache/pacaur/libunity
:: libunity build files are up-to-date -- skipping
:: Checking libunity integrity...
==> Making package: libunity 7.1.4-9 (Wed May 20 09:11:17 2020)
==> Retrieving sources...
-> Found libunity_7.1.4+19.04.20190319.orig.tar.gz
-> Found 0001-Fix-FTB-with-recent-vala-requiring-non-public-abstra.patch
==> Validating source files with sha256sums...
libunity_7.1.4+19.04.20190319.orig.tar.gz ... Passed
0001-Fix-FTB-with-recent-vala-requiring-non-public-abstra.patch ... Passed
:: Preparing libunity...
==> Making package: libunity 7.1.4-9 (Wed May 20 09:11:17 2020)
==> WARNING: Skipping dependency checks.
==> Retrieving sources...
-> Found libunity_7.1.4+19.04.20190319.orig.tar.gz
-> Found 0001-Fix-FTB-with-recent-vala-requiring-non-public-abstra.patch
==> WARNING: Skipping all source file integrity checks.
==> Extracting sources...
-> Extracting libunity_7.1.4+19.04.20190319.orig.tar.gz with bsdtar
==> Starting prepare()...
patching file src/unity-aggregator-scope.vala
patching file src/unity-deprecated-scope.vala
patching file tools/preview-renderer.vala
which: no in (/home/juan/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/var/lib/flatpak/exports/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/sbin:/usr/sbin)
You need gnome-common from the GNOME Git repository
==> ERROR: A failure occurred in prepare().
:: failed to verify integrity or prepare libunity package

michaldybczak commented on 2019-10-22 13:44 (UTC)

Thanks. It's very rare that helpers cause an error. Oftentimes it's the opposite, especially with big and complicated compilations (2 hours long), where doing it officially results in an error while through pamac it works - no idea why.

billypilgrim commented on 2019-10-22 13:38 (UTC)

Ah, that's the problem then. It must be a bug in pamac.

I've pushed the change, but FYI AUR helpers aren't officially supported.

michaldybczak commented on 2019-10-22 13:33 (UTC)

Yes, I used pamac in this case. However, sometimes I use trizen with Octopi, sometimes yay with terminal, sometimes I build packages directly from PKGBUILD.

billypilgrim commented on 2019-10-22 13:16 (UTC)

I'm not quite sure what you mean. The PKGBUILD should work on everyone's setup, because the path to the patch is correct. It's not some weird artefact of my setup.

Are you using an AUR helper by any chance?

michaldybczak commented on 2019-10-21 19:27 (UTC)

I already installed it with the provided fix, but there was an error in the path to the patch so the build just errored out. Probably the path works only for you but it's not universal and must be set as @denisfalqueto mentioned. Or maybe the issue is, the build isn't happening in root directory for me. This is how I set it and this is how I prefer it. So if the path will work only for root then it's incorrect anyway. It has to be flexible.

billypilgrim commented on 2019-10-21 09:59 (UTC)

@denisfalqueto That's weird. It builds fine for me. The path shouldn't matter -- the patch is in the root folder AND symlinked into src/. So it should work either way.

What's the error you're getting?

michaldybczak commented on 2019-10-20 16:45 (UTC)

Thanks, @denisfalqueto. I applied your fix and the build finally was successful.

denisfalqueto commented on 2019-10-18 20:42 (UTC)

PKGBUILD has a problem when applying the patch. On line 22, it should be

patch -p1 < 0001-Fix-FTB-with-recent-vala-requiring-non-public-abstra.patch

Instead, the file is being prefixed with "../" which makes the patching fail.

billypilgrim commented on 2019-10-18 12:02 (UTC)

@Negher I've pushed a fix. Thanks for the report :-)

Negher commented on 2019-10-18 11:08 (UTC) (edited on 2019-10-18 12:04 (UTC) by Negher)

As of today the package doesn't compile. Searching for a solution I sumbled upon bug 1844158 on launchpad.

The following PKGBUILD patch should fix the problem:

< source=("<>${pkgname}_${pkgver}+19.04.20190319.orig.tar.gz")
< sha256sums=('56ecb380d74bf74caba193d9e8ad6b0c85ccf9eeb461bc9731c2b8636e1f1492')
> source=("<>${pkgname}_${pkgver}+19.04.20190319.orig.tar.gz"
>         "<>")
> sha256sums=('56ecb380d74bf74caba193d9e8ad6b0c85ccf9eeb461bc9731c2b8636e1f1492'
>             '98a2562dcf3b3a864d1c05331b4dc672d8bff4b592ca796a0bc132a416f33262')
>   patch -p1 < 0001-Fix-FTB-with-recent-vala-requiring-non-public-abstra.patch

PS: I hope I didn't screw up the Markdown syntax PS2: Yes I did

adsun commented on 2019-06-06 22:38 (UTC)

@BasT gnome-common is already in makedepends, so I cannot reproduce your error. However, the build fails because dee was not updated for a new version of vala and now libunity fails to build when using dee.

BasT commented on 2019-06-06 13:18 (UTC)

Trying to build this, I get:

which: no in (/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/android-sdk/platform-tools:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)
You need gnome-common from the GNOME Git repository

adsun commented on 2019-01-16 19:54 (UTC)

@FirefighterBlu3 I am not really sure but I think it is the use of a more recent source tarball, which may have fixed a bug causing the crash. Glad to hear that the crash no longer happens, though.

FirefighterBlu3 commented on 2019-01-16 19:38 (UTC)

@adsun what was the difference between -6 and -7? -6 was making blender crash

adsun commented on 2018-12-08 20:46 (UTC)

@gazellejaeger This is not out of date, and it builds fine on a clean chroot. Unflagging this now.