Jami version in the Trisquel 8 repos is still called Ring
- Inicie sesión ou rexístrese para enviar comentarios
The Trisquel 8 repos have a version of Jami so old it's still got the Ring branding. It's really not helpful to have this kind of thing in the repos. Is it possible to backport a newer version? If not, it probably makes sense to just remove it from the repos
Also, I went to the Jami download page to try to add their repo, so I can get a more updated version, but I'm a bit confused. They only have manual install instructions for various versions of Ubuntu, Debian, and Fedora, and I suspect my browser isn't displaying the page properly, because whichever I select, the instructions are exactly the same. That doesn't seem right. I've asked on the fediverse for the Jami team to add instructions for Trisquel and mentioned the display problem I'm having with the website.
> Also, I went to the Jami download page to try to add
> their repo, so I can get a more updated version, but
> I'm a bit confused. They only have manual install
> instructions for various versions of Ubuntu, Debian,
> and Fedora
On this page,[1] you should be able to click on the link that says
"Ubuntu 16.04 (64-bit)" or "Ubuntu 16.04 (32 bit)" (depending on your
architecture). If you have gDebi installed, Abrowser should offer to
open the deb package in gDebi. Alternatively, you can install it via
the command line with
$ sudo dpkg -i /path/to/package.deb
> On this page,[1] you should be able to click on the link that says
> "Ubuntu 16.04 (64-bit)" or "Ubuntu 16.04 (32 bit)" (depending on your
> architecture).
In case for some reason you can't see these links (although I can see them
just fine in Icecat with JS blocked, so I can't think of a reason you
wouldn't), here are directly links to the deb packages.
64-bit: https://dl.jami.net/ring-manual/ubuntu_16.04/ring-all_amd64.deb
32-bit: https://dl.jami.net/ring-manual/ubuntu_16.04/ring-all_i386.deb
I did see the .deb downloads. But doesn't this mean I'll have to manually download and reinstall again every time there's a new release? Not having to micromanage app versions is one of the reasons GNU/Linux is such a pleasure to use compared to Windows ;)
That's why I wanted to add their repo instead. But as I mentioned in the OP, I'm a bit confused about how to do that.
> The Trisquel 8 repos have a version of Jami so old it's still got the
> Ring branding. It's really not helpful to have this kind of thing in
> the repos. Is it possible to backport a newer version? If not, it
> probably makes sense to just remove it from the repos
Ubuntu 16.04 (and thus Trisquel 8) is based on a 2016 snapshot, so with
the exception of Firefox/Abrowser and packages which have been
specifically backported, everything in Trisquel's repositories is the
same age as the this version of Ring/Jami. If we were to start removing
or backporting packages just because they are old, it would have to be
basically the entire distro. I think it is only worth doing this for
packages whose version in the repos has a specific problem.
Are you worried that the package being under its old name will be
confusing for users looking for Jami? If so, that might be a good
enough reason to backport it. It looks like the name change is
relatively recent. Ubuntu 18.04 (and thus Trisquel 9) still calls the
package "ring". It wasn't until Ubuntu 19.04 that "ring" became a
transitional package that points to "jami", so without any backporting
it will not be until Trisquel 10 that "jami" is in the repos.
Since Ring is in Ubuntu's Universe repository, it does not receive
security updates from Canonical, so if there are known security issues
then that would also be a reason to backport. (We do this with Tor, for
example). Are you aware of any issues like this?
Chaosmonk:
> I think it is only worth doing this for packages whose version in the repos has a specific problem.
I understand that backporting adds a lot of work that I don't have the skills to volunteer for (although I'm willing to learn with some mentorship). But I think Jami is a strong candidates for backporting.
1) As you say, the name. Users looking to install Jami from the repos may not realize they need to install a package called "ring".
2) ensuring best possible first impressions of a GNU package that is on the FSF list of high priority projects. A number of improvements have been made to the Jami UX since the ring version in the repos. Eg in that version, a message sent to a user who is offline immediately fails. In the current version, the message instead goes into a queue, to be delivered next time the other user comes online at the same time as the sending user.
3) Similar reasons to Tor. Jami intends to deliver an end-to-end encrypted communications app. Supplying long out-of-date versions may lead to avoidable breaches of communications privacy for anyone who uses them.
Given these reasons, I think it would be best not to have Jami in the repos at all, and direct users to the Jami site for downloads, than to include obsolete versions.
> I understand that backporting adds a lot of work that I don't have the
> skills to volunteer for (although I'm willing to learn with some
> mentorship).
It would probably take less time for me to do it myself, but if you are
really willing to learn how to do it, I would much prefer to take the
time to walk you through it, both so that you know how to do so for the
future, and because I feel that there is an unfortunate disconnect
between Trisquel development and the Trisquel community, and would like
for more community members to feel comfortable contributing. There are
so few contributors to Trisquel, that even minor contributions make a
large difference.
What follows might seem like a lot of information, but none of it
requires any programming skills, and I'm happy to provide as much time
and guidance as you need. I can do so through this thread, or if you
would prefer more interactive help we can do so over IRC. I understand
that you cannot make the Friday meetings, but we can arrange another
time during which our waking hours overlap. My time zone is PST.
First you'll need to set up the sbuild workflow to build and test the
backported package. See the contributing guide to learn how.[1] If any
steps are unclear, please say so. This is the first barrier to entry
for getting involved in Trisquel development, so any feedback on how to
make it more accessible would be very valuable.
There is already a package helper for ring, so you'll be modifying
helpers/make-ring[2] with your preferred text editor.
(Note that although Ring has been renamed to Jami, the source package is
still called "ring".[3] In case you're unaware of the distinction
between source and binary debian packages, a binary (deb) package is
what users actually install, and a source package is used to build
binary packages. The name of a binary package might be different from
the name of it's source package, and a source package might provide
multiple binary packages. For example, the "ring" source package builds
four binary packages: jami, jami-daemon, ring, and ring daemon. If you
are ever unsure which source package provides a binary package, run "apt
showsrc $PACKAGE", where $PACKAGE is the name of the binary package.)
Here's a breakdown of this package helper:
* The file name determines which source package gets built. Since the
name of the ring source package has not changed, you don't need to
change the filename. If you ever write a new package helper from
scratch, the file name should be "make-$SOURCEPACKAGE".
* You should update the license header. Immediately below the line
containing Ruben's name and email address, add another line containing
your own.
* The commented lines between the license header and "VERSION" are
listing build dependencies of ring. This is helpful to keep track of
when backporting, because some times the target version of Trisquel does
not meet the dependencies of the newer version of the package you are
backporting, and so you need to backport one or more dependencies as
well.
* "VERSION=1" means that this is the first Trisquel revision of the
package. It makes it so that the version string of the package will
have +8.0trisquel1 appended. When you create a new revision, you should
increase the revision number by 1.
* "EXTERNAL=" determines which repository to grab the original source
package. If this line is absent, then the target Trisquel version's
upstream (xenial in the case of flidas) will be used, so this line is
only needed for backporting or importing from another repository. The
format of this line is the same as that in /etc/apt/sources.list. As
you can see, ring *should* be backported from Ubuntu disco already.
* "REPOKEY=" is the gpg key of the external repository. This line is
only needed when "EXTERNAL=" is used.
* ". ./config" runs a script which downloads and extracts the source
package.
* Everything in between ". ./config" and "changelog" modifies the source
code. In this case, the only change to the upstream code is done by the
"sed" line. I don't think you need to understand what it does at this
point, so I'll gloss over it for now to avoid overwhelming you with too
much information.
* "changelog" summarizes Trisquel's changes to the package. This line
reveals that ring was originally backported from cosmic, and should
probably be updated to say "Disco".
* "compile" builds a new source package from the modified source code.
So what do you need to do?
(1) Make a branch for your change, as per the contributing guide.
(2) Add your copyright info below Ruben's.
(3) Bump the version number from 1 to 2. (I'm actually not 100% sure
that this is necessary for a backport, since the backported version
should have a higher version number anyway, but let's do it to be safe.)
(4) It would be nice to be able to use Jami's apt repository for Ubuntu
16.04, which should always have the latest version without us needed to
keep updating the helper every time there is a new Ubuntu release
Unfortunately, their repository only provides binary packages (debs),
and not source packages (dsc, tar.gz),[5] which are what the package
helper needs. Instead, just change "disco" to "eoan" in the "EXTERNAL"
line and change "Cosmic" to "Eoan" in the "changelog" line.
(5) Run "bash make-ring" and see if you get any errors. If you get
errors, I let me know any I will help you figure out what needs to be
done. The most likely error is an unmet dependency. If you get no
errors, proceed.
(6) Use the source package you just generated to compile binary packages
using sbuild, as per the contributing guide. Again, if you get errors
let me know. If not, proceed.
(7) Test the jami and jami-daemon binary packages and to make sure that
there are no problems.
(8) If everything looks good, push your branch to Gitlab an open a merge
request.
[1]
https://devel.trisquel.info/trisquel/package-helpers/blob/flidas/CONTRIBUTING.md
[2]
https://devel.trisquel.info/trisquel/package-helpers/blob/flidas/helpers/make-gutenprint
[3] https://packages.ubuntu.com/source/eoan/ring
[4] https://packages.ubuntu.com/source/cosmic/ring
[5] https://dl.jami.net/ring-nightly/ubuntu_16.04/pool/main/r/ring/
> There is already a package helper for ring, so you'll be modifying
> helpers/make-ring[2] with your preferred text editor.
Sorry, link [2] is wrong. (Before I saw that there was already a
package helper for ring I was going to suggest using the one for
gutenprint as a template.) Here is the link to make-ring:
https://devel.trisquel.info/trisquel/package-helpers/blob/flidas/helpers/make-ring
Thanks Chaosmonk for the details instructions. Is there a generic version of them on the wiki? If you want to get more people involved in Trisquel dev, it might help to make it very easy to find a list of entry level tasks like this, with links to detailed information on how to carry them out.
Anyway, I'm happy to have a crack at this. I often find myself grumbling about out-of-date apps in the Trisquel repos so it would be great to be able to help solve the problem. It will take me some time to carefully read your instructions and have a look at all the links. If I get stuck, I'll ask some questions here, and as you say, these sticking points can be used to improve the instructions for others.
I would appreciate being able to communicate with you on Jabber, Matrix, or the fediverse if you use any of these. My contact info can be found here:
https://www.coactivate.org/projects/disintermedia/danyl-strype/
(or if CoActivate is misbehaving, here: https://wiki.p2pfoundation.net/Danyl_Strype)
> Is there a generic version of them on the wiki? If you want to get
> more people involved in Trisquel dev, it might help to make it very
> easy to find a list of entry level tasks like this, with links to
> detailed information on how to carry them out.
The contributing guide I linked to is the only documentation I'm aware
of. It explains the steps common to all package helpers, but nothing
specific about the helpers themselves. Maybe it would be a good idea to
have some specific guides about how to write different kinds of helpers,
especially some of the beginner-level ones like modifying package
metadata, trivial backports, and simple rebranding. Perhaps seeing what
is clear/unclear in the Jami walkthrough can inform a more general
backporting guide.
> I would appreciate being able to communicate with you on Jabber,
> Matrix, or the fediverse if you use any of these.
Jabber is usually the best way to reach me. I'll send you a message.
> > I would appreciate being able to communicate with you on Jabber,
> > Matrix, or the fediverse if you use any of these.
>
> Jabber is usually the best way to reach me. I'll send you a message.
I sent a message to your jabber.org address. If you didn't receive it
let me know.
FWIW Linphone is another comms app that relies on E2EE to protect user privacy. The version in the 8.0 repos is 3.6.1 and seems to have a number of bugs when trying to add or connect to accounts on Linphone.org. The latest version according to Wikipedia is 4.1.1. The SFD lists a stable 3.7.0 release, which may or may not be the most recent stable release in the 3.x branch. This is another candidate for backporting or removing from the repos.
> FWIW Linphone is another comms app that relies on E2EE to protect user
> privacy. The version in the 8.0 repos is 3.6.1 and seems to have a
> number of bugs when trying to add or connect to accounts on
> Linphone.org. The latest version according to Wikipedia is 4.1.1. The
> SFD lists a stable 3.7.0 release, which may or may not be the most
> recent stable release in the 3.x branch. This is another candidate for
> backporting or removing from the repos.
I use Linphone regularly. JMP is my SIP provider, not Linphone.org, and
I have not experienced any problems. I would be fine with backporting a
newer version, but I would be annoyed if the current version were
removed from the repos without being replaced. Removing a package from
the repos is pretty invasive. Even if a package seems useless to you,
you cannot be certain that it is not important to another user. As a
general policy, I think that we should only remove packages which (a)
have freedom issues which are either impossible or too costly to fix
or (b) are Ubuntu-specific.
The approach to backporting Linphone will be similar to that for
bacporting Jami. There does not appear to be a PPA or apt repository
packaging the latest version for Ubuntu 16.04, so we will backport it
from a later version of Ubuntu. Let me know when you want to work on
this and I'll walk you through it.
chaosmonk:
> Even if a package seems useless to you, you cannot be certain that it is not important to another user.
Fair enough. I'd definitely prefer updated to removed. But I do worry about distributing obsolete versions of software whose homepages make strong security claims that may no longer be justified in older versions. I'm particularly concerned about this as it applies to communications apps and their dependencies.
> The approach to backporting Linphone will be similar to that for bacporting Jami.
OK. I just found out that two time-consuming tasks have been taken off my plate, so I may be able to carve out some time for learning about backporting during the week.
FYI I have opened an issue on the Jami issue board politely making the case for making Trisquel the 8th distro that officially support and include on their download page:
https://git.jami.net/savoirfairelinux/ring-project/issues/733
Really nice move, Strypey. I support that immediately & good thing I
have a GitLab account.
Trisquel is now officially supported by Jami!
https://jami.net/download-jami-linux/
I just tried to follow the manual instructions using 64-bit Trisquel 8.0. Everything seemed to be working until I got to:
sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/jami-archive-keyring.gpg] https://dl.jami.net/nightly/ubuntu_16.04/ ring main' > /etc/apt/sources.list.d/jami.list"
It didn't seem to do anything and I was left sitting on a ">" prompt. I checked my sources list and nothing seems to have been added. There may be something I don't understand here, but "sh" doesn't seem to be a program on my system, and I can't find anything called that in the Trisquel repos. Is there something missing in this command?
If this is a user error on my part, please help! If you can see something that needs to be fixed, please share that info here:
https://git.jami.net/savoirfairelinux/jami-packaging/issues/39
BTW that command was cut'n'pasted verbatim from :
https://jami.net/download-jami-linux/#manual-install
Ignore this, it seems like it was either a race conditions bug or, most likely, user error (although I still can't figure out what I did wrong the first time). I now have the repo added and apt update is loading from it, but I can't actually install Jami due to dependency problems. See the discussion at:
https://git.jami.net/savoirfairelinux/jami-packaging/issues/39
- Inicie sesión ou rexístrese para enviar comentarios