Package Details: bitlbee-facebook-git v1.2.1.r7.49ea312-1

Git Clone URL: https://aur.archlinux.org/bitlbee-facebook-git.git (read-only, click to copy)
Package Base: bitlbee-facebook-git
Description: Facebook protocol plugin for BitlBee
Upstream URL: https://github.com/bitlbee/bitlbee-facebook
Keywords: bitlbee facebook
Licenses: GPL
Conflicts: bitlbee-facebook
Provides: bitlbee-facebook
Submitter: mickael9
Maintainer: feel
Last Packager: feel
Votes: 5
Popularity: 0.000000
First Submitted: 2015-01-24 15:44 (UTC)
Last Updated: 2021-02-03 22:20 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

polyzen commented on 2016-02-02 12:16 (UTC) (edited on 2017-01-06 00:24 (UTC) by polyzen)

maciejjo, I'm using aur/bitlbee-facebook now that there are releases.

maciejjo commented on 2016-02-02 09:47 (UTC)

polyzen: you no longer maintain this?

polyzen commented on 2016-01-27 00:05 (UTC) (edited on 2016-02-02 12:17 (UTC) by polyzen)

You beat me to the punch, arnottcr :) Should be just a matter of time before your PKGBUILD gets upstreamed. Then again, the bitlbee package was out-of-date for some time.. Also, thank you for the notice to bump the pkgver.

<deleted-account> commented on 2016-01-25 12:57 (UTC)

This *is* a compiled release. The arch field describes the end result package, not just the PKGBUILD. By the Arch packaging standards (https://wiki.archlinux.org/index.php/Arch_packaging_standards#Architectures) arch=any is only used for architecture-independent packages, which this is not; and `man PKGBUILD` and the Arch wiki (https://wiki.archlinux.org/index.php/PKGBUILD#arch) confirm that.

arnottcr commented on 2016-01-25 06:29 (UTC)

polyzen: can you add a conflict to your PKGBUILD so that this development version cannot be installed beside the release version of bitlbee-facebook: https://aur.archlinux.org/packages/bitlbee-facebook Celti: I understand that it would be nice to know which architectures a given piece of software runs on; however is C source code, much like scripts, not architecture independent? Furthermore, I realize that gcc cannot compile for every architecture, but having to explicitly add support for each seems like extra work for no gain. I thought that something like "arch=('x86_64')" was only used for compiled releases or binary blobs, where the package will only run on x86_64.

polyzen commented on 2015-12-22 18:51 (UTC)

Thank you, corrected.

<deleted-account> commented on 2015-12-21 18:08 (UTC)

arch=any is for packages that don't have a specific architecture, like scripts. This is a compiled binary plugin and should list the separate architectures it is known to work on.

polyzen commented on 2015-12-21 14:01 (UTC) (edited on 2015-12-21 14:31 (UTC) by polyzen)

yar, why is that? https://github.com/polyzen/pkgbuilds/commit/eb7b15f75bfb40aaddbb0421677d702ae8ea2873

yar commented on 2015-12-21 07:45 (UTC)

This needs to be arch=(i686 x86_64), not arch=(any)

« First ‹ Previous 1 2 3 Next › Last »