tmux

Rating: 
5
Your rating: None Average: 5 (1 vote)

NOTE: There is already a tmux version here maintained by Kabouik which includes some extra plugins.

About tmux

tmux is a program which runs in a terminal and allows multiple other terminal programs to be run inside it. Each program inside tmux gets its own terminal managed by tmux, which can be accessed from the single terminal where tmux is running - this called multiplexing and tmux is a terminal multiplexer.

tmux - and any programs running inside it - may be detached from the terminal where it is running (the outside terminal) and and later reattached to the same or another terminal.

Programs run inside tmux may be full screen interactive programs like vi(1) or top(1), shells like bash(1) or ksh(1), or any other program that can be run in a Unix terminal.

There is a powerful feature set to access, manage and organize programs inside tmux, both interactively and from scripts.

The main uses of tmux are to:

  • Protect running programs on a remote server from connection drops by running them inside tmux.
  • Allow programs running on a remote server to be accessed from multiple different local computers.
  • Work with multiple programs and shells together in one terminal, a bit like a window manager.

See also:

https://tmux.github.io/

EXTRA DEPENDENCIES (they will auto resolve if you have the repo enabled):

libevent >= 2.1.11

ncurses >= 6.1 (already present in default SFOS repos)

Category:

Keywords:

Application versions: 
AttachmentSizeDate
File tmux-3.1b-1.armv7hl.rpm267.56 KB13/06/2020 - 00:20
Changelog: 

* 3.1b-1 (tmux 3.1b) compiled for SFOS 3.x (armv7hl)

Comments

Kabouik's picture

Hey Pamoedo, there is already a package for tmux 3.1b that I uploaded a couple weeks ago, bundled with some key plugins (tpm, tmux-resurrect, tmux-sensible). Since it's the same version, I'm not sure it's a good idea to have concurrent packages.

Is that fine with you if I just upgrade mine to use the same libevent version you require for telegram-cli?

pamoedo's picture

Absolutely, please go ahead and recompile your tmux with latest libevent, if you need just copy my libevent package into your repository to enable auto resolution when installing your version of tmux. This is something openrepos should improve, cross-repositories dependencies, to avoid duplicating libraries everywhere.

Regarding concurrent packages, well, I'm afraid this is one the good things of open source, I don't think it will cause any harm to have multiple alternatives of the same application but like yours has more plugins what I will do is to put a note in this tmux version recommending yours instead ok?

NOTE: Instead of removing it, I will change the type of the package to libraries, on this manner my tmux version will disappear from the main page of Storeman but still be searchable if needed.

Regards.

Kabouik's picture

Sounds good, thanks Pamoedo. I don't think it's an issue to have concurrent packages when they offer different version of the binary, but here we're both shipping 3.1b so that'd be confusing (even without the plugins).

I recompiled using libevent 2.1.11, but turns out `zypper install` on the new package complains about `libevent-2.1.so.7` not being provided, while it is actually there in `/usr/lib/` when I install your libevent package. Do you have any idea what could be wrong in my spec file? I added `livevent >= 2.1.11` as a requirement, and if I force the installation of tmux, everything works. It's just rpm that fails to find what provides the dependency.

pamoedo's picture

It should be `libevent >= 2.1.11`, I think you have a typo in the spec file.

Kabouik's picture

No, unfortunately the typo is only here in my comment. The spec file reads: "Requires: libevent >= 2.1.11-1, ncurses >= 6.1", but I also tried with just "Requires: libevent = 2.1.11" and other variations and had the same issue. Yet the libevent 2.1.11 package is now available on my repo, and anyway I have you repo enabled too.

What are the Requires/Obsoletes/Conflicts fields in your tmux spec file? Does your libevent package explicitly "Provides:" libevent-2.1.so.7?

pamoedo's picture

Have you also tried to remove first all previous libevent packages that you have installed? maybe there is some kind of conflict between them.

pamoedo's picture

Here you have some details in case they can help you:

