Package Details: lib32-bluez-libs 5.64-1

Git Clone URL: https://aur.archlinux.org/lib32-bluez-libs.git (read-only, click to copy)
Package Base: lib32-bluez-libs
Description: Deprecated libraries for the bluetooth protocol stack (32-bit)
Upstream URL: http://www.bluez.org/
Licenses: LGPL2.1
Submitter: WoefulDerelict
Maintainer: WoefulDerelict
Last Packager: WoefulDerelict
Votes: 20
Popularity: 0.037738
First Submitted: 2017-01-07 01:55 (UTC)
Last Updated: 2022-03-18 03:02 (UTC)

Pinned Comments

WoefulDerelict commented on 2016-05-15 19:43 (UTC) (edited on 2018-08-18 20:24 (UTC) by WoefulDerelict)

This PKGBUILD verifies the authenticity of the source via PGP signatures which are not part of the Arch Linux keyring. In order to complete the process it is necessary to import the key(s) from the ‘validpgpkeys’ array into the user’s keyring before calling makepkg. There is a helpful article explaining this process by one of Arch Linux's developers located here: http://allanmcrae.com/2015/01/two-pgp-keyrings-for-package-management-in-arch-linux/

Instructions on importing keys from a keyserver and how to automate the retrieval process can be found in the Arch Linux wiki here: https://wiki.archlinux.org/index.php/GnuPG#Use_a_keyserver This article also contains helpful information describing the installation of GnuPG, its configuration and usage.

Execute the following to import keys using gpg:

gpg --recv-keys <KEYID - See 'validpgpkeys' array in PKGBUILD>

The PGP signature check can be skipped by passing --skippgpcheck to makepkg.

