Package Details: libplist-git 1:2.3.0.r19.gd45396a-1

Git Clone URL: https://aur.archlinux.org/libplist-git.git (read-only, click to copy)
Package Base: libplist-git
Description: A library to handle Apple Property List format whereas it's binary or XML
Upstream URL: http://www.libimobiledevice.org/
Licenses: GPL2, LGPL2.1
Conflicts: libplist
Provides: libplist, libplist++-2.0.so, libplist-2.0.so
Submitter: intellitech
Maintainer: intelfx
Last Packager: intelfx
Votes: 31
Popularity: 0.000003
First Submitted: 2009-04-17 04:15 (UTC)
Last Updated: 2023-09-27 16:03 (UTC)

Dependencies (6)

Required by (56)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3

intelfx commented on 2014-03-22 13:20 (UTC)

@kingd: Updated. However, -git packages are not usually version-bumped; the user is expected to watch/rebuild them by themselves.

kingd commented on 2014-03-22 09:56 (UTC)

please update the name, the most recent version is 1.11.

intelfx commented on 2014-01-10 15:04 (UTC)

Well, the ones who use -git versions should be aware of possible breakage and the possible dirty-fix, as well as the possibility to edit PKGBUILD by hand and set commit to build manually. I think that it is superfluous to create a separate package just for that purpose.

migerh commented on 2014-01-10 08:56 (UTC)

I went through the project history. The version was increased when upstream switched from cmake to autotools [1]. Since then they only fixed compiler warnings except [2] which *might* introduce an API change but the commit log says the function was only used internally. For now it should be safe to fix this with a simple symlink. We only need a better solution (maybe a libplist.so.1 AUR package that compiles the last commit before an API change and installs libplist.so.2.0.0 as libplist.so.1?) if the API changes before version 1.11 is released. [1] https://github.com/libimobiledevice/libplist/commit/a798afc8b5b00a43f4b121168e0419df2d398338 [2] https://github.com/libimobiledevice/libplist/commit/fc347787ea32d5ffdd2709127fb70c295e510a15

intelfx commented on 2014-01-09 19:23 (UTC)

I have symlinked libplist.so.1 -> libplist.so.2 locally and it works, but this is a dirty hack. The problem is unsolvable from here: we're just tracking the upstream.

gegenschall commented on 2014-01-09 16:50 (UTC)

Same thing here, migerh. With upowerd not starting up, GDM also doesn't come up. I reverted to the rep versions of libplist, libimobiledevice, etc. Symlinking really is a bad idea™, library versioning is there for a reason. When I've got spare time, I'll compile upowerd from source, see if that works.

migerh commented on 2014-01-09 08:15 (UTC)

The latest version of libplist-git stopped providing libplist.so.1 which is required by /usr/lib/upower/upowerd (upower in [extra]). upowerd is started by dbus but because it fails dbus apparently waits and retries. This takes a lot of time: boot time is now ~90s instead of ~10s before. Adding a symlink /usr/lib/libplist.so.1 -> /usr/lib/libplist.so.2.0.0 at least speeds up the boot process back to 10s max but doesn't sound like a very good idea. Any advice?

intelfx commented on 2013-12-13 05:17 (UTC)

Updated to reflect cmake -> autotools transition by upstream.

intelfx commented on 2013-10-20 21:58 (UTC)

Package updated to comply with pacman 4.1 VCS/packaging standards.

intellitech commented on 2011-10-10 19:13 (UTC)

If anybody is interested in taking over as maintainer of this package, feel free to e-mail me.

« First ‹ Previous 1 2 3