Need package maintainers

[gnunn1]

I'm currently maintaining the Arch package for Terminix but would like to hand it over to someone else so I can concentrate on development. If you use Arch and have experience maintaining a package and are interested in taking this on feel free to let me know.

Additionally, as per the suggestion below package maintainers for other distros would certainly be welcome.

[bilelmoussaoui]

Would love to have a copr repo for fedora too! 👍

[gnunn1]

I'm now also maintaining packages for Fedora 23 and CentOS 7 on the openSUSE Build Service (OBS) thanks to the generosity of Asif Ali Rizvan for putting together the necessary spec file. However, like the Arch package I'd prefer to transition this to someone else so I can concentrate on development.

[dsboger-zz]

I'm trying to create an AUR package terminix-git and build the git master in arch, but I'm having some trouble.

I installed dub and dmd from the official repos, then I run dub build --build=release, as indicated in the README.md. Everything seems to compile and link fine. I created a PKGBUILD and it installs identically to the current terminix package, but when I try to run $ terminix it crashes with the following message:

object.Exception@../../../../../.dub/packages/gtk-d-3.2.1/src/gtkc/Loader.d(123): Library load failed: libvte2_91.so

Any clues?

Edit: once I manage to create a stable terminix-git package, I can take over terminix also.

[gnunn1]

There hasn't been a release of GtkD yet with the two patches you would need. One fixes the libvte library name and the other fixes a serious memory issue. I've been building Terminix off of a local git version of GtkD, hence why if you look at dub.json the dependency references a specific commit.

To make the build work, you would need to clone the GtkD git repository and then use dub to add it as a local repository. I don't this would be very practicable at this point in time. It's probably best to just wait for GtkD to do a new release.

On another note, any interest in taking over the terminix AUR package from me?

[gnunn1]

Oops ignore my last sentence, didn't see your offer at the end :)

[dsboger-zz]

Ok, waiting for the fixed GtkD release.

[dsboger-zz]

AUR package terminix-git is alive and running (well, works for me anyway). You can transfer terminix to me also (I don't know exactly how to do that, but I think you can disown it and then I take it?). I'll adapt my compile-from-source PKGBUILD, ok? Also, I'll tentativelly enable i686 architecture, but I cannot test it. Is there any special differences in the build process for that?

[gnunn1]

That's great, thanks for doing this. I'm out for a few hours but when I
get home I'll see what it's involved with transferring the package.

For the i686 probably best not to enable it as I'm not planning on
supporting it at this time as per the FAQ. If someone wants to take on 32
bit and can support it with patches and fixes I'd consider it but at this
point people could report bugs against it and I would be ignoring them
which isn't a great situation.

Cheers,

Gerald
On 23 Jan 2016 12:13 p.m., "dsboger" notifications@github.com wrote:

AUR package terminix-git is alive and running (well, works for me
anyway). You can transfer terminix to me also (I don't know exactly how
to do that, but I think you can disown it and then I take it?). I'll adapt
my compile-from-source PKGBUILD, ok? Also, I'll tentativelly enable i686
architecture, but I cannot test it. Is there any special differences in the
build process for that?

—
Reply to this email directly or view it on GitHub
#25 (comment).

[dsboger-zz]

Ok, understood, i686 removed from terminix-git.

[gnunn1]

I've added you as a co-maintainer for terminix so you should be able to manage the package from now on, I can't see how to drop my status as maintainer and have you take over though. I'll google some more if needed ask in the forums about this.

[dsboger-zz]

Would you like to keep the binary distribution in AUR, or can I replace the current PKGBUILD with a build-from-source one? I could create a new package terminix-bin for the binary distribution, if you want.

[gnunn1]

I'd prefer binary myself, otherwise wouldn't the user have to install of
cruft on their system to do a from source build like the dmd package and
dub? Additionally, it also facilitates things if I ever to manually patch
libraries again like GtkD. Personally I'd prefer to keep the terminix
package and just get it assigned to you, is the -bin style common on Arch,
I just checked the packages I have and didn't see any.

I just googled for 'transfer AUR package' and apparently the word transfer
was the package was the key, all I have to do is disown the the package and
you will become the official maintainer, is that alright with you?

https://bbs.archlinux.org/viewtopic.php?id=199613

On Sat, Jan 23, 2016 at 7:30 PM, dsboger notifications@github.com wrote:

Would you like to keep the binary distribution in AUR, or can I replace
the current PKGBUILD with a build-from-source one? I could create a new
package terminix-bin for the binary distribution, if you want.

—
Reply to this email directly or view it on GitHub
#25 (comment).

[dsboger-zz]

Ok, no problem! That means you will continue to provide binaries same as of now? The -bin was intended as disambiguation in case we had both. Personally, I'm used to building AUR packages from source, or installing from binaries, no preferences.

It's alright.

[gnunn1]

Yes, I will continue to do releases on github with the binaries pre-built just as I do now. I'll go ahead and dis-own the terminix package, hopefully this works.

[gnunn1]

That was easy, it worked fine, you are now the maintainer so congratulations. :)

[gnunn1]

