Arch Linux User Repository

well this works with Vala 0.56.1

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

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

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

The most recent update keeps failing in Manjaro: https://pastebin.com/Y56PPUvk

@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: https://aur.archlinux.org/cgit/aur.git/commit/?h=libunity&id=c6a50ece4247f880ee0e21481428595418d6c38e

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

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

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.

@draig29

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.

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

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

@CaptainKrull Thank you, solved )

The same update problem

/usr/bin/ld: warning: libicui18n.so.69, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/libdee-1.0.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libicuuc.so.69, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/libdee-1.0.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/libdee-1.0.so: undefined reference to `u_strFromUTF8Lenient_69'
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/libdee-1.0.so: undefined reference to `u_errorName_69'
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/libdee-1.0.so: undefined reference to `utrans_transUChars_69'
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/libdee-1.0.so: undefined reference to `utrans_close_69'
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/libdee-1.0.so: 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

@michaldybczak

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

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

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

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

@drarig29

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

@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.

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)

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)

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().
    Aborting...

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!

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.

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

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.

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

Building errs out with:

(...snip...)
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

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

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

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-0.7.6.121130-2  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 gnome-autogen.sh 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().
Aborting...
:: failed to verify integrity or prepare libunity package

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.

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.

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.

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?

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.

@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?

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

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.

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

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:

15,16c15,18
< source=("<https://launchpad.net/ubuntu/+archive/primary/+files/>${pkgname}_${pkgver}+19.04.20190319.orig.tar.gz")
< sha256sums=('56ecb380d74bf74caba193d9e8ad6b0c85ccf9eeb461bc9731c2b8636e1f1492')
---
> source=("<https://launchpad.net/ubuntu/+archive/primary/+files/>${pkgname}_${pkgver}+19.04.20190319.orig.tar.gz"
>         "<https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1844158/+attachment/5290648/+files/0001-Fix-FTB-with-recent-vala-requiring-non-public-abstra.patch>")
> sha256sums=('56ecb380d74bf74caba193d9e8ad6b0c85ccf9eeb461bc9731c2b8636e1f1492'
>             '98a2562dcf3b3a864d1c05331b4dc672d8bff4b592ca796a0bc132a416f33262')
19a22
>   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

@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.

Trying to build this, I get:

which: no gnome-autogen.sh 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

@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.

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

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