Package Details: libdbusmenu-gtk2 16.04.0-1

Git Clone URL: https://aur.archlinux.org/libdbusmenu.git (read-only)
Package Base: libdbusmenu
Description: A library for passing menus over DBus
Upstream URL: https://launchpad.net/libdbusmenu
Licenses: GPL3, LGPL3, LGPL2.1
Submitter: alucryd
Maintainer: WoefulDerelict
Last Packager: WoefulDerelict
Votes: 431
Popularity: 16.050358
First Submitted: 2016-02-03 18:04
Last Updated: 2016-03-17 02:09

Latest Comments

amagnasco commented on 2016-03-18 05:14

successfully compiled on the 'armv7h' architecture

Kwpolska commented on 2016-03-15 19:47

@WoefulDerelict Probably because those “more common helpers” and makepkg do not even bother checking split package dependencies, relying on pkgbase dependencies only. Which is a bug in my opinion — forcing people to rely on makedepends. I released PKGBUILDer v4.2.6 to fix this special case.

WoefulDerelict commented on 2016-03-15 19:29

Kwpolska: This is a valid split package. When manually building and installing this set of packages via makepkg and pacman the issue you describe does not occur. In testing this PKGBUILD and others with more common helpers like bauerbill, cower, pacaur and yaourt one has not come across a case such as yours. This behaviour seems isolated to your specific helper and its inability to properly cope with this type of PKGBUILD.

Kwpolska commented on 2016-03-15 16:30

This package trips up PKGBUILDer (my AUR helper) libdbusmenu-gtk2 and libdbusmenu-gtk3 depend on libdbusmenu-glib, leading to an infinite loop. I’ll patch it on my side, but you should make sure this is the right way to package things.

WoefulDerelict commented on 2016-03-02 02:08

The --pkg option was removed in the latest series of updates to the package tools. Try running makepkg without options and installing the specific package you want using pacman -U

Theredbaron1834 commented on 2016-03-02 01:51

This is failing to build with "makepkg: invalid option '--pkg'", and I am not smart enough to find out why.

WoefulDerelict commented on 2016-02-09 16:47

macstar: Indeed that is a simple solution, glad you got it sorted. I will add docbook-xsl as a make depend so that other users don't encounter the same error.

I'm not sure why yaourt would start outputting in german if you have LANG=en_US.UTF-8 as your system default in /etc/locale.conf either. Many programs like your desktop environment will maintain their own settings for language and only reference the default when their own settings aren't available. I'm sure not having the locale errors is nice but it is an odd trade off. If you're running yaourt in a terminal emulator hosted inside a DE I'd check the settings in the terminal emulator. You can often find help debugging things like that in #archlinux on freenode.

macstar commented on 2016-02-09 09:30

@WoefulDerelict

i got it working now! the solution was that simple:
sudo pacman -S docbook-xsl
then i ran yaourt update again and the installation went fine without any error message.

macstar commented on 2016-02-09 09:14

@WoefulDerelict

thank you for your answer. i am pretty sure an internet connection is available since all other packages update just fine. i tried to fix the locale problem and now i won't get the locale errors anymore, however yaourt outputs in german now (i have not the slightest clue why, i set everything to en_US.UTF-8 and my DE is in english) so the errors are gone, but it still would not compile.

https://paste.kde.org/pppvil825

WoefulDerelict commented on 2016-02-08 18:45

macstar: It appears the error has something to do with the build system's inability to fetch a remote source:

warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl"
compilation error: file /usr/share/gtk-doc/data/gtk-doc.xsl line 10 element import
xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl
Makefile:754: recipe for target 'html-build.stamp' failed

If an internet connection isn't available you might receive such an error. This may in turn have something to do with the frequent complaints issued regarding your locale. It is often necessary to have the en_US.UTF-8 available alongside your native language for some programs to behave reliably. On my own systems /etc/locale.gen has both the en_US.UTF-8 and the en_GB.UTF-8 options enabled. My /etc/locale.conf specifies LANG=en_GB.UTF-8 as the system's default preference.

Have a look at the Locale entry in the Arch Wiki for more information (https://wiki.archlinux.org/index.php/locale). Ensure that your locale settings are correct. If everything appears sound enable en_US-UTF-8, regenerate your locales and try building the package.

All comments