This may be a repeated topic. But is there any effort to add to the repos the packages of Qt to develop for Android? If there isn't how can I help?
I don't really know. I've been looking and in the download page, and there's a package, named qtandroidextras-opensource-src-5.x.x.tar.XXX; but there's that much explanation if it is the core for develop in android, or addons to the core (the "extras" part in the name confuses me); then I found this page (http://qt-project.org/wiki/Qt5ForAndroidBuilding), on that page, summarizing it, they talk of how to build it from the entire sources (with no split sources), it mentions that you need the Android NDK and SDK; at first I though it could be a trouble ; then I remembered that those packages are licensed in Apache license, they even have a git repository for each one.
Another "but" or thing to be considered is the fact if "we" (I don't know if there's any "I" in we) need to package those too, or not. So, since I'm practically kind of an illiterate in this thing called rpm and packaging, I don't if this can be done, or going further if I can be of some help; but be sure of these:
1) If I can help, hell I'll do! 2) It will be great news for the developers out there using fedora as a primarily OS.
-Isaac C.
2014-05-26 6:39 GMT-06:00 Rex Dieter rdieter@math.unl.edu:
Isaac Cortés González wrote:
This may be a repeated topic. But is there any effort to add to the repos the packages of Qt to develop for Android? If there isn't how can I help?
What "packages of Qt" does this include?
-- Rex
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
After looking at the link you provided, it's easy to see that we must have Android SDK packaged which is non-free IMO.
On Mon, Jun 2, 2014 at 12:44 AM, Christopher Meng cickumqt@gmail.com wrote:
After looking at the link you provided, it's easy to see that we must have Android SDK packaged which is non-free IMO.
It's plausible that Qt5 could be buildable against Replicant, though.
--Andy
But it is licensed under an Apache license, we can download the source and build it ourselves.
-Isaac C.
2014-06-02 12:14 GMT-06:00 Andrew Lutomirski luto@mit.edu:
On Mon, Jun 2, 2014 at 12:44 AM, Christopher Meng cickumqt@gmail.com wrote:
After looking at the link you provided, it's easy to see that we must have Android SDK packaged which is non-free IMO.
It's plausible that Qt5 could be buildable against Replicant, though.
--Andy
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Isaac Cortés González wrote:
But it is licensed under an Apache license, we can download the source and build it ourselves.
Yes, please contact the Replicant folks for how to rebuild the Android SDK from source. (Last I checked, they didn't document the procedure either, but they should know how to do it because they ship a rebuilt SDK.) We cannot ship Google's binaries, both because of the license of the binaries and because Fedora does not ship upstream binaries by policy. We have to build the SDK from source code (which will land in the SRPM, so it needs to be free from non-Free or patent-encumbered (e.g. MP* codecs) code; any bad code needs to be ripped out from the tarball).
Kevin Kofler
On Thu, Jun 5, 2014 at 4:16 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Isaac Cortés González wrote:
But it is licensed under an Apache license, we can download the source and build it ourselves.
Yes, please contact the Replicant folks for how to rebuild the Android SDK from source. (Last I checked, they didn't document the procedure either, but they should know how to do it because they ship a rebuilt SDK.) We cannot ship Google's binaries, both because of the license of the binaries and because Fedora does not ship upstream binaries by policy. We have to build the SDK from source code (which will land in the SRPM, so it needs to be free from non-Free or patent-encumbered (e.g. MP* codecs) code; any bad code needs to be ripped out from the tarball).
The ripping things out of tarballs policy seems really weird to me. It means, for example, that I can't compare the hash of the openssl tarball to upstream's.
Is it really necessary? I understand that Fedora can't ship anything infringes on a patent, but I had the distinct impression that patents didn't cover uncompiled source code. It would be a lot simpler if it were sufficient to merely patch it out in %prep or something.
Even for not-quite-free stuff, there are weird cases. For example, globalplatform's tarball [1] includes a couple of binaries. There is actually source available, and the license is fine, but the source isn't in the tarball. [2] I seriously doubt that Fedora would infringe on anyone's rights by leaving the tarball as is in the SRPM, but doing so is currently against policy. The binary RPMs would be identical either way.
Of course, if there is actually stuff in the tarball that isn't redistributable, that's a different story.
If this is something that shouldn't be discussed here, I'll shut up.
[1] I'm thought about resurrecting this package, but dealing with hacked up tarballs is such a mess that I don't really want to.
[2] I've never actually tried to build the thing, but I wouldn't want to install the binary on anyone's system anyway.
--Andy
Andrew Lutomirski wrote:
The ripping things out of tarballs policy seems really weird to me. It means, for example, that I can't compare the hash of the openssl tarball to upstream's.
Is it really necessary? I understand that Fedora can't ship anything infringes on a patent, but I had the distinct impression that patents didn't cover uncompiled source code.
Your impression is incorrect, afaik, ianal, yada yada. Everything fedora ships needs to be freely re-distributable, including the source code.
-- Rex
On Fri, Jun 6, 2014 at 4:00 AM, Rex Dieter rdieter@math.unl.edu wrote:
Andrew Lutomirski wrote:
The ripping things out of tarballs policy seems really weird to me. It means, for example, that I can't compare the hash of the openssl tarball to upstream's.
Is it really necessary? I understand that Fedora can't ship anything infringes on a patent, but I had the distinct impression that patents didn't cover uncompiled source code.
Your impression is incorrect, afaik, ianal, yada yada.
[citation needed]
Everything fedora ships needs to be freely re-distributable, including the source code.
Well he said " Of course, if there is actually stuff in the tarball that isn't redistributable, that's a different story." ..
We have been shipping patented code in freetype for a while (until it expired) we just disabled it at build time.
So I simply do not know whether the "remove patented code from he tarball" is simply paranoia or there is really a legal reason for it.
So it's more a reason of manpower than any other thing. The question would be: is there any to accomplish this task?
I can look for any "patented" or closed source software and if any of them are critical to build the SDK and NDK. Also I'll ask to the Replicant project for any hint/tip on this. El jun 7, 2014 2:28 PM, "Rex Dieter" rdieter@math.unl.edu escribió:
drago01 wrote:
So I simply do not know whether the "remove patented code from he tarball" is simply paranoia or there is really a legal reason for it.
I've been asked by fedora-legal to remove stuff from tarballs on multiple occasions for this reason.
-- Rex
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Sun, Jun 8, 2014 at 8:36 PM, Isaac Cortés González < w.isaac.cortes@gmail.com> wrote:
I can look for any "patented" or closed source software
IANAL, but multiple lawyers have told me that it is generally a bad idea to go looking for patents, at least in the US. If they're brought to your attention, you should probably do whatever is necessary to avoid them, but you shouldn't actively seek them out, even just to try to confirm that you're not using anything patented.
El jun 8, 2014 10:53 PM, "Eric Smith" spacewar@gmail.com escribió:
IANAL, but multiple lawyers >have told me that it is generally >a bad
idea to go looking for >patents, at least in the US. If >they're brought to your >attention, you should probably >do whatever is necessary to >avoid them, but you shouldn't
seek them out, even just to try >to confirm that you're not using anything patented.
So, should I just clone the git repositories and build from those raw sources?
Eric Smith wrote:
IANAL, but multiple lawyers have told me that it is generally a bad idea to go looking for patents, at least in the US. If they're brought to your attention, you should probably do whatever is necessary to avoid them, but you shouldn't actively seek them out, even just to try to confirm that you're not using anything patented.
Hunting for patents is one thing (I wouldn't recommend it either), but looking for obviously patent-encumbered stuff (like MP3 codecs) is another.
Kevin Kofler
On Tue, Jun 10, 2014 at 7:49 PM, Kevin Kofler wrote:
Eric Smith wrote:
IANAL, but multiple lawyers have told me that it is generally a bad idea to go looking for patents, at least in the US. If they're brought to your attention, you should probably do whatever is necessary to avoid them, but you shouldn't actively seek them out, even just to try to confirm that you're not using anything patented.
Hunting for patents is one thing (I wouldn't recommend it either), but looking for obviously patent-encumbered stuff (like MP3 codecs) is another.
That's not quite obvious anymore. Most MP3 patents have expired by now. Whether any of the remaining handful of patents are violated by an MP3 codec implementation needs some non-trivial consideration.
Orcan
On Tue, Jun 10, 2014 at 5:49 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Hunting for patents is one thing (I wouldn't recommend it either), but looking for obviously patent-encumbered stuff (like MP3 codecs) is another .
Unfortunately it is generally not obvious what things are "obviously patent-encumbered".