Package maintainers please be aware that the next release will include localization, this means copying mo files to /usr/share/locale when installing terminix. As per now, the release archive will have all the mo files in the right location so hopefully it's easy to get things installed correctly. There will be a an english mo file (en.mo) and hopefully one other language to handle.

[gnunn1]

Just one more FYI, I'm including the nautilus "Open in Terminix" extension in tonite's release which will create a dependency on the package libnautilus-extension in Arch. I would suggest making this an optional dependency in case people don't have Nautilus installed. The py file can still be installed with no ill effect.

[luisdavim]

Are there any deb packages available?
A PPA would be great.

[gnunn1]

Not that I am aware of, if you want to create one that'd be great.

[edubxb]

I tried to build a DEB package (in Debian Testing) with no success, if finally I can build a functional package, I will try to keep it up to date.

[carlwgeorge]

Creating a proper Makefile would be very beneficial to packagers.

[gnunn1]

Unfortunately I'm not very knowledgeable of make as none of the programming toolchains I use (Java and D) really make much use of it.

[dsboger-zz]

I'd like to point that the library needed for the "Open Terminix Here" nautilus extension is actually python2-nautilus (in Arch, at least), and not libnautilus-extension, as stated above.

[gnunn1]

dsboger, I made a mistake and accidentally uploaded an old version of terminix rather then the current 0.50.0 one. Can you please update the package signature and bump the minor version number to trigger an update. My apologies about this.

[dsboger-zz]

Done.

[Conan-Kudo]

@gnunn1 To bounce off of @carlwgeorge's point, I can't make a Fedora package for this because of the lack of a Makefile or a CMake script or something else that can build this package from source. Unfortunately dub is not available in Fedora yet, though it is undergoing review.

[gnunn1]

I've pushed 1.30 as a stable release.

[ximion]

@Dicebot That would already be very helpful!

[ximion]

@debian derivatives: LDC is now fully working in Debian (testing/unstable), so you can grab version 1:1.1.0+b3-1 or any later version (check https://tracker.debian.org/pkg/ldc ) and build Terminix with it. The packages in Debian are a bit out of date at time though.

[gnunn1]

@dsboger I noticed that the vte3-notification and vte-common-notification packages in AUR has been orphaned. I've been personally using these packages as a way to get notification support in Terminix. I'm wondering if the time has come to create a vte3-terminix package that would contain the notification patch as well as the two other VTE patches I have that are required to support badges and triggers.

In an ideal world my patches would get upstreamed but I'm not overly optimistic about this happening in a timely fashion. The one needed to support triggers is very tactical at this point and frankly it's not suitable for upstream in it's current form. The other patch required to support badges has been submitted to upstream for consideration but even if accepted it will take a awhile to make it into a release version and available to users.

There is also a bit of a chicken and egg here, I'd like to get people using these features in order to test them out and validate what I give upstream is viable. For example, I don't want to invest the time in creating a strategic patch for triggers if testing shows there is a fundamental flaw with it but to do so it really needs to get in the hands of more users in order for that testing to occur.

So long story short, do you think it makes sense to have a vte3-terminix package and would you be interested in maintaining it? If so, I can put together an initial PKGBUILD for you as I've been building the vte3-notification package with my patches included for a couple of months now with no issues. Note that my patches are compatible with gnome-terminal and as far as I can tell do not impact other VTE based terminal emulators.

The other option I'm looking at is using flatpak to ship terminix and patched version of the VTE, unfortunately this is looking somewhat more complicated then I originally anticipated due to the restrictions placed by the flatpak sandbox model. While sandboxing makes perfect sense for most applications, it doesn't work for a terminal application and there are some code changes required to make it work.

[dsboger-zz]

@gnunn1 I've adopted vte3-notification in AUR, so that the "orphaned" status does not scare people away, but I'm not sure how well I'll be able to maintain it. I'm starting the vte3-terminix-git (stable vte3 + stable Fedora patches + terminix patches from git) PKGBUILD. I'm following the instructions in the README. I'll post here if I need help.

[gnunn1]

@dsboger Thanks, I'm happy to help as necessary,

Note that for the alternate-screen.patch to work with the fedora notification patch you need to make one change to the patch. There is a padding variable that is used to fill out the memory of a structure, as events get added the padding needs to be decremented. The current VTE source code has the padding set to 16. To apply both the fedora notification and alternate-screen patch and maintain gnome-terminal compatibility you need to tweak my alternate-screen patch.

In a nutshell, have the PKGBUILD apply the fedora notification patch before the alternate-screen patch. Then in the alternate-screen patch, change line 148 so that gpointer padding[16] becomes gpointer padding[15]. Then in line 149, decrement the padding again so that gpointer padding[15] becomes gpointer padding[14].

[dsboger-zz]

I've assembled a PKGBUILD with a quick and dirty sed command to make those changes to the patch. It seems to be good. I've tested a simple trigger and it is working. It seems these patches also enable the badges feature, but I could not find documentation on what is that feature, so I don't know how to test it. Also, is there any other thing to test from the patches in order to see if the package can be released?

[gnunn1]

The badges feature can be set on the Profile preferences page on the General tab right under the terminal title as per the screenshot below.

You can also run terminix --version which will indicate which special features are active or not, for example:

terminix --version
Versions
    Terminix version: 1.3.5b
    VTE version: 0:46
    GTK Version: 3.22.2

Terminix Special Features
    Notifications enabled=1
    Triggers enabled=1
    Badges enabled=1

The only other thing I would suggest testing is making sure that gnome-terminal still works fine using this new vte package.

[gnunn1]

And I guess I should explain what a badge is. This is is a block of text that appears in one of the corners of the terminal and can be used to display additional information. It is cribbed from the identically named iterm2 feature here https://www.iterm2.com/documentation-badges.html.

I'll write up a wiki entry for it this weekend.

[dsboger-zz]

I just created AUR packages for vte3-terminix-git/vte-terminix-common-git. I'm using them right now, so they Work For Me® (but notice that I'm using terminix-git, not the stable release). Also, terminix --version output is:

