Package Details: libunity 7.1.4-9

Git Clone URL: https://aur.archlinux.org/libunity.git (read-only, click to copy)
Package Base: libunity
Description: Library for instrumenting and integrating with all aspects of the Unity shell
Upstream URL: https://launchpad.net/libunity
Licenses: LGPL
Submitter: adsun
Maintainer: billypilgrim
Last Packager: billypilgrim
Votes: 5
Popularity: 0.002018
First Submitted: 2018-10-07 13:17
Last Updated: 2019-10-22 13:36

Latest Comments

1 2 Next › Last »

michaldybczak commented on 2019-10-22 13:44

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

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

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

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

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

@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

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

denisfalqueto commented on 2019-10-18 20:42

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

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

Negher commented on 2019-10-18 11:08

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