Consult the makepkg manual page for a full list of options. [https://www.archlinux.org/pacman/makepkg.8.html]

Latest Comments

oxalin commented on 2020-10-18 04:41 (UTC) (edited on 2020-10-18 04:46 (UTC) by oxalin)

Any chance of seeing an update?

Also, could you disable tests. This is the workaround applied under bluez-libs package.

Iglu47 commented on 2020-05-28 05:21 (UTC) (edited on 2020-05-28 05:46 (UTC) by Iglu47)

hang on unit/test-gatt

upd. It seems like need to use a "generic" kernel or something https://bugzilla.kernel.org/show_bug.cgi?id=196621#c10

By the way, PASS means successfully completed one of the previous tests. This is not the one that hung. I saw PASS: unit/test-gobex-transfer too.

WoefulDerelict commented on 2020-03-08 22:03 (UTC)

Strunkenbold: That is not an issue I can reproduce in a clean chroot on my test machines. Modifying the PKGBUILD is not necessary to skip the tests. Simply passing --nocheck to makepkg will skip check(). Building this with AUR helpers is unsupported and may result in unexpected issues.

Strunkenbold commented on 2020-03-08 21:05 (UTC)

"For me it hangs during running the tests, last line is "PASS: unit/test-gobex-transfer"."

Same for me. Workaround by commenting out the test section in the pkgbuild.

Win8Error commented on 2019-11-02 20:40 (UTC)

breaks at

CCLD unit/test-sdp ./test-driver: Zeile 107: 21597 Abgebrochen (Speicherabzug geschrieben) "$@" > $log_file 2>&1 FAIL: unit/test-sdp CC unit/test-avdtp.o CC android/avdtp.o CCLD unit/test-avdtp

DarkShadow44 commented on 2019-06-20 15:08 (UTC)

For me it hangs during running the tests, last line is "PASS: unit/test-gobex-transfer".

adsun commented on 2018-02-11 20:41 (UTC)

Thanks. Will remember that from now.

WoefulDerelict commented on 2018-02-11 20:30 (UTC)

adsun: The issue with lib32-dbus should now be resolved. Some lib32- packages do add their 64-bit counterparts as a dependency; however, most frequently this is because the maintainer chose to symlink the licence for the lib32- package to the one provided in the standard 64-bit package and not because the two pieces of software are actually interdependent. bluez-libs was already listed as a dependency for lib32-bluez-libs.

adsun commented on 2018-02-10 19:16 (UTC)

This is missing lib32-dbus as a dependency. Without lib32-dbus, the build fails.

Also, please add regular 64-bit bluez-libs and bluez-plugins as depends. Other lib32 packages add their 64-bit counterparts as depends. Thanks.

WoefulDerelict commented on 2017-02-28 01:22 (UTC)

I've expanded this PKGBUILD, adding a split package function to include the bluez sixaxis plugin as requested by a user via e-mail. This does complicate the build a little and results in some extra compile time and wasted output; however, the final product should mirror the output of bluez in [Extra].

WoefulDerelict commented on 2017-01-07 02:03 (UTC) (edited on 2017-01-07 16:29 (UTC) by WoefulDerelict)

My apologies to users for the very confusing and dirty set of updates. I should have rebuilt this package instead of importing it as it was. I've completed a PKGBUILD that focuses solely on the libraries with fewer dependencies. As an added bonus there should be no out of repo prerequisites to build now. In order to retain feedback and some continuity for users wondering what happened to the split package I'll be requesting that this package and the new lib32-bluez-libs be merged.

WoefulDerelict commented on 2017-01-06 23:45 (UTC) (edited on 2017-01-06 23:51 (UTC) by WoefulDerelict)

hashworks: It looks like lib32-libical is out of date and you're missing the lib32-icu dependency. Try rebuilding and installing lib32-libical and then try building lib32-bluez* again. Edit: I've iterated the lib32-libical pkgrel to encourage users to update to a version which appropriately includes the dependency.

hashworks commented on 2017-01-06 23:34 (UTC)

Failes to build for me: CCLD emulator/hfp /usr/bin/ld: warning: libicuuc.so.57, needed by /usr/lib32/libical.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libicui18n.so.57, needed by /usr/lib32/libical.so, not found (try using -rpath or -rpath-link) /usr/lib32/libical.so: undefined reference to `u_strFromUTF8Lenient_57' /usr/lib32/libical.so: undefined reference to `ucal_close_57' /usr/lib32/libical.so: undefined reference to `uloc_setKeywordValue_57' /usr/lib32/libical.so: undefined reference to `ucal_setAttribute_57' /usr/lib32/libical.so: undefined reference to `ucal_getMillis_57' /usr/lib32/libical.so: undefined reference to `ucal_getKeywordValuesForLocale_57' /usr/lib32/libical.so: undefined reference to `ucal_get_57' /usr/lib32/libical.so: undefined reference to `ucal_open_57' /usr/lib32/libical.so: undefined reference to `ucal_setDateTime_57' /usr/lib32/libical.so: undefined reference to `ucal_setDate_57' /usr/lib32/libical.so: undefined reference to `uenum_next_57' /usr/lib32/libical.so: undefined reference to `ucal_add_57' /usr/lib32/libical.so: undefined reference to `ucal_getLimit_57' /usr/lib32/libical.so: undefined reference to `uenum_close_57' /usr/lib32/libical.so: undefined reference to `ucal_setMillis_57' /usr/lib32/libical.so: undefined reference to `ucal_set_57' collect2: error: ld returned 1 exit status CCLD peripheral/btsensor make[1]: *** [Makefile:4161: obexd/src/obexd] Fehler 1 make[1]: *** Es wird auf noch nicht beendete Prozesse gewartet.... make: *** [Makefile:3092: all] Fehler 2 ==> FEHLER: Ein Fehler geschah in build(). Breche ab... :: Konnte lib32-bluez-libs-Paket(e) nicht erstellen

WoefulDerelict commented on 2017-01-06 23:26 (UTC)

I've trimmed down this recipe to just the shared objects as there are no cases in my own use where the daemons or cups backend were necessary as a 32-bit utility so those packages were never used. If this causes issues for anyone please let me know.

StefanMajonez commented on 2016-08-17 09:54 (UTC)

WoefulDerelict: I figured out why the gpg didn't work, and that is - my gpg.conf didn't exist. For some reason. So I added the keyserver you recommended and keyserver keys.gnupg.net, and now it works. Thanks for the help1

WoefulDerelict commented on 2016-08-15 19:12 (UTC)

StefanMajonez:The pacman keyring and your personal gpg keyring are two different things as explained in the two keyring article in the pinned post. The error you're receiving is because gpg can't reach a keyserver. Check out dirmngr and ~/.gnupg/gpg.conf and have a look at the keyserver entries to ensure that the basics are in order. One of them needs to be uncommented and there are alternatives if you can't reach that one. I've had little trouble with: keyserver hkp://keys.gnupg.net Check the GnuPG article in the wiki for more information about keyservers. The green /tip/ box contains some especially helpful tidbits on configuring gpg.

StefanMajonez commented on 2016-08-15 17:01 (UTC) (edited on 2016-08-15 17:03 (UTC) by StefanMajonez)

Hi! I have a problem which probably stems from my lack of Linux understanding, but it took me +2 hours to try to find a solution and so I decided to post a comment. When trying to make: One or more PGP signatures could not be verified! Inputting gpg --recv-keys 1DCF2659 gives me this: gpg: keyserver receive failed: No keyserver available I downloaded and signed the key using pacman-key, didn't help.

WoefulDerelict commented on 2016-05-19 01:11 (UTC)

oi_wtf: It's what I'm here for. Glad it is working for you as well.

oi_wtf commented on 2016-05-19 00:27 (UTC)

thanks. build works now.

WoefulDerelict commented on 2016-05-18 20:10 (UTC)

It appears as though I've located the missing dependencies and included them where appropriate. I am able to build this package in an initial pacstrap of base and base-devel after enabling multilib to satisfy dependencies from the repo and building lib32-libical. I'll have the package updated shortly. UPDATE: All my local build tests are complete and the updated package is now live. Good luck.

WoefulDerelict commented on 2016-05-18 01:41 (UTC) (edited on 2016-05-18 19:44 (UTC) by WoefulDerelict)

I will take a look at this in a clean environment and see if I can't track down the issue you're experiencing. Our builds definitely diverge rather early in the process; however, I'm unsure if this is due to missing dependencies or something less transparent. While our configure outputs are identical your build is reaching profiles/sap/bluetoothd-sap-dummy.o and crashing quite early where as on my local system it builds a great many other pieces before reaching the same point. It is possible it is skipping those components because of a missing dependency. It is just as likely to be something else simple as well or a complicated mess neither of us has imagined yet. If you could edit the PKGBUILD to disable parallel building by suffixing the make command in build() with -j1 I'd appreciate the additional test data to eliminate other possibilities. EDIT: I seem to have produced a complaint about something missing by the linker in one test. Investigating further. I've succeeded in reproducing the error and generated an identical build output. I'll see if I can't track down what is broken or missing and get it mended. Thanks for finding the issue. UPDATE: As this package is derived from the bluez split package in the extra repo I'm going to investigate to see if the error is shared between them. RESULTS: As I expected bluez from the extra repos builds just fine. This is likely because all of its requirements are met by a basic pacstrap of base and base-devel. I suspect this will narrow my search quite a bit to one of the core glibc components in lib32 that isn't getting pulled in but should likely exist before building any lib32 package.

oi_wtf commented on 2016-05-17 23:33 (UTC)

It fails to build in a clean chroot. Probably because some dependency is missing. Could you look into it? Buildlog: https://ptpb.pw/g1QB

WoefulDerelict commented on 2016-05-15 19:43 (UTC) (edited on 2018-08-18 20:24 (UTC) by WoefulDerelict)

This PKGBUILD verifies the authenticity of the source via PGP signatures which are not part of the Arch Linux keyring. In order to complete the process it is necessary to import the key(s) from the ‘validpgpkeys’ array into the user’s keyring before calling makepkg. There is a helpful article explaining this process by one of Arch Linux's developers located here: http://allanmcrae.com/2015/01/two-pgp-keyrings-for-package-management-in-arch-linux/

Instructions on importing keys from a keyserver and how to automate the retrieval process can be found in the Arch Linux wiki here: https://wiki.archlinux.org/index.php/GnuPG#Use_a_keyserver This article also contains helpful information describing the installation of GnuPG, its configuration and usage.

Execute the following to import keys using gpg:

gpg --recv-keys <KEYID - See 'validpgpkeys' array in PKGBUILD>

The PGP signature check can be skipped by passing --skippgpcheck to makepkg.

Consult the makepkg manual page for a full list of options. [https://www.archlinux.org/pacman/makepkg.8.html]