Package Details: bitlbee-facebook 1.2.2-1

Git Clone URL: https://aur.archlinux.org/bitlbee-facebook.git (read-only, click to copy)
Package Base: bitlbee-facebook
Description: Facebook protocol plugin for BitlBee
Upstream URL: https://github.com/bitlbee/bitlbee-facebook
Licenses: GPL
Submitter: arnottcr
Maintainer: SanskritFritz
Last Packager: kql
Votes: 19
Popularity: 0.000000
First Submitted: 2016-01-25 06:17 (UTC)
Last Updated: 2021-05-16 13:50 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

tiagoboldt commented on 2017-04-05 09:31 (UTC)

If you've updated this package and restarted bitlbee, that should no longer happen (mine's working right now). If it persists, please report the issue upstream.

cybertron commented on 2017-04-05 09:30 (UTC)

@tiagboldt I had updated, but still same problem

tiagoboldt commented on 2017-04-05 09:11 (UTC)

@cybertron, that has been fixed in 1.1.0. Please update.

cybertron commented on 2017-04-05 06:33 (UTC)

I cannot login anymore 08:24 <@foobar> facebook - Login error: Null value for $.viewer.message_threads.sync_sequence_id 08:24 <@foobar> facebook - Logging in: Signing off.. 08:24 <@foobar> facebook - Logging in: Reconnecting in 900 seconds.. since one week I think.

thinh commented on 2017-03-29 16:15 (UTC)

Can you update this to the latest version? (https://github.com/bitlbee/bitlbee-facebook/releases/tag/) Facebook disabled their older client support which makes v1.0.0 unusable.

ChrisLane commented on 2017-03-16 16:39 (UTC)

Could you please make this available for the 'aarch64' architecture?

arnottcr commented on 2016-12-05 03:01 (UTC)

done

polyzen commented on 2016-11-29 23:04 (UTC) (edited on 2016-11-29 23:31 (UTC) by polyzen)

Please use a unique name for the source file like so: source=("$pkgname-$pkgver.tar.gz::$url/archive/v$pkgver.tar.gz")

arnottcr commented on 2016-05-01 02:57 (UTC)

Celti, I have corrected the repo, thanks for the info I was not about that migration. The autogen.sh tip is useful too, and it too is now fixed. I have used the 'any' arch because, despite the package being compiled code, it can be compiled on any architecture. This has been of particular headache for me running code of this type on arm devices. AUR resources usually run with no issue on ARM devices, but you have to explicitly ask a package maintainer to add _support_ for your arch to the PKGBUILD. Note this is not a code changes, just formatting fixup. My thought was that this would only need to be explicitly specified if the source code explicitly mandated a particular arch set. What are your thought based on my traction with this issue?