Search Criteria
Package Details: pidgin-espeak-git 2019_11_20..210876f-3
Package Actions
Git Clone URL: | https://aur.archlinux.org/pidgin-espeak-git.git (read-only, click to copy) |
---|---|
Package Base: | pidgin-espeak-git |
Description: | espeak plugin for the pidgin IM |
Upstream URL: | https://github.com/coldfix/pidgin-tts |
Licenses: | WTFPL |
Conflicts: | pidgin-tts |
Provides: | pidgin-tts |
Submitter: | core-problem |
Maintainer: | core-problem |
Last Packager: | core-problem |
Votes: | 6 |
Popularity: | 0.000000 |
First Submitted: | 2013-08-06 04:34 (UTC) |
Last Updated: | 2024-10-13 11:18 (UTC) |
Dependencies (5)
- espeakAUR
- glib2 (glib2-gitAUR, glib2-selinuxAUR, glib2-patched-thumbnailerAUR)
- libpurple (pidgin-mam-gitAUR, pidgin-hgAUR, pidgin-miniAUR, libpurple-gnutlsAUR, libpurple-minimalAUR)
- pidgin (pidgin-mam-gitAUR, pidgin-hgAUR, pidgin-miniAUR, pidgin-gnutlsAUR)
- git (git-gitAUR, git-glAUR) (make)
Latest Comments
core-problem commented on 2024-10-13 11:19 (UTC)
Many thanks for your efforts, I've gone through the list and pushed fixes.
micwoj92 commented on 2024-10-12 23:46 (UTC) (edited on 2024-10-12 23:47 (UTC) by micwoj92)
I've gone through all. This is last, additional explicit depends:
'glibc' 'glib2' 'libpurple'
Also, since this invokes
espeak
binary, it should be possible to change toespeak-ng
, it would be better as -ng version is in repos, where old espeak is in aur.core-problem commented on 2024-10-12 22:10 (UTC)
sure, that would be great, thank you
micwoj92 commented on 2024-10-12 21:53 (UTC)
Thanks for quick fix, would you mind if I went through your other packages to check for simple packaging issues?
core-problem commented on 2024-10-12 20:40 (UTC)
I'm sorry you are right. I seem to have misread/remembered that section.
micwoj92 commented on 2024-10-12 20:33 (UTC)
No. This is not what "any" means. Please read: https://wiki.archlinux.org/title/PKGBUILD#arch
core-problem commented on 2024-10-12 14:29 (UTC)
@micwoj92: "any" means that the package can be built for any architecture, not that the final build artifacts (in this case the .so) will be independent of the architecture.
And while I haven't tried building it for other architectures myself so far, I am not aware of anything to suggest that it would not be possible on any particular arch - which is why I wouldn't limit the package to any particular architecture beforehand. So "any" seems to be justified to me?
micwoj92 commented on 2024-10-12 14:21 (UTC)
Package shouldn't be 'any' architecture as it contains .so file.