Versions
    Terminix version: 1.3.5b
    VTE version: 0:46
    GTK Version: 3.22.2

Terminix Special Features
    Notifications enabled=1
    Triggers enabled=1
    Badges enabled=1

I've quickly tested notifications, badges and triggers and all seems to be fine. GNOME Terminal also Works For Me with the patched VTE, including notifications. I think it is ready for broader testing, but I'll wait a few days before making it a (optional?) dependency for terminix[-git].

To use it, just replace vte3[-notification] and vte[-notification]-common with vte3-terminix-git and vte-terminix-common-git.

@gnunn1 is it desirable to create a similar package for the current stable version of Terminix (so people could use triggers more easily in Arch)?

[gnunn1]

@dsboger I just tried the package, works very well for me as well. I like how you are getting the patches from git and fixing the alternate-screen patch with sed, I likely would have taken the easy way and just bundled a fixed version. Great job and really appreciate you taking care of this. I'll post about it on my google+ account to try to get the word out.

I think a stable version would be desirable but only as an optional dependency, I worry making it a mandatory dependency might scare people off from trying terminix. I'd also suggest waiting to create a stable version for a few weeks just to make sure any showstopping bugs get discovered, reported and fixed (hopefully!).

[egmontkob]

Hey guys,

Does anyone here know how to compile Terminix on 16.10 (yakkety) (or get a precompiled version somewhere)? I totally failed so far (see #507). Thanks in advance!

[egmontkob]

Oh, nevermind. I figured out 17.04 (zesty) beta already contains a terminix package, and it (along with its few dependencies: libphobos2-ldc71, libgtkd-3-0 and libvted-3-0) installs and works fine on yakkety. This is good enough for me right now :)

[gnunn1]

I've updated the version tag to 1.4.0-beta as I'm planning on pushing out a new release in the next week or so. Testing and localization updates would be very much appreciated.

[gnunn1]

Just an FYI that all future releases will be compiled with LDC instead of DMD to align with what the various linux distros are doing.

[gnunn1]

I'm going to close this off, I think this has gotten long enough and served it's purpose.

[bilelmoussaoui]

Hello, guys(packages maintainers). Can you please ping me whenever you update the package to the new name? So,I can update the website too. Thanks and have a great weekend

[ivoarch]

@bil-elmoussaoui
You can remove CentOS 7.x package from the list . Since version 1.5.x the Epel builds are broken .
These packages do not exist for CentOS-7 on Epel - ldc-druntime , ldc-phobos .

Error: Package: terminix-1.5.2-2.el7.x86_64 (/terminix-1.5.2-2.el7.x86_64)
           Requires: libphobos2-ldc.so.71()(64bit)
Error: Package: terminix-1.5.2-1.el7.sos.x86_64 (/terminix-1.5.2-2.el7.x86_64)
           Requires: libdruntime-ldc.so.71()(64bit)
Error: Package: terminix-1.5.2-1.el7.sos.x86_64 (/terminix-1.5.2-2.el7.x86_64)
           Requires: ldc-druntime
 You could try using --skip-broken to work around the problem

[bilelmoussaoui]

Alright! i will hide the package from the website until a new update

[hotice]

@bil-elmoussaoui but isn't the binary resulted from the new package still going to be called "terminix"? I think we need to wait for a new version to be released which includes the new name everywhere.

[gnunn1]

@hotice is correct, there's not point re-naming packages until a Tilix release is available. I'm hoping to push out a Tilix package this weekend. It will obviously include the name change, a couple of minor fixes and address the issue that is preventing the Fedora COPR package from working.

[ximion]

Debian has Tilix now and it will be present in the next Ubuntu release as well: https://packages.debian.org/sid/tilix

Renaming the package in our current soon-to-be-released Debian 9 release will unfortunately not be possible, or be very unlikely to happen, as the rename is accompanied by a lot of feature changes.

Tilix is not available for all architectures yet because we are hit by an elusive LDC bug which will highly likely affect other distributions building Tilix from source as well: ldc-developers/ldc#2022
At least amd64 users will automatically be upgraded to Tilix though, if they use Debian unstable.

[ivoarch]

EPEL Package for CentOS 7 via CORP .