$ rpm -qp tmux-3.1b-1.armv7hl.rpm --requires
libevent >= 2.1.11
ncurses >= 6.1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

---

$ ls libevent-2.1.11-stable/fakeinstall/usr/lib/
libevent-2.1.so.7            libevent.la
libevent-2.1.so.7.0.0        libevent_openssl-2.1.so.7
libevent.a                   libevent_openssl-2.1.so.7.0.0
libevent_core-2.1.so.7       libevent_openssl.a
libevent_core-2.1.so.7.0.0   libevent_openssl.la
libevent_core.a              libevent_openssl.so
libevent_core.la             libevent_pthreads-2.1.so.7
libevent_core.so             libevent_pthreads-2.1.so.7.0.0
libevent_extra-2.1.so.7      libevent_pthreads.a
libevent_extra-2.1.so.7.0.0  libevent_pthreads.la
libevent_extra.a             libevent_pthreads.so
libevent_extra.la            libevent.so
libevent_extra.so            pkgconfig

 

I think the problem is in the iteration version, you shouldn't include "-1" in the dependency spec, just "2.1.11", try with that. Sorry, just re-read your message and saw you have also tried without iteration version, then I'm not sure where the problem can be.

Kabouik's picture

There must be something that differs with rpmbuild's auto-detection of dependencies when building on device (my case) and cross-compiling (your case), because my tmux package seems to require both libevent >= 2.1.11 and libevent-2.1.so.7 (yet the package does create the .so.7 file) but fails to find the link between them:

$ rpm -qp RPMS/armv7hl/tmux-3.1b-2.armv7hl.rpm --requires
[…]
libevent >= 2.1.11
libevent-2.1.so.7
[…]

I'm not sure what I can do in the spec file to tell rpmbuild that libevent 2.1.11 provides the necessary libevent.2.1.so.7. I think adding the corresponding "Provides:" in the libevent spec file might work, but I don't have the file.

I did remove all pre-existing libevent packages before installing the latest one.

pamoedo's picture

It's strange, it makes no sense to have "libevent-2.1.so.7" as requisite.

I have never compiled directly on the phone, I always use the VM that comes with the SFOS SDK to make the cross-compiling.

Kabouik's picture

I investigated and checked older libevent packages on OBS. I found that they explicitly list "Provides: libevent-2.0.so.*". I didn't know if that was the case for your package with the equivalent 2.1.so.*, so I figured I should just try.

I built a new libevent-2.1.11 on OBS using the latest stable libevent tarball, and explicitly listed "Provides:" as other OBS packages did before. Then I added this libevent 2.1.11 update on my Openrepos repository. I tried again installing tmux from Openrepos, and this time it could find the required dependency in this new libevent package, and succeeded upgrading libevent and installing tmux.

I made sure this updated libevent package is compatible with your telegram-cli package, so I think we can both update our repository with this new libevent rpm, which you can find here: http://repo.merproject.org/obs//home:/kabouik/sailfish_latest_armv7hl/ar.... This should solve all incompatibily issues between our packages and dependencies.

I noticed however that your version was larger (2 MB), did you include some extra files in the package?

pamoedo's picture

Thanks for the info, I have checked your rpm "provides" list and uploaded a new verion of my libevent package with something very similar:

$ rpm -qp libevent-2.1.11-2.armv7hl.rpm --provides
libevent = 2.1.11-2
libevent(armv7hl-32) = 2.1.11-2
libevent-2.1.so.7
libevent_core-2.1.so.7
libevent_extra-2.1.so.7
libevent_pthreads-2.1.so.7

I think this will solve any cross-repo reference that could happen if someone installs first my libevent package and your tmux after.

I will take a look (when I have time) to double check why the pkgconfig specs is not working as expected, maybe the VM sandbox lacks some libtool.

Regarding the size, I think is because I create the packages using the whole sources installation of the library, including the headers if present, you can take a look at the contents of my package with the following command if needed:

$ rpm2cpio <package> | cpio -idmv

Regards.