Package Details: telegram-tdlib-purple-git 0.7.9.r496.80a9163-3

Git Clone URL: https://aur.archlinux.org/telegram-tdlib-purple-git.git (read-only, click to copy)
Package Base: telegram-tdlib-purple-git
Description: libpurple/pidgin Telegram plugin implemented using official tdlib client library. Needs TD_API_ID and TD_API_HASH env vars to be set for makepkg.
Upstream URL: https://github.com/ars3niy/tdlib-purple
Keywords: bitlbee libpurple pidgin tdlib telegram
Licenses: GPL2, LGPL2.1, custom:FTL, custom:PIX, custom:RPD, custom:SKIA, custom:STB
Conflicts: telegram-tdlib-purple
Provides: telegram-tdlib-purple
Submitter: mk-fg
Maintainer: mk-fg
Last Packager: mk-fg
Votes: 6
Popularity: 0.25
First Submitted: 2020-06-27 20:23 (UTC)
Last Updated: 2022-05-15 16:15 (UTC)

Pinned Comments

mk-fg commented on 2021-12-07 14:44 (UTC) (edited on 2022-03-18 16:03 (UTC) by mk-fg)

If you're getting error like this on login:

Login error: Authentication error: code 400 (API_ID_PUBLISHED_FLOOD)

Check https://core.telegram.org/api/obtaining_api_id URL, for generating api_id/api_hash values (only a couple clicks) and specify those for makepkg like this:

TD_API_ID=... TD_API_HASH=... makepkg -f

WARNING messages should be printed if these values are missing in env during build.

This might be unnecessary in future versions, if these credentials can be specified via the UI there. See tdlib-purple README or https://github.com/ars3niy/tdlib-purple/pull/129 for more up-to-date info.

Latest Comments

1 2 3 4 Next › Last »

mk-fg commented on 2022-08-30 08:35 (UTC) (edited on 2022-08-30 08:35 (UTC) by mk-fg)

I think it's not required in a sense that its on/off status is auto-detected at build time (unless you use -DNoVoip=True), and don't think that's what optional dependencies are for - they are for stuff not required at runtime, so it'd seem to be a wrong and misleading thing to do.

There is a minimal version of this PKGBUILD here: https://aur.archlinux.org/packages/telegram-tdlib-purple-minimal-git

Which maybe you can use, it has -DNoWebp=True -DNoLottie=True -DNoVoip=True and no corresponding dependencies.

Otherwise I think it'd have to be a separate PKGBUILD like that -minimal one (-novoip maybe), and idk if adding that on AUR with such packages is a better idea than maybe you removing that from depends=() in PKGBUILD or making some AUR-build-tool do that automatically (they probably have hooks for that).

jabcross commented on 2022-08-30 03:59 (UTC)

Can the libtgvoip dependency be made optional? It doesn't seem to be required (it's just for voice calls) and it's currently broken.

mk-fg commented on 2022-07-28 19:33 (UTC)

You seem to be reporting an issue against wrong package - there are no such files here.

shackra commented on 2022-07-28 19:30 (UTC)

The patches fail checksum:

==> Validando los archivos source con sha512sums...
    7563a96b8f8e86b7a5fd1ce783388adf29bf4cf9.zip ... Aprobado
    11bc9089ad136b713190e0e8f5b484cba9ad495c.patch ... HA FALLADO
    6e82b6e45664c1f80b9039256c99bebc76d34672.patch ... HA FALLADO
==> ERROR: ¡Uno o más archivos no superaron el control de validación!

mk-fg commented on 2022-05-15 16:16 (UTC)

Fixed, thank you!

Thaodan commented on 2022-05-15 15:48 (UTC)

Can you change tdlib from depend to makedepend? The plugin is using the static C++ interface.

mk-fg commented on 2022-03-18 16:02 (UTC)

Got around to add the patch and test the thing with it - works fine here as well, with current tdlib 1.8.2+ from git.

patch --dry-run -tNp1 -R ... || patch -tNp1 ... should hopefully match the applied PR in the future too, instead of breaking the build after that.

Thanks for pointing it out.

pepper_chico commented on 2022-03-14 19:17 (UTC)

@mk-fg yes it does make it compatible. I can confirm it works, and I'm building on top of that PR instead of sticking to tdlib 1.7.9 as a solution. Hopefully it gets merged.

mk-fg commented on 2022-03-14 11:57 (UTC)

Presumably it makes tdlib-purple compatible with current tdlib?

Probably a good idea to add if it fixes that tdlib version annoyance, at least until they eff-it-up again.

Though it seems like a bad idea for -git package in general, as it'll probably either get merged or broken soon enough, and this shouldn't be my own fork of the thing.

pepper_chico commented on 2022-03-14 10:56 (UTC)

@mk-fg what about integrating this PR as patch meanwhile:

1 2 3 4 Next › Last »