Arch Linux User Repository

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 your own api_id/api_hash values (only a couple clicks), and specify those in the plugin parameters.

Thanks for the reply, and sorry, indeed it's the wrong package. I raised it on that one, I see the upstream project has a pull request for it too, but looks fairly abandoned. It's my first go at pidgin, so not yet sure what I need, just trying stuff.

Also fwiw, can't build libtgvoip here either, with a ton of errors popping-up.

I think it just needs updating to use a newer git snapshot, where such issues are likely fixed, as it haven't been since 2022.

If you don't need its functionality (voice chats? dunno whether it works in pidgin), can add -DNoVoip=True to cmake command in PKGBUILD to build without that lib/dependency (like it's done in e.g. https://aur.archlinux.org/packages/telegram-tdlib-purple-minimal-git ).

I think you filed this issue against wrong package - TgVoip.cpp file is in a separate libtgvoip, which is a dependency of this one, but its build can't be patched from here.

Link to libtgvoip package: https://aur.archlinux.org/packages/libtgvoip

I am getting some errors compiling, starting with

In file included from TgVoip.cpp:1:
TgVoip.h:11:5: error: 'uint16_t' does not name a type
   11 |     uint16_t port = 0;
      |     ^~~~~~~~
TgVoip.h:8:1: note: 'uint16_t' is defined in header '<cstdint>'; this is probably fixable by adding '#include <cstdint>'

Thanks, it was actually exactly the issue, I was too impatient and assumed that something got stuck, while it actually just needed a very long time to complete the linking!

Oh, I think you might mean "stuck" as in "taking too long wall-clock time to move past that point" - that seem to be unfortunately normal for td library build.

It takes plenty of cpu (and memory in some places) to build (iirc like 30min on 4 cores of somewhat old Ryzen 5600X with 32G RAM here), so I think you can either wait or e.g. add more zram, if memory/swapping is what slows it down to a crawl.

Haven't looked into which parts of the build take what wrt resources, but maybe "run_all_tests" part is non-critical and you can also disable it? Quickly checking via ccmake, I don't see any obvious on/off flag for it, though maybe it's documented how to do it, or can probably patch it out too. Can also just leave it running overnight, as mentioned, if there isn't any more difficult bottleneck than just CPU power/time.

Another option might be using pre-built td library for the plugin, e.g. downloaded from somewhere trustworthy (and working with Arch libs), and use path to where it's installed with -DTd_DIR= in PKGBUILD. This plugin links it statically, so it won't be needed after the build.

Wrt sqlite3.c I also get those warnings here, seem to be non-critical:

[ 36%] Building CXX object CMakeFiles/tdcore.dir/td/telegram/AttachMenuManager.cpp.o
/usr/src/debug/telegram-tdlib-purple-git/telegram-tdlib-purple-git/td/sqlite/sqlite/sqlite3.c: In function ‘tdsqlite3SelectNew’:
/usr/src/debug/telegram-tdlib-purple-git/telegram-tdlib-purple-git/td/sqlite/sqlite/sqlite3.c:131688:10: warning: function may return address of local variable [-Wreturn-local-addr]
/usr/src/debug/telegram-tdlib-purple-git/telegram-tdlib-purple-git/td/sqlite/sqlite/sqlite3.c:131648:10: note: declared here
[ 36%] Building CXX object CMakeFiles/tdcore.dir/td/telegram/AudiosManager.cpp.o

Hm, worked for me yesterday, but I probably haven't ran "pacman -Syu" in a week or so...

But also, given that it's on a linker step, maybe try nuking build-cache in ~/.cache/yay/telegram-tdlib-purple-git/src/telegram-tdlib-purple-git/td/ or just whole ~/.cache/yay/telegram-tdlib-purple-git - seem to happen to me sometimes too when build tools update, but dunno if it's the same type of issue.

The build gets stuck at

[100%] Linking CXX executable run_all_tests
/home/photon/.cache/yay/telegram-tdlib-purple-git/src/telegram-tdlib-purple-git/td/sqlite/sqlite/sqlite3.c: In Funktion »tdsqlite3SelectNew«:
/home/photon/.cache/yay/telegram-tdlib-purple-git/src/telegram-tdlib-purple-git/td/sqlite/sqlite/sqlite3.c:131688:10: Warnung: Funktion liefert möglicherweise Adresse einer lokalen Variablen zurück [-Wreturn-local-addr]
131688 |   return pNew;
       |          ^
/home/photon/.cache/yay/telegram-tdlib-purple-git/src/telegram-tdlib-purple-git/td/sqlite/sqlite/sqlite3.c:131648:10: Anmerkung: hier deklariert
131648 |   Select standin;
       |          ^

Added -DCMAKE_POLICY_VERSION_MINIMUM=3.5 as a workaround as cmake suggests. Build seem to work, so probably good enough for now.

Thanks for reporting.

Looks like this package has been snagged with Arch's CMake updates, which have removed support for CMake behavior pre-3.5:

~/.cache/yay/telegram-tdlib-purple-git/src/td ~/.cache/yay/telegram-tdlib-purple-git/src/telegram-tdlib-purple-git
HEAD is now at 3870c29b1 Update version to 1.8.21.
~/.cache/yay/telegram-tdlib-purple-git/src/td/build ~/.cache/yay/telegram-tdlib-purple-git/src/td ~/.cache/yay/telegram-tdlib-purple-git/src/telegram-tdlib-purple-git
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.

This should be a simple patch to change cmake_minimum_required() unless upstream explicitly relies on some old behavior. I tried a couple of clean builds to remove stale sources and it's still present, so until upstream updates their CMakeLists a workaround for building for now would be to patch where possible.