anthonybilinski / tox.pkg Goto Github PK

Create an OBS account with repos setup for appropriate arches. Focus on supporting any non-EOL Debian, xUbuntu, Fedora, Opensuse for now.

qTox has moved to toktok due continuing development. Move build source for OBS as well.

There are some architectural choices in abbat's tox.pkg that I don't understand.

• naming all generic dependencies like ffmpeg, libvpx as tox-ffmpeg and tox-libvpx

I'm wondering if this is to allow the packages to be built containing only the libs needed for the build servers to compile qTox, but not complete enough to replace user's system packages, which would take place if they had generic names and were newer than those provided by system repos.

• tox-prefixed file locations, like /usr/tox/lib, /usr/tox/include

@abbat I'm wondering if you could help me out and confirm/deny if my speculation is right.
If people have input on how to provide dependencies without having users be able to install them, let me know.

If the prefixing is to prevent users from installing the packages and have them only used by the build servers, I'm wondering if there's a way to better remove them as install options for users. i.e. keep them with their original names but in a different location so that they aren't added as install options when a user adds the repo for qTox.

I think it's pretty clear that we can't support all Linux distributions so we need to define a set of target distributions to cover a maximum of users with a reasonable amount of work.

To start the discussion I suggest the following list of distributions:

• OpenSUSE Leap 42.3
• OpenSUSE Tumbleweed
• Debian Stretch
• Ubuntu 16.04 LTS
• Ubuntu 17.04
• Fedora 25
• Fedora 26

I didn't include Arch Linux, because they seem to have a working build from git in the AUR.

Additionally, we shouldn't intentionally break something for other distributions.

Update maintainer info in all build scripts to point to either me for the time being, possibly the qTox organization in the future, instead of abbat, to prevent him from getting spammed from our broken builds :P

There are multiple qTox patches maintained in the packaging scripts. I'm not sure if there are still needed to fix issues, but if they are I think the issues should be fixed upstream in qTox instead of being maintained in parallel in tox.pkg.

qTox has deprecated the use of qmake and its qtox.pro. Use the recommended cmake build.