1:21 p.m.
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?
7:43 p.m.
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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
2:44 a.m.
After looking at the link you provided, it's easy to see that we must
have Android SDK packaged which is non-free IMO.
11:01 a.m.
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(a)mit.edu>:
On Mon, Jun 2, 2014 at 12:44 AM, Christopher Meng
<cickumqt(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
6:16 p.m.
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
6:32 p.m.
On Thu, Jun 5, 2014 at 4:16 PM, Kevin Kofler <kevin.kofler(a)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
9 p.m.
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
12:23 a.m.
On Fri, Jun 6, 2014 at 4:00 AM, Rex Dieter <rdieter(a)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.
9:36 p.m.
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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
11:53 p.m.
On Sun, Jun 8, 2014 at 8:36 PM, Isaac Cortés González <
w.isaac.cortes(a)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.
11:50 a.m.
El jun 8, 2014 10:53 PM, "Eric Smith" <spacewar(a)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?
6:49 p.m.
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
12:09 a.m.
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
4:32 a.m.
On Tue, Jun 10, 2014 at 5:49 PM, Kevin Kofler <kevin.kofler(a)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".
3605
days inactive
3625
days old
18 comments
8 participants
participants (8)
-
Andrew Lutomirski -
Christopher Meng -
drago01 -
Eric Smith -
Kevin Kofler -
Lain Cortés González -
Orcan Ogetbil -
Rex Dieter