The Replicant project calls for the Android SDK to be included in Trisuqel. Can you help?
- Inicie sesión ou rexístrese para enviar comentarios
Hello everyone,
here's the announcement:
http://blog.replicant.us/2017/04/there-wont-be-a-replicant-6-0-sdk-because-there-is-already-something-better/
Basically, the Replicant project won't be maintaining a libre version of the Android SDK anymore.
The reason is that it will be included in the next Debian release by default, so it makes no sense to waste time and resources to the same job.
The hope is for Trisquel to follow up on that, and to include all the free fundamental parts of the SDK in the upcoming Trisuqel 8.
Please, read the announcement and join the effort, if you can!
Replicant people will be available for helping, if required.
Happy hacking,
Fil
It will be in Trisquel 8: http://archive.trisquel.info/trisquel/pool/main/a/android-sdk-meta/
Thanks for pointing out.
Unfortunately, it seems the SDK packed in Trisquel 8 could be incomplete. Here's an extract from Replicant's mailing list, where Wolfgang, the main developer, states this:
It looks like the next release of Trisquel (8.0 Flidas) will be based on Ubuntu 16.04. Ubuntu 16.04 has the android-sdk packaged[3], but it's not complete as some packages didn't make it in time. android-sdk-platform-23 which is the actual target platform is only in Zesty (17.04)[4]. Are there some Trisquel folks reading along that could chime in on this? Would it be possible to get the rest of the needed Android packages included in Flidas by backporting them from newer Ubuntu releases? Are there other procedures to get packages uploaded and included in a Trisquel release?
Wolfgang also told me, that:
Likely a manual upload of the packages built from this source package is needed: https://packages.debian.org/source/stretch/android-framework-23
So, I relaunch the call:
Is there any community member which could work on adding the missing part of the SDK to Trisuqel 8?
You'll have to ask quidam. This is a one-man project.
Correction: Someone will need to create an account on https://devel.trisquel.info and create a merge request, which can be approved by any of the project admins (And if you'll notice it's possible to find merged requests from mtsio, Kevin, Andrew, Isaac, Legimet, Harry, Casey, etc. so it's hardly a one-person project.) So the question remains: Who will submit the merge request to get it into Trisquel 8?
> Correction: Someone will need to create an account on https://devel.trisquel.info and create a merge request.
Yeah exactly. But how long does it take for the merge requests to be reviewed? In practice, it would be called a one-man project as Legimet indicated.
PS: Just as a reminder: https://listas.trisquel.info/pipermail/trisquel-devel/2017-January/001031.html
There isn't much motivation for people to do that, because they take forever to be reviewed. In effect, a one-man project for now.
Sounds like a very defeatist argument. And also a self-fulfilling prophecy at the same time. You're not going to do it because it'll take forever to be merged and so it's never submitted and so it never happens and you get to prove yourself right. And so, no one will even try? That guarantees it won't make it in.
Two people currently have access to merge things:
https://devel.trisquel.info/groups/trisquel/group_members
I'm still waiting to see the person that steps up and starts making high quality code contributions to the project and can be trusted to merge things on their own. quidam once offered access to me; I didn't pursue it. That alone shows he's open to other people, and that's usually how it works in free software projects: People are usually not granted high level access when they first show up, nor for drive-by commits. There needs to be a sustained pattern of high quality long-term code contributions over time.
But anyway, I am getting off my original point. The only reason I chimed in was because Fil asked "Is there any community member which could work on adding the missing part of the SDK to Trisuqel 8?" to which legimet said "You'll have to ask quidam." And that isn't entirely true. Yes, quidam (or aklis) will need to approve the merge, but doing the technical work in advance so that all they need to do is approve the merge will go a long way toward increasing the chances that it actually happens. It's not necessary to defer the *entire thing* to quidam, as legimet originally suggested. In fact, doing that will probably work against the desired outcome by giving quidam extra work to add to his already full plate, and thereby help to ensure that it *doesn't* happen. So, who will help increase the chances that his happens by getting the technical work done and sending it in? Are there any takers? Hopefully there is someone and not just the naysayers or I agree that this task will probably not ending up happening. Anyone?
Two people currently have access to merge things
The second person is aklis... who is not more optimist. See his last post on this forum: https://trisquel.info/forum/forum-or-subforum-dedicated-only-code-contributors#comment-113923
Have you seen the queue of merge requests? https://devel.trisquel.info/groups/trisquel/merge_requests
I am not going to work on this when it is unlikely to be even merged. If you are so optimistic about it, why don't you do it?
"If you are so optimistic about it, why don't you do it?"
I'm too busy for it. It does seem a neat idea though.
Other possibility is, instead of depending on a "one version per package
only" package manager, is to package this to Guix. However, I must note
that I'm not a developer, and I don't know how well an "SDK" is tied to
the operating system. This "tieying" is important to note because, even
though the SDK can be packaged to Guix, it might need system services or
other things that cannot be specified in the Guix recipe (but can be
defined as GuixSD services, or be left for the non-GuixSD users to
provide).
Also, Guix isn't held to "being based off of [Some distro]", because it
tries to provide the base packages for it's own, GuixSD. Although the
Guix package recipes can be used in any GNU+Linux system distribution
--- except for the GuixSD services.
--
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
/software/ livre. Favor entrar em contato em caso de dúvida.
- Inicie sesión ou rexístrese para enviar comentarios